Older blog entries for joolean (starting at number 7)

SDOM

The first release of SDOM as been... released! Check it out at http://www.nongnu.org/sdom/. I've already found several major bugs since releasing, so it's obviously not ready for serious use, but it's very full-featured as it stands, and I'd be much obliged if people would take a look. (Currently it only works with Guile; hopefully some day there will be ports to PLT and Chicken, neither of which I know anything about.)

Here's an interesting little thing that came up, Scheme-wise, while I was working on SDOM. Backstory: A lot of the node-manipulation functions defined in the Core module will cause events to be dispatched; the Events module, though, which contains the event-handling functions, is optional. I wanted to make it so that an event dispatch would be fully handled if the Events module was loaded, a no-op otherwise. Here's the code I was using initially:

(if (defined? 'sdom:dispatch-event-internal)
    (apply sdom:dispatch-event-internal args)
    #f)

That wasn't working: Guile kept telling me it didn't know anything about sdom:dispatch-event-internal, and, infuriatingly, when I debugged it, I discovered that defined? was returning #t! I thought I was going nuts.

Here's the denouement, thanks in no small part to unknown_lamer in #guile: Apparently, defined? looks at the top-level environment, where exported module symbols go when you load a module. However, the environment in which my code was then trying to look up that function to apply it didn't contain that binding. After some trying, I found a way to do what I want:

(if (defined? 'sdom:dispatch-event-internal)
    (apply (module-ref (resolve-module '(sdom events))
                       'sdom:dispatch-event-internal) args)
    #f)

Phew!

Has anyone here actually subscribed to the Free Software magazine that the FSF is hawking? Is it any good? I'm wondering if I should ask for a subscription as a birthday present this year.

SDOM

I've made some significant progress on SDOM, to the extent that I feel like the core recommendation is more or less completely implemented. I'm porting the Java DOM test suite to SDOM (at least, the parts of it that SDOM supports / make sense) and using that process to show me which parts are broken and / or incomplete. I realize some people can be a bit leary of CVS, so I'd like to throw together a "developer's release" in the next couple of days so that people can have something to play with. Haven't updated the docs recently either; I've made a lot of progress since the last big revision.

Hopefully I can get back to working on libruin when all this has stabilized a bit.

SDOM has gone public! It's being hosted by the gracious people at Savannah nonGNU. Please go over there and take a look -- it's currently only available through anonymous CVS, but I could really use some feedback, particularly on the aspects of the design that I've documented so far (I'd link directly to the home page / docs, but I'm still waiting, I think, for a Savannah cron job to make it publicly available).

Yes, currying -- that's what it's called. Thank you, judge.

You know, I've only been on advogato for a week or so, but it seems to me that with a few tweaks, these diary entries could really act like a... discussion-graph, I guess. That is, it would be cool if I could refer to something in a diary entry that someone else had written -- either a specific point or the entry or diary itself. That way I could ask a lot of development / design questions and everyone else could spend their time answering them.

My friends at Amherst College use this system called Planworld, a sort of enhancement of finger in which you can not only "link" to other users' .plans in your own .plan, but you can see who's currently linking to yours.

SDOM

In an attempt to reconcile the amount of data that's available from a DOM tree as part of the W3C recommendation with my own desire to minimize the amount of annotation to apply to existing SXML trees, I came up with the following scheme (pardon the pun):

I maintain an abstract hierarchical model of DOM structure, complete with representations of all the different properties for that node interface such that...

• Each representation specifies whether or not the property can be set explicitly.
• Each representation specifies how to get the value of the property -- either by applying a function that derives the value from the content of the node or, by default, by retrieving an annotation attached to the node.
• Each representation specifies how to set the value of the property (if it's not read-only) -- either by applying a function that modifies the node in some way or, by default, by adding / updating an annotation attached to the node.

We'll see how that bears out as a design decision.

Happy new year, FOSSers!

I've decided to go ahead with a fully Scheme-based DOM implementation -- I'm gonna call it SDOM, originally enough. I spent the better part of last week and this weekend getting some pieces of it running. So far it's just a set of annotations that add explicit parent pointers and an event queue to a user-specified S-list in Oleg's SXML format. What took so long, though, was making sure the annotations get applied correctly (e.g., annotations to element nodes are added as "sub-annotations," since attributes are kind of like first-order annotations for elements).

It feels good to get back into a functional mindset, even if it means I have to think extra, extra hard. I wrote a really killer fold that just about tore the ass out of me. Scheme's plenty fun, but it's missing some syntactic sugar that I got used to in ML -- ML, for example, I think, lets you pass around partially-bound or partially-closed functions (forget what they're actually called) that you can call as soon as you furnish a missing argument. Eh, I'm too lazy to go look it up.

I'm going about my other projects in a sort of recursive way, I noticed. gzochi's on hold until I can get a suitable client ready to really test the advanced functionality, which means I need to get libruin finished, and libruin's waiting on the Scheme stuff I'm doing now.

What was I going to say? Uck, I can't remember. It's probably time for bed -- hope I don't dream in parentheses.

Okay, I've refactored the rendering code so that it's all "libruin" inside and out. I also managed to fix a couple of color and size problems. It's really a thing to behold -- tab tab tab tab tab. Unfortunately, fast it is not. It takes 2-3 seconds to size and render even a marginally complex interface.

So now I have to choose between Savannah and SourceForge for hosting it as a project. I don't know that much about Savannah's policies, but it kind of seems like they want you to know way in advance whether you want your thing to be part of the GNU project, and if you do, it had better have Texinfo documentation. Well I just started this thing a month ago! So maybe I'm leaning towards SourceForge at the moment, because they just don't give a...

Here's something that I'm having trouble working out -- if anyone reads this diary, maybe you can comment or e-mail me your opinion. So the XML dialects that I want to render (XUL, XHTML, etc.) all make the implicit choice of ECMA/JavaScript as their scripting languages. I'm not a huge fan of those languages, especially because they sort of presume a particular type of viewing apparatus (i.e., web browsers) so I've chosen Guile Scheme as an alternative -- maybe this is stupid, let me know what you all think -- but this means, I think, that I need to separate out these little scriptlets on an attribute level, so as not to break compatibility with the original XML specs for these languages. For example, a lot of XUL elements let you set an event handler for the "command" event by specifying ECMAscript code in the oncommand attribute. E.g.,

<button label="hello" oncommand="document.foo();"/>

So I figure I should put my Scheme-flavored oncommand in a different XML namespace, like so:

<button label="hello" xul-scheme:oncommand="(document-foo)"/>

That way, traditional XUL parsers can still interpret the XML without freaking out -- they can just ignore the "xul-scheme" namespace.

But it feels kind of... needlessly fragmented to me. And furthermore, in order to be able to do useful things in these little scriptlets, I need to implement a kind of DOM for Scheme. However, at the moment, my DOM functions are all built straight into libruin, which only renders stuff for ncurses. The ultimate goal in my doing all this was to create rendering support for my client-agnostic online gaming system, gzochi. So I'm also going to want, probably, a GTK+ version of this library. If that's the case, it seems a bit silly to build the Scheme DOM implementation into each of the libraries. I think it would make more sense to make something like SXML but for DOM -- that is, a fully-Scheme implementation of the W3C DOM. (The SXML people seem to think this is not terribly brilliant.)

What do all you people out there in computer-land think? I'm literally crying out for feedback here.

Got a lot of work done on the renderer -- for one, it now has a fledgling event-handling system. (I was pretty pleased with it before, but then I realized you could only look at the interfaces, not actually, you know, interface with them.) So now you can, for example, hit the TAB key and it'll "fire" a keypress event that an event handler listens to and it shifts the focus to the next element in the focus list.

It's awesome -- aside from the fact that it gets some colors wrong and still craps the bed when it discovers an element with less-than-0-width elements.

I also came up with a name for it -- libruin, the RUIN standing for Renderer for User Interfaces in Ncurses. Anyone else got that one already? Speak up now or forever hold your peace... I'll do some more googling to avoid name clashes, and then I'm setting up a Savannah or SourceForge project. And then everyone can join in.

Finished refactoring my ncurses XUL renderer so that it relies on guile-lib's SXML instead of libxml2. I'd also like to remove the libcroco requirement, but that isn't going to happen just at the moment -- because I need to come up with a name for this thing!

What would you guys call a UI framework for ncurses that can render a whole bunch of different XML interface markup languages and provides a DOM event-handling interface in Scheme? I was thinking 'ncanvas', but a quick googling reveals that to be a part of the KDE API.

nrcurses (Newer Curses)?