blog/archives/2008/10zack's home pagehttp://upsilon.cc/~zack/blog/archives/2008/10/zack's home pageikiwiki2009-11-28T12:00:16Zdebcheckout hackinghttp://upsilon.cc/~zack/blog/posts/2008/10/debcheckout_hacking/2009-11-28T12:00:16Z2008-10-31T00:31:47Z
<h1>New features for debcheckout, ... now with TopGit support!</h1>
<p>Today I've spent some time hacking on <a href=
"http://upsilon.cc/~zack/blog/posts/2007/08/debcheckout/">debcheckout</a>,
which for weird reasons happens to be at the bottom of a stack of
chained things that I need to do in the forthcoming days. Also, I
had neglected <code>debcheckout</code> for a while, and the other
<a href="http://packages.debian.org/devscripts">devscripts</a>
folks where ready to shout at me because of that <img src=
"http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /> .</p>
<p>Well, it has been fun, and beside having fixed all the
outstanding bugs, <code>debcheckout</code> has grown some cute new
features:</p>
<ul>
<li>
<p>the ability to <strong>query a VCS repository</strong> (using
<code>-d</code>/<code>--details</code>) for details, at the very
minimum it will parse for you the <code>Vcs-*</code> fields, but it
is expected that in the future will be able to be more telling, and
it is already so for <a href=
"http://repo.or.cz/w/topgit.git">TopGit</a> ...</p>
</li>
<li>
<p>... and speaking about that, debcheckout now has <strong>support
for TopGit</strong>. In two ways: the first one is using
<code>-d</code>, which will tell you whether a GIT repo is
TopGit-enabled or not and, if it is so, also the <em>list of
available top-bases</em>. For instance:</p>
<pre><code> zack@usha:~$ debcheckout -d topgit
type git
url git://git.debian.org/git/collab-maint/topgit.git
top-bases debian/locations
topgit yes
</code></pre>
<p>or even more brutally</p>
<pre><code> zack@usha:~$ debcheckout -d git://git.debian.org/git/pkg-ocaml-maint/packages/ocaml-batteries.git
type git
url git://git.debian.org/git/pkg-ocaml-maint/packages/ocaml-batteries.git
top-bases features/flexi-build
topgit yes
</code></pre>
<p>The other way in which TopGit is supported, is that when
checking out a GIT repo which is detected to be TopGit's as well,
population of top-bases (i.e., <em>TopGit local
initialization</em>) is automatically performed.</p>
<p>... yes, a while ago I've fallen in love with TopGit, is it
<em>that</em> evident? <img src="http://upsilon.cc/~zack/smileys/smile.png"
alt=":-)" /></p>
</li>
<li>
<p>it is now possible to specify <strong>custom rules for
authenticated mode</strong>, this way you can use <code>-a</code>
also on packages not hosted on well known Debian/Ubuntu VCS
servers</p>
</li>
<li>
<p>finally, you can now ask <code>debcheckout</code> to
automatically enable <strong>remote tracking of remote GIT
branches</strong>, which is usually what a maintainer wants to do
when doing a fresh checkout</p>
</li>
</ul>
<p>Enjoy!</p>
<p><small>(ah, of course all this is not uploaded yet, but you can
grab a <a href=
"http://svn.debian.org/viewsvn/devscripts/trunk/scripts/debcheckout.pl?rev=HEAD&view=log">
preview</a> from devscripts' VCS or, better, doing
<code>debcheckout devscripts</code> which is soooo bootstrapy.
SCNR.)</small></p>
releasing yummy cookieshttp://upsilon.cc/~zack/blog/posts/2008/10/releasing_yummy_cookies/2009-11-28T12:00:16Z2008-10-28T09:02:55Z
<h1>Cookies, bugs, and releases</h1>
<p><a href="http://www.perrier.eu.org/weblog/">Christian</a> knows
how to be very inspiring and provocative with his blog posts, the
<a href=
"http://www.perrier.eu.org/weblog/2008/10/24#apt-bug-triaging">APT
case</a> is a very good example of how useful that can be. I
believe <a href=
"http://www.perrier.eu.org/weblog/2008/10/27#releasing">today's
post</a> is yet another example of that, many thanks Bubulle!</p>
<p>Still, I stopped believing in the incompatibilities among having
discussions (possibly heavy, possibly flamish) and releasing. Fact
is:</p>
<ul>
<li>
<p>I've been participating in the <code>-project</code> discussion
about Debian membership. The reason why I did that is that I firmly
believe we need to open up Debian to non-technical (or at least
non-packager) contributors. We have been wishing that for years, no
matter if/how flawed was the initial proposal, keeping the ball
rolling on that aspect is very important for our project, possibly
more than releasing ...</p>
</li>
<li>
<p>... nevertheless, this did not inhibit me from taking part in
the wonderful idea of the <a href=
"http://wiki.debian.org/BugSprint">BugSprint</a> game. In fact, I
also think that I deserve some cookies, but I'm waiting to see how
Joss will determine the first 5 winners <img src=
"http://upsilon.cc/~zack/smileys/smile.png" alt=":)" /></p>
</li>
<li>
<p><small>(and no, I did not gave up my job either :), I've been
following the discussion on <code>-project</code> like 1 hour per
night for a couple of random nights last week, and playing the
BugSprint some hours during the past week-end)</small></p>
</li>
</ul>
<p>The BugSprint has been anticipated well before the inflamatory
membership reform proposal, and repeatedly advertised by Joss in
various ways (kudos). Still the participation has been way too low.
That has nothing to do with other "distractions".</p>
from Vim to Emacs - part 1http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/2009-11-28T12:00:16Z2008-10-23T07:24:26Z
<h1>One month with Emacs and counting - Part 1</h1>
<div class="notebox">
<p>other posts in the <em>from Vim to Emacs series</em>:
<span title="Flawed Vim design decisions"><strong><a href=
"http://upsilon.cc/~zack/blog/posts/2008/11/from_Vim_to_Emacs_-_part_2/">
part 2</a></strong></span></p>
</div>
<p>Straight to the point: <strong>since mid September I've been
using <a href=
"http://www.gnu.org/software/emacs/">Emacs</a></strong>, trying to
evaluate whether I was willing to switch from <a href=
"http://www.vim.org">Vim</a> to it.</p>
<p>Yup, that's true, me (user of Vim since the day I've started
using GNU/Linux 10 years ago, (not so) active <a href=
"http://alioth.debian.org/projects/pkg-vim/">maintainer in Debian
of <code>vim</code> and related packages</a>, author of some
popular Vim extensions and of <a href=
"http://packages.debian.org/sid/vim-addon-manager"><code>vim-addon-manager</code></a>)
it's considering switching to Emacs. What is worse is that
<strong>I've de facto already switched</strong>. May <a href=
"http://alioth.debian.org/users/jamessan/">jamessan</a> forgive
me.</p>
<p>OK, that was the hardest part to write, now ...</p>
<p>This choice will have an impact on me: partly because I'm quite
sure several fellow DDs will start making fun of this story
<img src="http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /> , and partly
because as many geeks I've always had strong opinions on <a href=
"http://en.wikipedia.org/wiki/Editor_war">the editor war</a>.
Switching side ain't easy.</p>
<p>Hence, I've decided to write a small (2-3) series of blog posts
on the issue, to future memory. The post you are reading is about
<em>why, since a few months ago, I wasn't willing to give Emacs a
try, and how I've changed my mind</em>.</p>
<h2>Why I wasn't willing to give Emacs a try, but then changed my
mind</h2>
<p>I love knowing tools which can improve my workflow, no matter
the task. Editors happen to be at the intersection of many tasks,
hence <em>knowing well</em> his own editor and <em>feeling
satisfied about it</em> is quite important. This is even more so
for free software hackers which, for a reason or another, happen to
use the very same editor for a lot of different tasks; in my case:
programming, conf file hacking (i.e., playing the sysadm role),
mail writing, and everything in between.</p>
<p>I've started using <code>vi</code> on Solaris around 1998, then
switched to Vim starting from version 4.0, and then followed all
its releases up to 7.0. I consider my "Vim karma" to be quite hight
and I've delivered several talks about using Vim for LUGs and other
free software-related events. Still, I've always been hit bit
several minor nuisances and glitches of Vim which couldn't be fixed
by simple configuration tuning or add-on implementations (more on
this in a future post).</p>
<p>In the quest for the perfect workflow, those glitches have made
me try several times other editors hoping for more satisfying work
environments. Of course Emacs was one of them, which I've tried
repeatedly during the years; the last time was circa 2006.</p>
<p>For one reason or another, after a few days of experiments, I've
always decided to give up with it. Why? Various reasons, listed
below, together with an explanation of what (I think) has changed
since then.</p>
<ol>
<li>
<p><strong>Poor Unicode/multibyte support.</strong> Support for
whatever Unicode encoding was close to null. It was not available
in the legacy editor, and you had to use something called MULE, to
be specifically enabled. That was so 60's, and rather hard to
use.</p>
<p>Now (<a href=
"http://en.wikipedia.org/wiki/Emacs#Release_history">apparently
starting from Emacs 22.1</a>, June 2007) finally you have built-in
Unicode support and the needed two variables for setting the input
encoding and the file encoding, which is basically all you need.
Looks easy once you have it ...</p>
</li>
<li>
<p><strong>Lack of "modern" UI toolkit support.</strong> Yes, I do
live in a console and invoke my editor from it, but nevertheless
for long coding sessions I do also love having a nice GTK+ window
containing my editor using settings which smoothly integrated with
the graphical settings of my desktop environment. Maybe I'm getting
old, maybe GNOME has changed my perceptions, but why the heck I had
to tolerate different monospace fonts in my
<code>gnome-terminal</code> wrt my GUI editor I never understood.
Firing up Emacs was like getting back in time of 15 years, and if a
geek having a maximized terminal on most of its workspaces had this
feeling, then something was really wrong.</p>
<p>This has changed: starting again from Emacs 22.1, the editor has
frown support for that "bleeding edge" technology called GTK+.
Finally you can use Pango font faces and avoid the time travel
feeling when switching from a terminal to your GUI.</p>
</li>
<li>
<p><strong>"Dead upstream" syndrome.</strong> As we all know by
experience, choosing a free software product is not only a matter
of evaluating bugs and features, there are other environmental
factors. A notable example is how active upstream is. A few of us
will use a product affected by the "dead upstream" syndrome. That's
exactly what I was feeling about Emacs. The first argument I can
offer to back that feeling is again the <a href=
"http://en.wikipedia.org/wiki/GNU_Emacs#Release_history">Emacs
release history</a> (noted that "small" hole between 2001 and 2007?
Rest In Peace <q>release early, release often</q> ...).</p>
<p>The second argument is the bug tracking system: there was none,
bug discussions happened only on the development mailing list and
the bug tracker was a text file on CVS! (Yes, Vim doesn't have a
proper BTS either, but I was looking for reasons to switch from it
and hence looking for something better in several respects.)</p>
<p>That has changed completely, as I discovered only at <a href=
"http://debconf8.debconf.org">this year DebConf</a> thanks to
<a href="http://luca.pca.it/">gismo</a>. 2007 has enjoyed 1 Emacs
release and 2008 already two. They do have <a href=
"http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacs">
a BTS now</a> and guess what? is dear old <a href=
"http://bugs.debian.org">debbugs</a>. According to my first
experiences as Emacs bug reported the maintainers are very reactive
and also friendly in dealing with bug reporters. Finally, also
keeping up with snapshot releases in Debian is entirely trivial,
thanks to <a href="http://emacs.orebokech.com/">Romain's
repository</a>.</p>
</li>
<li>
<p><strong>Poor performances & memory consumption.</strong>
This goes in the direction of probably the most popular joke used
by Vim zealots in the editor war: <q>Emacs is a nice operating
system, but lacks a good editor</q>, or something such.</p>
<p>In the past I had the impression that starting Emacs was really
slow and that generally the memory footprint was too high to be
acceptable. You know what: starting a <a href=
"http://packages.debian.org/sid/vim-full">full-blown</a>
<code>gvim</code> with a good deals of add-ons (and I used quite a
lot of them, that's why <a href=
"http://packages.debian.org/sid/vim-addon-manager"><code>vim-addon-manager</code></a>
was born) is not that faster. And on the contrary, firing up an
<a href=
"http://www.emacswiki.org/emacs/EmacsClient"><code>emacsclient</code></a>
is way <em>faster</em> than starting up a new <code>gvim</code>
instance.</p>
<p>Regarding memory consumption Emacs is still "gaining" the
battle. Still, one has to keep in mind the different workflow: with
Vim you are encouraged to enter and exit the editor (not without
drawbacks, as I'll discuss in a future post), while with Emacs you
always use the same one. It turns out that via
<code>emacsclient</code> the resulting feeling is the same as
having multiple editors (as you can fire them up as separate
windows or in separate consoles), still sharing all user
memory.</p>
<p>A final comment on memory consumption while looking at my
<code>top</code> sorted by decreasing RSS memory: the top process
is xulrunner (from the browser) with 356Mb, then Xorg (159M),
pidgin (128Mb !!!!), trackerd, gnome-terminal, gnome-panel, ...,
Emacs shows up with 51 Mb at the 7th position. Yes, it is not the
thinnest editor in the world, but on average machine it doesn't
really matter <em>at all</em>.</p>
</li>
</ol>
signature zainohttp://upsilon.cc/~zack/blog/posts/2008/10/signature_zaino/2009-01-05T17:01:30Z2008-10-19T01:21:40Z
<h1>Signature, kudos to backpacks</h1>
<pre><code>Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right
uno zaino -- A.Bergonzoni \__/ keys at the right time -- J.S.Bach
</code></pre>
<p>Data la nuova signature, non posso esimermi dal citare: <q>di
zaini senza Zack se ne vedono tanti, ma di Zack senza zaini molto
pochi</q> (Giacomo).</p>
<p>Il vostro inviato da Nashville.</p>
ocaml batteries included debian packageshttp://upsilon.cc/~zack/blog/posts/2008/10/ocaml_batteries_included_debian_packages/2009-11-28T12:00:16Z2008-10-13T09:04:46Z
<h1>preview of OCaml batteries included Debian packages</h1>
<p><a href="http://batteries.forge.ocamlcore.org/"><strong>OCaml
batteries included</strong></a> is a wonderful community-driven
initiative to standardize the OCaml development platform. It is
similar to initiatives sharing the same motto, like <a href=
"http://www.haskell.org/haskellwiki/Haskell_Platform"><em>Haskell
batteries included</em></a> and <em>Python batteries included</em>
(which then has become the legacy Python distribution), but I have
always felt that OCaml was more desperately needing a similar
initiative.</p>
<p><a href=
"http://dutherenverseauborddelatable.wordpress.com/">David
Teller</a> and the OCaml batteries included team have been the
first actually doing something to address the frustration of many
otherwise enthusiastic OCaml developers.</p>
<p>A couple of days ago, their efforts have given birth to a first
milestone: the <a href=
"http://dutherenverseauborddelatable.wordpress.com/2008/10/11/ocaml-batteries-included-version-alpha/">
release of the first alpha version of batteries included</a>.</p>
<p>To help out, I've released as quickly as possible <strong>the
Debian packages of OCaml batteries included</strong>. You can find
them in <a href=
"http://packages.debian.org/experimental/">experimental</a>
(actually in <a href=
"http://ftp-master.debian.org/new.html">NEW</a>, at the time of
writing), and from <a href=
"http://people.debian.org/~zack/ocaml-batteries/">my
<code>people.d.o</code> space</a>.</p>
<p><small>I've only built the packages for <code>amd64</code>, if
you need some other architecture you can build on it by yourself,
but I recommend <em>not</em> trying to rebuild the
<code>-doc</code> package (which takes 10 minutes on my laptop to
build). You can reuse the <code>-doc</code> package I've built,
which is <code>arch: all</code>, to rebuild only the
<code>-dev</code> part unpack the source package and do
<code>fakeroot debian/rules binary-arch</code>.</small></p>
worst quoting practicehttp://upsilon.cc/~zack/blog/posts/2008/10/worst_quoting_practice/2009-11-28T12:00:16Z2008-10-03T08:13:37Z
<p>On the saga of weird SPAM, today I received a SPAM message in
French about advertising a backgammon portal (WTF?).</p>
<p>One of the funniest part was the end of the message (original,
horrible line breaking preserved):</p>
<pre><code>P.S.: Pour un meilleur suivi des communications, merci de bien vouloir laisser
l'intégralité
du message et de répondre au-dessus de l'historique.
</code></pre>
<p>Which roughly translates to: "to better follow further
communications, please keep the totality of the original message
and write your response on top of it".</p>
<p>To be read as: "just in case you know how to quote properly,
please don't do that".</p>