Older blog entries for wlach (starting at number 47)

2 Aug 2006 (updated 2 Aug 2006 at 20:38 UTC) »
apenwarr: A few years back, I remember reading an article (unfortunately I can't find it cited anywhere) about a little experiment that was conducted on a first year psychology class. Each student was asked to fill out a questionaire describing how they would react to a number of routine situations. A few weeks later they all received exactly the same analysis of their personality (containing such exciting generalities as "you are outgoing sometimes and introverted at others" and "you have abilities that you have not yet capitalized on"). As I recall, just about every student thought the analysis was tailored to their unique personality.

This isn't to discount the Myers-Briggs test entirely.. just that you have to take into account the mind's ability to fill in all sorts of blanks, especially when you're being told what you want to hear. The INTJ profile is pretty flattering as I recall (I scored as one too). Who doesn't want to be an independent and creative freethinker?

Update: A co-worker correctly attributed this experiment to Bertram Forer.

14 Jun 2006 (updated 14 Jun 2006 at 06:43 UTC) »

Index: wvgzip.cc
--- wvgzip.cc	(revision 11207)
+++ wvgzip.cc	(working copy)
@@ -151,7 +151,7 @@
         if (retval == Z_DATA_ERROR && mode == Inflate
             && ignore_decompression_errors)
             retval = inflateSync(zstr);
-    } while (retval == Z_OK && (!out_limit || (out_limit == output)));
+    } while (retval == Z_OK && (!out_limit || (out_limit > output)));
     if (retval == Z_STREAM_END)

This fun little error cost me almost a week of debugging time. I really need a vacation.

The rest of you may enjoy the new zlib output-limiting support (which, to great irony, no longer puts you at risk of completely exhausting your machine's memory) in the next WvStreams release.

20 Apr 2006 (updated 20 Apr 2006 at 03:02 UTC) »

Not that anyone outside of Montréal particularly cares, but the Wok Cafe's (probably the best fast-food Chinese restaurant in the city) website can be found here:

The Wok Cafe

It's useful to know their take-out number and menu for late night hacking adventures-- unfortunately they don't seem to have much google juice. Maybe this will help.

Burgundavia: I also noticed that the OpenDocument filter was not being installed by default with AbiWord. Which is annoying to say the least.

However, I think that's really the fault of the distribution (and/or the package maintainers) rather than the application developers. Surely there must be some way of ensuring that the abiword and abiword-plugins packages get installed as a pair-- perhaps by creating a meta package that will install them both?

24 Dec 2005 (updated 24 Dec 2005 at 08:27 UTC) »
Burgundavia: Fooling people into believing something that just isn't true doesn't seem right to me. I dunno, maybe this whole "OpenDocument" hoopla is a useful fiction and hyperbole: after all, it seems to provide an opening for getting OpenOffice (or GNOME Office, or KOffice, whatever) into places where it wouldn't be able to otherwise. But if winning's the important thing (and I'm with robsta that it might not be), I'd rather it be for the right reasons.

For some more context, see my earlier entries on the topic.

apenwarr: A bit late replying to this one (blame you-know-what), but for what it's worth, the article you cite in your recent post deals with something pretty different from what you were talking about. In philosophical circles, idealism generally means taking "ideas" as being prior to external reality in some way (by stating that they exist independant of it, or that external reality is an idea, or somesuch variation).

This is, of course, different from the colloquial understanding of "idealism", which generally implies a focus on "how things ought to be" rather than "how they actually are".

robsta: My point was that in order to share your documents seamlessly with other people, you really need to standardize on the same creation tool. My experience has been that people using these things tend to tear their hair out over even minor losses in formatting that come from converting between document formats (image positioning, section handling, font faces, what have you).

Of course, the ideal would be that people would just produce the content of documents along with some semantic markup, and their document viewer would produce something aesthetically pleasing based on a style sheet of the user's preference. For that, a document format like XHTML is more than sufficient. And on the surface, one might think it would solve 80% of use cases (I mean, aren't people just writing documents to be read?).

Much to my despair however, people's behaviour (and feature requests) says otherwise. The model of Microsoft Office has made everyone into an amateur desktop publicist: a control freak who wants absolute control of the details of formatting. They want their TPS reports to be exactly one page, have two columns (3.53 inches apart), and an image exactly 1.62 inches from the top, center-right. And dammit, anyone viewing or editing that TPS report should see the exact same thing. Anything else would be unprofessional. (Sigh)

And so we seem to be stuck with large unwieldly document formats like OpenDocument (and RTF, and MsWord, and WordPerfect). To change this, we need something that can capture people's imaginations the same way that fiddling with margins and image positions does.. and I'm not quite sure what it is yet (if I did, I'd probably be working on it!).

robsta: While that article is quite silly, I don't think XHTML makes any more sense as a common interchange format. When it comes to sharing documents, the ideal is to lose as little formatting as possible as the document is passed around, viewed, and modified. For the average office worker, trained in WIMP document production applications, I think the following is the current set of best practices:

If you only want other people to be able to read your document, PDF is the most sensible option: it more or less guarantees a perfect reproduction of your document's formatting without placing a burden on the reader to use the software you used to create it. If you want other people to be able to edit your document, it only makes sense for you to come to a common agreement as to which editor you want to use (GNOME Office, OpenOffice, Microsoft Office, whatever). If you don't, formatting information will (almost always) be lost and people will be annoyed.

Unless and until XHTML supports a strict superset of the formatting options of all word processing applications out there (which seems rather unlikely), I don't see it having a large tangible effect. Actually, the only thing that I see changing the above set of recommendations is the outright displacement of office software (in the mold of Microsoft Office) from the software landscape.

28 Sep 2005 (updated 28 Sep 2005 at 05:49 UTC) »
Argument parsing libraries, continued

Results from my informal poll:

1. haruspex recommended using getopt. Yes, there is a Microsoft-friendly version of this routine (they actually recommend using it in lieu of argp in one of their lame Unix->Win32 porting guides).. but it really only provides a small subset of the functionality of argp / popt (e.g.: you can't use it to automagically generate help messages).

2. Jim Morrison (ex-Nitiite and free software hacker extraordinaire) pointed out that argp was, in fact, not part of glibc. It's part of a stand-alone library called gnulib. The idea here is to provide a set of tiny standalone routines that you can compile into your own program and library as needed. This sounded promising, so I played with it a little bit this evening.

Sigh. Their version of argp depends on something like 10 other gnulib modules, few of which compile out of the box on Windows (they expect a certain amount of unixism in your environment). End result is that I'd need to hack this up quite a bit-- and I'm not sure if the end result would be much better than including popt in the WvStreams distribution. The gains of a cleaner API and a "guaranteed" future seem rather marginal compared to the extra effort involved in making this thing work properly (not to mention the bloat of a huge number of otherwise unnecessary functions). If it compiled out of the box, it would be a different story.

(yes, it would be a worthwhile project to do a full port of gnulib to MSVC.. but that's frankly not a project I'm particularly interested in).

3. Fridrich Strba pointed out that Tor Lilqvist has put up a Win32-friendly version of popt here. I'm not sure how comfortable I am on relying on this as an external dependancy. Only libgnome uses it, and I understand that will be going away in the near future.

My conclusion is that statically including popt is probably the best option (which isn't really that horrible at the end of the day). I sure hope this pedantry was useful to someone.

Cryptic insights

apenwarr: You might want to go into more detail, since I doubt the average advogatan has much insight into NITI's internal development processes. :) The difference between specification and design wouldn't have been obvious to me a few years ago.


bwh: That's a very interesting, under-engineered approach to interoperability (I mean that in a good way).

The fact that it worked out so well for you likely has much to do with the fact that SVG has become such an ubiquitous format for vector graphics. To contrast, there is no real "hub" format for word processors so you really do need to write implementation-specific importers/exporters to get the best results. Maybe OpenDocument will change this, but I'm skeptical.

libwpd's "translation format" is actually a superset of what OpenOffice and Abiword provide. It has a richer model for lists than AbiWord and expresses more semantic content for page spans than OpenOffice.

23 Sep 2005 (updated 23 Sep 2005 at 07:03 UTC) »

Decided to continue using this account for random technical entries (gotta cater to an audience which cares, and all that). The techblogging muse doesn't strike me that often, so still no promises on frequency of updates..

Option-parsing libraries

WvStreams has recently acquired an argument processing class. This really makes life much easier when writing daemons and other tiny network utilities: not having to write tons of boilerplate code for parsing command line options and printing out help/usage messages is a godsend. Unfortunately, the backend library that this class uses (popt) has a number of problems, namely:

  1. It's not actively maintained in standalone form (you need to download rpm to build it these days).
  2. It's not buildable using MSVC++ as is.

As an interim solution, I patched the hell out of it to get it compiling under Windows and decided to live with it for the time being (most Linux distributions come with an obsolete version that's good enough for our purposes on that platform).

But really, that's a non-optimal approach over the long term. So I went searching for an alternative. In my travels, I found two widely-distributed libraries which seem to offer comparable functionality: argp (part of glibc) and GOption (of GNOME fame). Both have fatal disadvantages: argp does not exist as a standalone library (hence there is no easy path to distributing it in a form buildable by MSVC++) and GOption is tightly coupled to glib (which is difficult to justify depending on for such a small task).

So I'm pretty much at wits end, except for the slim hope that there might be some viable alternative that I've missed. Does anyone know of a C library for argument processing library which meets the following criteria:

  1. Actively maintained
  2. Buildable under both win32 (Microsoft VC++) and Unix
  3. Free of external dependancies
  4. Has a sane license (LGPL or BSD)

.. 'cause the alternatives (including a patched copy of popt with WvStreams or writing a new library from scratch) are looking like a whole lot more work than directly reusing something that already exists.

My journal has mostly moved here. I may still pop up on Advogato occassionally to comment on other people's postings..

38 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!