[darcs-users] annotate output

Max Battcher me at worldmaker.net
Mon Sep 6 20:58:40 UTC 2010

On 9/6/2010, Petr Rockai wrote:
> PS: I find it curios, if somewhat amusing, how nothing happened with the
> annotate output for a couple years, until someone re-implements it with
> a new output format. All of sudden, everyone has an opinion on how
> should the output look...

I think I've been rather consistent on this topic. I've stated before 
that I would be happy if the XML support is made better/more valid. But 
the reason we've been splitting hairs so long on this particular subject 
this time around is because we are discussing the dropping/removal of 
--xml support and if such a thing happens I have been commenting on my 
thoughts for hopefully making sure that the machine-readable output 
stays *at least* as useful as --xml, if not *more so*.

> "Stephen J. Turnbull"<stephen at xemacs.org>  writes:
>> But by now there are freely available YAML parsers for pretty much any
>> language but shell, no?  ISTM that if people are doing anything that
>> requires actually interpreting non-ASCII strings or other "hard to
>> read" output, they probably don't want to be doing it in shell anyway.
>> At least my experience on the Mac has been that non-ASCII file names
>> often don't work as you'd expect in shell (and shell quoting of file
>> name variables whose values might-or-might-not contain spaces is a
>> real headache, too).

The Official YAML spec page gives a mostly decent overview of the major 
parsers. Unfortunately it doesn't do a great job of pointing out the 
supported nature of them. (The two under C#/.NET for instance: one is an 
under-documented student work that hasn't been maintained and isn't up 
to date, and the other is an in-progress work that isn't completed yet.)

In my experience, though, the "core" parsers in C, Python, Ruby, and 
Perl all are more than adequate and generally well-supported. Python, 
Ruby, and Perl are increasingly common shell scripting languages at this 
point, and it seems a reasonable assumption to me that someone doing 
shell scripting will know at least one of those and will have access to 
one or more of that language's YAML parsers...

> There isn't one (that would be at least basically documented) for
> Haskell. I imagine that's the case for majority of languages in
> fact. (Majority in number of languages, not users.)

I find the YAML packages on hackage quite fascinating, myself.


That seems to the "the" reference parser for the YAML specification from 
which all others are supposedly built. Nice to see that it is Haskell. 
But we aren't interested as much in parsing so, moving down the list we 
have two big ones:


Interestingly, both of these of are parser/emitters and both bind a C 
API, libyaml and libsyck respectively. Both C APIs are event-oriented 
stream parsers (SAX and its derivatives being the obvious comparison 
from the XML world), with libsyck being the older, deprecated YAML 
library and libyaml the current standard. HsSyck is a product of the 
Pugs project and yaml is seemingly lone effort, hosted on github. HsSyck 
tries to do a little bit of wrapping of the stream structure into to 
more conceptual data structures whereas yaml sticks to the low-level 
event structure...

I'm thinking about using this an excuse to write some more Haskell, so I 
may take one of these two (probably yaml) and write some code with it. 
I'll keep darcs in mind as a potential consumer of whatever my efforts 
might be.

--Max Battcher--

More information about the darcs-users mailing list