A week of ICRA’10

The first week of May I was in Anchorage, Alaska at the 2010 IEEE International Conference on Robotics and Automation (ICRA’10). In short, it was an awesome event amidst great scenery, but for my tastes it was way too large and too far away. (The US customs officer even asked me why they decided to hold the event so far away from the rest of the world.)

View from convention center balcony

View from convention center balcony

Size

Anchorage welcomes its new robot overlords

Anchorage welcomes its new robot overlords

There were roughly 1,600 registered attendees, so the event was spread out over two big convention centers. All of Anchorage’s hotels were packed with roboticists. It wasn’t long until local cafetarias were playing into this.

More than 2,000 papers were submitted submitted, of which 857 were accepted. While that’s an acceptance rate of only about 40%, it’s still one heck of a lot of papers! Instead of actual paper proceedings we received a booklet called the “Conference Digest”, containing a single slide for each paper. With six slides on each side of each page, this thing is still about the same size as the full proceedings to SoCG or EuroCG. The actual proceedings came on a DVD, and my tablet PC lacks a DVD drive, so I have not been able to look at them yet. But I presume that there is still a lot of space left on the DVD, so I wonder why there is a 6-page limit on the submitted papers. For the initial versions it makes sense, as this reduces the reviewing load, but why not allow larger final versions?

Diversity

Image from the slides of my talk

Image from the slides of my talk

To accomodate all these papers there were thirteen parallel tracks; but really, it felt more like thirteen parallel conferences. Robot-building disciplines like mechanical engineering, electrical engineering, and computer science come together with application areas for robotics such as the life sciences, geology, logistics, and manufacturing. It seems like you could present research on just about any topic (“X”) at ICRA, provided you word it the right way (“X using robots”). Heck, I attended one talk that went into anthropology! While it was nice to get a glimpse of what is happening in other fields, and how they all relate to one another, most speakers assumed the audience already had intimate knowledge of their specific field and its acronyms. I felt a bit left out, most of the time, and wondered whether that described half the audience or just me.

Workshops

Willow Garage's PR2 checking us out

Willow Garage's PR2 checking us out

On Monday I attended the workshop on Best Practice in 3D Perception and Modeling for Mobile Manipulation. My main take-away was that we’ve come farther than I thought, and that the state-of-the-art is all freely available as open-source libraries. You just download the ROS robot operating system and OpenCV computer vision library, and you’re all set. In a couple of lines of code you can combine a stereo image into a single image where you know the distance of each pixel to the camera. A bunch more lines and you can build up a fully textured 3D model of the world from a stream of these images, captured as the robot moves around.

Of course, that’s when the tricky part starts of determining what all the objects you are seeing are, and what you should do with them. This is where the open problems are. The rest of the workshop had some talks on these. All were interesting techniques for different kinds of special cases, but we are still nowhere near dealing with the full variety of objects humans deal with on a daily basis.

Technical sessions

Tuesday till Thursday were exhausting. A 12-minute talk every 15 minutes from 8:30 to 19:30, except for breaks and the occasional plenary or keynote speakers who had longer talks. The sessions ended earlier on Wednesday because of the conference banquet, but that’s still more than 70 talks I attended. For many of them I only vaguely understood the problem that was being solved, and usually had no idea what the state-of-the-art was and how the presented method improved on it. Still, there were a couple of talks I found really enjoyable.

  • My own talk was on pushing a disk with a disk-shaped robot, and it turns out there were two more talks on the subject of pushing (though all in different sessions, for some reason). In A Dipole Field for Object Delivery by Pushing on a Flat Surface, Takeo Igarashi presented a very simple and elegant algorithm for the same problem I looked at, and even showed how it worked with actual Roombas. The algorithm cannot (yet?) deal with obstacles, but I had a nice chat with him afterwards about future work. In Dynamic Pushing Strategies for Dynamically Stable Mobile Manipulators, Pushkar Kolhe (how awesomely appropriate is that name?) studied how a differently designed robot should push or pull in order to exert the most force. It turns out that pulling is actually better than pushing.

  • In Adaptive Multi-Robot Coordination: A Game-Theoretic Perspective, Gal Kaminka talked about a new protocol for moving robots to avoid colliding with each other. They could easily have had the paper accepted after just showing through experiment that their method works, and I would have thought nothing special of the talk. Instead, they went the extra mile in using game theory to also show why the method works.

  • In Avoiding Zeno’s Paradox in Impulse-Based Rigid Body Simulation, Evan Drumwright explained how physics simulation libraries such as ODE and Bullet get resting contacts wrong, and presents an alternative method that has been implemented in a new physics library called Moby.

  • My favorite talk actually won the best paper award in its category. In Gesture-Based Human-Robot Jazz Improvisation, Guy Hoffman presented his jam sessions with Shimon, a marimba-playing robot. Rather than play a preprogrammed piece of music, it improvises based on what the human is playing. The result sounds great, and the addition of a head that head-bangs to the beat was a nice touch. It really looks like it gets into the groove!

Tutorials

On Friday morning I went to the workshop on Guaranteeing Safe Navigation in Dynamic Environments. All great talks on how to avoid collisions among moving obstacles, each illustrated with pretty videos. Jur van den Berg showed an especially impressive video on simulating human movement in crowds.

Friday afternoon I attended the tutorial on Real-Time Planning in Dynamic and Partially-Known Domains. It emphasised how almost any planning problem can be reformulated as finding a path in a graph where edges are labeled with a cost and/or probability. The obvious way to do that is using A* search, but I had no idea how many different variants of A* have been developed to deal with different kinds of problems. Almost a dozen of them were explained, having funky names like Fringe-Saving A*, Lifelong Planning A*, and Anytime Repairing A*.

Homecoming

The A* tutorial at the end was actually the first time during this conference that I saw someone use theorems and complexity theory. What’s perhaps a little disturbing is that that actually made me feel relieved, as if I had come home from a long ardous journey through the wastelands. That’s not to say that the other talks at the conference were bad, but they were rather different from the kinds of talks I’m used to. I think computational geometry may have spoiled me a bit in that regard. I’m used to talks with clear, precise definitions and theoretical analyses. It’s easy to forget that in the “real world” one deals with vague concepts and must rely on experimental validation.

Posted in Computational geometry | Leave a comment

EuroCG 2010 in Dortmund

Last Wednesday evening I returned from EuroCG 2010 held in Dortmund, Germany.  The weather was nice throughout the conference, and so were the food and drinks. (Although some people did not seem to care for the coffee in the lobby, but I’m not a coffee drinker.) Jan Vahrenhold and his team made this into a very smoothly run event, even in the presence of some unforeseen cancellations of talks.

A lot of interesting topics were presented in talks ranging in quality from moderate to excellent. I have to give special mention to Amit Chattopadhyay. When the speakers for the talk 2-Factor Approximation Algorithm for Computing Maximum Independent Set of a Unit Disk Graph” could not attend the conference, he offered to give the talk instead of letting it get cancelled. Not being one of the authors, nor being affiliated with them, he just read their article and their slides a day in advance and gave a talk on-the-fly. Kudos!

Fast-forward sessions

As decided by vote at the business meeting of EuroCG 2009, this year’s EuroCG was the first to have fast-forward sessions. In these short sessions, all conference attendees are together in one room. The speakers of the next two parallel sessions get 60 seconds each (with slides submitted in advance) to promote their talks. There is a coffee or lunch break before the actual parallel sessions start, and then the process repeats. This way, attendees are supposed to be able to make a more informed choice about which talks they want to attend.

This notion stolen from inspired by SIGGRAPH was still a bit unfamiliar to both organizers and speakers. During the first few fast-forward sessions the speakers were asked to go in “column order”, that is, first all the speakers of session A, then all speakers of session B. At the suggestion of several attendees, this was changed to “row order” so that “competing” speakers went one after another. This order was then kept for the rest of the conference.

In both orders, the speaker of session A always came before the parallel speaker of session B. This seemed unfair to me, but no one present seems to have used this to their benefit. More generally, I think most speakers (myself included) did not think the fast-forward through from a strategic point of view. My parallel speaker even had a slide with the title of our paper on it, saying something to the effect of “this guy is speaking in parallel to me, and his talk will surely also be nice”. Certainly a nice gesture , but I’m not entirely sure why someone would do this except to get a smaller audience. ;)

All in all, I quite like the concept. Skimming the proceedings in advance says something of the topics, but not of the speakers. The addition of fast-forward sessions thus gives one this extra variable by which to decide which talks to attend. At the business meeting, the vote was n-3 against 3 in favor of keeping the fast-forward sessions, so they will be used again at EuroCG 2011 held in Morschach, Switzerland.

Keynote speaker

Although all the invited speakers gave excellent talks, the one by Timothy Chan was the most memorable to me. With his inimitable enthusiasm he gave a one-hour talk on Instance-Optimal Geometric Algorithms.

He explained the concept using the example of computing 2D convex hulls. For some, “easy” sets S of n points there are algorithms to compute its h point convex hull in O(n) time, while for other, “hard” point sets different algorithms with a running time of O(n log h) are known to be optimal.
"Easy" and "hard" point sets for computing the convex hull
Timothy defined a function H (somewhat similar to entropy) so that H(S) is a number that measures how “hard” it is to compute the convex hull for point set S. More precisely, he proved that there is a Ω(H(S)) lower bound for computing the 2D convex hull in the multilinear decision-tree model, by a simple and elegant adversary argument. He also showed that a slight modification of the Kirkpatrick-Seidel convex-hull algorithm yields a running time of O(H(S)). Thus its running time (up to constant factors) is as good or better than any other 2D convex hull algorithm that does not depend on the order of the points.

Timothy ended the talk with applications of the same technique to other problems, which in some cases did require new algorithms, such as for 3D convex hull. All in all a very impressive talk on some very impressive research, the paper for which can be found on Timothy’s website.

Posted in Computational geometry | 1 Comment

Xournal on Windows

Screenshot of Xournal running natively on Windows Vista

Screenshot of Xournal running natively on Windows Vista

Xournal is a free software note-taking application similar to Microsoft Windows Journal. It used to be Linux-only, with MacOS and Windows ports on the TODO list. But as you can see it is now possible to run it on Windows. Hopefully a nice installer can be created for it, like the ones for Inkscape and Gimp, but for now the process is rather tricky and involves editing and compiling Xournal’s source code.

Update: Denis Auroux, the author of Xournal, has graciously incorporated my code changes into Xournal and made an official Windows release available on the Xournal homepage. Go try it out!

Here’s what I did:

Step 1: Setting up the development environment

We’ll need to set-up a compiler and install all the libraries that Xournal uses (directly or indirectly) before we can compile its source code. Here are the software packages I installed with their version numbers (newer versions will probably work, significantly older versions might not), website addresses (I’d provide direct download links, but they’ll probably end up as dead links as soon as version numbers change), and where I installed them (of course, you’ll probably want to use different paths, unless your name is also Dirk):

MinGW + MSys, a minimalist Unix-like environment for Windows, for the C compiler and other build tools. These can be gotten from MinGW.org:

  • MinGW 5.1.4 (into c:/Users/Dirk/Programming/MinGW)

  • MSys 1.0.11 (into c:/Users/Dirk/Programming/msys)

  • perl 5.6.1_2-1 (into c:/Users/Dirk/Programming/msys/1.0)

  • libcrypt 1.1_1-2 (into c:/Users/Dirk/Programming/msys/1.0)

  • autoconf 2.63-1 (into c:/Users/Dirk/Programming/msys/1.0)

  • automake 1.11-1 (into c:/Users/Dirk/Programming/msys/1.0)

Some Gtk+ and GNOME libraries that Xournal uses for its GUI. These can be gotten from Gtk.org:

  • Gtk+ 2.16.5-20090731 development bundle (into c://MinGW)

  • Cairo 1.8.8-2 binary+dev package (into c://MinGW, overwriting the one from the bundle because the latter is apparently built without FreeType support)

  • FreeType 2.3.9-1 binary+dev package (into c://MinGW)

  • fontconfig 2.7.1-2 binary+dev package (into c://MinGW)

  • win_iconv 20080320 binary+dev package (into c://MinGW)

GNOME.org:

  • libgnomecanvas 2.20.1 binary+dev package (into c://MinGW)

  • libgnomeprintui 2.12.1 binary+dev package (into c://MinGW)

  • libgnomeprint 2.12.1 binary+dev package (into c://MinGW)

  • libart_lgpl 2.3.20 binary+dev package (into c://MinGW)

and more GNOME.org:

  • libxml 2.7.3 binary+dev package (into c://MinGW)

  • expat 2.0.1-1 binary package (into c://MinGW)

In the C:/Users/Dirk/Programming/MinGW/lib/pkgconfig/libgnomeprint-2.2.pc file we have to make a small change, replacing “pango” by “pangoft2″ on the “Requires:” line, so that in now reads:

Requires: libart-2.0 glib-2.0 gmodule-2.0 gobject-2.0 libxml-2.0 pangoft2

Step 2: Building libpoppler from source

The above gave us all the libraries Xournal needs, except for Poppler. I haven’t seen a pre-compiled binary version for Windows, so we’ll have to build it ourselves. We simply download the Poppler source code, start MSys, cd into the directory where we unpacked the source code, and type:

$ export ACLOCAL_FLAGS=-I/c/Users/Dirk/Programming/MinGW/share/aclocal/
$ ./configure --prefix=/c/Users/Dirk/Programming/MinGW/
$ make
$ make install

(Don’t type the dollar signs, they just indicate the MSys prompt.)

Step 3: Removing Xournal’s screenshot functionality

Once we’ve downloaded Xournal’s source code from the Xournal website, we can’t immediately compile it for Windows. Xournal has one bit of functionality that’s not implemented with the cross-platform Gtk+ library, but instead is implemented directly using X. This will of course not work on different platforms such as Windows.

The functionality in question is in the menu under “Journal > Background screenshot”. On Linux, it hides the Xournal window, then when you click anywhere it’ll bring back the Xournal window with an added screenshot of whatever window you clicked on. There is no way to implement this “clicking on a window”-mechanic in the Windows API, so a proper fix would be to change the mechanic to something different, as the Gimp guys have done. There one drags a crosshair onto a window.

I have not taken the effort to actually implement this different screenshot mechanic, as I don’t use it and it’s a lot easier to just remove it:

  • In src/xo-misc.c in the function hide_unimplemented at the bottom of the file add the lines

    #ifdef WIN32
      gtk_widget_hide(GET_COMPONENT("journalScreenshot"));  
    #endif

  • In src/xo-file.c at the top of the file, disable the X-specific #includes under Windows:

    #ifndef WIN32
    #  include <gdk/gdkx.h>
    #  include <x11/Xlib.h>
    #endif

  • In the same file, replace the body of the attempt_screenshot_bg function to do nothing on Windows:

    struct Background *attempt_screenshot_bg(void)
    {
    #ifndef WIN32
      ... old body here ...
    #else /* WIN32 */
      return NULL;
    #endif
    }

Step 4: Building Xournal from source

To build Xournal, we just use MSys as before, and inside the xournal directory type the following:

$ export ACLOCAL_FLAGS=-I/c/Users/Dirk/Programming/MinGW/share/aclocal/
$ ./autogen.sh
$ make

Step 5: Running Xournal

To run Xournal we can type

$ src/xournal

or just double-click src/xournal.exe in Windows’s explorer.

If all went well, you’ll see that Xournal “works”, but has some bugs. I’ll describe below how to fix each of these by editing Xournal’s source code. Recompiling (that is, repeating Step 4) will then give you a truly working Xournal. If you don’t want to manually apply all my fixes, you can just download the resulting source code.

Bug 1: The cursor is a big black square

Cursor is a black square and loading/saving doesn't work.

Cursor is a black square and loading/saving doesn't work.

For the pen and highlighter tools, you’ll notice that the cursor is always a 16×16 black square, regardless of the selected color. This is a defect in GDK’s Windows backend (Bug 541377). The function gdk_cursor_new_from_pixmap, which Xournal uses, will only give you monochrome cursors on Windows, and produces strange results when trying to produce a colored cursor.

While this should be fixed on the GDK end, a workaround is to just use different functions from GDK to create colored cursors. This can be done by putting the following code near the top in src/xo-paint.c:

#ifdef WIN32
gboolean colors_too_similar(const GdkColor *colora, const GdkColor *colorb)
{
  return (abs(colora->red - colorb->red) < 256 &&
          abs(colora->green - colorb->green) < 256 &&
          abs(colora->blue - colorb->blue) < 256);
}

/* gdk_cursor_new_from_pixmap is broken on Windows.
   this is a workaround using gdk_cursor_new_from_pixbuf. */
GdkCursor* fixed_gdk_cursor_new_from_pixmap(GdkPixmap *source, GdkPixmap *mask,
					    const GdkColor *fg, const GdkColor *bg,
					    gint x, gint y) 
{
  GdkPixmap *rgb_pixmap;
  GdkGC *gc;
  GdkPixbuf *rgb_pixbuf, *rgba_pixbuf;
  GdkCursor *cursor;
  int width, height;

  /* HACK!  It seems impossible to work with RGBA pixmaps directly in
     GDK-Win32.  Instead we pick some third color, different from fg
     and bg, and use that as the 'transparent color'.  We do this using
     colors_too_similar (see above) because two colors could be
     unequal in GdkColor's 16-bit/sample, but equal in GdkPixbuf's
     8-bit/sample. */
  GdkColor candidates[3] = {{0,65535,0,0}, {0,0,65535,0}, {0,0,0,65535}};
  GdkColor *trans = &candidates[0];
  if (colors_too_similar(trans, fg) || colors_too_similar(trans, bg)) {
    trans = &candidates[1];
    if (colors_too_similar(trans, fg) || colors_too_similar(trans, bg)) {
      trans = &candidates[2]; 
    }
  } /* trans is now guaranteed to be unique from fg and bg */

  /* create an empty pixmap to hold the cursor image */
  gdk_drawable_get_size(source, &width, &height);
  rgb_pixmap = gdk_pixmap_new(NULL, width, height, 24);

  /* blit the bitmaps defining the cursor onto a transparent background */
  gc = gdk_gc_new(rgb_pixmap);
  gdk_gc_set_fill(gc, GDK_SOLID);
  gdk_gc_set_rgb_fg_color(gc, trans);
  gdk_draw_rectangle(rgb_pixmap, gc, TRUE, 0, 0, width, height);
  gdk_gc_set_fill(gc, GDK_OPAQUE_STIPPLED);
  gdk_gc_set_stipple(gc, source);
  gdk_gc_set_clip_mask(gc, mask);
  gdk_gc_set_rgb_fg_color(gc, fg);
  gdk_gc_set_rgb_bg_color(gc, bg);
  gdk_draw_rectangle(rgb_pixmap, gc, TRUE, 0, 0, width, height);
  gdk_gc_unref(gc);

  /* create a cursor out of the created pixmap */
  rgb_pixbuf = gdk_pixbuf_get_from_drawable(
    NULL, rgb_pixmap, gdk_colormap_get_system(), 0, 0, 0, 0, width, height);
  gdk_pixmap_unref(rgb_pixmap);
  rgba_pixbuf = gdk_pixbuf_add_alpha(
    rgb_pixbuf, TRUE, trans->red, trans->green, trans->blue);
  gdk_pixbuf_unref(rgb_pixbuf);
  cursor = gdk_cursor_new_from_pixbuf(gdk_display_get_default(), rgba_pixbuf, x, y);
  gdk_pixbuf_unref(rgba_pixbuf);

  return cursor;
}
#define gdk_cursor_new_from_pixmap fixed_gdk_cursor_new_from_pixmap
#endif

Bug 2: Loading and saving doesn’t work

Using our Windows version of Xournal to try to load a file saved by Xournal on Linux gives an error message. What’s more, a file saved with our Windows version of Xournal gives an error message when trying to load it with Xournal on either platform!

It took me quite a while to figure this out, but the culprit here is that Xournal uses zlib in the wrong way, namely with text-mode I/O instead of binary I/O. This bug doesn’t show up on Linux because there text-mode and binary I/O are pretty much the same thing. On Windows, however, text-mode I/O converts a '\n' character into "\r\n" on writing, and vice versa on reading. This is fine for text documents, but not for binary files such as Xournal’s!

The fix is simple: replace text I/O modes ("r" and "w") by binary I/O modes ("rb" and "wb") in all the relevant gzopen, popen, and fopen calls. That is, all the calls in src/xo-print.c and all the calls in src/xo-file.c except for

  f = fopen(ui.mrufile, "w");

in save_mru_list, and

  f = fopen(ui.configfile, "w");

in save_config_to_file.

Bug 3: Fullscreen isn’t truly fullscreen

When I tried Xournal’s fullscreen mode, I could still see the Windows taskbar. This seems to be a bug in the gtk_window_fullscreen function on Windows. Inkscape’s fullscreen functionality does work properly, however, and that also uses gtk_window_fullscreen. It’ll take some more detective work to pin this down properly, but in the meantime it is fairly easy to work around.

  • In src/xournal.h, add two new fields to the UIData struct:

      gint pre_fullscreen_width, pre_fullscreen_height;

  • In src/xo-callbacks.c, in the on_viewFullscreen_activate function, replace the two lines

      if (ui.fullscreen) gtk_window_fullscreen(GTK_WINDOW(winMain));
      else gtk_window_unfullscreen(GTK_WINDOW(winMain));

    by the lines

      if (ui.fullscreen) {
        gtk_window_get_size(GTK_WINDOW(winMain), &ui.pre_fullscreen_width,
                                                 &ui.pre_fullscreen_height);
        gtk_window_fullscreen(GTK_WINDOW(winMain));
        gtk_widget_set_size_request(GTK_WIDGET(winMain), gdk_screen_width(),
                                                         gdk_screen_height());
      } else {
        gtk_widget_set_size_request(GTK_WIDGET(winMain), -1, -1);
        gtk_window_unfullscreen(GTK_WINDOW(winMain));
        gtk_window_resize(GTK_WINDOW(winMain), ui.pre_fullscreen_width,
                                               ui.pre_fullscreen_height);
      }

With all of the above fixes, compiling the resulting source code gives a working version of Xournal on Windows (minus the screenshot functionality).

Posted in Programming | 29 Comments

If you die in Canada, you die in real life

xkcd #180 - Canada

I love xkcd. It is definitely my most favorite webcomic ever. Erik Torstensson was the one to introduce me to it. Living in Canada, this particular strip surely must have made him chuckle. Always when a great xkcd strip went online we’d laugh about it together through instant messaging. Now we’ll never do that anymore… Last weekend Erik died in Canada, and while I still don’t believe it, I’ll have to learn to accept that this means he died in real life.

Erik has helped me through some really rough times, “threatening” even to take the next plane to the Netherlands to straighten me out. :) I might not even be here to write this if it hadn’t been for him. And there are many with similar stories. He’s touched a lot of lives in profound ways, making each one a little happier. No matter how much life got himself down, he’d always be there to cheer up saddened friends.

If there’s one thing Erik had to teach, it’s that life is what you make of it. That if you follow your ambitions, and don’t give up in the face of adversity, anything is achievable. What you’ll come to regret the most is not acting on your ambitions, rather than acting on them and not getting immediate success. So apply for that job, go on that trip, buy that new gadget, learn something new, do something exciting, visit that old friend. It’ll be one less thing to regret.

Personally, my biggest regret in life is never having met Erik in person, even though I’ve known him for years. This summer I might have been in Canada anyway, so it would have been an excellent opportunity to visit. But why would I need any other reason to be in Canada than to visit my best friend? “There’s always another day” is a poor excuse, because there isn’t always.

Old for his age in wisdom; young for his age in spirit. Never too old to goof around; always too young to die. He will be sorely missed. My best wishes go out to his other friends, his family, and most of all to Jacquie. I hope you share Erik’s strength to bounce back from anything life throws at you, even something like this.

Erik Torstensson

Erik Torstensson

Posted in Real life | Leave a comment

More than 9 for Lisp?

I’ve just read about LispNYC‘s Summer of Lisp.

The idea is to also mentor students without Google funding, on the projects that didn’t make the cut. Also, there seems to be a possibility that funding for one other Lisp project will be made available!

Sign up for the Summer of Lisp mailing list to stay informed.

Posted in Lisp | Leave a comment

E-on-CL

I should have started going to #lisp on irc.freenode.net ages ago…

Today I talked with Kevin Reid. Apparently, he’s been working on implementing another concurrent language on top of Common Lisp: E. Initially announced in December 2004, E-on-CL is younger than Erlisp, yet already more complete. To try it out, follow these instructions. More info can be found through Google.

Posted in Lisp | Leave a comment

Erlisp and 8 others funded by Google

Google has just announced the final per-organization project breakdown on their Summer of Code. LispNYC got awarded no less than NINE project fundings! That’s more than SVN, NetBSD, Wine, Samba, and Inkscape! Who said Lisp was dead? ;)

And guess what? Erlisp is one of the nine! I’m not exactly sure how this selection was made, but if it had anything to do with community feedback: thank you all for the support.

The other eight projects are:

  • Lisp Sockets
    This is great! I have needed to use sockets on several occasions, and had to settle for non-portable solutions with SB-BSD-SOCKETS. Better yet, Erlisp will eventually need portable sockets as well.

    Now we “just” need a library and/or CLRFI to be able to serialize any Lisp object, send it to another Lisp implementation running on another computer, and deserialize it…

  • Fetter – foreign function interface generator
    Generating foreign function interfaces automatically is a cool thing in itself, but this project promises to bring not just C but C++ support to the Open Source Lisp masses! Way cool! (Might it even get wxCL off the ground?)

  • Axiom User Interface
    I know of 2 Common Lisp computer algebra systems; Maxima I’ve used, Axiom I haven’t. There is some cool stuff going on in the Maxima GUI camp, let’s see what this summer will bring for Axiom.

  • Gene Ontology Database
    Not my cup of tea, but a cool example of how Common Lisp is being put to use.

  • Hello-C, extending UFFI
    UFFI with callbacks, better documentation, and higher level abstractions… what more could we ask for? Also, it’ll serve as the basis for Fetter (mentioned above).

    [EDIT] I don’t know where I got that, but Fetter is not based on Hello-C (it’s based on UFFI). I guess that’s sensible, to make sure these projects can be developed in parallel.

  • Extend PLT Scheme’s Stepper
    This would have interested me 2-3 years ago, but I’m off Scheme now. Still, nice to see they’re in on the action too.

  • Unified low-level database drivers for PLT Scheme
    Ditto.

  • A Stepper for Slime
    Last but definately not least: better debugging tools for SLIME. Any SLIME addition makes me happy, but this one will be especially well-appreciated. ;)

Posted in Lisp | 2 Comments

Erlisp on GMANE

Thanks to GMANE, the Erlisp mailing list is now also accessible as the newsgroup gmane.lisp.erlisp.devel on news.gmane.org. The newsgroup is a bi-directional interface to the mailing list, so e-mails sent to either one will show up on both. Newsgroup lovers rejoice! ;)

Posted in Lisp | 1 Comment

To those who’d like to try Erlisp 0.0001

Erlisp currently doesn’t come with documentation yet, so here are some pointers to get started.

  1. From Erlisp’s download page you should get erlisp-snapshot.tar.gz. This file contains the source code in the Erlisp repository, and is updated whenever that repository is updated. Extract its contents somewhere. (Alternatively, you can check out the source code directly from the repository, as described here.)

    In your new erlisp directory, there should be the following:

    • LICENSE
      Contains Erlisp’s license (BSD).

    • erlisp.asd
      ASDF system definition for Erlisp.

    • doc/external/, doc/internal/
      Currently empty. Should hold external (user) documentation and internal (developer) documentation at some point.

    • src/
      Contains all actual source code. This directory will probably be subdivided into further subdirectories (and corresponding ASDF modules) when Erlisp grows.

    • test/
      This contains all automated FiveAM (unit) tests. At the moment, this is the closest thing to documentation there is.

  2. To conveniently use Erlisp, you’ll need ASDF. Create a symlink to erlisp.asd from one of the directories in ASDF:*CENTRAL-REGISTRY*, or add the erlisp directory to that list.

  3. Start SBCL, and load Erlisp using (asdf:oos 'asdf:load-op :erlisp).

    If you’d like to run the automated tests, you’ll need to have FiveAM. Then you can use (asdf:oos 'asdf:test-op :erlisp).

  4. To see what you can do now that you have Erlisp loaded, have a look at the automated tests. Be careful though. Both the internal and external API are tested, so this doesn’t really show “what you’re supposed to be using”. I guess I should be making this distinction clear by exporting symbols from the ERLISP package, but I haven’t gotten around to that yet.

    So at the moment do (in-package :erlisp) and, as a rule of thumb, stay away from anything that isn’t SPAWN, CURRENT-PROCESS, SEND, RECEIVE, RECEIVE-WITH-MATCHER, or SET-DEFAULT-PATTERN-MATCHER.

If any non-SBCL users among you tried the above, you would have gotten a message like “Threads are currently only implemented for SBCL”.

The file src/compatibility.lisp makes sure that the rest of the code doesn’t have to depend on implementation specific features, but it is only implemented for SBCL at the moment. If you know the threads API of your Lisp, feel free to send me a patch. The download page describes how to check out the repository, make your changes, and send them to me in a patch. It’ll be much appreciated!

Posted in Lisp | Leave a comment

8 months of Erlisp

It’s been over 8 months since I announced Erlisp to the Lisp community, and I’m sure that I’m not the only one who had hoped that Erlisp would have come farther in all this time. However, many of you may not be aware of the things that have happened, hence this summary.

I’ve implemented (for SBCL):

  • Processes as threads.

  • Local message sending and receiving.

  • API to plug in your own pattern matcher.

Apart from actually writing code, I’ve been taking steps to get development back on track:

  • I’ve switched from GNU Arch to darcs for version control. Darcs is much easier to use, and in my opinion also conceptually nicer. (For example there is no difference between a working copy and a repository.) It’s the first version control system I like to use.

  • To get more community interaction, I’ve started this blog, and there is now an Erlisp mailing list. Thanks to Mario Mommer of Common-Lisp.net for setting it up for me.

  • I’ve written a little Bash script that:
    Synchronizes the main Erlisp repository with my local one.
    Uploads a new Erlisp snapshot tarball.
    Sends an e-mail to the mailing list about the new patches in the repository.

Other noteworthy events are:

  • I’ve been contacted by Heow Eide-Goodman of Lisp NYC about Google’s Summer of Code. Apparently, Lisp NYC is a participating mentoring organization and they list working on Erlisp as one of their project ideas.

    I’m very flattered by all this, but I’m not sure whether I can mentor a student to work on Erlisp. I’m only figuring this stuff out as I go, so I’m by no means an expert, and I’m not exactly drowning in spare time either (not even during the coming summer vacation).

  • As part of the website revamping I’ve made a (very primitive) search mechanism for the Erlisp reference section. There has also been a slow but steady stream of reference additions over the months.

  • This blog has been added to Planet Lisp.

Posted in Lisp | 3 Comments