Tag Archives: scala

GUI interpreter frontend coming along nicely

I’ve separated the interpreter frontend out into its own separate project. It’s available at http://www.drmaciver.com/repos/guinterpreter/

It’s doing pretty well. The UI has been improved, it supports multiple interpreter windows in the same VM, and is generally in a pretty usable state. It still has a few quirks, but it’s getting there (still a little bit of a headache to set up, but I’ll work on that). My plans for the immediate future mainly revolve around UI polishing and embeddability – I’d like it to be really easy to include this inside another (Jambi) application. hemant / gnufied has been taking a look at the code and has some interesting plans for it, starting with syntax highlighting. I’ve given him commit access, so we’ll see what happens on that front.

If you want to give it a try, go right ahead. You’ll need to resolve the Jambi dependency yourself, but otherwise it should be pretty easy (I will probably set up some sort of maven (sigh) repository for the jambi dependencies and switch the build script over to buildr so it can use them at some point, but I haven’t yet).

Trampoline Systems and Scala

So, as I’ve mentioned a few times my company Trampoline Systems have been using Scala at work. This is, somewhat unfortunately, about to change.

It’s not really due to any problems with Scala. I’m certainly still planning to continue using it myself. There have been a few hitches that have meant we’ve not been able to take advantage of it as well as I’d like, but this is mainly a strategic rather than a technical decision. The majority of our code is in Ruby (even more so than it was at the start of this project), and most of our expertise is in Ruby, so it was starting to look increasingly silly that we had just this one project in Scala. Consequently we’ve decided to move the stuff we were previously doing in Scala to JRuby.

Oh well. It was nice to be a professional Scala developer for a bit. Now I get to be a professional Ruby developer instead. Life’s all about dealing with changes. :-)

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.

“Object Main extends Application” considered harmful

You’re probably all familiar with the standard Java invocation for creating an applicaiton’s start point.
class Main{ public static void main(String[] args){ // code } }

Scala has a nice feature which lets you use a trait to define your application where you don’t care about the initial arguments.

object Main extends Application{

//code

}

What happens is that Application has a method main(args : Array[String]) which gets inherited, then a corresponding static method is created on the class Main. The application logic goes in Main’s initialisation code. Neat, huh?

All we’re missing is what the definition of main is.

trait Application{

def main(args : Array[String]) = createHorrificallyConfusingBugsIfYouSoMuchAsLookAtAThread();

}

Oops.

Ok, that’s not actually true. Really it’s

trait Application{

def main(args : Array[String]) = ()

}

It doesn’t do anything. Everything happens in the object initialisation code.

Why is this an issue?

object Main extends Application{

val foo = stuff();

spawn { doSomethingWith(foo) }

doSomeLongRunningThingThatBlocks();

}

Why is this an issue?

Well, foo is a field. And Main’s constructor hasn’t completed. This means that the visibility of foo to other threads is completely undefined. Bad things will happen.

This isn’t a hypothetical scenario. We’ve just spent a non-trivial amount of time debugging a problem caused by this. We were spawning a background process from Main, and then entering QApplication.start() (the “let QT start doing stuff” method). The background process was blocking on trying to read a field from Main, and only unblocking when QApplication finally exited.

You should not expose partially constructed objects like this. It’s a bad idea, the VM will hate you for it and it will punish you with incomprehensible bugs as a result.

Edit: In fact, it turns out that this isn’t about partially constructed objects. It’s about static initialization. Because the initialization of the Main$ class depends on the construction of the Main object, Main$ will not be fully initialized until the constructor has exited. The JVM semantics guarantee that class loading is single threaded and that other threads cannot access the class until it has finished loading. Hence the observed problem.