Blogs

After much MUCH swearing and cursing and after finding this page on the net:

http://www.scalatest.org/download

I finally managed to get my scala sbt android project to bloody work using 2.8.1 as the base, having built an emulator ramdisk with the predexed jars already on it.

How? I changed the 1.6.1 to 1.5.1, which seems to fit the text of the above page i.e. 1.6.1 is for scala 2.9.1 and 1.5.1 is for 2.8.1+

In fact, here is my complete build.scala file from the project directory.

Low down is to go here and do what it says to the letter. I am using 11.04 and it worked like a charm!

http://android.modaco.com/topic/308968-19may-superboot-rooting-the-pulse...

Download the zip, chmod the linux script, follow the instructions and reboot the phone.

The next time you login with "adb shell" you are at the su prompt...

Kudos to MoDaCo one again. Great site.

:)

Now I can get back to installing the scala libraries on my phone

I always seem to get hardware that falls just outside of being out-of-the-box usable.

Thanks to a great many web-sites and time spent bashing I can now offer a simple solution to being able to get the damned thing to play ball with Ubuntu 11.04 for development...

First, as root, go to /etc/udev/rules and enter this, changing the username (USER) to be whatever account you are developing as:

In my continued quest to use Haskell for everything, I wrote this today: it creates a simple checksum for a Nokia CIMD2 communications driver that I am writing in PHP.

I needed a second source of verification that my PHP code was doing the right thing so I banged this out in fifteen minutes, warts and all. It may not be "perfect" Haskell but for me to get this done in fifteen minutes has been a real confidence booster, both in reading the error messages and understanding what I am doing.

Ok, following on from last time where we briefly hinted at something called referential transparency and see-through referees. We've only really started to explore all the interesting things that are going on, so to recap, here's the code for the main loop again:

SO, I sat and thought and thought and sat some more and tried to decide what would be a good introduction to doing something useful without repeating all those "hello world" programs or launching straight into to mathematical proof of how many UK politicians it takes to screw up a countries economic system. That would all be too dry.

Instead I came up with the idea of writing a real simple little program that behaves like a REPL, a "read-eval-print loop", familiar to LISP hackers and available for many other languages.

<PROMISE>I hereby solemnly promise not to show any example code ever, ever, ever, never ever on how to implement some utterly irrelevant and ivory-tower function like calculating Fibonnaci numbers, polynomials or bloody pointless recursive things to work out things that most programmers may have heard about when they were in school but ceased to have any meaningful value the minute school-life ended. Ever.</PROMISE>

Damn this was a pain. For more heads up go here: http://drupal.org/node/1065942

It's caused by stale records in the block table that then fail to resolve. There's plenty of reading material out there and suggested fixes etc. that I am sure work but once I knew what the problem was I applied *my process* for all Drupal problems like this.

We all know that by issuing this command:

bin/nitrogen attach
sync:go().
<Ctrl+D>

that the framework will rebuild things as you edit them so that you can edit and refresh the page just as you would for any other web development language like PHP for example.

I wanted to be able to make it do this when the application starts for the first time and then turn it off when I release a project.

So, how do you do it... simples... just add the call into the "/site/src/nitrogen_app.erl" file like so: