Equal implies "less or equal", right? Right?!?

Well, no, not really according to (my understanding of) C# language specification.

While reading the specification, I was struck by the definition of the relational lifted operators. The idea, roughly, is that if you've defined a relational operator working on, say, (non-nullable) types A and B, then the language automatically gives you a lifted operator working on the (nullable) types A? and B?. The specification says: For the relational operators < > <= >= a lifted form of an operator exists if the operand types are both non-nullable value types and if the result type is bool. The lifted form is constructed by adding a single ? modifier to each operand type. The lifted operator produces the value false if one or both operands are null. Otherwise, the lifted operator unwraps the operands and applies the underlying operator to produce the bool result.

Isn't it strange to define the result as false when both operands are null? Ok: unless both operands are non-null we can't really execute any user-defined operator (since they are written for non-nullable types) but throwing a NullReferenceException couldn't convey this idea well enough? You may think that, in a nullable-type, null really means "I don't know", as it happens in SQL. Indeed, in a SQL expression null is different from any value, including itself. Well, as you may be suspecting, I wouldn't write a blog entry without an interesting twist ;-)

So, here it is: the equality operators are lifted too and, guess what, The lifted operator considers two null values equal, and a null value unequal to any non-null value.

Ah ah! So null is equal to null after all... yet, it's not "less (greater) than or equal" to itself! Am I the only one finding this definition... aehm unusual?

A simple example:
int? i = null;
Console.WriteLine(i == i); // true
Console.WriteLine(i <= i); // false

Press play on tape - c64 revival band

It's certainly not a secret I'm a Spectrum addicted, yet I have a thing for home computers in general. So, today I'll post something about a Commodore 64 (!) revival band. They're called Press play on tape and they really rock: my advice is to check their site out and enjoy their music. Have fun!

Dog risks life for kittens

This is not a word play and the subject would be definitely off-topic if it weren't for the "random things" part of the blog subtitle ;) Anyway, it's been a while since I posted something and I've found this piece of news quite moving.

Why java.io.PrintStream is badly designed

Sweeping the exceptions under the carpet is considered a bad practice, I mean really bad practice. Consider, for instance,
try {
  do something
} catch (SomeException e) {
  set a flag (or, even worse, do nothing!)
}


Obviously, one of the great advantages of having an exception mechanism is that programmers do not need to explicitly check for error conditions after every single statement: when something wrong happens, an exception is thrown and it will be handled where it is sensible to do so (low-level code can't usually know what to do but, thanks to the automatic propagation of exceptions, it luckily doesn't have to).

When exceptions are swept under the carpet, instead, higher level-code can't react with some sensible action (when something wrong happens) for the simple reason that such a code has no way to know that something has happened! Well, ok, if a flag is set, then the high-level code could do something if it checks for the flag after every single statement. This works, but it clutters the code with a series of "if (flag is set) do something appropriate" that could be totally avoided by simply using the exception mechanism in the first place.

I hope everyone agrees that sweeping exceptions sucks; keeping this in mind, let's read the documentation of java.io.PrintStream (from the API docs): Two other features are provided as well. Unlike other output streams, a PrintStream never throws an IOException; instead, exceptional situations merely set an internal flag that can be tested via the checkError method. Ah ah! They call it a feature! I'm so sorry I've missed the point and I thought it's a bad hack to avoid to follow their "Catch or Specify requirement".

I know: it would be annoying to declare that every method that prints something may throw java.io.IOException, yet, it would be the only correct way to handle the error condition. With a flag we:

1. have to check the flag everytime
2. lose both the reason (the type of the exception) and the place (the line of code) where something bad has happened

Is this the worst thing about the class PrintStream? Actually, no, it isn't: PrintStream extends Outpustream, overriding the write methods with its set-the-flag semantics. So, every time you handle an OutputStream you're handling something that may or may not throws exceptions in the way it should!

Sun has admirably implemented two "features" ;) in one fell swoop:

• sweeping the exceptions under the carpet (bad practice)
• defining a subtype whose methods do not respect the specification of its supertype, that clearly states that an exception is thrown when an I/O error occurs (awful practice)

Who wants to be a researcher?

In [Javascript is not enabled; please enable JS in your browser to see the counter], an open competition will take place at my university to fill a position as Assistant Professor. Will I get the position or the sack? ;)

I'm excited, kinda scared and counting the seconds down.

Running Turbo Pascal 1.0 on (a real) Spectrum +3

As I wrote in my previous post, I was determined to run Turbo Pascal 1.0 on a (real) Spectrum +3. The issue is how to dump a DSK image file (on the PC) onto an actual three-inch Amstrad/Sinclair floppy disk (like the one shown in the second picture by a friend of mine who, by the way, is a very skilled hacker).

One obvious way is to connect a three-inch floppy drive to a modern PC. While this should work, I've already tried and failed :-(
Moreover, in doing so I was always worrying about damaging the floppy drive, the PC or both. For these reasons, I was looking for an "all software" solution.

Luckily, I've found a very nice utility in the Alchemist Software PD/Shareware Library allowing to backup (and then restore) disks to tapes. Basically, this utility dumps the disk tracks to a series of data files. Each disk (actually, each side of a disk) is dumped into five 36K blocks, which is hardly surprising considering we need to dump 180K and the available RAM is about 40K. Curiously, this neat utility cannot be found in the Utils section. To obtain this utility you need to download the game Cannon Bubble +3, from the Games section. While it is indeed a good game, we're not interested in the game per se, but rather in the bundled utility.

Using this utility in Spectaculator it's easy to create a (virtual tape) TZX file containing the dump of any DSK image file. In my test I used the Turbo Pascal image file I've previously created.

I thought (hoped) to bring this TZX into a real Speccy using an SD card and the ZXMMC+ interface. This would have been amazingly fast and cool ;) ... unfortunately, my plan have failed because I haven't figured out how to use the ResiDOS, needed to load the virtual tape stored in the SD card, and the +3 floppy drive (when the ResiDOS is active the drive identifiers are mapped to the SD card slots). I think there must be some workaround, but I haven't found it out yet.

So, how did I manage to dump the disk? Well, in the old-fashioned, simple and painfully slow way of using the EAR socket of the Speccy (as you might remember, it takes about five minutes to load a 48K game and we need to dump 180K... you do the math!). What I did is equivalent to dumping the DSK image into a real tape and then load it into the Speccy... but without the real tape ;)

I've connected the Speccy to the soundcard of my PC and I've used the tape recorder of Spectaculator to play the just-created virtual tape. If you try this way, make sure to select "Boost loading noise volume" in the options for the Cassette Recorder (Main menu -> Options... -> Cassette Recorder).

While I'm not totally satisfied because the way I had to fall back on the soundcard-based solution, it indeed worked :-) as the third picture shows.

Running Turbo Pascal 1.0, on the CP/M, on the Spectrum +3 (emulated on Windows)

I've never been a fan of the Pascal programming language; actually, I can't stand it... for a lot of reasons, many of which can be found in the (old and must-read) paper "Why Pascal is not my Favorite Programming Language" by Brian Kernighan.

However, Turbo Pascal was different. The language was still not my favorite, but I have to admit it was far better than the standard one and the IDE was quite revolutionary for its time. I've used Turbo Pascal in the early nineties for some projects in high-school and college and, after that, I thought that was it.

Well, never say never I guess: today, when I've come across Turbo Pascal 1.0, in a wave of nostalgia I felt the urge to write and compile an "Hello World" program in dare I say ... Pascal! ;-)

It turns out that my favorite computer, in its +3 flavor, can run CP/M... how interesting! In the picture you can see Spectaculator (probably the best Spectrum emulator around) running my just-written one-liner Pascal program, compiled with Turbo Pascal one-oh :-)

In preparing this little experiment, I've found invaluable the French program (with, luckily, a French/English GUI) Manage DSK, that can create DSK disk images from a collection of files on your PC. In my case, the files contained in the Turbo Pascal ZIP archive.

For unknown reasons, in the conversion process I had to pretend that all the files were ASCII even if they're clearly not. I've noticed that in converting the files as binaries the program prepends some sort of header, which makes them unusable (maybe this has something to do with how the Amstrad CPC handles files, I don't know).

My experiment is not over though: now I have to run it on the real hardware. So, I need to find a way to put the Turbo Pascal files on an actual 3-inch disk. I think I can use an SD card and the almighty ;) zxmmc+ interface to bring the data in the real-Speccy realm, so I can then dump the image on an actual disk. This will be (probably) the topic for a future post: stay tuned.