Older blog entries for joolean (starting at number 39)


So maybe I've missed the memo, but according to my calculations, GPLv3 is going to be finalized on June 29th -- and nobody's planning to throw a party?! This thing's been cooking for years, people. Look, I live in Brooklyn and I'm all set to get hammered the Friday after next. Who's with me?

Moved into my new place; enjoying cheap tacos and cable Internet. Still unpacking, etc. Question, though:


Anyone know what the story is on this project? The only thing I've been able to glean (from the barest minimum of Google-sleuthing) is that it used to be maintained by jkaivo, and he doesn't seem to be a fixture on the 'net any more. Anyone know him? Or heard of GNUTS? I think it's about time we had a cross-toolkit interface markup framework, and if people are working on it, I'd like to get in on the ground floor.

Thing are hectic at work and I'm prepping to move, so I haven't had time to really focus on, you know, my life's work, but:


I got the standard, slightly negative response to the latest release of SDOM that I usually do, but the email from Andrew Reilly turned me onto WebIt!, which, in addition to sxml-match, defines a CSS representation that's a whole lot nicer than the one I came up with originally. So I'm rewriting the grammar and associated parsing code -- which I was going to do anyway, in the cause of better fault tolerance -- and make my representation match WebIt!'s.

I'd also like to add a SAC interface. Because it's pretty damn easy.


While poking around in PLaneT, I also found this neat JavaScript implementation by dherman that I'd like to port to Guile. Once I've done that, I can conceivably expose SDOM to it and use libRUIN to feed it events. And think of the things I'd be able to do then!

15 Apr 2007 (updated 15 Apr 2007 at 21:22 UTC) »

While poking around with Snow, I got kind of interested in the PLT module system and started looking into porting SDOM to PLaneT. It turned out to be kind of a pain in the ass, but I did it anyway. And thus a new release, 0.4.2. Get it while it's hot: http://www.nongnu.org/sdom/

KumaGames, please explain the process by which users of your software can obtain a copy of the source code.

Dodging a nasty outbreak of Norwalk at my office by curtailing my social life has had the welcome side effect that I've managed to throw together libRUIN 0.1.4! The automatic table layout stuff is actually working now -- including, for example, nested tables, and there are fixes from the latest releases of SDOM and SCSS, adding support for automatic XML dialect detection and Unicode characters. Lots of miscellaneous fixes, too, including one for the intermittent rendering corruption that'd been there since the beginning (it was a race on Guile's GC, it turns out). Check out the NEWS file for more information -- the release is in the official place, http://www.nongnu.org/libruin/.

I find that putting a release together is kind of stressful -- not because of the testing or the packaging itself, but because I have to write the mailing list announcement, the freshmeat release notes, an entry in this diary, etc., and I have to word each one a little bit differently or I feel like I'm spamming. This way I just feel like a crank.

Now I'm gonna see about getting SXML into Snow.

Pursuant to my ramblings on the possibilities of some kind of CPAN-for-Scheme, slef has helpfully pointed out the existence of SNOW, which seems to be exactly what I was thinking of.


SCSS 0.2.3 is out -- no major enhancements, per se, but there's Unicode support, which was long overdue, and some parsing / validation fixes. Tarballs are in the usual place, http://www.nongnu.org/scss/. This release is mainly to support the pending release of libRUIN, which will be more impressive and should be out in a day or two. I'm trying to get the docs up to speed, first.

After that, I kind of what to embark on something else. I'm thinking about doing something to enhance module management support for Scheme, namely, a Scheme port of Perl's CPAN -- not the entire library of modules, just the CPAN module itself, which handles downloading and installation. I'd like to have it support more than just Guile -- a lot of Scheme modules distribute scripts or Makefiles that customize the module code to particular interpreters, so that might be one path to multi-interpreter/platform support. I don't know how many other Schemers are here besides wingo, but can anyone tell me if this is quixotic? Any toes I'd be treading on if I did this?


SDOM 0.4.1 is out! New stuff includes DTD and entity parsing, which makes document normalization actually work the way it's supposed to (though you'll need 0.1.3 or later of wingo's guile-lib to really see the benefit). Grab the tarball from http://www.nongnu.org/sdom/. Focus for the next release is, I think, going to be on the events subsystem and the documentation.

For the moment, though, back to SCSS and libRUIN for a little while.


I find that public support forums like IRC are useful even when nobody answers your question -- even when nobody even acknowledges that you asked a question. This is because that is what often happens (at least, to me) when the question itself is totally wrongheaded. Getting the online equivalent of crickets chirping in a silent auditorium tells me that I need to go back and check the assumptions that led me to ask in the first place.

Case in point, I've been trying to get someone in Freenode #xml to explain how entity dereferencing could possibly be sanely implemented in the context of the DOM. Because an entity reference can be expanded, as per the DOM recommendation, into practically any of the full set of DOM Node types, I wanted to know what a reasonable DOM implementation would be expected to do with a situation like:

<!ENTITY ent "&quot;&gt;&lt;foo attr=&quot;baz&quot;&gt;&lt;/foo&gt;">
<foo attr="bar&ent"></foo>
If the expansion lead to:
<foo attr="bar"><foo attr="baz"></foo></foo>
...that would be problematic for my DOM implementation, since the parent of the entity reference and any nodes that came after it in the document order could have the meanings modified or positions changed, and I'd probably have to pass a serialized version of the entire document back through the XML parser. The proposition filled me dread.

But when I didn't have any luck on IRC, I went back to the DOM recommendation and eventually realized that I didn't have much of a problem after all -- regardless of where entity references can appear during XML parsing, when you're manipulating the DOM they can only be added as proper children of nodes, and not as children of text or CDATA sections. The only case that has to be taken care of is something like this:

<foo attr="bar">&ent</foo>
No sweat!

30 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!