Blog Without An Important Name

After several months of not getting around to it, I’ve finally put out a new version of eMusic/J. There aren’t a huge number of changes in this one, but there is one that will be significant for new users: it no longer requires Sun Java, any 1.4 Java environment will do the job. Thanks to Retroweaver, eMusic/J can be run in a completely Free Software environment. And, as a more practical benefit, no more jumping through hoops to get the right version of Java installed, and then recognised as default by the system. I’ve tested it on GCJ 4.1 (which comes with Ubuntu) and there was no noticable difference.

I hope that this gets me closer to being able to do a native build, and have it run without a Java runtime at all. However, despite running it just fine, GCJ is unable to compile it (even compiling the bytecode - the source is still 1.5, which I expect it to choke on anyway). If anyone has experience with this kind of thing, please let me know!

Here’s the changelog:

• Added ‘User Manual’ option in help menu, which opens a browser (by
  default Firefox, this can be changed by using the ‘undocumented’
  browserCommand option in the prefs file.) - this should have been there some time ago, but I kept putting it off, planning to try using JDIC to do it. However, JDIC doesn’t provide a 64-bit build, and I don’t yet have one of those machines myself to build it on. So I did it by hand.
• The update dialogue now offers to open a browser to the application homepage - as above
• Updated SWT to stable 3.2 build - a recent SuSE update has killed SWT for a few people. Hopefully this fixes it. Unfortunately, I can’t test it.
• Added option to automatically remove completed downloads from the downloads list. This happens 30 seconds after it finishes. - I don’t see much point keeping a list of completed downloads at the top of the screen, you’re normally just interested in the ones that have finished. So now, completed ones go away after 30 seconds (this can be turned off)
• Builds now use retroweaver to gain JDK1.4 compatibility. This means it works with GCJ, and probably other open JREs. - probably the most important change, but the one that current users will (hopefully) notice the least

Don’t delay! Go get yours today!

If you want to link to an html file directly in a subversion repository, there is a problem. By default, subversion doesn’t distinguish between filetypes other than binary versus text. So when you request a (text) file directly from the repository, it comes in as text/plain, no matter what it really is. This causes all standards-following browsers to render it as text, which isn’t so good if it’s an HTML file. The same problem will also exist if you reference CSS files, as they will be ignored if they don’t have the correct MIME type (at least, this used to be the case with Firefox).

However, fixing this is pretty simple:

svn propset svn:mime-type text/html *.html
svn propset svn:mime-type text/css *.css

do a commit, and you can now provide links directly to HTML documents inside your repository.

This change can be made across all new files you put in the repository by adding the following lines towards the end of ~/.subversion/config:

*.html = svn:mime-type=text/html
*.css = svn:mime-type=text/css

This stuff is documented more in the subversion book. One word of warning, the MIME type for JavaScript files is application/x-javascript. If you set your .js files to this, then Subversion may start treating them as binary. I haven’t tested this, but it doesn’t matter, as Firefox doesn’t seem to care what the MIME type of JavaScript files is.

Here is a great explanation of when using proprietary, or at least close-format-based, software can be life-threatening.

Quite a scary idea.

I was playing with a test server for something I was working on, and one of the data files got corrupted. From the look of it, half way through one write process, another started, erased the file, wrote the new content, finished. Then the first one wrote the remainder of the data. This confused me a fair bit, as I knew I’d implemented file locking to prevent that very thing happening.

So I wrote a test case.

The test case I wrote seems to work on Windows, but throws an assertion failure on Linux. I’d be interested to know what’s going on here. File locking seems a little bit black-magic-like.

The test case can be download from here, but the bulk of it (in ugly wordpress non-formatting) is:

File testFile = new File("_testfile.txt");
FileOutputStream fout = new FileOutputStream(testFile);
fout.write(new byte[] {1,2,3,4,5,6,7,8,9});
fout.close();
fout = new FileOutputStream(testFile);
FileLock lock = null;
try {
	lock = fout.getChannel().lock(0, Long.MAX_VALUE, false);
	assertNotNull(lock);
	Thread thr = new Thread() {
		public void run() {
			File testFile = new File("_testfile.txt");
			FileLock lock = null;
			try {
				FileOutputStream fout =
					new FileOutputStream(testFile);
				lock = fout.getChannel().
					lock(0, Long.MAX_VALUE, false);
				if (!isInterrupted()) {
					fail("Lock broken :(");
				}
			} catch (Exception e) {
				throw new RuntimeException(e);
			} finally {
				if (lock != null && lock.isValid())
					try {
						lock.release();
					} catch (IOException e) {
						throw new
							RuntimeException(e);
					}
			}
		}
	};
	thr.start();
	Thread.sleep(1000);
	thr.interrupt();

I was asked to install Ubuntu Linux on someone’s Acer Travelmate 230 laptop, and I ran into a problem that was very easily fixed, once I knew what it was. However it wasn’t documented anywhere under the laptop model, which made finding the solution hard.

The problem was that X would start with only a 640×480 resolution, and no amount of xorg.conf tweaking would make it behave otherwise (well, it also often came up with a completly black screen. I have no idea what that was about). The installer correctly detected that it needed the i810 driver, and that was set up. However, the video card (I can’t remember the exact chipset name, but it’s an Intel) has no RAM of its own, and instead relies on taking over part of the system RAM to work. By default, this is set at 1Mb, which isn’t enough for any kind of decent resolution. I think that the Windows drivers must override that, but it seems the Linux ones don’t. To make it work, all you have to do is go into the BIOS settings, go to Advanced and change the setting, which (IIRC) it calls ‘UMA’, from 1Mb to 8Mb. All of a sudden, the Linux drivers report that it can happily go up to 1024×768, and it works well. If I’d known that from the start, the install would have been quite seamless.

I haven’t tested the other parts of the hardware, such as the modem, but I wouldn’t be surprised to find that they work well too.