OSGi for Robot Middleware

Seems like "middleware" is the term in robotics for the platform that lets the different components (usually system processes) communicate with each other. I'd previously thought about whether OSGi might be a good fit for that.

I searched a bit and found a Tobias Wegner that seems to be doing something like that, but I haven't found any papers from him at Google Scholar. Maybe I should try contacting him sometime to see about the status of his thesis.

Learning MATLAB

I'm out of industry and back in school these days, focusing on autonomous robots to speak generally. One of the things I knew to expect was MATLAB, and I'm learning it as I thought I'd need to. But I don't want to make it my tool of choice in the long run. I won't give a technical review here (and I don't know enough yet to give a full review), but I'm generally a pro-open kind of person. And MATLAB is definitely propriety.

But it sure pwns the competition in the research world. (Update: I mean this in terms of apparent market share, not in terms of technical merit which again I feel too ignorant to comment on.)

The main alternative is SciPy. JScience and many other options for Java seem either unmaintained or too complicated. Hmm.

Confirm Quit and Logging Off

It just occurred to me that the "Are you sure you want to quit/close/etc.?" features should be promoted to an OS (or desktop/platform) level concept. These things prevent log out, shut down, and so on. They can also cause other confusion when the system tries to guess if the software is behaving well.

Probably can't completely standardize the content of such quit confirmations, but some level of communication with the system about what's going on could make this user experience tons better.

Fan Language

By the way, I should have blogged a while back about the Fan programming language. I got relatively involved in conversation there. And I even got into the code just a bit.

My quickest summary: It's a better Java. As in, it tries to be a nice, clean, accessible language that encourages consistent style and good, readable code. But it's better than Java in that it clears out the cruft (starting with a clean slate, almost), and it's much nicer in the syntax arena. You don't have to slave away to get everyday things done like in Java. And it's still mostly statically typed.

That short review ignores a lot of the details. See the site for more. But as a summary, can you say all the same things about Groovy or Scala (alternative "better Javas")?

That said, I'm still not sure whether I'll be using it in the future. I think it's possible. For now, I think I still want Java's tool support and low-level speed. (Yes, I said "low-level speed" in reference to Java.)

3D Java Physics: JBullet

After having trouble finding much better than ODE wrappers for 3D physics in Java, someone pointed me this week to JBullet. Seems to work great from my experiments so far (just learning how to run the demos from a new Eclipse project at this point).

Pure Java is nice.

Side note, a project to convert x86 to JVM bytecode and automatically run DLL and ELF so files would be sweet. That would auto-port lots of native libraries to Java. Well, in some cases you might need semi-deep OS emulation.

Trac and Mercurial for JVM?

Does this mean we get a chance at running Mercurial and Trac within the JVM someday soon? That would be t3h r0x0rs.

Scala Object Literals

Groovy has great object literals. See, for example, the Customer constructor call here. Unless I've missed it, Scala can't quite do that. So far as I can tell, you can only get inside the context of a class within a class body. Sort of like Java.

That's good and bad. It's bad because you can't construct objects easily without making new classes, and we all know what classes do to jar file sizes (even with pack200, so I guess I should add another $20 JVM bounty or something on inlined nested class definitions in the bytecode, something again that more than Scala can benefit from). But on the good side, it means that there are fewer ways to get things done. Fewer choices is sometimes better. Just swallow the bytes for consistency.

But, well, there are still a few options. Here are some examples without explanations of pros and cons or what's happening:

  trait Person1 {
    def name: String
    def age: Int
  }
  val person1 = new Person1 {
    def name = "Bob"
    def age = 25
  }

  trait Person2 extends Person1 {
    var name = ""
    var age = 0
  }
  val person2 = new Person2 {
    name = "Stanley"
    age = 73
  }

  case class Person3(name: String, age: Int) extends Person1
  val person3 = Person3("Harold", 7)

I only do the "extends Person1" above to show that they are compatible at the interface level. Note also that there is no need for doubling the "{{" as in Java to write arbitrary code in a class body.

Once the object is made, you can't get back inside it again. That is, no 'with' blocks. If you go pure functional, I guess that's okay, but it would be nice to have available.

Anyway, there's another concept (and something you can do in Java with varargs, too, so remember that varargs are your friends), if you need heterogeneous lists:

  abstract class Option
  case class For(name: String) extends Option
  case class Name(name: String) extends Option
  case class Text(text: String) extends Option

  abstract class Widget
  case class Button(option: Option*) extends Widget
  case class Label(option: Option*) extends Widget
  case class TextField(option: Option*) extends Widget
  case class HBox(kids: Widget*) extends Widget
  case class VBox(kids: Widget*) extends Widget

  val form = VBox(
    HBox(Label(Text("Age"), For("age")), TextField(Name("age"), Text(person1.age.toString))),
    Button(Text("Submit"), Name("submit"))
  )

And don't forget the options for inline XML:

  val xmlForm = <vbox>
    <hbox><label text="Age" for="age"/><textfield name="age" text={person1.age.toString}/></hbox>
    <button text="Submit" name="submit"/>
  </vbox>

And that will conclude my summary of rudimentary object creation for today.