Advogato blog for rotty

Docs, features and babbling

Wed, 12 Aug 2009 18:12:00 GMT

sbank Tutorial

There's now a tutorial for sbank; this is work-in-progress, but I'd be happy about any suggestions on how to expand it and what to focus on.

New IRClogs features

Also, I've been brushing up my IRClogs webapp recently; it now features:

Showing a configurable amount of context around search hits, so you can make more sense of search results without having to go back to the page for that day.
Matching phrases in the search results are now highlighted.
Each search result entry now links directly to the corresponding day-page entry.

See this link for an example that shows off the features listed above. On the non-user-visible side, there's now support for gzipped logs, which saves a considerable amount of space, just

gzip
  -9

the older log files — this should also work while the IRClogs server is running.

Ruby babbling

I'm using feed2imap to get all those RSS and Atom feeds into my beloved MUA. As I run spam filtering, and split incoming email into Maildir folders on a small server at home (in a setup involving SpamAssassin, Postfix and scmail) and serve those folders over IMAP (using Dovecot), I've decided to add Maildir support to feed2imap, so I no longer have to place my IMAP password in feed2imap's plain-text configuration file.

As feed2imap is implemented in Ruby, this has provided me the opportunity to get my feet wet (or rather moist) in this language. Having a good grip on Python and Scheme, my one-word summary so far would be: Unsurprising!.

If you're interested in the patch, have a watch on the bug report — I'll attach it there once it's in a reasonable shape.

Shiny New Blog

Sun, 12 Jul 2009 14:17:51 GMT

While I had a WordPress-based blog quite some time ago (which I rarely made use of), I was never quite content with it; I wanted something more simple, something that does not need a whole LAMP stack, doesn't require tinkering with mod_rewrite, and ideally has a codebase that I'd want to hack on (which definitely rules out WordPress, which is written in PHP).

Tekuti in R6RS clothing

Well, meet Tekuti. It's a lean blogging engine using Git as storage (so you get hot-backup and versioning for free), and, best of all, it's written in Scheme. Since I already have a Scheme HTTP server running for IRClogs, I decided to hack Tekuti so it could run in the same process; this involved porting Tekuti to R6RS and adding code to interface with the web-server (the original Tekuti only provides its services via the mod_lisp protocol). I must say that working with the Tekuti code was a joy; after getting it running using the mod_lisp protocol under Ikarus and Ypsilon, I could add the HTTP integration without touching the rest of the code at all. Kudos to Andy Wingo for writing this nice piece of code.

Yet another Scheme Web server

To avoid code duplication, I re-factored the ad-hoc libsoup-based web server that drove the IRClogs application into its own library. The interface provided by the library is very much inspired by the SUnet Web Server and hides libsoup entirely.

So, how does my script for running IRClogs and Tekuti inside the SPEnet HTTPd look like? Well, leaving out the customization and library imports, like this:

(define (rforge-request-handler irclogs)
  (alist-path-dispatcher
   `(("blog" . ,(tekuti-handler))
     ("irclogs" . ,(lambda (path request)
                     (irclogs 'dispatch path request))))
   (rooted-file-handler *static-dir*)))

(let ((irclogs (make-irclogs *irclogs-config*)))
   (httpd (make-httpd-options
           with-port *port*
           with-request-handler (rforge-request-handler irclogs))
          (lambda (httpd)
            (irclogs 'update-state)
            (httpd/add-timeout httpd 60 (lambda ()
                                          (irclogs 'update-state)
                                          #t))))))

Running the above code, with *port*, *static-dir* and *irclogs-config* appropriatly defined, will launch a completely stand-alone web server that will serve IRC logs, run a Tekuti blog instance, and provide static content from *static-dir*.

Code

You can fetch the R6RS port of Tekuti via git:

git clone git://gitorious.org/tekuti/tekuti.git
git checkout t/r6rs/do-port

22 Oct 2005

Sat, 22 Oct 2005 02:02:23 GMT

My blog is now wordpress-powered, please adjust URL.

13 Oct 2005

Thu, 13 Oct 2005 21:03:20 GMT

A Guile rant

I began to program in Scheme using the Guile interpreter. While I knew that its not blazingly fast, its the official GNU extension language, and as feeling quite close to the goals of the GNU project and the FSF, I felt confident it was the right choice, also considering the supreme quality of other GNU software, such as the GNU toolchain (GCC, binutils, gas) and the Gimp, to name just a few.

So, feeling confident with my choice, I started to crank out code and eventually even took over maintainership over a Guile application, namely G-Wrap, after giving it a complete brush-up code-wise. When Tom Lord, of GNU Arch fame (and coincidently a former Guile maintainer), announced the Pika project (a from-scratch Scheme implementation, with ambitous goals), I decided to get on the mailing list and lurk, and later got opportunities to contribute a bit. Unfortunatly that project stalled due to time constraints on Tom's side. Anyway it was a very valuable experience, as it opened my eyes to other Scheme implementations, foremost Scheme 48. Looking at its code base was a real eye-opener: as opposed to Guile, it was, except for a tiny amount of glue code, written in Scheme; its virtual machine is written in a subset of Scheme called Pre-Scheme that can be compiled to efficient C code, so you get most of the benefits of Scheme and the speed of C.

Around the same time I discovered Scheme 48, I got involved in conjure, a make replacement being written in portable Scheme. I split off the library code from it to form a separate project, spells. As spells is basically a layer above the individual Scheme implementations which hides away their differences and presents their features (foremost the module system, but also hash tables, file system access, ...) in a portable way, I gained some experience regarding the different module systems and how they compare, and I honstly must say that Guile's is basically unusable with macros. Here's why:

A decent module system allows for macro code to refer to bindings in the module they are defined in, without requiring these bindings to be also exported; imagine a macro that expands to a call to some helper procedure that should itself should not be visible from outside the module. A real-life example are the reference implementations of SRFI-34 and SRFI-35, which define the helper procedures guard-aux and type-field-alist->condition, respectively. This deficiency (which is not present in Scheme 48, PLT Scheme, Gauche and probably most other Schemes) is really unfortunate, as it makes modules, when used with macros, a lot less usable. This, besides the total orientation toward interpretation and the codebase that is mostly in C are reasons why I'd recommend Scheme newbies also looking at other options before settling on Guile because it's the "official GNU extension language", as I did ;).

30 Jun 2005

Thu, 30 Jun 2005 09:02:19 GMT

Getting paid for OSS work!

I'm going to get paid for open source developement! Wooha! More specifically, the company I work for since 2 months is going to switch away from CVS as SCM tool.

We had a look several SCM systems, among them Subversion, GNU Arch and several commercial offerings, including BitKeeper :-0. The final contestants were GNU Arch and AccuRev. Subversion fell flat for its missing features (mediocre merging support, no distribution), and BitKeeper was not considered seriously because they don't even list prices at their site (which indicates a fairly high price tag, normally ;) and due to opposition from myself (for the obvious political reasons).

Well, finally the case was made for GNU Arch, and since it lacks a decent GUI (currently the GUIish guys here use WinCVS), it was decided to develop the GUI in-house, and as an open source project!. It will probably be developed using Python and GTK+, so it will run also on Windows (which is a requirement). Expect more news, including project announcement soonish.

18 Jun 2005

Sat, 18 Jun 2005 19:43:24 GMT

Scheme48 fork update

Mike Sperber finally reviewed my patches; they unfortunatly were not deemed appropriate for the Scheme48 distribution, see this thread. Hopefully these issues can be sorted out in the not-to-far future. If you also need the one or other features from my hacks so far, and are adventurous, you can conact me on #scheme on freenode for help with getting and building my fork.

Writing portable Scheme programs with scmxlate and spells

For the conjure project, we are using scmxlate to make it portable across multiple Schemes. For that purpose, I slightly extended scmxlate and built a kind of meta-module system on top of it. Here is how that looks like:

You write a description of the modules your application or library is made of; this is done in a sightly extended subset of the Scheme48 configuration language. For example (from this page, see there for more details):

 (define-structure conjure.foo.bar (export qux baz
					  ((froboz fribnitz)
					  :syntax))
  (open scheme srfi-1 srfi-13 conjure.util.files)
  (dialect (guile (open ice-9.syncase))
           (scheme48 (open extended-ports)))
  (files (foo basic-bar)
         (foo bar)))

This defines the module conjure.foo.bar, which exports the identifiers qux and baz, as well as the macros froboz and fribnitz. The open clause means: this module is written in R5RS Scheme (scheme), plus additionally using srfi-1, srfi-13 and the conjure.util.files module. The dialect clause can be used for specifiying additional modules needed for the dialect-specific code for the module. Finally, the files clause tells us that this module consists of the files foo/basic-bar.scm and foo/bar.scm.

This file then gets processed by scmxlate, generating a file with the right module definitions for the selected target dialect, e.g.:

(define-module (conjure foo bar)
  #:use-module (srfi srfi-1)
  #:use-module (srfi srfi-13)
  #:use-module (conjure util files)
  #:use-module (ice-9 syncase)

   #:export (qux baz)
  #:export-syntax (froboz fribnitz))

 ;; code for foo/basic-bar.scm and foo/bar.scm follows

will be generated for Guile.

We recently split scmxlate and the meta-module systeem out of conjure, see the scmxlate category in the conjure archive, so it is available for other projects. Now the split-out of the general purpose modules into a separate project -- SPELLS, (S)pell's a (P)ortability (E)nvironment (L)ibrary for (L)ots of (S)chemes -- is in preparation. This library will further aid writing portable code, by providing a consistent interface to functionality that has different APIs in different Schemes. These modules are already there:

spells.util.pregexp: Dorai Sitaram's portable regular expressions
spells.util.named-args: Conviniently create procedures with named arguments
spells.util.table: Hash tables
spells.util.condition: SRFI 34 and SRFI 35
spells.system.file: Lots of file-related proedures, e.g. copy-file, directory?, ...

All of those are implemented for all of mzscheme, Guile, Scheme48 and Gauche, using native functionality where available. Other modules will surely follow, a project has been requested at Gna! to facilitate contribution. The spells library will also be used by my upcoming port of G-Wrap to Scheme48.

16 Jun 2005

Thu, 16 Jun 2005 12:19:26 GMT

Status of Scheme48 hacking

Over the last months, I've started several hacks on Scheme48. My interest in Scheme48 was initially sparked by Jivera, who started to bring a Pika-style C API to Scheme48.

The features/projects I've been working on:

The new buildsystem: it is now easily possible to build Scheme48 completely from scratch, bootstrapping it with another Scheme48 installation.
R5RS-compatible keywords (e.g. #:foo). There seems to be some controversy about the usefulness and "good taste" of keywords, but I need them for my GOOPS-compatible TinyCLOS version.
Relaxed string escaping, i.e. allow e.g. (display "Hello World!\n").
A scheme48 executable that allows command-line access to the exec language; you can do
```
scheme48 -cl packages.scm -o mystructure
```
which is equivalent to typing:
```
,config ,load packages.scm
,open mystructure
```
at the Scheme48 prompt.
Some initial work on a PLTish FFI. See Foreign Interface for PLT Scheme for how this FFI looks like. The cool thing about it is that you don't have to delve into C for creating bindings anymore.
Porting Kali Scheme. This has just started; so far, I've been able to get the Kali VM to build on top of Scheme48 1.2, but it is probably far from working.

Most of the above is still not polished and not ready for release or even sending patches upstream. I have, however, submitted some very simple patches to the Scheme48 mailing list, and got no response from the maintainers. Should working with them not work out, I might have to create my own fork of Scheme48. In fact I have forked already, but if I can't get (parts) of my stuff into mainline Scheme48, I might start to actively push my fork as "extended Scheme48" or with a new name.

13 Jun 2005

Mon, 13 Jun 2005 21:06:39 GMT

GNOME for Scheme48

I've decided to laying the foundation for creating bindings of the GNOME software stack for Scheme48, specifically: create bindings for GLib/GObject.

At the core of GNOME, there is the GLib Object System (GObject), on top of which GTK+ and the rest of the developer platform are built. Thanks to the header scanning tool h2def.py, which creates a S-Expression representation of the API, you are able to create bindings for any GObject-based library, once you got the core bindings right.

I have a rough plan how to do this; basically I plan to fork guile-gnome and reuse the existing infrastructure (e.g. .defs processing). The Guile-GNOME fork will drive a G-Wrap that's capable of emitting code for the upcoming Scheme48 FFI. Work on G-Wrap/Scheme48 has already progressed to a degree where it's possible to turn to the GObject bindings and fill out the holes as needed in the process.

The plan is also to make the resulting bindings "mostly compatible", so that programs written for Guile-GNOME will also work with Scheme48-GNOME and vice versa. Since Scheme48 has no built-in object system, and the object system would have to be compatible with GOOPS (Guile's object system) anyway to achieve source-compatibility between the bindings, I started working on a GOOPS-compatible version of TinyCLOS.