blog/archives/2008/11zack's home pagehttp://upsilon.cc/~zack/blog/archives/2008/11/zack's home pageikiwiki2009-11-28T12:00:16ZPTS SOAP interfacehttp://upsilon.cc/~zack/blog/posts/2008/11/PTS_SOAP_interface/2009-11-28T12:00:16Z2008-11-29T23:05:12Z
<h1>Hacking the PTS using SOAP</h1>
<p>I've finally found some time, thanks to the <a href=
"http://wiki.debian.org/DebianQAExtremadura2008">Extremadura QA +
ftpmaster + i18n meeting</a>, to release the first draft of the
<strong>SOAP interface to the <a href=
"http://packages.qa.debian.org">PTS</a></strong>.</p>
<p>You probably already got the idea, which is quite simple after
all. The PTS, as always, gathers information about (source)
packages from various sources and melds them together into web
pages. With a SOAP interface you just gain the ability of accessing
such information from your programs via SOAP.</p>
<p>A proof of concept is overdue:</p>
<pre><code> $ cat ./test.py
#!/usr/bin/python
import SOAPpy
url = 'http://packages.qa.debian.org/cgi-bin/soap-alpha.cgi'
ws = SOAPpy.SOAPProxy(url)
print ws.versions(source="ocaml")['unstable']
print ws.uploaders(source="ocaml")[1]['name']
$ ./test.py
3.10.2-3
Stefano Zacchiroli
</code></pre>
<p>Everything is still in alpha version, but already working. Some
links which you might find useful:</p>
<ul>
<li>(fancy) <a href=
"http://people.debian.org/~zack/pts/soap/"><strong>API
reference</strong></a> (blame <a href=
"http://packages.debian.org/unstable/python-epydoc">epydoc</a> if
you think it's too fancy)</li>
<li><a href=
"http://wiki.debian.org/qa.debian.org/pts/SoapInterface"><strong>general
information</strong> about the SOAP interface</a> (from wiki.d.o),
including pointers to other doc / tools</li>
</ul>
<p>Please let me know if / how you are using of the SOAP interface,
it will help for future developments.</p>
<h2>How it works</h2>
<p>Just a few comments on how it works. You might remember that a
while ago I've made all PTS pages XHTML-valid. Well, on top of it
I've implemented something along the lines <a href=
"http://www.microformats.org">microformats</a>, that just make a
clever use of ingredients already available in XHTML like classes
and unique identifiers.</p>
<p>Having that, a "reshuffling" of the information already
available on the web pages (which are now kinda "semantically"
tagged) can be obtained by evaluating a handful of XPaths on the
(not anymore) <em>final</em> XHTML pages. That's precisely what
<a href=
"http://svn.debian.org/viewsvn/qa/trunk/pts/www/cgi-bin/soap-alpha.cgi?view=markup">
the CGI</a> implementing the SOAP API is currently doing. This way
one can avoid implementing two different access paths to the
information collected by the PTS: one for rendering, and one for
SOAP (no, reusing the rendering one for SOAP was not an option,
given that it was originally written in XSLT).</p>
<p>The only annoyance I've encountered is that XPath is completely
unaware of the "CSS-like" semantics of XHTML classes, which states
that classes are space-separated list of class names, to be
interpreted as sets. That means that to check whether an element
belongs to a given class you need to fiddle with substring matches
on the class attribute (which is quite crappy).</p>
from Vim to Emacs - part 2http://upsilon.cc/~zack/blog/posts/2008/11/from_Vim_to_Emacs_-_part_2/2009-11-28T12:00:16Z2008-11-15T12:30:05Z
<h1>One month with Emacs and counting - Part 2</h1>
<div class="notebox">
<p>Other posts in the <em>from Vim to Emacs series</em>:
<span title=
"Why Emacs is now ready to be switching to"><strong><a href=
"http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/">
part 1</a></strong></span></p>
</div>
<p>A while ago I've blogged about <a href=
"http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/">my switch from
Vim to Emacs</a>, promising a blog post <em>series</em>, quite a
mouthful <img src="http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" />
nevertheless, it's time to continue the series. The <a href=
"http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/">first part</a>
was about why I think that nowadays <a href=
"http://www.gnu.org/software/emacs/">Emacs</a> is ready to be
switching to. This second part is about <strong>flawed <a href=
"http://www.vim.org">Vim</a> design choices</strong> which
substantially contributed to my choice.</p>
<p><small>(Of course all this post is under a IMO-/rant-disclaimer,
it can't be otherwise, so take it <em>cum grano
salis</em>)</small></p>
<h2>Flawed Vim design choices</h2>
<p>Vim started as a wonderful editor, following the path of Vi,
which in turn has got right a good deal of design choices. One is
the often debated <strong>modality</strong>. In spite of being a
<acronym title="Human-Computer Interaction">HCI</acronym>
<acronym title="Pain In The Ass">PITA</acronym> in general,
modality is not a problem at all for software you are using every
single day (and the editor is the 2nd program I use the most, with
the terminal being the 1st), because you learn it as <a href=
"http://en.wikipedia.org/wiki/The_Humane_Interface">a habit</a>. In
the case of Vim, modality is good because it let you use powerful
yet simple <strong><a href=
"http://vimdoc.sourceforge.net/htmldoc/usr_04.html#04.1">motions</a></strong>
in command mode, which can be easily combined with <strong><a href=
"http://vimdoc.sourceforge.net/htmldoc/intro.html#Operator-pending">
operator-pending</a></strong> commands.</p>
<p>This can be considered yet another incarnation of the <a href=
"http://en.wikipedia.org/wiki/Unix_philosophy">UNIX philosophy</a>,
casted <em>inside</em> the editor itself. ... which brings us to
the good old joke which describes Emacs as <q><em>a great operating
system, lacking only a decent editor</em></q>. In fact, <strong>Vim
is no longer the nice Unix philosophy player</strong> which it used
to be, and Emacs plays much more nicely with external tools than
Vim.</p>
<p>As arguments, let's consider a few (not so) recent Vim
evolutions:</p>
<ul>
<li>
<p><strong>Spell checking</strong>. Starting with version 7, Vim
has got support for <em>on-the-fly</em> spell-checking of text
buffers. It is a super-nice feature, which I've <a href=
"http://erlug.linux.it/talkdisera/media/vim7.pdf">advertised in the
past</a>, because spell checking is needed in many tasks we daily
do with editors (mail/doc writing, code commenting), and having a
single interface to do it comes handy.</p>
<p>Unfortunately, <em>how</em> that is implemented in Vim is
definitely <em>not</em> along the lines of the UNIX philosophy. We
have countless different FOOspell implementations whereas Vim
implemented yet another one, without relying on any pre-existing
implementation. Even more so, the file format of spell files is
basically ad-hoc, and not sharable with other tools. This is
already a PITA for packaging (let's add to Debian another 20 binary
packages <code>vim-spellfiles-FOO</code>), but is even worst than
that: the spell files must be generated in ad-hoc ways which are
seriously prone to failures (guess why in Debian we don't have yet
the <code>vim-spellfiles-FOO</code> packages which used to exist in
experimental a long time ago?).</p>
<p>What would have been the UNIX-friendly way of achieving the same
result? Well, obviously spawning <code>FOOspell</code> and
<em>interact with its process</em> from the editor. Keep that in
mind.</p>
</li>
<li>
<p><strong>Internal grep</strong>. A feature of Vim I've always
loved is <a href=
"http://vimdoc.sourceforge.net/htmldoc/quickfix.html#:grep">:grep</a>
(yet another instance of <a href=
"http://vimdoc.sourceforge.net/htmldoc/quickfix.html">quick-fixing</a>,
which is also used for jumping to compile-time errors). In its
original incarnation it was as simple as invoking <code>grep</code>
and parse its output. <span title=
"Keep It Simple, Stupid">KISS</span>.</p>
<p>Then, Vim started to have a problem: <code>grep -r</code> can
take ages and in the meantime the editor was stuck. Hence, starting
with Vim 7, <a href=
"http://vimdoc.sourceforge.net/htmldoc/quickfix.html#:vimgrep">vimgrep</a>
has born: an <em>internal re-implementation of grep</em>. OK, it is
more portable (but how many of us do care? on how many system you
use you are missing grep? damn, I used to install it also on
Windoze!), and the editor retain control. Control that is exploited
just to show a nice progress bar of what is being scanned ...,
while the editor is still stuck.</p>
<p>Well, to me it looks like the problem would have been solved
much more nicely by adding the ability to <em>interact with an
external process</em> (deja vu?). That process can then be
<code>grep -r</code>. Full stop.</p>
</li>
<li>
<p><strong>Lack of debugging support</strong> (on purpose). Long
standing missing feature of Vim: you can not "easily" drive a
debugger from Vim, because a firm choice in Vim is to ... (OK, I
confess, I'm starting to beat a dead horse) ... <strong>not have
support for interaction with external processes</strong>.</p>
<p>I found such a choice quite dumb: to me it is evident that it
induces a trade-off between being feature-complete wrt programmer
needs (as available external tools get available to face those
needs) and not "re-implementing the wheel" <em>inside</em> the
editor.</p>
<p>Going back to the lack of debugging support in Vim, that has
spawned projects like <a href=
"http://www.volny.cz/zellerin/gdbvim/">GdbVim</a>, <a href=
"http://clewn.sourceforge.net/">Clewn</a>, Bram's <a href=
"http://www.a-a-p.org/">Agide</a>, and my own tiny teeny
incarnation specific to <a href=
"http://caml.inria.fr/pub/docs/manual-ocaml/manual030.html"><code>ocamldebug</code></a>
called <a href=
"http://upsilon.cc/~zack/hacking/software/wowcamldebug/">WOWcamldebug</a>.
Every single project of that list acts as an intermediary between
Vim and an external process (a debugger of some sort), whereas that
could have been implemented by an editor plugin, provided that the
editor offer, guess what, support for interaction with external
processes.</p>
</li>
<li>
<p><strong>Top-level</strong>. Similar to the debugging support
issue, there is the <em>interpreter</em> issue, namely how to
evaluate "phrases" of your interpreted language of choice directly
from the editor. Nowadays a lot of languages have the so called
top-levels which evaluate language phrases interactively (Python,
Ruby, OCaml, many Lisps, ...) and show evaluation results. That
ability can speed up testing considerably, but can become
cumbersome to use for large code snippets without editor support
(good luck with copy and paste).</p>
<p>Yes, Vim has support for that, but the implementation choice is
close to be ridicolous: only if you have <em>linked</em> Vim
together the interpreted for a given language, then you will be
able to interactive evaluate phrases of that language. What if you
program in Python, Ruby, and Perl? Well, you need to link all of
them. What if you also program in OCaml? Then you're screwed,
because Vim currently does not support linking with it.
<small>(Yes, I know that there are other reasons for doing that
linking, they are discussed below.)</small></p>
<p>Do I need to tell you which feature will be enough to address
top-level support? <strike>interaction with extern..</strike> OK,
I'll drop it, you know that already.</p>
</li>
</ul>
<p>Well, I acknowledge that Emacs got this choice right, and that
it's <em>an important one</em>: Emacs supports interaction with
external processes, and plugin authors have been happy to exploit
it to create really cool stuff (sticking to the UNIX philosophy).
Please welcome: <a href=
"http://www.gnu.org/software/emacs/manual/html_node/emacs/Spelling.html">
Flyspell</a>, <a href=
"http://www.emacswiki.org/emacs/GrepMode#toc2"><code>M-x
grep</code></a> (shameless smartass plug: same number of keystroke
of <code>:grep</code>), <a href=
"http://www.gnu.org/software/emacs/manual/html_node/emacs/Debuggers.html#Debuggers">
Grand Unified Debugger</a>, <a href=
"http://www.emacswiki.org/cgi-bin/wiki/PythonMode">a</a> <a href=
"http://www.emacswiki.org/cgi-bin/wiki/TuaregMode">sampling</a> of
language-specific major modes with top-level support. (But I
recommend having a look at least once at the coolness of other
stuff built-on top of external process support, like <a href=
"http://flymake.sourceforge.net/">Flymake</a>, <a href=
"http://www.netfort.gr.jp/~dancer/diary/200810.html.en">mentioned
by dancer</a> not a long ago.)</p>
<ul>
<li>
<p><strong>Its own scripting language</strong>. I've bored you
enough with the external process topic, hence here is the second
one: the saga of Vim and its scripting language, i.e., the
programming language using which you can customize the editor.</p>
<p>Note that the choice of scripting language impacts on 2
different targets: final users in need of fire and forget
automations (when they start to get to complex to be implemented on
top of, say, <a href=
"http://vimdoc.sourceforge.net/htmldoc/repeat.html#recording">macros</a>),
and developer of editor extensions such as <a href=
"http://www.vim.org/scripts/index.php">addons</a>.</p>
<p>The impact of scripting language on extension developer is
crucial for the evolution of an editor aiming at being powerful. If
the scripting language and the API towards the editor is flexible
enough, then a lot of cool extensions and features will be
developed by third party authors, otherwise the burden stays on
editor upstream author.</p>
<ol>
<li>
<p>In its <em>phase 1</em> (my term, Vim < 7.0) Vim pretended
that it needed only a <em>minimal</em> scripting language (<a href=
"http://vimdoc.sourceforge.net/htmldoc/usr_41.html">Vim script</a>)
and that everything else can be developed using external
programming languages, linked in the editor. As a consequence Vim
script was just a tiny teeny procedural language with editor
interfacing capabilities, most notably lacking any "decent" data
structures (no lists, no dictionaries, ...).</p>
<p>In that phase, if you were a user it was fair enough. You just
had to chose your external programming language (at compile time
...), and you were able to write your quick hacks with it. But if
you were willing to develop an extension you were screwed, because
you had either to impose your external programming language to the
final user (that is what gave born to absurdities like <a href=
"http://packages.debian.org/etch/vim-full"><code>vim-full</code></a>,
look at the deps!) or to enjoy a good deal of masochism to explode
your 30 lines of Python extension into 200 lines of Vim script to
make your Vim extension more "portable".</p>
</li>
<li>
<p>In its <em>phase 2</em> (Vim >= 7.0) it has been realized
that something were wrong in the initial choices about Vim script,
and data structures (lists, dictionaries, function references!)
have been added to it, relieving a bit the pain of programming
portable extensions.</p>
<p>Nevertheless, and probably due to how it started, Vim script is
far from being a programming language one can enjoy programming in.
Consider for example the <a href=
"http://vimdoc.sourceforge.net/htmldoc/eval.html#functions"><em>standard
library</em></a> of the language. It started as a random collection
of unrelated functions being added on a "as-needed" basis, ... and
continued along that path! Now the API reference lists together
totally unrelated functions, organized inconsistently, and making
really painful finding what you need (assuming it exists).</p>
</li>
</ol>
</li>
</ul>
<p>Even in this respect, I acknowledge that Emacs got this right.
It has chosen a single, now full-fledged, programming language
(<a href="http://en.wikipedia.org/wiki/Emacs_Lisp">Elisp</a>),
which is offered both to the final user (<em>fact</em>: the average
Emacs user knows much better how to program her own editor than the
average Vim user) and to extensions developer. The standard library
of the language is organized with a consistent naming (even though
not always intuitive) and <a href=
"http://www.gnu.org/software/emacs/manual/html_mono/elisp.html">documented
in an organized manner</a>.</p>
<p>You might not like the language, but at least is has been taken
seriously and managed as such. Finally, being a Lisp dialect, you
might need what you learn with Elisp elsewhere. Vim script is too
committing: it is useful only inside Vim. I believe that
contributed significantly in its scarce diffusion among Vim
users.</p>
<p>The fact that Elisp was born together with Emacs and that it is
also used internally for the editor implementation is not relevant
here: I do care about what is offered to me as an user and as an
extension developer. What I see on the Emacs side in this respect
is much better that what I see on the Vim side. Moreover, from the
point of view of the users, is the difference between what is
<em>inside</em> the editor and what is <em>outside</em> (i.e., the
extensions) that relevant? I think it is not, and that brings me to
the final Vim choice which I consider flawed and which has the
potential of seriously limit its future evolutions:</p>
<ul>
<li>
<p><strong>Editor as a distribution</strong>. Emacs is managed as a
intermediate software distribution layer, similarly to what happens
in other softwares where many third party authors cooperates (e.g.,
<a href="http://www.tug.org/texlive/">TeXLive</a>). The
distribution architecture has advantages and contributes to the
longevity and potentialities of a software project.</p>
<p>What does this mean concretely in the Vim vs Emacs dispute? For
example it means that Emacs get more feature-complete each passing
release, still preserving uniformity in documentation and
keybindings. On the contrary Vim sports many addons, which are very
likely to step on each other feet when enabled simultaneously.
Actually, that is one of the reason which brought me to the
creation of <a href=
"http://packages.debian.org/lenny/vim-addon-manager">vim-addons</a>:
you cannot enable all the content of <a href=
"http://packages.debian.org/lenny/vim-scripts">vim-scripts</a>
together due to various kind of conflicts. As we know well in
Debian, distributions have a fundamental role in blending together
lightly-coupled software components, that's role is missing in Vim
evolutionary path and I find that worrisome.</p>
</li>
</ul>
<p>Where to from here in this blog post series? For sure some tips
on how to migrate for hard-core Vim users, then we'll see ...</p>
<p>If you did enjoy the read please let me know commenting in the
discussion page (as you did in the last post, thanks!).</p>
signature preverthttp://upsilon.cc/~zack/blog/posts/2008/11/signature_prevert/2009-01-05T17:01:30Z2008-11-12T16:29:31Z
<h1>a tale of backpacks, poetry, and hacking</h1>
<pre><code>Stefano Zacchiroli -o- 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'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
</code></pre>
batteries alpha2 Debian packageshttp://upsilon.cc/~zack/blog/posts/2008/11/batteries_alpha2_Debian_packages/2009-11-28T12:00:16Z2008-11-12T07:51:03Z
<h1>OCaml Batteries alpha 2: Debian packages</h1>
<p>Out of popular request (wow, people on
<code>#ocaml@freenode</code> are very excited about the Batteries
thingy, good!), I've prepared <strong>Debian packages for <a href=
"http://batteries.forge.ocamlcore.org">OCaml Batteries
Included</a>, version <a href=
"http://forge.ocamlcore.org/forum/forum.php?forum_id=211">alpha
2</a></strong> (which does include the <a href=
"http://upsilon.cc/~zack/blog/posts/2008/11/ocaml_batteries_gzip/">support for
transparent gzip-ed channels</a>).</p>
<p><small>Packaging shameless plug: packaging this version has been
a nice showcase for <a href=
"http://packages.debian.org/sid/topgit">TopGit</a> as now I've a
couple of inter-dependent branches. TopGit has indeed rocked my
world, yay. (Well, I also have to admit to myself that this tiny
bit of TopGit mention wont assolve me from the need to
<strike>advertise</strike>blog about TopGit, ...
eventually!)</small></p>
<p>Packages have been <strong>uploaded to experimental</strong>. As
usually I build/upload for amd64, but experimental in Debian
<em>is</em> auto-built so eventually the will show up also for
other architectures, of course including i386. If you want to take
them directly from experimental you have to add this line to your
<code>/etc/apt/sources.list</code>:</p>
<pre><code> deb http://ftp.de.debian.org/debian/ experimental main non-free contrib
</code></pre>
<p>and then install requesting explicitly experimental (for some
time now, experimental is treated specially, and it won't be used
by APT unless explicitly asked for):</p>
<pre><code> apt-get install -t experimental ocaml-batteries-included
</code></pre>
<p>The Debian version (roughly) corresponding to alpha 2 is
<code>0.20081112+gitBB342A7-1</code>.</p>
<p>Alternatively, you can grab the packages <a href=
"http://people.debian.org/~zack/ocaml-batteries/"><strong>from my
people.d.o space</strong></a>. Since people were interested I've
made available both amd64 and i386 builds there.</p>
camlbz2 bzip2 ocaml bindingshttp://upsilon.cc/~zack/blog/posts/2008/11/camlbz2_bzip2_ocaml_bindings/2009-11-28T12:00:16Z2008-11-03T22:26:05Z
<h1>CamlBZ2: OCaml bindings for libbz2</h1>
<p>Since the next building block for <a href=
"http://upsilon.cc/~zack/blog/posts/2008/11/ocaml_batteries_gzip/">proper compression
support</a> in <a href=
"http://batteries.forge.ocamlcore.org">Batteries</a> is <a href=
"http://www.bzip.org">bzip2</a> integration, I started from the
basic ingredient: <strong>OCaml bindings for bzip2</strong>.</p>
<p>It was not entirely missing: the <a href=
"http://ocamlplot.sourceforge.net/ocamlplot.html#gz">old GZ
project</a> by <a href="http://oandrieu.nerim.net/">Olivier
Andrieu</a> was in fact offering bzip2 bindings, but was doing that
in tandem with <a href="http://www.gzip.org">gzip</a> bindings
(which already have a standard de facto implementation: <a href=
"http://caml.inria.fr/cgi-bin/hump.en.cgi?contrib=84">Camlzip</a>).</p>
<p>Hence I contacted the author and together we decided to split
away the two parts and releasing <strong><a href=
"http://camlbz2.forge.ocamlcore.org">CamlBZ2</a></strong> as a new
project, devoted to bzip2 bindings alone.</p>
<p>The old code has been ported to latest OCaml versions and a
couple of bugs have been squashed in the interim. The project is
now hosted on <a href="http://forge.ocamlcore.org">the OCaml
forge</a>, has its own <a href=
"http://camlbz2.forge.ocamlcore.org">homepage</a>, and <a href=
"http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=camlbz2/camlbz2.git;a=summary">
a Git repo</a> (<em>look ma, it looks like a serious
project!</em>).</p>
<p>Today I've made the first alpha release: <a href=
"http://forge.ocamlcore.org/frs/download.php/70/camlbz2-0.5.99.tar.gz">
<strong>CamlBZ2 0.5.99</strong></a> is <a href=
"http://forge.ocamlcore.org/forum/forum.php?forum_id=206">now
available</a>. It is intended to be a test release ... so please
test it <img src="http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /> and
report any issue you find using <a href=
"http://forge.ocamlcore.org/tracker/?group_id=63">the
tracker</a>.</p>
<p>Next steps for CamlBZ2:</p>
<ul>
<li>0.6.0 release,</li>
<li>a <a href="http://www.debian.org">Debian</a> package,</li>
<li>and of course an API flexible enough to enable Batteries
integration!</li>
</ul>
ocaml batteries gziphttp://upsilon.cc/~zack/blog/posts/2008/11/ocaml_batteries_gzip/2009-11-28T12:00:16Z2008-11-02T21:40:09Z
<h1>OCaml batteries, now with GZip-ed channels</h1>
<p>This week-end I've spent some time to kick-start my hacking onto
<a href="http://batteries.forge.ocamlcore.org/">OCaml Batteries
Included</a> (yes, it deserves a proper website).</p>
<p><a href=
"http://upsilon.cc/~zack/blog/posts/2008/10/ocaml_batteries_included_debian_packages/">Last
time I wrote about it</a> was with my package maintainer hat on. In
the meantime I've got trapped<code>^W</code>involved with upstream
development as well, after having been so fool to propose
integration with <a href=
"http://batteries.forge.ocamlcore.org/doc.preview/batteries-alpha1/batteries/html/api/System.IO.html">
Batteries' I/O channels</a> of compression/decompression
libraries.</p>
<p>Well, here are the first tiny teeny results:</p>
<pre><code> # open Batteries.System;;
# let i = File.open_in "/tmp/fstab.gz";;
val i : InnerIO.input = <abstr>
# let i2 = GZip.uncompress i;;
val i2 : InnerIO.input = <abstr>
# IO.read_line i2;;
- : string = "# /etc/fstab: static file system information."
# IO.read_line i2;;
- : string = "#"
# (* same goes for output of course *)
</code></pre>
<p>i.e., no matter how you created an I/O channel (and with
Batteries you can create it out of <em>a lot</em> of entities), you
can apply a <code>gzip</code> compress/decompress filter.</p>
<p>The underlying library is <a href=
"http://caml.inria.fr/cgi-bin/hump.en.cgi?contrib=84">Camlzip</a>,
which also sets a precedent on how to integrate external libraries
into Batteries properly.</p>
<p>The code is not released yet (hey, Batteries is still alpha!),
but is available from the <a href=
"http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=batteries/batteries.git;a=summary">
Git repo</a>, (<a href=
"http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=batteries/batteries.git;a=shortlog;h=refs/heads/zack/compress">zack/compress
branch</a>).</p>
<p>Next milestone: <code>bzip2</code> ... of course with the same
interface, so that changing (de)compressor will be as easy as
<code>s/GZip/BZip2/g</code> in the code above. <code>tar</code> and
<code>zip</code> will come next (but with different interfaces, as
old *nix jokes tell us, compressing and archiving are different
tasks).</p>
debian developer portfoliohttp://upsilon.cc/~zack/blog/posts/2008/11/debian_developer_portfolio/2009-11-28T12:00:16Z2008-11-01T22:44:22Z
<h1>DDPortfolio: a bunch of per-developer information</h1>
<p>There are quite a lot of per-DD information resources out there,
and I've always kept on wondering whether I was aware of all or
them or not.</p>
<p>After having found yet another interesting view of myself as DD
(the nice <a href=
"http://debtags.alioth.debian.org/todo.html?maint=zack@debian.org">personal
debtags page</a>) I decide to start collecting that info.</p>
<p>As a (supposedly) cute name for that I chose <strong>Debian
Developer Portfolio</strong>, you can find it on the <a href=
"http://wiki.debian.org/DDPortfolio">DDPortfolio page</a> on the
<a href="http://wiki.debian.org">Debian wiki</a>. The idea is to
collect there link templates to <strong>resources which show some
kind of per-developer view</strong>.</p>
<p>Personally, it is the kind of stuff that I want to have either
as bookmarks or on my homepage, but another possibility is to use
it as a <a href="http://moinmo.in/HelpOnTemplates">MoinMoin
template</a> to create personal pages on the Debian wiki.</p>
<p>Of course it is the kind of stuff which <strong>need
help</strong>, please add to the page links to resources you know
that give a per-developer view of some kind. I'm grateful in
advance!</p>
<p>Closing notes:</p>
<ol>
<li>
<p>there were already something similar on the <a href=
"http://wiki.debian.org/DebianDeveloper">DD</a> page, done by
Daniel. I think a specific page is better, hence I've integrated
what was there with my links and split a separate page.</p>
</li>
<li>
<p>it is not evident how to give link templates. On one hand one
wants anonymous links, on the other links that work. ATM I've
created link using my login, and noted that is used as meta-syntax
to be replaced.</p>
</li>
</ol>