Async and Await

On Microsoft’s PDC Anders Hejlsberg gave a talk about two new keywords in C# - async and await.

I will not get into them to much - those interested in more can start with taking a look at actual presentation. In essence, they give you new way of dealing with asynchronous tasks. You just point to system where asynchronous operation might occur and C# (or VB.NET) compiler will build all background code that it needs to handle this gracefully. For me it does same revolutionary thing as yield did for enumeration. Seeing this, I got pissed at Java.

Part of my time I spend as Java developer. And I get pissed at it all the time. Whether it is half-assed implementation of generics, absence of in-language support for yield, and in a year-or-so, I will extend this to absence of async and await.

True Java believer would say that all those things are just syntactic sugar - there is nothing magic in them that could not be written by hand. I consider this irrelevant. It is not point whether something can be written, to me most important is point how easily. If I use e.g. yield, there is almost no chance I will mess it up in three lines it takes to do it. When I write code for it in Java, this expands to few tenths of lines needed for state machine. Error chance and debugging time increases exponentially.

I value Java a lot. It is beautiful language at it’s core and it gave huge boost to development of all managed languages. However, it seems as Latin language to me. Nice and beautiful but there is just no significant development of it’s syntax. It takes more and more effort for me to switch between new modern languages (where I would include C#) and Java. I always find something missing…

P.S. Yes, this post is full of exaggeration, but I do not consider it too much off mark.

2032

Illustration

After annual maintenance of power grid in my neighborhood with few hours without power, my trusty file server went down. It wasn’t first time that it went down. It was first time it stayed down.

This was alix1d embedded PC with FreeNAS running on it so my first thoughts went to file corruption. And I was right, there was some file corruption, but nothing that simple fsck could not solve. However, boot process still had issues.

I will not detail everything that I tried. It is sufficient to say that I wasted whole day playing with this thing. As last resort I decided to reinstall system.

As I went into BIOS to set my boot device, I noticed that my BIOS password is missing. As I went through setting, everything seemed to be on default. And default is not state you wish your alix1d board to be in.

FreeNAS has some issues with ACPI on this board. It will just not boot if you have it turned on. And I had it turned on in my BIOS. Fixing was easy - just turn it OFF. All that wasted time amounted to issue I already knew.

Reason why BIOS settings were changed was simple CR2032 battery. It usually keeps BIOS settings nice and fresh but mine was dead. Any power outage would cause same issues. It was accident waiting to happen.

I checked old invoices and it happens that this system is only two years old. I find it quite peculiar that battery is already gone. There is something that is drinking battery like mad on this motherboard.

Anyhow, everything works perfectly with new battery. I only hope that I will remember this issue when everything fails again in two years. :)

Infinity Is Not an Exception

From time to time I find some behavior that I cannot really neither explain as correct nor as incorrect. Best description would be peculiar.

Let’s take simple code:

static void Main() {
    int x = (int)double.PositiveInfinity;
    Debug.WriteLine(x);
}

This will cause compile error “Constant value ‘1.#INF’ cannot be converted to a ‘int’ (use ‘unchecked’ syntax to override)” and personally I view this as correct behavior.

Let’s complicate things a little:

static void Main() {
    double posinf = double.PositiveInfinity;
    double neginf = double.NegativeInfinity;
    int x = (int)posinf;
    int y = (int)neginf;
    Debug.WriteLine(x);
    Debug.WriteLine(y);
}

Here I expected one nice runtime exception. However, I was greeted with -2147483648 as a result for both positive and negative infinity. This I did not expect.

My personal opinion here is that this operation should throw exception. I cannot see any sound reasoning for converting infinity to any finite number. It is called infinity for a reason!

However, I do notice that most of languages choose to have this conversion pass. Unfortunately for C# they (e.g. Java) opted for slightly different behavior.

Java converts negative infinity in same manner C# does but positive infinity gets converted to 2147483647. This may not seem like much, but this at least enables positive infinity to be larger than zero which seems mathematically sound to me (if we ignore all that infinity thing :)).

My personal opinion here is that exception should be thrown. Only thing that this conversion can lead to is data corruption - and this is not a good thing.

P.S. I reported this as an issue to Microsoft. I am really interested how they view this situation.

[2010-12-30: I got answer. It is by design.]

LogCat Does Not Show Log Messages

LogCat is quite good thing to look at when program goes haywire since it usually shows both system and developer’s own log messages.

If you are trying to debug your Android program inside of Eclipse and you cannot see your custom log message, fixing it might be as simple as going to DDMS perspective and selecting your current device (whether real or simulated).

LogCat window displays only messages from device in focus and that might not be device you are currently debugging.

QText 2.30 (Beta 3)

Although I was preparing for final version here goes another beta. I decided upon it since internals of QText were rearranged quite a bit.

Just to make it worthwhile, there is support for hiding tabs and lot of polishing. Download is here and soon (really this time) there will be final.

P.S. Since most of things that was asked for is now implemented, I am open for suggestions.