Older blog entries for joolean (starting at number 16)

Re: lkcl's article, I think the terms of the argument are a bit off. Free Software "wins" when there are computing platforms which permit interoperability, because this interoperability allows people to choose Free Software solutions over proprietary ones. Internet services do not all need to be implemented with Free Software in order for Free Software to win.

lkcl seems to be making the argument that services are the new desktop PC / operating system, which is not really a valid comparison. Go back to RMS's parable of the printer drivers -- Free Software is threatened by proprietary hardware and software platforms because they tend to limit the effectiveness of Free Software platforms. In the case of the AI lab printer, the owner of the driver source code's refusal/inability to hand over the code deprived the lab of important freedoms related to the ownership of the printer. Having a proprietary software platform that actively discourages interoperability (e.g., Samba) as the dominant OS is Bad, because it means that you, as a Free Software author (and, deep down, really just a dude who wants his printer to work right) have a much harder time getting what you want, if you can get it at all.

But the services model of software has a significantly different business model. Whereas Microsoft needs Windows to stay "closed" in order to keep people hooked and sell the next version of Windows, Google has the liberty to provide an open API for their services, because as long as you're looking at their ads, it doesn't really matter to them how you use the service. Free Software doesn't need to replace Google Maps on the server side, for example, in order to "win" -- it just needs Google Maps to allow interopability on the client side so that people who want to innovate / experiment / get work done their way can do so. And that's been working out okay so far. And as long as people want to continue using their Free Software desktop platforms, they can do so.

SCSS

I just released version 0.2.0 of SCSS! Go check it out at http://www.nongnu.org/scss/. I fixed a ton of bugs that basically made 0.1.1 useless for any non-trivial queries.

However, just after putting it out there, I've run into a bit of a thorny problem. The CSS specification says that style information specified explicitly as the content of an attribute (for example, the "style" attribute in HTML) basically overrides whatever you got out of the natural flow of the cascade. My initial plan to handle this for RUIN was to store this extra information "out of band" in a special field in the intermediate representation I maintain for each element node and override the result I get from my SCSS query with it if it's there, but that won't work -- it fails to take inheritance into account, since SCSS doesn't know about it.

For example, let's say I've got a distant parent element with some explicit style attribute style. This style info won't show up in a query on the cascade because it's not part of the cascade, but it also won't show up if I check the current element, because it's not attached to the current element, it's attached to the parent. But I can't just surf up the tree and check all the out-of-band style data because if there was a closer ancestor that contained in-band (i.e., in the cascade) style information, that info should override the explicit style. And so why am I using SCSS in this case? So I'm still thinking about this one. Maybe a re-read of the spec will offer the prospect of a loophole.

What I really need, I think, is a predicate that'll tell the caller whether a query would need to inherit or use a default to provide style information about a node... but that just seems like it defeats the whole purpose of the cascade.

Re: mako's article, I'm not certified enough to post a comment, apparently, but: It was always my impression that the goal of CC was not expressly to encourage the freest possible exchange of media but to give independent producers an easier way to "free" their work. That is, given the choice between reserving all rights by default on a particular piece of work and venturing out into shaky (from the artist's point of view) legal territory by attempting to dictate the terms of a license on your own (or simply releasing the work into the Public Domain), the artist will choose the easier and safer (and most restrictive) of the two and thus make his/her work less available in the process. The Creative Commons most important tools are its ready-made licenses, which allow media producers, particularly independent ones without the benefit of legal counsel, to offer their work in the freest way they're comfortable with while still enjoying the protections of copyright law (and having the opportunity to make a profit).

That is all.

SCSS

Since getting the lexer and parser in place, implementing the rest of SCSS has been relatively trouble-free, though deciding what, exactly, the API should offer was a bit of a challenge. Hopefully I've got all that stuff ironed out at this point. I can do relatively simple queries against stylesheets and SXML nodes now, including stuff like matching:

foo[bar="baz"]:first-child { color: black; }

to

<snurk>
  <foo bar="baz">
</snurk>

I've registered it as a project on Savannah, so hopefully it'll take off the same way SDOM did. Right. Speaking of which, though...

SDOM

...is still in the shape it was a few months ago, namely that it's good enough for what I wanted to use it for, but I have no idea of its quality as a whole and may never (until I decide to use it for something more than I am right now). I know for a fact that some parts of it will not work correctly (e.g., queries and methods related to node ordering within a document). I've already posted on Savannah, but if anyone here is interested in or wants to learn more about W3 standards or Scheme, there's some fairly easy work to be done fleshing out the test suite for SDOM. You'd basically be converting applicable tests from the W3C's Java test suite to Scheme, which is pretty easy. Respond to the job posting on the Savannah project page if you think you can do this.

SCSS

So I've spent the past several weeks tooling away at a lexer / parser to use with SCSS. I wanted something small and (hopefully) portable. Guile's old (lang lex) module was looking good -- it's no longer part of the distribution, but it was small enough to just snarf into my project wholesale. Unfortunately, it depended on Tom Lord's Rx library, and having my Scheme CSS parser depend on a rather scarce library of C code was a big no-no. So I decided to rewrite the requisite parts of Rx (basically regular expression to DFA conversion code) in Scheme -- no easy task as I discovered. I got depressed, totally stressed out. My regexp->dfa parser got to the point where it could more or less convert a well-formed regexp to an S-expression representing a DFA, and you could feed strings to it and have the states change, but for some reason it just didn't work with (lang lex). My desperation led me to start my module hunt from scratch. Thanks to providence, or, I don't know, something, I came across Silex. About an hour and a half of work later, I'm parsing CSS into S-expressions and handling errors. It's a wonderful thing. Thank you, Danny Dubé!

SCSS, Here I Come

Well, I finally got automatic table layout working in libRUIN (a fairly major coup), so I decided to reorganize it a bit, particularly to eliminate the complexity related to mapping document structure to libRUIN's "intermediate language," making it more automatic based on the stylesheet cascade. Unfortunately, this lead to the discovery that libcrocodoes not meet my needs at all -- most importantly because, as I failed to understand until recently, CSS depends on an XML/DOM interface to handle selectors based on relative node position. libcroco uses libxml2 to handle this, and since I rely on SDOM and SXML for that kind of thing, it wasn't meant to be. Also, though, libcroco's documentation could be a bit better; maybe I'm misunderstanding its target audience, but the Doxygen might be easier to understand if so many of the internals weren't exposed. I still can't figure out how you'd go about obtaining a property value for a particular selector in the cascade.

Yeah, so I'm going to have to take a stab at implementing the cascade API in Scheme. Obviously it's a lot less complicated than DOM, and most of the CSS spec has to do with the visual model, which I've got down in libRUIN, but I'm still not thrilled about having to start another new project from scratch. I'm beginning to feel like a bit of a crank, like I'm pissing into the void, as it were.

Maybe I was naive or didn't read the spec closely enough to grok these things immediately, but here are a couple of CSS details that took me a long time to get my mind around. Maybe they'll save you some fretting when you're doing some CSS-related programming.

1. CSS doesn't squish content! References to the wisth od the containing block are only for resolving lengths specified in terms of percentages. This also means that you're perfectly free to specify percentages in excess of 100% or percentages for the various width / height components that add up to more than 100%. If the requested / required size of content is greater than that available in the containing block it just spills out or gets cropped, depending on the 'overflow' property for that block.

2. This is a trivial point, but the 'width' property only specifies the width allotted to the element's content -- the total width of the element also includes border width, padding, margins, and outline.

3. CSS tables provide display-types for both columns and rows, so you might be inclined to think that you can specify table cells as the children of either, but you can't -- only rows can contain cell elements. Columns (and column groups) can only be used to specify properties that get inserted into the cascade for cells in the appropriate positions in their respective rows.

Thanks for the certification, lerdsuwa.

libRUIN

I finally solidified the libRUIN code enough to add it as a project on Savannah (project page here). The time I've been spending on it is mostly devoted to rewriting the layout algorithms to be more in tune with the W3C CSS algorithms -- I'd basically fudged it all in earlier revisions. I'd spent a lot of time writing a not-inelegant sizing algorithm that produced reasonable layouts in most circumstances but rather squished things in certain cases in a very un-CSS way. So now I've separated the layout algorithms according to 'display' property and I've got block and inline layout working. Now it's on to table layout (shudder).

Boy, it's been a while since I've posted here.

SDOM

There's a new development release (0.1.2) available at http://www.nongnu.org/sdom/. Many thanks to everyone who answered my sometimes naive questions in #guile and #xml on Freenode!

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!