Sean's blog

IE8 javascript not running from script element in head

After staring at other people’s solutions to this problem for a day or so, I finally realised what I was doing wrong and thought I’d better share it, just in case you also fail to see for several hours how you caused the problem. I have a page that works nicely in Firefox, Chromium, Opera etc and fired up an old copy of WinXP on VirtualBox to check the site worked okay in IE. I wanted to show it to someone whose website was obviously written by and for users of Microsoft software, so was gutted to see a horribly broken page or, when I tried various hacks to see what was happening, no page at all.

To cut a long story short, the problem was caused by me emitting a SCRIPT element in the document’s HEAD that looked like this:

<script src="/static/js/shipping-methods.js" type="text/javascript" />

when it should be this:

<script src="/static/js/shipping-methods.js" type="text/javascript"></script>

The former (empty element) works just fine in every browser I have but IE8, the latter (block element) works in every browser including IE8.

Now that I’ve figured out what the problem is, it’s easy enough to find a web-page with the answer (and several comments recalling the pain this problem caused for them) such as “Why don’t self-closing script tags work?” at Stack Overflow. Reading through the comments – far enough – makes me think “D’oh! Of course!”. My site’s pages are served as XHTML unless the user-agent is IE, in which case my XHTML-generating code includes these headers:

X-XHTML-HTML-Hack: http://www.w3.org/TR/xhtml-media-types/#media-types
Content-Type: text/html; charset=UTF-8

The problem is that the self-closing element (or whatever you like to call it – I have Java classes that generate such things with names varying on a theme of EmptyElement, but I see pages that suggest that’s something different) is valid in XHTML but not in HTML. IE gets content from the server which it is told is HTML and silently fails to parse the self-closing element, trashing the page in the process.

So now I know. Beware the self-closing script element in XHTML pages sent with the text/html kludge to Microsoft browsers.

Posted in Broken, Fixed, Useful | No Comments »

Having your own printer is so last century: online printing services

We needed to send a couple of small documents by post and realised – while we are in the ‘No Fixed Abode’ phase of our Keep-It-Simple-Stupid plan to move back to the UK – that another thing we don’t have in our luggage is a printer. We’re currently using a friend’s house in a beautiful village in the Peak District which is not over-equipped with Internet cafes. I helped a friend pack up their belongings after their job in Cheltenham had come to an end last week, and I picked up an old inkjet printer from among her belongings, but the ink was dry and a new printer seems cheaper than replacement cartridges for the old one. We have an inkjet printer in Malaysia, and there’s an old one in my parents’ attic, but perhaps in parents’ attics is the right place for a printer now? After all, that’s where the VHS video recorder is, that’s where the LP collection and ‘hi-fi cabinet’ is, and the fax and the dialup modem. And the Walkman!

It seems silly to buy yet another inkjet printer and sillier to buy ink that is more expensive than a new inkjet printer. We don’t print very often. We tried thinking of what we do print. Recently letters of complaint / campaign and AirAsia booking confirmations have been the most common prints. A few datasheets a year? Not a lot really. Since my last phone upgrade I’ve been in the habit of snapping timetables and maps with the built-in camera and viewing the stored image on my phone’s screen when I need to.

I searched for “print documents online” to see what it would cost and got a few pleasant surprises. With a few offerings of A4 prints coming in under 30p per page (for small prints, for large multiple-page prints prices fall to below 10p per page), we would spend far less over the course of a year than we would spend on printers and ink. I’m excited by this idea and looking forward to receiving my first online print: a 2-page letter complaining about lost mail.

There’s no great need for urgency for this job, so I’ve chosen options that cost me a grand total of 64p – but had to pay £1 as a minimum balance on my account. I found another site that suggested the same job would cost 36p a couple of days ago, but didn’t bookmark it. I used pc2paper.co.uk for this job, and found it quite straightforward. One small wrinkle is that PC2Paper doesn’t seem to allow sending 2 files in one envelope, and my second page was a PDF document from a 3rd party. I struggled to add the PDF to an OpenOffice.org (or is it LibreOffice now?) document, so in the end used this handy PDF concatenation incantation:

gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=combinedpdf.pdf -dBATCH 1.pdf 2.pdf 3.pdf

to combine the two PDFs into one.

I’m interested to see how quickly my (2nd class postage!) cheaply printed document will arrive. I could have sent it directly to the recipient, but we want to send the letter registered and that option wasn’t offered by PC2Paper.

Posted in Broken, Fixed, hardware, Life, Money, Useful | No Comments »

Trying out JBullet: IntBuffer is not direct

JBullet Basic Demo

I’ve been simulating the movement of a line-following robot in plain old Java recently, but wanted to try a few problems that need physics, so I downloaded JBullet – a Java port of the Bullet  Physics Library. It needs LWJGL – the Lightweight Java Game Library – to run its demos, so I installed that in exactly the way they say you don’t need to and ran into this Exception when I tried running the JBullet demos/basic/BasicDemo.java (I setup my PC so that I can right-click on Java files in ROX-Filer and choose ‘File..theJVM’) – here’s the stack trace:

Exception in thread "main" java.lang.IllegalArgumentException: IntBuffer is not direct
at org.lwjgl.BufferChecks.checkDirect(BufferChecks.java:127)
at org.lwjgl.opengl.GL11.glGenTextures(GL11.java:1459)
at com.bulletphysics.demos.opengl.FontRender$GLFont.load(FontRender.java:124)
at com.bulletphysics.demos.opengl.FontRender$GLFont.<init>(FontRender.java:68)
at com.bulletphysics.demos.opengl.LwjglGL.init(LwjglGL.java:55)
at com.bulletphysics.demos.opengl.LWJGL.main(LWJGL.java:60)
at com.bulletphysics.demos.basic.BasicDemo.main(BasicDemo.java:221)

I saw a couple of pages that suggested using an old version of JBullet to avoid this error, but a quick read of the API documentation for java.nio.Buffer made me think this wouldn’t be so hard to fix. Here’s the change I made to jbullet-20101010/src/com/bulletphysics/demos/opengl/FontRender.java:

// next line is the one that causes Exception
// glGenTextures(IntBuffer.wrap(id));
ByteBuffer bb = ByteBuffer.allocateDirect(4);
// ENDIANNESS has no effect here?
// bb.order(ByteOrder.LITTLE_ENDIAN);
IntBuffer ib = bb.asIntBuffer();
ib.put(1);
glGenTextures(ib);

recompiling FontRender.java leads to a similar Exception in com.bulletphysics.demos.opengl.LwjglGL.glLight, so a similar change in jbullet-20101010/src/com/bulletphysics/demos/opengl/LwjglGL.java:

/*
public void glLight(int light, int pname, float[] params) {
  GL11.glLight(light, pname, FloatBuffer.wrap(params));
}
*/
public void glLight(int light, int pname, float[] params) {
  ByteBuffer bb = ByteBuffer.allocateDirect(params.length * 4);
  bb.order(ByteOrder.LITTLE_ENDIAN);
  FloatBuffer fb = bb.asFloatBuffer();
  for (float f : params)
    fb.put(f);
  fb.flip();
  GL11.glLight(light, pname, fb);
}

… and we get the demo! I hope this helps someone. I’m sorry there’s no explanation about that ENDIAN constant. Omitting the line in glLight() produces a working demo, but without light. I’m guessing the explanation for why it’s needed is quite straightforward, but it’s 2:30am and I must sleep.

PS – the code looked horrible, and I realised I’ve been posting horribly-formatted code for donkey’s years, so I installed the WordPress SyntaxHighlighter Evolved plugin. I think it looks pretty good – well, comparatively!

Posted in Broken, Fixed, FOSS, software | 10 Comments »

LEGO Mindstorms RCX cable rot / decay

Some of the LEGO I have in the house must be 30 years old. It’s as good as the day it was first unwrapped. I have to admit to being disappointed when one of my two RCXes stopped responding to the IR tower. I was pleased the other one was still working just fine and was looking forward to testing my old research software (a program that uses a ‘genetic’ algorithm to create a novel kind of controller which I then simulate on the RCX). When I looked through the bag of cables I discovered a catastrophe – the cable sheaths had rotted away:

LEGO RCX cable rot / decay

It looks to me like some kind of mildew and varies in severity from cable to cable, but I don’t have a single unaffected piece. The best ones (click on the photo for a larger image, see the top cable) have just a little cracking around the entry into the terminal brick. The cables sheaths on these ones are unusually soft and the black sheath surface can be easily scraped off with a thumbnail, though not down to bare wire. Most of the others have far worse decay where the sheath has disintegrated into flakes or lumps which has fallen away leaving bare wire.

I rather stupidly opened the worst-affected piece – a light sensor – to see how difficult it would be to replace the entire cable, but broke the light sensor, probably while trying to de-solder the glued-in end of the wires from the small PCB inside. I think my best bet for now is to clean the bare cables, cut the cables quite close to the terminal bricks and insert new wires with boots over the joins. I can’t buy any replacements at the moment as I’m due to move from Malaysia to the UK in the next few weeks. I may well check eBaY for RCX cables when I’m unpacked in the UK.

I’m a bit rattled by the severity and extent of the failure of these cables – LEGO should last forever, right?

Update: Not sure why I forgot to update this article, but I filled in a ‘contact us’ form at LEGO’s website soon after writing this article and LEGO sent me some replacement cables within days of the article’s date. Thanks to Juan Carlos for reminding me with his comment, I can finish the article with thanks also to LEGO!

Posted in Breaktime, Broken, Life | 4 Comments »

BrickOS on Ubuntu 10.10 Maverick Meerkat

BrickOS was an integral part of some work I did many years ago and I’ve been trying to dig the code up recently. It seems as though it fell out of the Ubuntu repositories some time ago (in as legos before the name change), so I’m currently installing the source package from the BrickOS sourceforge repository.

I followed the BrickOS installation instructions. Binutils was downloaded from packages.debian.org (stable/squeeze). Ubuntu Software Centre reminded me that the package was available from normal software channels – but I tried that first and failed! Next up, gcc-h8300-hms (stable/squeeze), also installed via Ubuntu Software Centre.

Attempting to ‘make install’ the BrickOS source at this point got me a “Error: invalid operands” fail, but a search turned up a lugnet comment by ‘Kyle’ who had the same problem and posted a link to his own notes on how to install BrickOS. He used a patch by Jochen Hoenicke to fix the problem. I used ‘wget http://hoenicke.ath.cx/rcx/brickOS/brickos-gcc33.diff’ in the BrickOS source directory to download the patch and ‘patch -p0 < brickos-gcc33.diff’ to apply it. After applying the patch ‘make install’ finished without error.

The next problem is that none of my current PCs have a serial port! I have some USB-serial adapters that work a treat with some other hardware. According to /var/log/messages (watched with the Log File Viewer from the System..Administration menu) my serial port is ttyUSB0. The installation notes tell me to issue the command ‘export RCXTTY=/dev/ttyUSB0’. The first attempt at using firmdl3 got me no result at all, it just sat there apparently doing nothing. I got much the same response from the ‘dll’ command. Not sure what might have been going on, I installed a serial terminal emulator (gtkterm / moserial) and connected to the serial port. A few random keypresses later, I spotted the green LED in the lego IR tower lighting up and some kind of data being sent back to the serial terminal. firmdl3 and dll both seemed to work just fine with the tower after that.

The last step is to try communicating with my 2 RCXes which have been languishing in a box for 6 years. I’ve a feeling at some point in the past when I had access to more RCXes, I may have ended up with mis-matched IR towers. I have one RCX2.0 and one RCX1.0 – I have old pictures of the 2.0 in action, but couldn’t connect to it with either of my IR towers. I successfully uploaded BrickOS and the helloworld demo to the 1.0 though, even if the RCX1.0 took a lot of cell-rolling before it would even switch on (both rechargeable cells and contacts were corroded).

So I’m rolling on RCX1.0, BrickOS and Ubuntu Maverick Meerkat – time to make some progress! Not sure what to do with the RCX2.0 – it’s going back in the box for now until I can work up the motivation to probe the problem in greater detail.

Posted in Breaktime, Broken, Fixed, FOSS, hardware, Life | No Comments »