Older blog entries for joolean (starting at number 52)


Sent the final patches in (including the Scheme implementation stuff and the test suite) on the 13th. Hopefully this'll be the last go-round -- well, the last go-round before it's done, you know, as a feature. There're certainly some bugs in there.


Ludovic just committed a patch I made to Guile's reader a while back that lets you use postfix colons to signify keywords (e.g., foo:), and tacked on a trivial implementation of SRFI-88 that just sets the appropriate `(reader-options)' flag. Not having compatible keyword-parsing was standing in the way of some other cool stuff, notably SRFI-89 (Optional positional and named parameters) and SRFI-90 (Extensible hash table constructor). I'm working on a SRFI-89 implementation now in the form of a conversion layer for Guile's (ice-9 optargs) module.

In other exciting(-ish) news, it looks like Ludovic and Andy Wingo are going to revive Guile-VM, possibly for inclusion in 1.10. Rock!


Who's coming to the FSF Associate Members meeting tomorrow? Come on, Advogatters, let's see a show of hands. (I'll only be staying 'til 4:00, though, 'cuz I have to hop the Acela back to NYC to catch The Pogues!)


Whee -- the second of the three SRFI-18 patches has just been committed to Guile HEAD. This one was a doozy, and included a bunch of additions to the core threading API. Specifically, the following functions are now available for use: scm_join_thread_timed, scm_thread_p, scm_make_mutex_with_flags, scm_lock_mutex_timed, scm_unlock_mutex_timed, scm_mutex_p, and scm_condition_variable_p. In addition to providing the groundwork for a full Scheme implementation of SRFI-18, I think these functions bring Guile's threading API comparably up to date with most other modern, you know, commodity language platforms.

One of the neat things that came out of this round of discussion and debugging is that, as kind of pointed out by Marc Feeley's SRFI-18 spec, waiting on a condition variable is actually a special case of mutex unlocking.

Next up: The Scheme parts of SRFI-18. This should come fairly quickly, given that it's already written -- and that Scheme's far less brittle than C when it comes to refactoring.

The big blue (server) room

I spent yesterday (Saturday) in the office, helping my boss build a rack for our servers, something neither of us had ever done before. The process involved completely dismantling the network used by our company (and the two other companies we share space with); dismantling the existing rack; building our new rack; hastily purchasing underpowered power tools to drill holes into the hardwood floors to brace the thing; painstakingly hooking everything back up according to the notes I'd taken; having nothing work right; panicking; finally realizing at midnight that there was a bad Ethernet cable between the T1 and the switch; celebrating.

Woke up at 2:00 PM today, still groggy, all the muscles in my back cramped to hell.


Because this is still novel for me: Neil just committed the first of the trifecta of patches necessary to add SRFI-18 support to Guile. This one includes fixes for a couple of deadlocks related to thread creation and cleanup. We discussed the inclusion of a fix for another deadlock related to waiting a condition variable using an inconsistent set of mutexes, but I think that one's going to have to wait. Next on the docket: The enhancements that provide the C foundation for the pure Scheme SRFI-18 implementation.

Hey-O! It's been a real long time. I got a new job, and now I am busy all the time. Happy New Year, software hippies!


A lot of work, but not a whole lot of progress on this front. Submitted an implementation, which involved a lot of changes to Guile C and Scheme; Neil Jerram wisely pointed out that it really belonged in several separate patches. What ought to go in each of them has been a subject of discussion on guile-devel for the past month or so. I think we are making some headway -- I will keep the 'gato informed.


Over the past few weeks I've done a lot of work in Guile. Highlights:

  • SRFI-18: Rewrote the fat mutex system and added timeouts for a number of the blocking thread calls in C -- this provided the necessary support for the full Scheme implementation of SRFI-18 I wrote. Also did a test suite. An exhausting experience!
  • SRFI-88: I came up with a small patch that lets Guile's reader understand the colon-postfix format for self-quoting keywords.
  • Snowflake: A small, buggy Guile module for converting and loading snowballs "natively" -- that is, as if they were Guile modules.
These projects have given me a newfound appreciation for how robust Guile's codebase actually is. But I'd like to get back to my other projects now, specifically libRUIN, which I was on the verge of releasing a few months ago when I made one of my periodic decisions that SCSS was too slow to server as its CSS system... which led me to want to seriously profile it... which meant I wanted to use MzScheme's profiling tools instead of statprof... which meant I had to port it to PLT... which got me interested in all of these cross-interpreter compatibility issues in the first place. It's funny how attention works.
20 Oct 2007 (updated 20 Oct 2007 at 22:51 UTC) »
Today I am a man

...and it only took 26 years! Ludovic Courtès has just applied my thread cancellation patch -- my first patch accepted, ever -- to the HEAD of GNU Guile. It took me forever to get working, and then another week or two of hand-wringing over copyright assignment and the disclaimer from my employer, but it's in! Thanks are due to Ludovic, whose patience was... epic.

This paves the way for the implementation of SRFI-18 that I'm working on, which I think will be pretty useful in terms of making Guile more competitive with other Scheme platforms.

bcully: I'm pretty sure ncm is an American. But he's not a New Yorker.

ncm: As a life-long New Yorker myself, I'm just a little curious as to what you think the response of New Yorkers was. (You may not be aware, but this town is overwhelmingly liberal, politically speaking.)

What was the response of New Yorkers?


SCSS 0.3.0 is out -- I completely rewrote the grammar, mostly so that I could make the parsing system a bit more... reentrant for error-handling purposes. The S-exprs used to represent stylesheets are now very similar to the ones that WebIt! uses, though there are some incompatibilities when it comes to CSS2.1-specific stuff. And there's some other stuff, too. The NEWS file in the distribution will fill you in. Tarballs are at http://www.nongnu.org/scss/

For the next release, I'd like to improve the performance a bit more -- I feel like using regexps for validating and querying style values is overkill in most cases, though in others it's practically necessary. So... not sure what I'm going to do about that. I'd also like to add SAC support, but there may be some linguistic / architectural hurdles there.

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