Category: Programming

Posted on

Perl 5 to 6

Moritz Lenz has written a series of informative blog posts about Perl 6, for Perl 5 programmers. Here’s a bit of his introduction:

> Perl 6 is underdocumented. That’s no surprise, because (apart from the specification) writing a compiler for Perl 6 seems to be much more urgent than writing documentation that targets the user.

> Unfortunately that means that it’s not easy to learn Perl 6, and that you have to have a profound interest in Perl 6 to actually find the motivation to learn it from the specification, IRC channels or from the test suite.

> This project, which I’ll preliminary call “Perl 5 to 6” (in lack of a better name) attempts to fill that gap with a series of short articles.

[Read more…](http://perlgeek.de/blog-en/perl-5-to-6/)

Posted on

Fedora 9 and the OpenJDK

Java development is getting easier under Linux because of Sun’s OpenJDK, which linux distributors like Fedora now include. No more need to go through the hassle of downloading it from Sun. Here’s how I installed it.

yum install java-1.6.0-openjdk-devel java-1.6.0-openjdk-javadoc java-1.6.0-openjdk-plugin

A downside is that the default fonts in some Java applications, like IntelliJ IDEA, look terrible. Fedora 9 includes the RedHat Liberation fonts, which stand in for Microsoft fonts. I went into IDEA’s configuration, and changed the default font from “Arial” to “Liberation Sans”. IDEA’s visual appearance is nearly, but not completely, _fontastic_ compared to what it was before.

Posted on

Test-driven development in Perl

There’s an impressively in-depth presentation from [OSCON 2008](http://en.oreilly.com/oscon2008/public/schedule/proceedings) about [Practical Test Driven Development in Perl](http://assets.en.oreilly.com/1/event/12/Practical%20Test-driven%20Development%20Presentation.pdf). It covers Test::More, Test::Class, Test::Differences, Test::Deep and Test::MockObject.

I also found the following to be interesting: [Even Faster Web Sites](http://assets.en.oreilly.com/1/event/12/Even%20Faster%20Web%20Sites%20Presentation%202.ppt) and [Pro PostgreSQL](http://assets.en.oreilly.com/1/event/12/Pro%20PostgreSQL%20Presentation.odp). Reading these helps me to know a little bit about what I don’t know.

Posted on

Getting core dumps on RHEL/CentOS 4, 5, Fedora

Sometimes, it’s nice to get core files, system wide, on a RedHat, CentOS, or Fedora Linux system. Here’s how: [http://kbase.redhat.com/faq/FAQ_49_3652.shtm](http://kbase.redhat.com/faq/FAQ_49_3652.shtm)

The “[core manpage](http://linux.die.net/man/5/core)” is also useful, in particular, the bit about /proc/sys/kernel/core_pattern.

Posted on

Git underwhelms

I work on source code from two separate SVN
repositories. One of them is geographically remote. Working with the remote server is slow for ‘log’, ‘diff -r’, ‘blame’, etc. Due to my interest in distributed version control, and my desire for faster repository access, I decided to try git and git-svn. Doing ‘log’, ‘diff’, etc. with a local git repo is much faster, but on the whole, working in a git repo created with git-svn has been difficult and unrewarding. Perhaps it would be easier if others at my company were using git-svn and we could share ideas. Working with git and git-svn requires learning a new workflow, and I haven’t yet reached enlightenment.

Challenges with Git:

  • The Git Wiki is often out-of-date and/or incomplete (submodule support, for example).
  • No Nautilus, Konquerer, or Windows Explorer integration.
  • No KDevelop itegration.
  • git-gui should:
  • let me double-click on files listed in either “Staged Changes” or “Unstaged Changes” to edit the file. Or let me right-click and choose an “edit” option.
  • Let me use an external diff program such as meld or kdiff3. git-gui should let me set this up and use it. qgit has an external diff option (defaults to kompare), but it doesn’t use the working copy on the right hand side, so it’s not possible to use the diff tool to change the working copy file.

Challenges with Git-SVN: (More complicated to use than Subversion)

  • Two stage commit instead of single stage. ‘git commit’, ‘git-svn dcommit’
  • Error messages are cryptic, so I don’t know how to resolve the errors.
  • git-svn rebase doesn’t merge changes from upstream Subversion server into my working copy, and git-svn doesn’t tell me what workflow I should be using. So I ran git-svn fetch to pull upstream Subversion changes. Then I ran git-gui and chose Merge->Local. It told me something helpful. “You are in the middle of a change. File X is modified. You should complete the current commit before starting the merge. Doing so will help you abort a failed merge, should the need arise.” “git-svn rebase” should have told me
    the same thing.

Reasons to continue with Subversion:

  • Workflow is easier, less complex — perhaps because I’m used to it.
  • Windows Explorer integration via TortiseSVN.
  • IDE integration. Nearly every IDE supports or has a pluging for Subversion.
  • svnmerge.py gives me cherry-picking support (between branches within the same repository)
  • svnmerge.py remembers merges, so I don’t have to resolve the same
    conflicts twice.
  • I don’t need disconnected operation in my workplace.

I hope that in a year, Git, git-svn and developer tool integration will be more mature and thus rewarding to use. With the rapid development I see happening, it wouldn’t be surprising.

I will continue to use git-svn. It gives me the speed I need for working with log history, annotate and diff.

Update: I’ve come across Git for Computer Scientists, and seeing the pretty graphs leads me to believe that working with git requires an understanding of how git works.

Posted on

Article: The Pillars of Concurrency

[The Pillars of Concurrency](http://www.ddj.com/dept/64bit/200001985), July 02, 2007 by Herb Sutter

“In his inaugural column, Herb makes the case that we must build a
consistent mental model before talking about concurrency.
Herb is a software architect at Microsoft and chair of the ISO C++
Standards committee.”

* Pillar 1: Responsiveness and Isolation Via Asynchronous Agents
* Pillar 2: Throughput and Scalability Via Concurrent Collections
* Pillar 3: Consistency Via Safely Shared Resources
* Composability: More Than The Sum of the Parts

Posted on

Ubiquitous Version Control and the future of Subversion

Mantra: “[Version control must become ubiquitous](http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=128193)” — Branko Čibej

Subversion developers are gradually leaning toward distributed version control techniques [[1]](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128301), [[2]](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128301). However, they don’t want users to have to know it’s distributed. They don’t want users to know they’re even using version control. Lawyers, architectes, etc. all need version control, and often, they don’t even know that it’s possible. It also needs to be easy to do text searches on commit history.

> We do need to recognize that users are not interested in becoming version control experts, and we need to pay close attention to what they actually want, as opposed to what experts might want them to want.

> The reason Subversion is taking over the world is because it is tremendously
user-focused, and because it provides well-documented APIs that enable other
developers to write software on top of Subversion. We should copy what
we need from the decentralized systems, but remember that most users don’t know
or care whether a system is centralized or decentralized — their ideal system
is one they don’t notice. — [Karl Vogel](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128111)

Apparently, users really like the ability to “lock” files in the repository. How does that work with distributed version control? I don’t know.

[Eric Raymond praised the Subversion developers](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128106), although he believes the future lies in distributed systems like Mercurial.

Karl Fogel [replies to this and to Linus Torvald’s criticisms of Subversion](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128111). He does a great job of summarizing Linus’s talk on Git, and the things people want to do with version control:

> For many organizations, including open source projects, centralization is a
feature: you want changes (and branches) to end up in the master repository
sooner rather than later, so they’ll be visible to everyone, so they’ll be
backed up, so they’ll go through the central hook system, etc. It
focuses the community on a shared object (Ben Collins-Sussman makes this argument in
more detail at [http://blog.red-bean.com/sussman/?p=20](http://blog.red-bean.com/sussman/?p=20)).”

> A general tool configured to behave in a specific way is never quite
as natural to use as a tool designed for that specific use in the
first place. In other words, Subversion can — will have to — take
on some of the features of decentralized VC systems, but it will never
be as good a decentralized system as they are. By the same token, a
decentralized system can be configured to work like a centralized one,
but will never be as good at it as Subversion is.”

Individual [.svn dirs may go away](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128148), along with the ability to move a
subdirectory from a checkout somewhere else and have it still work. The reason? Better performance.

Posted on

glibc malloc hooks and TLSF

Recently, I was asked to constrain the memory usage of an application on Linux. Glibc provides hooks for [malloc, free, etc](http://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html). By the way, the hook functions are responsible to guarantee thread safety — glibc doesn’t do it automatically. I used the malloc hooks in combination with a memory manager that a colleague found: TLSF. There are two implementations:

* [http://tlsf.baisoku.org/](http://tlsf.baisoku.org/) (public domain)
* [http://rtportal.upv.es/rtmalloc/](http://rtportal.upv.es/rtmalloc/) (GPL)

There are benefits and caveats when using a custom memory allocator. TLSF was meant to shine for real-time use, because the overhead of malloc and free are O(1) constant-time operations. On the other hand, TLSF isn’t thread-safe.