Wednesday, April 20, 2011

My GNOME customization script

I find myself reformatting my computers dozens of times a year. Don't ask why. So after many lost hours I created a script that completely sets up a new Debian or Ubuntu computer. It sets every bit just the way I like it. Unfortunately I can't post that entire script because it's deeply entangled with various passwords, system-specific info, etc. So as a compromise I teased out my GNOME customization stuff and am posting it as a standalone script.

There are two things you might find useful about the script:

  1. It makes gconf changes as root, something that's tricky to do. While that isn't really necessary for GNOME customization, my full setup script needs to run as root.
  2. It incorporates a bunch of customizations, some of which you may wish to automate too.


Can’t see the code?

Monday, April 18, 2011

Case classes with toStrings that print label names

Overview
The Labeled ToString project provides several traits you can mix into case classes in order to get toString representations that include parameter labels. That means you get Person(name=John Doe,age=30) instead of Person(John Doe,30).

Example
Here's a normal case class:
  case class Person(name: String, age: Int)
Person("John Doe", 30).toString
//result is "Person(John Doe,30)"
Here's our labeled case class:
  import com.yuvimasory.tostring._
case class Person(name: String, age: Int) extends LabeledToStringDef
Person("John Doe", 30).toString
//result is "Person(name=John Doe,age=30)"

Choosing a trait
The com.yuvimasory.tostring package provides three traits: LabeledToStringDef, LabeledToStringVal, and LabeledToStringLazyVal. They override the default case class's toString method with a def, val, and lazy val, respectively.

  • If you're not sure which to use, start with LabeledToStringDef, which works in all cases.
  • Consider LabeledToStringVal if you know the case class's parameters are either immutable (e.g., primitive types, immutable collections), or have string representations that never change (e.g., arrays).
  • Try LabeledToStringLazyVal if you meet the criteria for LabeledToStringVal and want lazy initialization.
  • Both of the *Val traits may run slightly faster (since they don't have to recompute toString every time it's needed) at the cost of more memory usage.
  • You must use LabeledToStringDef if your case classes are Squeryl tables. If you don't Squeryl will generate bogus SQL.

Performance
The ToString traits use Apache Commons Lang under the hood, which uses reflection to find the parameter lables. Surprisingly, there does not seem to be any performance cost for this. In fact, using these traits actually results in code faster than the default case class toString. Try the tests yourself by running sbt run.

Warning
  • These traits do not produce the right strings in the REPL yet due to the way the REPL wraps code and mangles names.
  • These traits do not work if you add bodies to your case classes (i.e., additional methods or fields).

Saturday, April 16, 2011

Detect Scala version at run-time

Thanks to Josh Suereth for this one.

Update 1: add stainsby's improvement.
Update 2: add Ismael Juma's improvement.
Update 3: add Samuel Tardieu's improvement.

Can’t see the code?

Wednesday, April 6, 2011

Scalathon - how you can help

Today marks the "official" announcement of Scalathon, even though people have been eagerly tweeting about it for days now.

This event was born in no small part from my frustration in finding new projects and collaborators. I don't know how you all do it, but I never seem to find the right group to work with that wants to work with me too. I'm hoping Scalathon will change all that. Putting 100 of the best Scala developers in a room for two days should make it easy for anyone to give something back to the community. Or at the very least have a good time trying.

Some other idealistic goals for the event are:
  • Improving scalac and scala-lib documentation. Once logistics are worked out with the core team I'm hoping to announce a documentation spree on Friday, July 15 for anyone who wants to make this shindig last 3 days. Stay tuned. Anything on Friday will be separate from the hackathon and totally optional.
  • Putting a face on the core team. Until a few weeks ago I didn't even know who was *on* the core team. Sure there was Martin. And uh ... After Scalathon you'll know them, their favorite text editors, and their beers of choice. And what the hell does a Swiss accent sound like anyway?
The Scalathon organizers are doing everything they can to make this event a success. But you can help too:
  • We need sponsors! We'd love to fly out the entire EPFL team, issue travel grants to student Scala hackers from Germany and Australia, provide meals at the event, etc. But that costs a lot more money then we're getting from the measly $35 registration fee. We're counting on the Scala community to try and hook us up with sponsors. Can you help us?
  • Send someone to represent your Scala project. We'd like to have *every* major Scala library represented at the event. All you need to do is give a quick talk on Saturday aimed at helping newcomers develop your project.
  • Volunteer to give a Sunday enrichment talk. Those NE Scala videos are pretty awesome, am I right? We'll be posting our talks too. Now we just need some more awesome speakers.

I want to thank PHASE, especially Brian Clapper and Jamie Allen for agreeing to be my co-conspirators. Also special thanks to Daniel Spiewak, whom we tricked into joining the organizers listserv and accepting assignments. Logo by Felice Ford. Finally, a big thank you to Martin Odersky and Josh Suereth for enthusiastically getting behind this idea.