Links for 16-Jul

Functional C# -- Part 5 and last, the Match operator.

IronPython 1.1.2RC1 and Jython 2.5 first alpha release.

F# -- semi-formal spec

oMeta (and oMeta#) -- Object-Oriented Language for Pattern Matching i.e. a lexer/parser/... kit

Links for 13-Aug

A better Symbol#to_proc -- iterating and refining collections with less "yellow code"

JVM languages group -- Virtualisation works at the code level, too.

Python IDE in the browser -- Silverlight proof of concept

JavaScript debugging in Orcas -- work on client-side code in your server pages

Decisions, decisions

When I'm doing stuff for my own interest and enjoyment, it's almost certainly client-side applications. And unless it's something that is very definitely targeted at a particular set of OS specific functionality, I like it to be cross-platform and easy for a naive end-user to run. This was a particular pull of Java — though it was soon shown to be very definitely “debug everywhere” when the two main browser JVMs (Microsoft and Netscape) interpreted the thumb-width of a scrollbar differently (inclusive or exclusive of the range — or “lol, box-model”). And the API, even for AWT, was far nicer than any of raw Win32/Win16, MFC or OWL, back in the day.

So then the progression went AWT to GWT (a light-weight widget set that had all the missing widgets from AWT) to Swing… and there it stayed. But that did mean programming in Java, which, over the years, I've come to find lives at the wrong level of abstraction : it doesn't afford the ruthless power that C++ does (templates, multiple inheritance), but without giving very much in return (generics are latecomers, and comparatively weaksauce; there's nothing like mix-ins; and everywhere a lot of the same scaffolding that C++ would require).

Growing dissatisfaction pushed me to look at native (as opposed to bytecode) toolkits, where I could get to use C++, eventually settling on FOX, over wxWidgets. The downside of FOX is that it was not built for localisation (too many strings baked in), and the event handling model seemed to fight the language compared with Java's X-style callback registration (wxWidgets lost on having what felt like a more opaque layout model). But than meant compiling on Windows and Linux, and having to tweak platform dependent system header files (and hoping that other *nix-like platforms would work).

The moving target that is C# provided a bit of a distraction — I'll learn it for work, but are all new languages going to be just warmed-over Java? It didn't matter that Mono was providing portable CLR GUI by stages, when the language (C#) had little appeal in and of itself. So it wasn't until stumbling into Ruby and Python in the last few months that I discovered some more shiny in terms of language.

But what to do for client-side applications? Python with wxWidgets? Ruby with FOX? and what about naive users? Jython 2.2 in stand-alone mode? Pity about JRuby's sprawling nature. But what about AllInOneRuby and its friends? I had just about come down on standalone Jython, when the whole silverlight business blew up.

So now I think I know my GUI toolkit. And while we only have IronPython out (and ported to Mono) at the moment, that both Python and Ruby should soon co-exist in the DLR means that it should be possible to do what works best for the application at hand. When an object is an object is an object, much fun should be available.

Undocumented Jython — Java callable Jython class idiom

You have to do

and not

in order to make jythonc generate the function calls you want in the intermediate Java code.

And as I'm in a “Jython calls Java calls Jython” state, doing some transcoding/refactoring, I have still not managed to get Jython at the front to call nicely into the Jython at the back.

causes

method myPackage.Backplane.performSetup of myPackage.Backplane instance 1
Traceback (innermost last):
  ...
AttributeError: abstract method "performSetup" not implemented

despite it being there quite plain as day:-

and despite Java code calling it quite happily.

*sigh*

Standalone Jython — ImportError: no module named awt

I've spent probably about a day figuring out what's going on here, Google being no help whatsoever, so figure I might as well publish.

Scenario -- Jython 2.2b1, installed in standalone mode i.e. all of /Lib inside the jar, and cachedir being skipped.

Now this sort of code works with Jython launched from the jar in the standard install:

but with Jython.jar from the standalone the code gives

C:\jython2.2b1-standalone>java -jar jython.jar
Jython 2.2b1 on java1.6.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import java.awt
Traceback (innermost last):
  File "", line 1, in ?
ImportError: no module named awt
>>> ^Z

Hunting down the error message, it is raised in org.python.core.imp, ultimately from JavaImportHelper.tryAddPackage() failing. Meanwhile, from the other direction, doing

import sys
dir(sys)

gave me that sys has a packageManager attribute. And that has a makeJavaPackage method. This lives in org.python.core.PackageManager

So, that seemed worth giving a try. Like

And that, at last, worked.

Now, you might think it would be elegant to do something like

to allow for the cases where it would work anyway; but this doesn't work -- the branch is taken, but the conditional packaging doesn't seem to stick. However, it doesn't seem to matter if you always explicitly add the package as part of the initialisation, even when not strictly needed. So stick with the simple case. It's more Pythonic that way, after all.