Space Station Lambda

I still enjoy work with Mercurial more, although git has grown a lot better in the last few years.

In the last few days I especially noticed that hg is faster for me than git (even after repack of the git repository).

That said, git has some very cool features that are missing in Mercurial.
Two of them are local branches (helpful for feature development or bug isolation) and the stash command that lets you stash away local changes for later (sort of a simplified patch queue).

Fortunately there are two extensions that provide both local branching and stash functionality.

Localbranches extension

Wiki page

http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches

Repository

http://hg.kublai.com/mercurial/extensions/localbranch

Shelve extension

Wiki page

http://www.selenic.com/mercurial/wiki/index.cgi/ShelveExtension

Repository

http://freehg.org/u/tksoh/hgshelve/

Installation

To use an extension just clone the repository and put the following line into the [extensions] section of your hgrc (create file and section if necessary):

EXTNAME=/path/to/EXTNAME.py

Usage examples are on the wiki pages.

Happy hacking!

Comments(0)

The CLHS says the following about DEFPACKAGE:

If the new definition is at variance with the current state of that package, the consequences are undefined; an implementation might choose to modify the existing package to reflect the new definition.

SBCL opts to modify the package but throws a warning, most often in the form of “PACKAGE also exports the following symbols: …”.

Luckily the warning is a specific one, i.e. SB-INT:PACKAGE-AT-VARIANCE.

So to get rid of the warning the following macro helps:

(defmacro without-package-variance-warnings (&body body)
  `(eval-when (:compile-toplevel :load-toplevel :execute)
     (handler-bind (#+sbcl(sb-int:package-at-variance #'muffle-warning))
       ,@body)))

Apply sparsely.

We need the EVAL-WHEN to ensure that the non-toplevel definition of the package is available at compile time.

There’s a minor catch here. One might be tempted to put the EVAL-WHEN clause inside the HANDLER-BIND. But this leads to the package not being available at compile time (therefore rendering the EVAL-WHEN ineffective) because “the compile-time side effects described in Section 3.2 (Compilation) only take place when eval-when appears as a top level form.” (CLHS on EVAL-WHEN).

Does anyone know how to muffle these redefinition warnings in other implementations?

Comments(0)