Tag Archives: API

Not really an announcement: GUI frontend to Scala Interpreter

So, I’ve finally got sick of the unusable command line interface to the Scala interpreter.

Don’t get me wrong, I like command line interfaces. But I’ve always found command line interfaces written in Java to be pretty horribly unusable, and the variety of different quirks shown by the scala one between windows and linux is pretty gruesome.

Anyway, the upshot is that I’m building a simple GUI frontend to it. It turns out that the interpreter API is actually really easy to work with – it only took me about half an hour to hack together a basic working frontend (after some… minor issues with Java’s IO API)

So far this isn’t really in a state that other people can use it – no proper buildscript, the GUI frontend is hacked together in the interface designer and doesn’t handle resizing properly at all (so is probably broken on any resolution but mine). This is more of a “If you want to look at the code and see how to do it” than anything else. It’s available in my misc hg repository.

A particular reason you might want to look at the code is that it uses QT Jambi rather than Swing, so if you want a Swing version you’ll have to write it yourself and might find this a useful starting point. Why? Well, two reasons. Firstly, I like the results and API of QT better than Swing’s. Secondly, Swing doesn’t work on my home PC so it would be pretty pointless for me to use it.

SBinary progress

If things have seemed a little quiet on the SBinary front, do not despair! It’s not because I’ve abandoned it. Partly I’ve been very busy recently, but I’ve also been held up with various issues on the implementation. One was waiting on Scala 2.7.1 as it fixes an issue I had with implicits, and another was a feature that I’ve decided to defer to 0.3 (to do with modifiers for binary instances. In particular I wanted to get sharing based on identity working properly, but I kept running into issues)

Anyway, I’ve spent most of today working on it and things are going pretty well. You can expect a 0.2 release at some point after 2.7.1 goes final. It will feature:

A revised API that I think is nicer to work with. It replaces the use of DataInput and DataOutput with custom Input and Output types. These define read and write methods for reading and writing things with Binary instances, plus a few other useful methods.
Improved generic methods for defining binary instances. In particular the length encoding has got a revamp and asUnionN has become significantly less irritating to work with.
A certain amount of experimental support for lazy IO via Streams. I’m not totally convinced this is a good idea, but it’s sufficiently useful that I’m going to provide it anyway with a big red warning sticker.
A much larger set of data types handled out of the box. It should cover most of the types available form the Scala standard library that it reasonably can (it can’t handle things like functions, etc)

As promised, this release should still be binary compatible with the last one.

Code for you to play with

As you might have noticed, I have a slightly silly number of google code projects. Most of these are crap or abandoned, although (I think!) there are a few good ones there. Rather than spamming the world with endless open source projects each with their own separate sites, I’m moving to using freehg.org for such things. You can find my code at http://freehg.org/u/DRMacIver/.

Right now what’s there is an alternative collections API for Scala that I’m tinkering with (it’s currently very basic, and the implementations that are there are more to explore the API than intended for serious use) and some random little Haskell projects I’ve written.

In the best spirit of open source, almost everything there is undocumented, uncommented and lacking a working build script. You can consider anything there that doesn’t come with an explicit license to be released under the WTFPL.

SBinary backends

I’m thinking about changing the scope of some of the code for SBinary.

Specifically, you remember that part where I said “SBinary is only for serializing objects and manipulating binary data, and it’s going to remain super minimal and specialised and this will never ever change!!”? I’m thinking of changing that. :-)

The reason for this change of heart is that I’m realising how incredibly generic the constructions you put together for SBinary are. You’re basically creating a walker for deconstructing and reconstructing your entire object graph. That’s pretty damn powerful. In particular I was thinking about how to modify formats to permit sharing (another post on that will be forthcoming) and suddenly thought “haaang on a minute. I’ve written this code before”. It looks suspiciously identical to some Java code I wrote a while back for generic cloning of object graphs*. A simple rebinding of the backend to use a queue of objects rather than input and output streams would give a pretty efficient deep clone mechanism. I’ve also been thinking of creating a JCR backend which mostly works the same as the binary data (indeed, most data would probably be stored as binary blobs in the JCR), but allows for references to other nodes (and would use this for data sharing).

At the very least, this will result in ditching the explicit dependency on java.io. It will still be used extensively in the back end, but this is only visible in the API for the parts that actually need to interact with it. (most likely approach – have an Input and Output opaque type to replace DataInput and DataOutput. These will just be wrappers around the java.io types, but this won’t be visible at first)

If I do do something like this, it would still be with making binary data the priority, and there would definitely be a specialised binary frontend which should be just as convenient as the current API. If it ever looks like feature creep is threatening to destroy that I’ll separate out projects and/or cut out the idea entirely.

* In the unlikely event that anyone who worked on that project actually reads this blog, they will probably shudder in horror at the mention of that code. It was very fragile with regards to changes in the rest of the code. But that wasn’t actually an issue with the cloning – it was an issue with the post-clone processing. The graph was of database mapped objects and it needed to be partially linearised in order to insert it back into the database due to constraint issues, and this never really worked right.

Open source project breakdown.

I realised today that I actually have a fairly large number of open source projects published online (all on google code. Another thing I realised is that I should fix that).

I also realised that some of these are totally defunct.

I thought this would be a good time to do a quick breakdown of them, explaining what’s there, what they do and what their current status is.

JTypebuilder

Code generator for creating immutable data structures in Java. The idea was to define simple datatypes with a record notation and get an immutable class from them with correct equality, hash code and toString implementations, getters for the properties and a builder class for generating instances.

Status: Very very dead. It was at best a weak idea, and I have no interest in pursuing it. Use Scala’s case classes instead.

Generators4j

A brief foray into functional programming in Java. Lazy generators with functions like map, filter, etc.

Status: So dead. I didn’t get very far before concluding that trying to do this in Java was unusably awful.

Lazy Strings

Experiments in efficient representation of String types, with the aim being to provide a drop in replacement for java.lang.String with a different set of performance characteristics. Started in Java, moved to Scala.

Status: Just resting its eyes. I’m not doing much with this at the moment, but I occasionally peek at it and will probably factor out some of the ideas and turn it into a more tightly focused library.

Ranged Types

Very small Scala library for statically checked numeric ranges.

Status: Awaiting a use case. I occasionally think about picking it up again, but then I wonder why. It’s a fun idea, but I don’t actually have anything I need to use it for and as far as I can tell neither does anyone else.

SBinary

A small library for binary serialization and deserialization of Scala data types, based on Haskell’s Data.Binary.

Status: Very much alive. I’ve just released version 0.1 RC1, am using it as a dependency in other things and am continuing to tinker with it to improve its usability.

Prefer Scala

A wrapper around the Java preferences API designed to be nicer to use from within Scala and support a wider variety of preferences in a typesafe way. Uses SBinary to serialize Scala types to and from the preference backing store. It’s been factored out of the code for Hector’s Reminder Service.

Status: Fledgling. I’ve only just released it. It’s very small, and I intend it to remain so, so I expect to push it towards a 1.0 fairly quickly and then have it enter maintenance mode where future updates are just to fix bugs and bring it into line with the latest versions of its dependencies.

Hector’s Reminder Service

Unlike the other ones, this one is an application. It’s a small cross platform status bar application based on QT which gives you reminder messages on a semi-regular basis. Designed to be unobtrusive and simple and intended for the occasional casual reminder rather than of specific events. Uses “Prefer Scala” for persisting of state between application runs.

Status: Again, quite recent. I have a semi-official version released which works and more or less does what I want. I’m intending to polish that, add a very small number of new features (currently planned are a more expressive way of specifying message intervals, the ability to temporarily suppress a message group and possibly a simple API for other programs to interact with him) and then declare it to be feature complete. Once it’s reached that point it will enter a similar state of “Updates are only to fix bugs and match new dependency versions”.