lunatechian (lunatech-ian)

knowing you can still understand output from diff, even though it has been months you touched any code.

I tried installing linux on my SO's (significant other) laptop today. WHAT IS WRONG WITH UBUNTU!! It takes ages to load up and the install process is resource intensive enough to make the laptop totally unresponsive. Finally installed Fedora and I am not happy with it. I will install debian for her, once I find out where to get blank CD here.

I saw this mail in one of the mailing lists I am on and thought it might be useful to a wider audience. This reply was given by Ben Finney

   I have some ambitious plans for enhancing the module, but I feel
   that it won't be practical to do it in the current conditions. I
   tried to soft-talk the maintainer into giving me repository access,
   but then the conversation got diverted into applying my latest
   patch, which he said he'd like to perform the next day. He didn't
   and it's been at least two weeks since then.

Since you talk about asking for “commit access”, I presume it's in an old-school centralised-only VCS. I'll assume Subversion.

What are your thoughts about a situation like this?

Use a distributed VCS to track your changes. I prefer Bazaar, so I'll discuss that below.

• Use Debian GNU/Linux, ‘lenny’ or later.
• Install the necessary packages: $ sudo aptitude install bzr bzrtools bzr-svn svn
• Get a local Bazaar checkout of the upstream Subversion branch so you can track upstream's changes discretely and easily: $ bzr checkout svn+ssh://vcs.example.org/foo/trunk/ foo.trunk/
• Bazaar uses the ‘bzr-svn’ plugin to work with Subversion repositories. It has its foibles, especially with writing to Subversion repositories; but for tracking an upstream Subversion repository against your Bazaar-managed branches, it's excellent.
• Branch from upstream so you can track your changes: $ bzr branch foo.trunk/ foo.interesting-new-feature/
• Work on your interesting new feature, committing often:

    $ cd foo.interesting-new-feature/
    $ emacs spam.py  # hack hack hack
    $ make test  # or however you run your full test suite
    $ bzr commit --message "One-line description"

• When upstream has new revisions in their repository, update your checkout:

    $ cd foo.trunk/
    $ bzr update

• When you want to send a patch of your current work against upstream, generate a Bazaar “merge directive” (a patch bundle):

    $ cd foo.interesting-new-feature/
    $ bzr send --output ../foo.interesting-new-feature.patch --no-bundle

• This makes a patch against the parent of the current branch (by default, since no other branch is specified), which is the ?foo.trunk/? branch you originally branched from. The --no-bundle option turns off the ?patch bundle? blob, which would be useful to a Bazaar-using remote user to merge the resulting patch and have identical revisions to you. Since you'll be sending it to a Subversion user, that blob won't be useful to them so we disable it.
• Send the ‘foo.interesting-new-feature.patch’ file to upstream attached to an email message that explains what the changes are.

The Bazaar documentation, both online at <http://bazaar-vcs.org/> and in the bzr help foo commands, is comprehensive and should fill the many gaps I've no doubt left from the above explanation.

I am using a Mac now, and this blog post is brought to you by the same php and lisp scripts that I was using on my linux box. Cheers!

Have you read the man malloc page recently? Did you notice this section there

Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.

So, you can do export MALLOC_CHECK_=1 and malloc will print debugging messages to the stderr.

If you want to check what compile options were used to build the emacs, check the value of the variable system-configuration-options in emacs. i.e. C-h-v system-configuration-options

In my case, it is `—with-x-toolkit=gtk' '—with-xft=yes' '—prefix=/home/rshekhar/fakeroot/'`

Check out SpaceGlow joomla template by Bernard Esterhuyse. It is nice, however, more importantly, it is GPL-ed. I have been checking put a lot of joomla templates for my site, but all the joomla templates that I came across shared an important defect. Even though the template authors mentioned that the template was GPL-ed, they usually had a link to their own sites in the template, along with the request (or order), not to remove that line.

The Spaceglow template is really GPL-ed. This will allow me to hack it up further.