:set spellIt's a bit annoying for code, but maybe it will help people spell things properly in their comments ;) It's also really good for LaTeX documents (if you're old school and do them by hand like I do) since those actually do have real writing in them which should definitely be spellchecked.
Nov 20, 2009
Spellcheck in Vim
Turns out Vim 7 and higher has a built-in spellcheck. To turn it on, do:
Nov 18, 2009
Using sdljava with Scala
After fixing up sdljava, I decided to try it out with Scala. Turns out it works really well!
Here is the code to get a simple window that closes when you click the close button:
Anyway the hard part is actually getting this junk to compile. If you check out my sdljava repo here you can grab all the files needed for compiling and executing provided you're running 64-bit Linux, otherwise you'll probably have to download and compile the library yourself.
Drop those into the same folder as your Scala file, and do this to compile:
Anyway, this should get you started to whatever SDL program you want!
Here is the code to get a simple window that closes when you click the close button:
import sdljava.SDLMainThis looks almost exactly like it does in C (I probably code Scala/Java with a C accent anyway). I might decide to start adding stuff to sdljava so that you don't have as much boilerplate as you do here, or I could even add in some Scala-only stuff to bind functions as callbacks or something. But I probably won't, sorry...
import sdljava.video.{SDLVideo, SDLSurface}
import sdljava.event._
object SDLTest{
def main(args: Array[String]){
SDLMain init SDLMain.SDL_INIT_VIDEO
try{
var framebuffer = SDLVideo.setVideoMode(800, 600, 32, SDLVideo.SDL_HWSURFACE)
var ev : SDLEvent = new SDLQuitEvent()
var loop = true
while (loop){
if ((ev = SDLEvent.pollEvent) != null){
if (ev.isInstanceOf[SDLQuitEvent]){
loop = false
}
}
Thread.sleep(1)
}
}finally{
SDLMain.quit()
}
}
}
Anyway the hard part is actually getting this junk to compile. If you check out my sdljava repo here you can grab all the files needed for compiling and executing provided you're running 64-bit Linux, otherwise you'll probably have to download and compile the library yourself.
Drop those into the same folder as your Scala file, and do this to compile:
scalac -cp ./sdljava.jar MyFile.scalaThat should work fine (if your code doesn't have any errors). The more annoying part is getting it to actually execute. Unfortunately it seems like when you use the actual scala program, it does not pass parameters to java. So you have to call java directly:
java -Djava.library.path=. -cp /path/to/scala/lib/scala-library.jar:./sdljava.jar:. MyClassThis is because sdljava uses native libraries which are not looked for in the classpath, you need to pass them in the java.library.path variable. Scala does not pass this to java when it is executed, so you have to call java manually.
Anyway, this should get you started to whatever SDL program you want!
Nov 17, 2009
Learning Scala: Euler's Method
I've been messing around more with Scala to see some of its more interesting features, two of which are pattern matching and currying. These are really handy in certain situations, and I decided to share them with you today.
The example I'm using is the Euler method for approximating a solution to a differential equation. This is probably not the most intuitive way of doing the Euler method, but it uses a lot of Scala's interesting features and I think it is a good way of illustrating them.
The Euler method works like this. You have a differential equation in the form y' = f(x, y) and an initial value (x0, y0). You calculate the slope at the initial value, which is f(x0, y0). You then take a step of size h in the x-direction following the slope, which brings you to (x0 + h, y0 + h * f(x0, y0) ). This becomes your new point, and you repeat until you are satisfied with the results. A smaller h will lead to more accurate results, but with more computation.
Here is the not-so-intuitive code:
The first parameter list takes a function representing the differential equation we are approximating, the second takes the parameters for the approximation which are the step size and the number of steps we take, the third takes the initial values.
If you look back at the main function, you'll see that we call solve_de with only one of its argument lists, and a _ at the end! This is called currying - it returns a new function with the first parameter list filled out. We save this as our variable my_de (note we use val, so this variable is immutable) which is a solution generator for our specific differential equation described above. You use the _ at the end to tell Scala that you are only partially applying the solve_de function.
Next, we call my_de with the values 0.1 and 10. This creates another function which solves our differential equation using a step size of 0.1 and 10 steps. We can then call this function with different initial conditions to get different solutions to the differential equation. Each time we call it, it returns a list of 10 points that lie along our solution curve. If we wanted to, we could then plot this curve using some graphing library.
Note: for some reason here you don't have to call my_de with the _ at the end, it is probably for some reason that I do not yet understand.
After that, we create a more precise generator with half the step size. I double the number of steps so that if we were to graph this alongside the first list, they would have the same range of x-values.
The next bit is the solve_de function, which illustrates some of the more interesting features of Scala. First one (which probably isn't that interesting) is that there are no curly brackets around the body of solve_de. If you have a function in Scala that is only one line, you can just write:
We have a fold using the /: operator. If you've used inject() in Ruby then you'll know what I'm talking about, otherwise take a look here for a description of what fold (aka reduce1) is. In Scala you can write this:
The initial value is a list that looks like this:
We fold this list into (0 until iterations), which is a range equivalent to 0..(iterations - 1) in Ruby. This is a very interesting piece of Scala, because it shows some of the fancier features. Scala is a pure object-oriented language so the 0 there is actually an object of class Int. Effectively what we are doing is calling 0.until(iterations), which returns a Range object that we can use fold on. In Scala for a method which only takes one argument, you don't need to put the . or the brackets.
However there is no until() method for Int. Where does this until() come from? Scala has a feature called implicit functions, which are used for implicitly converting one type into another - like the auto-boxing between int and Integer in Java. Little do you know, there is actually a class called RichInt which supplies the until() method, and a bunch of other handy things (you could write 0 to 5 if you like). When you call until() on 0, Scala first looks to see if Int has an until() method. Since it doesn't, it checks to see if there is an implicit conversion for Ints into a class that does have an until() method. Since there is only one such class (RichInt), it automatically replaces your statement with something like toRichInt(0).until(iterations). If there were more than one implicit conversions however, then Scala would give you a compile error and you would have to explicitly provide your conversion. The main difference between this and auto-boxing in Java is that you can provide your own implicit conversions between any classes you like, provided they don't result in ambiguities.
The next step is to provide a function to the fold operator to use for folding. After the => we see
Two small syntactic things to note:
- There is not a single semicolon in this program. Scala doesn't need the semicolons at the end of lines, although you can include them if you like.
- There are no return keywords in this program, even though we have functions. Scala doesn't require the return keyword, it will insert it where it thinks you are trying to return something.
So I'm not sure if I'd recommend you actually write Euler's method like this, instead you would probably write it something like this in Scala:
1In Scala fold and reduce are two different things: fold takes an initial element, where reduce uses the first element of the list as the initial element. Reduce will throw an exception if used on an empty list, where fold will just return the initial element. In non-Scala languages, reduce and fold are the same thing.
The example I'm using is the Euler method for approximating a solution to a differential equation. This is probably not the most intuitive way of doing the Euler method, but it uses a lot of Scala's interesting features and I think it is a good way of illustrating them.
The Euler method works like this. You have a differential equation in the form y' = f(x, y) and an initial value (x0, y0). You calculate the slope at the initial value, which is f(x0, y0). You then take a step of size h in the x-direction following the slope, which brings you to (x0 + h, y0 + h * f(x0, y0) ). This becomes your new point, and you repeat until you are satisfied with the results. A smaller h will lead to more accurate results, but with more computation.
Here is the not-so-intuitive code:
object Euler{
def main(args: Array[String]){
// Use the differential equation y' = x^2 + y^2
val my_de = solve_de((x, y) => Math.pow(x, 2) + Math.pow(y, 2)) _
// Use a step size of 0.1, and do 10 steps
val generator = my_de(0.1, 10)
// try with different initial conditions
println(generator(0, 1))
println(generator(1, 1))
// create another generator with a smaller step size
val precise_generator = my_de(0.05, 20)
println(precise_generator(0, 1))
println(precise_generator(1, 1))
}
def solve_de(func: (Double, Double) => Double)(step : Double, iterations: Int)(x_0: Double, y_0: Double) =
(List(List(), List(x_0, y_0)) /: (0 until iterations))((s, i) => s match {
case List(res, List(x, y)) => {
val fxy = func(x, y)
List(res ::: List(fxy), List(x + step, y + step*fxy))
}
}).head
}Look first at the definition for solve_de. It has three argument lists! One of them takes a function of type (Double, Double) => Double, also known as a function that takes two Doubles and returns a Double. The second takes a Double and an Int, and the third takes two Doubles.The first parameter list takes a function representing the differential equation we are approximating, the second takes the parameters for the approximation which are the step size and the number of steps we take, the third takes the initial values.
If you look back at the main function, you'll see that we call solve_de with only one of its argument lists, and a _ at the end! This is called currying - it returns a new function with the first parameter list filled out. We save this as our variable my_de (note we use val, so this variable is immutable) which is a solution generator for our specific differential equation described above. You use the _ at the end to tell Scala that you are only partially applying the solve_de function.
Next, we call my_de with the values 0.1 and 10. This creates another function which solves our differential equation using a step size of 0.1 and 10 steps. We can then call this function with different initial conditions to get different solutions to the differential equation. Each time we call it, it returns a list of 10 points that lie along our solution curve. If we wanted to, we could then plot this curve using some graphing library.
Note: for some reason here you don't have to call my_de with the _ at the end, it is probably for some reason that I do not yet understand.
After that, we create a more precise generator with half the step size. I double the number of steps so that if we were to graph this alongside the first list, they would have the same range of x-values.
The next bit is the solve_de function, which illustrates some of the more interesting features of Scala. First one (which probably isn't that interesting) is that there are no curly brackets around the body of solve_de. If you have a function in Scala that is only one line, you can just write:
def foo(x) = ...You don't need to include curly brackets.
We have a fold using the /: operator. If you've used inject() in Ruby then you'll know what I'm talking about, otherwise take a look here for a description of what fold (aka reduce1) is. In Scala you can write this:
(0 /: myList)(some function f)This does a left fold of myList with the initial value 0, using the function f - aka f(f(0, myList[0]), myList[1])....
The initial value is a list that looks like this:
[ [], [x0, y0] ]The first element of this list is where we will be sticking the approximated values, the second element is our current point.
We fold this list into (0 until iterations), which is a range equivalent to 0..(iterations - 1) in Ruby. This is a very interesting piece of Scala, because it shows some of the fancier features. Scala is a pure object-oriented language so the 0 there is actually an object of class Int. Effectively what we are doing is calling 0.until(iterations), which returns a Range object that we can use fold on. In Scala for a method which only takes one argument, you don't need to put the . or the brackets.
However there is no until() method for Int. Where does this until() come from? Scala has a feature called implicit functions, which are used for implicitly converting one type into another - like the auto-boxing between int and Integer in Java. Little do you know, there is actually a class called RichInt which supplies the until() method, and a bunch of other handy things (you could write 0 to 5 if you like). When you call until() on 0, Scala first looks to see if Int has an until() method. Since it doesn't, it checks to see if there is an implicit conversion for Ints into a class that does have an until() method. Since there is only one such class (RichInt), it automatically replaces your statement with something like toRichInt(0).until(iterations). If there were more than one implicit conversions however, then Scala would give you a compile error and you would have to explicitly provide your conversion. The main difference between this and auto-boxing in Java is that you can provide your own implicit conversions between any classes you like, provided they don't result in ambiguities.
The next step is to provide a function to the fold operator to use for folding. After the => we see
s match {This matches the variable s (the "accumulator") against a set of patterns. This is another feature of Scala called pattern matching. This example doesn't really do it justice since we only have one pattern here, and it is just so that we can have a nice way of extracting the variables out of s without using head() and tail(). I think I might post something more detailed on pattern matching in the future. Anyway, we use the expression List(res, List(x, y)) to match s, and this extracts out our current accumulated values as res, and the current position into x,y. We can then compute f(x, y) and put it in fxy (this is to save some time in computation) and then return:[ new res, [ x + step, y + step * f(x, y) ] ]The new res value is just res with f(x, y) stuck on the end (that's what the ::: operator does, it concatenates two lists).
Two small syntactic things to note:
- There is not a single semicolon in this program. Scala doesn't need the semicolons at the end of lines, although you can include them if you like.
- There are no return keywords in this program, even though we have functions. Scala doesn't require the return keyword, it will insert it where it thinks you are trying to return something.
So I'm not sure if I'd recommend you actually write Euler's method like this, instead you would probably write it something like this in Scala:
def solve_de(func: (Double, Double) => Double)(step : Double, iterations: Int)(x_0: Double, y_0: Double) = {
var x = x_0
var y = y_0
var res = List[Double]()
for (i <- 0 until iterations){
val fxy = func(x, y)
x = x + step
y = y + step * fxy
res = res ::: List(fxy)
}
res
}However in this case, you wouldn't be able to use all those fun little toys that Scala gives you, so I did it in a different way.1In Scala fold and reduce are two different things: fold takes an initial element, where reduce uses the first element of the list as the initial element. Reduce will throw an exception if used on an empty list, where fold will just return the initial element. In non-Scala languages, reduce and fold are the same thing.
Nov 16, 2009
Dusting Off sdljava
I've been wanting to use Scala for little graphical apps fairly often these days, however the major issue is that doing any basic graphics operations with Java seems to be a pain in the ass. You have to go through AWT, which is a big mess. In fact, I can't even do a basic plot pixel! (If I'm wrong, please correct me.)
So I looked up sdljava, which is a port of SDL to Java. They pretty much just wrap up the C calls using JNI, and put some nice little objects everywhere. It's a bit cleaner than regular SDL using C.
However after trying it out, I found that it crashed all the time. Which was pretty lame. So I decided to roll up my sleeves and make it work. After a little while, I realized that what was causing it to crash was some pointer tricks generated by SWIG, which is an interface generator for C/C++ code. I fixed up some of these pointer tricks and voila! It works again.
I was initially excited and was planning on notifying the maintainer of sdljava, however since there haven't been any commits to the repo for about 4 years, I figured that it has been abandoned. I forked the CVS repo, converted it to git (since I don't know how to use CVS and don't really feel like learning it) and have put up my own repo of it on Github here if you are interested in checking it out. I don't know if I will be actively repairing things, more just fixing things as they come up (since for the most part the system is complete).
So I looked up sdljava, which is a port of SDL to Java. They pretty much just wrap up the C calls using JNI, and put some nice little objects everywhere. It's a bit cleaner than regular SDL using C.
However after trying it out, I found that it crashed all the time. Which was pretty lame. So I decided to roll up my sleeves and make it work. After a little while, I realized that what was causing it to crash was some pointer tricks generated by SWIG, which is an interface generator for C/C++ code. I fixed up some of these pointer tricks and voila! It works again.
I was initially excited and was planning on notifying the maintainer of sdljava, however since there haven't been any commits to the repo for about 4 years, I figured that it has been abandoned. I forked the CVS repo, converted it to git (since I don't know how to use CVS and don't really feel like learning it) and have put up my own repo of it on Github here if you are interested in checking it out. I don't know if I will be actively repairing things, more just fixing things as they come up (since for the most part the system is complete).
Nov 15, 2009
Welcome to Karmic
Last year around this time I did a a little review of Intrepid. I forgot to do one in May about Jaunty, so I'll make up for it by doing one now about Karmic.
There's been some negative press about Karmic, saying it is really buggy and incomplete. Others haven't had too many problems, and say that the negative press is unfair.
One small note: there are bugs with every new operating system release that I have used. Ever since I installed Windows 95, I have seen issues with new operating systems. They don't always work the same as before, they change things, or introduce new bugs, etc. This is normal. Surprisingly enough, I have been impressed with past Ubuntu releases (Feisty and Jaunty come to mind) where things actually upgraded really smoothly - in fact the move from Edgy to Feisty is what really sold me on Ubuntu, it was a really great upgrade. Before that I was still using XP as a primary with Edgy for messing around.
My issues with Karmic haven't been terrible. My network still works, so does my sound. The issues are more with papercut-like things. There are little things that come up that are not giant failures (I remember back in Gutsy when you wanted to install the Nvidia drivers you had to kill the X server - see my post about it) but are annoying little things that you kinda go, "well that's annoying." A small list of them:
What has gone right with Karmic? Well, not a whole lot I think. It isn't horribly broken, which is nice. Ubuntu One is really useful, and I think the Ubuntu Software Centre is a lot cleaner than the Add/Remove programs that used to be there. Also it upgrades to Firefox 3.5, which is a bit speedier than Firefox 3.0.
All-in-all, I wouldn't say Karmic is a bad release, I just don't really see much point in using it. If you really want Ubuntu One then it is good, but other than that if Jaunty is working for you then you should probably just stick with that.
There's been some negative press about Karmic, saying it is really buggy and incomplete. Others haven't had too many problems, and say that the negative press is unfair.
One small note: there are bugs with every new operating system release that I have used. Ever since I installed Windows 95, I have seen issues with new operating systems. They don't always work the same as before, they change things, or introduce new bugs, etc. This is normal. Surprisingly enough, I have been impressed with past Ubuntu releases (Feisty and Jaunty come to mind) where things actually upgraded really smoothly - in fact the move from Edgy to Feisty is what really sold me on Ubuntu, it was a really great upgrade. Before that I was still using XP as a primary with Edgy for messing around.
My issues with Karmic haven't been terrible. My network still works, so does my sound. The issues are more with papercut-like things. There are little things that come up that are not giant failures (I remember back in Gutsy when you wanted to install the Nvidia drivers you had to kill the X server - see my post about it) but are annoying little things that you kinda go, "well that's annoying." A small list of them:
- Flash doesn't recognize mouse clicks - annoying for watching non-autoplay Youtube embeds, or using Google Analytics. A fix can be found here.
- Suspend/resume and compiz - sometimes when I come back from suspend compiz crashes. Slightly annoying since I'm using Avant Window Navigator which depends on compiz's livelihood. It's not a big deal, it's just annoying to have to go to Preferences->Appearance and start compiz again.
- Empathy - I posted about this here already so I won't go into details again, I just find that Empathy doesn't really offer anything over Pidgin. This is not a papercut, more just a "why did they do that?"
- System Tray Icons - sometimes system tray icons look really weird, and there's a bunch that don't make sense. I have one that says my network cable is unplugged, even though it is quite obvious that it's not since I am on the Internet as we speak. Also some of the icons are messed up, they show a solid grey square behind them instead of the gradient image I have for my GNOME panels. Again this one isn't a huge issue, just ugly.
- Bluetooth Applet - my fix no longer works since they changed the Bluetooth applet. It's nice that they show a system tray icon for Bluetooth, unfortunately there's a bit of confusion. When I right-click, it says "Bluetooth: On" and has a menu item to disable Bluetooth, but when I go into the Preferences panel it says Bluetooth is disabled and has a giant button to turn it on that doesn't actually work for me, when I click it the button goes grey and nothing else happens. Unfortunately the dialog has nothing else than that except an option to stop displaying the system tray icon. So I'm not really sure what to do here, if I fix it at some point then I will blog about it.
- Wine is weird to install. See my fix to install it.
What has gone right with Karmic? Well, not a whole lot I think. It isn't horribly broken, which is nice. Ubuntu One is really useful, and I think the Ubuntu Software Centre is a lot cleaner than the Add/Remove programs that used to be there. Also it upgrades to Firefox 3.5, which is a bit speedier than Firefox 3.0.
All-in-all, I wouldn't say Karmic is a bad release, I just don't really see much point in using it. If you really want Ubuntu One then it is good, but other than that if Jaunty is working for you then you should probably just stick with that.
Nov 14, 2009
Installing Wine in Karmic
Each time you upgrade Ubuntu you have to tweak your Wine repo for the newer version. This is not a huge problem, you can just follow the instructions on Wine's site which are nice and clear.
Karmic seems to be a little weird with this. The issue comes when you want to actually install wine through Synaptic. You can't install the package "wine" anymore, you get an error like this: "wine: Depends: wine1.2 but it is not going to be installed". You can fix this easily by just installing the wine1.2 package, but it is kinda weird that they did not set up the dependencies properly. Oh well.
So in short, to install wine:
1) Follow the instructions to add the Wine repository.
2) Go to System->Administration->Synaptic Package Manager
3) Search for wine1.2
4) Install the wine1.2 package by double clicking it. Accept any dependencies it asks for.
5) Click Apply.
Karmic seems to be a little weird with this. The issue comes when you want to actually install wine through Synaptic. You can't install the package "wine" anymore, you get an error like this: "wine: Depends: wine1.2 but it is not going to be installed". You can fix this easily by just installing the wine1.2 package, but it is kinda weird that they did not set up the dependencies properly. Oh well.
So in short, to install wine:
1) Follow the instructions to add the Wine repository.
2) Go to System->Administration->Synaptic Package Manager
3) Search for wine1.2
4) Install the wine1.2 package by double clicking it. Accept any dependencies it asks for.
5) Click Apply.
Nov 13, 2009
Accented Characters in Ubuntu
A long time ago I set up my computer so that it was easy to type accents, but with the recent Karmic release the settings are gone and since I forgot how to set it up. Now that I've rediscovered it, I can not only reset it but also blog about it!
So suppose you want to type French characters like é, ç, etc. In Ubuntu, you can activate these with the following steps:
1) Go to System->Preferences->Keyboard
2) Click the Layouts tab
3) Click the button saying Layout Options
4) Click the triangle next to the Compose key position
5) Choose which compose key you want. I use Right Win.
After that, you should be able to use the accented characters. You can do this by first pressing your compose key, then your accent (not at the same time!), and then the character. For example to do a é, I would hit the Right Win key, then the ' key, then the e key.
You can do special characters too, like æ, but those ones usually you have to figure out on your own (for those interested, that one is Right Win, a, e).
So suppose you want to type French characters like é, ç, etc. In Ubuntu, you can activate these with the following steps:
1) Go to System->Preferences->Keyboard
2) Click the Layouts tab
3) Click the button saying Layout Options
4) Click the triangle next to the Compose key position
5) Choose which compose key you want. I use Right Win.
After that, you should be able to use the accented characters. You can do this by first pressing your compose key, then your accent (not at the same time!), and then the character. For example to do a é, I would hit the Right Win key, then the ' key, then the e key.
You can do special characters too, like æ, but those ones usually you have to figure out on your own (for those interested, that one is Right Win, a, e).
Subscribe to:
Posts (Atom)
