Posts Tagged ‘javascript’

Andy Wingo: recent developments in Guile


I watched a talk by Andy Wingo recently: recent developments in Guile. GNU Guile is a Scheme implementation, and a library providing an extension language for applications. Guile is actively developed, and promises some exciting stuff in upcoming releases, which is why I took these notes and publish them here–read on.

Andy starts by noting that Guile is different things to different people:

  • A GNU language, with bindings for many components of the GNU system and under LGPL 3.
  • A Scheme implementation, supporting R5RS and part of R6RS, plus other goodies: modules (not the R6RS ones), hygienic macros, the CLOS-like object system Goops with transparent integration with GLib’s gobject, Posix interface, and Unicode support.
  • An extension language for applications, like the Gimp.
  • A part of the GNU system (that we are making, even if we don’t know yet how it will look like).

Andy sees Guile’s perception among developers as its main challenge currently. It’s seen as being slow, although it’s generally faster than Python. But there are also opportunities for its perception: its multilingual vision and support–its next release will support ECMAScript besides Scheme, and Emacs Lisp is coming–, and the GNU brand.

Some technical notes

It uses the Boehm-Weiser garbage collector now, which is fast and reliable.

There are ten committers and monthly releases. This is after the project emerged from a long drought in 2000-2007.

Guile has a VM, and a native compiler is coming. Also: JavaScript support, ELisp coming!

It has really good Emacs integration now with Geiser.

There was also a small remark about licensing. Readline and Guile are not quite license-compatible, which makes using the REPL a pain. This sparked a longish discussion–kinda what you expect from a GNU developers meeting :-)

Spreading the Emacs nature

And now, the meat of the talk: spreading the Emacs nature, to emacsify the GNU system. Yes, that sounds like it!

The upcoming Guile 2.0 (or maybe 2.1?) will have full ELisp support, at the moment about equally fast than Emacs’ own, but it will be much faster. It will also have native compilation for even more performance.

Besides performance, it will have much more to offer:

  • native threads,
  • a clear FFI,
  • modules,
  • other languages, as described above,
  • the Goops object system,
  • lots of library bindings – Emacs-Gnome integration would easily be possible, for instance.

Andy’s plan is to replace Emacs’ Lisp engine with Guile. The rest stays unchanged, existing ELisp code will run as-is. Then no form of coercion should be necessary to get people to start writing their Emacs code in Guile languages. The timeframe is 18-30 months from now–looks like a developer release is not too far off!


Java-based JavaScript unit testing with Rhino


At SwissProt, we test the UniProt website in several ways (though we still lack coverage, which is another topic). One area where testing was lacking for some time was JavaScript, which had accumulated over time to a somewhat substantial amount, about 3200 lines of code. We have Selenium tests for the site as a whole, but having unit tests for individual bits of JavaScript would have been great to make development of new code easier, and increase confidence in the code.

Many available frameworks such as JsUnit do in-browser testing. If you want to test actual UI code, that’s obviously what you need. But we have that at least partly covered with Selenium, and a problem with these tests is that they are difficult to run in an automated way, like from our ant test task. So I wanted something to easily and quickly test the UI-independent code, along with the Java code, from the command line, ant, or scripts. I also think that a standard JUnit-style test is way easier to write, but I guess that depends on what you’re used to.

Having read about Mozilla Rhino several times, a JavaScript interpreter written in Java with good integration between the two languages, I set out to see how much work it could be to write a simple test framework. As it turned out, it wasn’t much work at all, and there’s so little code that I can show all of it in this post.