Russel Winder's Website

Using a Vodafone GPRS Connection as a Modem

A few weeks ago, I was in the position of having to use my P900 as a modem or risk losing money. I had previously tried to get this working and researched lots of websites, set up phone, computer and Vodafone account but no joy. Vodafone do not support Linux and as I am using Ubuntu 6.06 Dapper Drake this means no technical support from them. Well it used to.

This time I had no alternative and had to the P900 as a modem. I went to my local Vodafone shop to rant and rave about their incompetance and discrimination against Linux users, threatening to change network operator but the very nice people in the shop remained cool and calm and told me that Vodafone had totally revamped its technical support and that I should try again rather than switch to another network operator. Having done the cathartic ranting, I just did what they told me and phoned technical support again and was pleasantly surprised by the change of attitude in technical support. Rather than fob me off with 'Linux is not supported, you should switch to Windows or Mac', they said 'We can't help you but here is the phone number of a group who can' and I phoned and they could. It turns out everything had been right about the set up I had in the first place except that I was using the wrong phone account because 3 didn't mean 3 it meant 1 - i.e. I changed a 3 to a 1 in my chat script and everything has worked since.

Of course this mechanism of getting an Internet connection is extortionately expensive but when you have to do it, it is good that it works.

I have written up some notes on my experience which can be seen here

A Groovy Article

Back in April I gave a talk on Groovy at the ACCU 2006 conference. As I mentioned on 2006-04-24, I wrote an article for the ACCU journal `{CVU}' based on some of the material. This has now appeared:

Russel Winder (2006) 'Hello Groovy', {CVU} 18(3), pp.3-7.

Unfortunately, there are a few typos in the printed code listings. If you want to see the original manuscript I sent in, you can get a PDF file by clicking here.

Is Erasure Ruining Java?

Java used to be a simply typed system. This led to lots of type errors but there was a sort of consistency. Then came Generics which were supposed to give us extra type safety and in simple cases do. However, as soon as you try to do anything half way sophisticated, erasure hits you over the head .

At compile time X<A> and X<B> are different types. This is good and very consistent with type theory. However at run time X<A> and X<B> are the same type -- they are both just X because of the erasure system Sun invented. Now this wouldn't be a problem if there was only static typing but there isn't, Java has dynamic type checking and casting -- not full dynamic typing but enough to cause real problems for the programming model. For example, If I define a generic type with value equality rather than identity equality then:

assertTrue ( ( new X ( ) ).equals ( new X ( ) ) ) ;

does not fail as a run time statement which is almost certainly totally surprising to the reader of the code since they are looking at the statement and thinking in compile time types. The conflict arises here because equals has to be written with a parameter of type Object to get overriding.

Then of course, we have the compile time / run time conflict associated with casting. For example:

X xa = (X) p ;

causes a compile time warning since the cast is actually (X) p due to erasure. However if you write:

X xa = (X) p ;

the compiler issues an error because of the inconsistency between the use of a parameterized type and the raw type. So Java has a built in conflict and it appears not to be going away in the near future.

I have other examples that get worse but they are too large to put up here.

Sun introduced this wonderful new technology of type erasure in the name of backward compatibility and not changing the JVM. But then they went and changed the JVM anyway but not by introducing the small changes that would allow run time types to include type parameters -- unlike C# which got it right from the outset. Like C#, Python and Ruby do not have this problem. Groovy avoids the problem by ignoring Java 5.0 and sticking with Java 1.4, at the expense of having all the problems of the underlying Java type system. However, it is a totally dynamic language like Python and Ruby so the mindset is different.

So my (bold) assertion is that Java is being ruined by the type erasure system and the programmer confusion it causes. Sun should alter the JVM to implement run time parameterized types properly. I don't see why this wasn't done for Java 5.0 -- it is clear that an extension to the JVM can be made that has no problem executing already compiled classes fine.

Or does anyone have a way of thinking about the Java type system and erasure that creates a nice consistent mental model?

Groovying at ACCU 2006

The ACCU 2006 conference was last week and was as good as ever. ACCU is a group of programmers, designers and trainers who are interested in C++, Python, Java, etc. -- see here for the ACCU website. On the Friday, I did a 90 minute presentation on Groovy and included a bit on Grails. A PDF file of the slides can be found here. I have no idea why OpenOffice.org2 rendered the slides so badly, when I view them with ooimpress2 they look a lot nicer - all green for a start, no white. If there is a clamour for the ODF format file, I will put it up.

All the source code for the presentation can be found here. I am in the middle of writing the talk up as a paper for the ACCU journal just now so, rather than write a long article here with all the code explained in context, I will leave you on tenterhooks awating publication of the paper!

Constructing `JList`s

I have just been using a JList for the first time in ages. I see that (in JDK1.5 -- why isn't it JDK5.0?) there is a constructor taking an array and one taking a Vector but not one taking a List, ArrayList or LinkedList. I would have thought that the requirement for the data to a JList was that it was a sequence. In Java, List is the type for a sequence so why isn't it allowed? Why pick out Vector for special treatment? I can see that discrimination against LinkedList is more or less acceptable because a LinkedList is not a random access sequence -- indexed access is O(n) instead of O(1) and so this is not a good data structure for the model of a JList. ArrayList however is a perfectly adequate random access sequence yet you have to use ArrayList.toArray() to create an array to provide the model for a JList.

Unless I am missing something really obvious, it seems that the people who develop Swing do not believe in The Collections Framework. Sun say that ArrayList is to be preferred over Vector but it seems that Sun is not listening to its own message, continuing to ignore Collections in Swing. I assume that the use of Vector is a hang over from pre-Collections days, which is many, many moons ago now. Given that a Vector is a List and the toArray method works fine, why haven't they deprecated the Vector constructor and/or replaced it with a List constructor?

If anyone knows the answer to this trivial but irritating conundrum do tell.

Trying to get my P900 connected to Debian GNU/Linux

I have tried a number of times in the past to get my Sony Ericsson P900 connected to my workstation (which runs Debian GNU/Linux Testing with the odd bit of Unstable, basically Mono and a couple of C# applications) either by Bluetooth or using the USB cradle. I have never managed to achieve the real goal which is managing the phone's filestore from the workstation and synchronizing the phone with Evolution. This time I decided I had to get it all working.

Getting basic file transfer using Bluetooth is actually relatively easy. I am running kernel 2.6.8-2 which means that all the necessary bits that need to be in the kernel are already in the stock kernel. So by loading the standard Bluetooth packages and getting Edd Dumbill's Gnome Bluetooth packages and using gnome-obex-server and gnome-obex-send I have Bluetooth file transfer in both directions. The site I used as a driver for my actions was Stefan Bellon's page on Debian GNU/Linux and the P900.

Next step was to follow Stefan's instructions for getting p3nfs working. The p3nfs package downloads and installs fine. Stefan then says load nfsapp into your phone. OK, so where is nfsapp? It is not in the downloaded package anywhere as far as I can see. Looking in /usr/share/p3nfs, it seems the package includes the source and you are supposed to build it yourself but that means loading the whole Symbian SDK in order to do the compilation. On speculation I downloaded the p3nfs source package and there was a precompiled file: bin/nfsapp-2.8-UIQ.sis. I used gnome-obex-push to send it to the phone and it worked nicely. Well it started and seemed to be behaving sensibly anyway. I wonder if the p3nfs packager needs to think a bit more carefully about the p3nfs binary package so that the prebuilt nfsapp actually arrives with the binary package.

Stefan's page then tells you to configure the rfcomm stuff which is easy except that he doesn't mention how to get the , i.e. the bluetooth address of the phone. He assumes you know that using "hcitool scan" gets you the information. OK so /etc/bluetooth/rfcomm.conf is set up. Stefan then says run "p3nfsd -UIQ -tty /dev/rfcomm11 -dir " (where for me is /media/RLW-P900) after having started nfsclient (presumably nfsapp!) on the phone -- NB I had already added set uid on the p3nfs command. Easily done and fails. I got:

|> p3nfsd -UIQ -tty /dev/rfcomm11 -dir /media/RLW-P900 p3nfsd: version 5.15, using /dev/rfcomm11 (115200), mounting on /media/RLW-P900 /dev/rfcomm11: No such device

but of course it is there:

|> ll /dev/rfcomm11 crw-rw---- 1 root dialout 216, 11 2005-02-18 19:28 /dev/rfcomm11

and I am in group dialout and p3nfs is set uid so I can run it as me rather than root. I emailed Stefan about this and we agreed that it may well be a udev problem. More experimentation needed to sort this out.

So I then looked at the p3nfs documentation (/usr/share/doc/p3nfs/doc/bluetooth.linux). It proposes using /dev/rfcomm0 rather than /dev/rfcomm11 and performing the rfcomm port binding manually rather than using the configuration file. I notice that the p3nfs documentation assumes you already have nfsapp (or is it nfsclient :-) loaded on the phone but following the instructions at least caused some communication between workstation and phone. Starting the nfsapp on the phone already starts the Bluetooth mode (despite what the documentation says in Point 7, do "rfcomm bind /dev/rfcomm0 11" as root or using sudo followed by "p3nfsd -UIQ -tty /dev/rfcomm0 -dir /media/RLW-P900" and I get a dialogue on the phone asking if I wish to accept the connection. Looking good. Press accept. And it worked. Amazing :-)

|> p3nfsd -UIQ -tty /dev/rfcomm0 -dir /media/RLW-P900 p3nfsd: version 5.15, using /dev/rfcomm0 (115200), mounting on /media/RLW-P900 p3nfsd: to stop the server do "ls /media/RLW-P900/exit". (pid 22305)

I was then able to wander around the A:, C:, D: and Z: drives of the phone from the workstation. Wonderful. OK, it may seem sad to find such a trivial thing exciting but it is progress and a lot further than I have got before.

Further experimentation indicates that using /dev/rfcomm11 works fine as Stefan said it would if the binding is done manually rather than relying on the /etc/bluetooth/rfcomm.conf file. I guess Stefan's instructions would have worked if whatever it is in the rfcomm system was doing what it should be doing. I guess the manual bind forces something that doesn't happen if you rely on the rfcomm configuration to do the binding. More experimentation needed.

Anyway enough for now. Next I try the cradle.

A Subrange Type for C++

I spent some time recently learning much more about C++ templates and generic programming in C++. As part of this I wrote a subrange type for C++. It seems only reasonable to release this (under the Boost Licence version 1.0) in case it is any use to anyone. More details on subrange are here.

Fontconfig Problems and Learning to Use Gtk+

I have been having a problem with fonts and font selection in on my Debian GNU/Linux system. In particular, I am having problems with fontconfig not correctly organizing the fonts into typefaces and styles. Also I have some fonts where I have both Type 1 and TTF files of the font in the fontconfig path and things are getting mightily confused but this is actually just another aspect of the basic naming problem.

The basic naming problem is that fontconfig assumes that the font will present font names, typeface names and style names in a consistent and known way. There seems to be no problem with Type 1 fonts, except occasionally Book is replaced by Regular as the style but this is not really a problem at all. TTF fonts on the other hand seem very problematic. The scheme for naming fonts, typefaces and styles seems either not to exist or to be flouted for some reason. I have no idea if Micro$oft Windows gets round the problem as I do not use that system but fontconfig clearly does not. To investigate this I need a browser of the fonts on my system that can more carefully deconstruct information about and browse fonts.

I have in the past used gfontview. However this has a number of problems: it is a GTK1 application and I am using GTK2 and, more importantly, it only displays fonts for a given directory and does not assemble fonts into typefaces and styles. However, it has many of the features of the sort of display I want. Nautilus of course provides thumbnail previews of fonts and by double clicking gives the individual font viewer. This is nice in many ways but doesn't allow easy browsing since the thumbnails only display Aa and it is directory at a time. OK so it is possible to have multiple Nautilus windows up but you have to specify each and every directory and so you end up with 9 or 10 windows and there isn't enough screen space. Also this does not allow fontconfig driven browsing. There is of course the GTK font selection dialogue. This understands fontconfig but it doesn't give information about the source of the font -- if there was a way of finding the file name for the given style of a give typeface using this dialogue I probably would be using that and not writing this!

So I am looking for a font browser which must:

  • Be able to work by being given a list of directories to show the fonts for or use fontconfig to work with the set of fonts available to GTK applications. So two distinct modes of working.
  • Be a browser of a catalogue of fonts rather than a simple chooser, i.e. I want to be able to see all the fonts all at once -- OK not entirely possible but I do want to be able to make a selection of a set of fonts and see them all displayed together.

Asking around, the two most helpful comments I got were "Its a 20minute hack in PyGTK." and "There are lots of new font browsers being worked on." For all the searching of Google I cannot find mention of any new font browsers but this may just be my bad searching ability. If anyone knows of any work please email me. So it seemed to be time to think about doing it myself. I have masses of other things to do and don't really have the time but it has to be done.

The immediate question then is which language? Well GTK etc. are all C-based systems but C is basically assembler so we don't want to use that. GTKMM gives a binding for C++ so that is one possibility. Python has PyGTK. Ruby has Ruby- Gnome. Java has Java-Gnome. Groovy is also a possibility since it can use Java-Gnome. So I did a little experiment: I wrote a program in each of these languages to put up the GTK font selection dialogue box just to see how painful each of the languages were. The idea being that if the project ended up being half-way useful then it would probably need to be written in C but for prototyping use the easiest language possible. So here are the various versions:

  • C++
  • Python
  • Ruby
  • Java
  • Groovy This is not groovy Groovy. It needs rewriting to use closures but this may entail writing a complete GTK builder like the SwingBuilder and the SWTBuilder.

In many ways they are all much of a muchness. Java, Groovy and Ruby allow signal handlers to be defined at the connection call using either anonymous classes or closures and that is nice. Very nice. C++ and Python are much more mainstream for these sorts of application.

Decisions, decisions. Time for some more dithering.

Apache2 and PyBlosxom 1.1

It is probably just me not looking hard enough or, perhaps, just not knowing enough (i.e. maybe everyone who installs PyBlosxom with Apache2 just knows this) but I couldn't find anywhere on the Web or the PyBlosxom 2 documentation the details of how to make Apache2 do the right thing. The PyBlosxom documentation itself says nothing but I did find How to Install PyBlosxom, Section 1.5 of which at least had something but it wasn't really the right answer.

I hassled Ross Burton as is traditional for me in this sort of situation and after a few email exchanges put some rewrite rules into the Apaches2 configuration file -- you can also use .htaccess files of course. Here is the relevant Directory section:

Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all RewriteEngine on RewriteBase / RewriteRule ^$ blog/ RewriteRule ^index.htm.$ blog/ RewriteRule ^default.htm.$ blog/ RewriteRule ^blog$ /cgi-bin/pyblosxom.cgi RewriteRule ^blog/(.*) /cgi-bin/pyblosxom.cgi/$1

The trick of redirecting everything through a dummy URL may well be standard and in hindsight it is obvious but it wasn't until Ross told me about it. (Many thanks to Ross for answering all my emails with patience and real facts.)

Learning about PyBlosxom

Prompted by the very widespread use of blog software for running Web sites, I decided to try the idea out. Given that Ross Burton uses PyBlosxom, I decided to try that. I already run Apache2 so installation of PyBlosxom was really as easy as "follow the instructions". Then there was the task of creating the flavour that actually gives the site its style, this was a totally different matter from the ease and simplicity of installing PyBlosxom but I found ideas from various Web sites and ended up with what you see here. It will change.

Perhaps the hardest two bits of getting going were: a. getting Apache to do the right thing and b. deciding on how to layout all the non-PyBlosxom controlled material. And trying to stop my UPS from spontaneously switching off all my machines.

Of course it is unlikely that anyone will actually read the stuff I put up but I have found so much good material that has helped me put up by others I thought it only fair to put stuff up that might be helpful to others.

Copyright © 2017 Russel Winder -