Saturday, 27 July 2013

Somehow I recently came across this old post by John Resign about Method Overloading in JavaScript. Just a few lines of beautiful JavaScript code, but I don't like much the idea of wrapping one function over another. Also, his sample applies only to "methods", so I decided to write my own, rather different, implementation, that applies to functions, uses my beloved technique of adding metadata and "methods" to functions, and allows for the removal of overloads.

Notice that both John's implementation and my implementation base the dispatch mechanism in the number of parameters received by the function. Last year I wrote about multimethods in JavaScript, that though related, is quite different. In this other case your function also has several implementations (so it's overloaded), but the dispatch is based on the "type" of the parameters.
My basic Multimethods implementation just will throw an error if not "full match" is found, that is, both the number of parameters and the exact type match (if the exact type does not match it won't consider as valid an overload where a base type exists). So well, I guess I should think about writing an improved version...

Monday, 22 July 2013

Yesterday I watched again The Devil's Advocate, one of my all times favourite films. The movie has an interesting plot and develops pretty well over it's first 2 hours, but it's the last 10 minutes what turn it into a masterpiece.

Al Pacino's anti religious speech left me speechless the first time I watched this film, you're before a Hollywood production and suddenly you stumble upon one of the fiercest and most intelligent attacks on religion that you can imagine!

John Milton: I want you to be yourself. Y'know, boy, guilt is like a bag of ing bricks. All you gotta do is set it down.....Who are you carrying all those bricks for anyway? God? Is that it? God? Well, I'll tell ya, lemme give you a little inside information about God. God likes to watch. He's a prankster. Think about it. He gives man instincts! He gives this extraordinary gift and then--what does he do? I swear--for his own amusement--his own private cosmic gag reel--he sets the rules in opposition. It's the goof of all time! Look. But don't touch! Touch. But don't taste! Taste. Don't swallow! [laughs] And while you're jumping from one foot to the next, he's laughing his sick ing ass off!! He's a tight ass, he's a sadist, he's an absentee landlord!! Worship that never!

Kevin: Better to reign in Hell than serve in Heaven, is that it?

Milton: Why not? I'm here on the ground with my nose in it since the whole thing began! [screaming] I've nurtured every sensation Man has been inspired to have! I cared about what he wanted and I never judged him. Why? Because I never rejected him. In spite of all his imperfections, I'm a fan of man!!
[Calms] I'm a humanist. Maybe the last humanist. Who, in their right mind, Kevin, could possibly deny the 20th century was entirely mine? All of it, Kevin, all of it! Mine! I'm peaking here! It's my time now. It's our time.

wow... can you picture yourself in Keanu Reeve's (Kevin) shoes? Al Pacino (John Milton) spitting such words of wisdom while a nude Scandinavian Goddess (yes, I've got sort of an obsession with this "Valkiria") tries to push you into bed?

The whole performance by Al Pacino is superb, I can't think of any way to improve the way he plays the polyglot, ultra smart, party minded, sleepless, handsome devil "business leader".

Sunday, 21 July 2013

I purchased a second hand laptop a few weeks ago (yes, it may sound like a bit retro/vintage thing to buy a netbook now when they've almost gone away... but let's say it took me a while to find a situation where a netbook could be useful to me).
It's a Vaio VPCW12J1E, and first of all, in case anyone is contemplating to get one, I want to state here that Lubuntu (light Ubuntu) works like a charm on this machine. WiFi will work nicely out of the box, sound card, everything, even the key shortcuts for brightness and sound! and it's absolutely astonishing to see how little memory it needs, really amazing, much more when we've got used to such resource hungry crappy software like Android...

This netbook already came with Windows 7 starter, which works pretty horribly performace wise, but it's not a Windows thing itself, it's something with the tons of (unnecessary) software that retailers add to it...
Well, the thing is that to my surprise Windows 7 tells me that I have a dual-core processor, which was quite unexpected cause it seemed to me that most netbooks (and more from that time, 2009) are single-core machines.

As you can see from one of the screenshots above, this is an Atom N280 processor, and as I suspected, Wikipedia tells us it's a Single-core Processor, so WTF?
After a few searches the answer revealed itself in some forum, it's a Hyper-threading (HTT) thing!

Hyper-threading, wow, that brings up some old memories. A long while ago I was pretty much into how hardware works, and I quite well remember having printed and read some material about this "Virtual MultiProcessor" kind of thing, back in early summer 2002 (at that time the Itanium also seemed like the new king of the party) In a few years Multi-core processors became common place, and the Hyper-threading thing just was no more (or at least that's what I wrongly thought).
In short (not just to save space, but because I have a minimum knowledge about this topic), in an Hyper-threading processor some units in the processor core are duplicated (but not all of them, so it's very far from being a Multi-core/Multi-processsor), so that under some conditions it offers some sort of multiprocessing. The Operating System will see it as 2 cores, and will schedule 2 threads simultaneously, and then depending on the instructions/state of the processor, sometimes some sort of parallelism will happen.

This has made me muse over concepts I had almost forgotten, like the Processor Pipeline and Superscalar processors. Well Superscalar and Hyper-threading seem quite related, as in both cases some functional units in the processor are duplicated in order to provide some form of parallelism. This wikipedia entry is quite elightening. My understanding then is that with superscalar techniques (the attempt of) parallelism happens with instructions belonging to the same thread/process, and without any knowledge on the OS side, while with Hyper-threading, this (attempt of) parallelism happens between different threads/processes, and needs of the OS taking part on it.

This thing of Lubuntu's Task Manager showing only 1 processor made me wonder whether my OS would have the Hyper-threading support enabled, so I did a couple of checks to verify that HTT support was enabled:

sudo dmidecode

where the status: Populated, Enabled means that HTT is enabled

run top and press the "1" key, so that processors are listed (Cpu0 and Cpu1):

This last check was particularly odd. As HTT is a very limited form of parallelism, it would appear fine to me if Linux decided to show me a single processor, but the fact of top displaying 2 processors and the Task Manager displaing 1, is confusing to say the least

Thursday, 11 July 2013

In my last article I mentioned that Java's Itearator&lt>T> features a remove method that is missing in .Net's IEnumerator<T>. Such difference is a bit surprising, and at first thought it seemed to me that it made Java Iterators more powerful that .Net Enumerators. Well, after giving it a second thought, it strikes me that such remove method should not be there.

Why am I saying this? Well, first I would recommend reading this good discussion, even when it's not much related to what I'm going to discuss below. So, in principle the idea looks good, as removing while iterating is problematic, why not add such functionality to the class that already takes care of the iteration? This class has deep knowledge of the class being iterated, enough knowledge to allow it to take the necessary measures so that a removal operation does not break the iteration. So far so good, so what's the problem?

First of all, now the Iterator interface has 2 capabilities (responsibilities), iterating and removing while iterating, when probably some classes just need the first one, iterating. So, I would prefer 2 interfaces here, something like Iterator (that just iterates) and something like RemoveEnabledIterator.

You could say that if you're not happy with current Iterator, you can just create your own ReadOnlyIterator/Iterable interface and use it rather than Iterator/Iterable in those classes that don't allow the removal. There's a huge problem here, that Iterator is a fundamental class in the Java language, as Iterable-Iterator form the basis for the enhanced for loop (for : ). This means that with the current design, if you want to be able to iterate one collection with (for : ) it has to implement Iterable, so you'll have to define an Iterator, and you'll be forced to implement a remove method in it. OK, some people will say that you're not forced, as the documentation states that the remove method is an optional operation. Problem is that this "optional" thing seems a bit messy to me, it just means that you can implement it or throw an UnsupportedOperationException, which entails that consumers of an Iterator can not assume that your Iterator supports remove and they'll expect to see it cleary explained in your documentation. This question provides some good information.

So, all in all, I reckon I'm quite more happy with .Net's IEnumerable-IEnumerator pair.

Sunday, 7 July 2013

Modifying (or trying to modify) a collection while iterating (enumerating, traversing) over it is one of those common source of errors that even if you're completely aware of it will probably continue to slip in your code once in a while, even more when there are differences between languages and platforms. So I thought it would be good to do a fast recap here.

Arrays and classic loops

Well, this is pretty clear and simple. Regardless whether you're writing C#, Java or JavaScript, if you're in the middle of a normal for loop or a while and decide to remove the current item, you'll have to be careful with the indexer or you'll end up skipping elements. The approach I always follow is iterating backwards:

.Net Enumerators

If you're iterating over any of the standard .Net collections with a foreach loop and you try to Add or Remove items to it (or even update a Dictionary so that an existing entry points to a different Object), you'll end up getting an InvalidOperationException.How does this happen?
.Net's iteration paradigm is based on the IEnumerable<T> and IEnumerator<T> interfaces. Whenever you use a foreach loop, the compiler is creating an Enumerator and using its Current property and MoveNext method. If you decompile the Framework assemblies with the wonderful ILSpy and check for example the source for List.RemoveAt and List.Enumerator.MoveNext you'll see that List has an internal numeric field: _version, that is incremented each time the List is modified. When an Enumerator is created over such collection, it saves the value for the collection's _version at that point, and in each MoveNext it compares the saved _version with the current _version in the collection, if they don't match it means that the collection has been modified and the Enumerator will throw an InvalidOperationException. This logic applies to all (I think) Collections in the BCL.

Depending on your collection (if it has a numeric indexer) you could switch to a classic loop and do as explained above, but you better stick to the foreach iteration, create a list of the items to be removed, and once the iteration is over, do a Remove of those items.

Removing while iterating a Dictionary deserves some extra attention. You'll run into the same "don't modify while enumerating" issue both with this:foreach(KeyValuePair&lg;K, V> pair in myDictionary)
and with this:foreach(K key in myDictionary.Keys())
cause the enumerator that you obtain in the second case is also watching the _version field in myDictionary.

This leads us to another strategy for removing from inside a foreach: iterating over a copy of the collection (that simple as using ToList()) but removing from the original collection. That is:

Java Iterators

Java's equivalent to C#'s foreach loop, IEnumerable and IEnumerator is the "enhanced for loop" (for (Type t : collection), Iterable<T> and Iterator<T>, and it all works right the same as in its .Net counterpart. If you try to remove an element from the collection from inside a "for :" you'll get an UnsupportedOperationException. The huge difference is that Iterators have a Remove method, which allows you to Remove while iterating if you're using a loop type other than "for :" (you don't get a reference to the iterator created by the enhanced for loop, so you can't use it directly there).

JavaScript for in, and Array.forEach

In accordance with its tradition of always being slightly unlike the others, JavaScript behaves a bit differently here. JavaScript objects are sort of dictionaries, so what would happen if you try to remove a property from an object while iterating those properties with a for in?

for (var key in person){
if (condition(person[key]))
delete person[key];
}

well, it works without a problem. And what if we try to remove from an Array being iterated with the modern Array.forEach?

I've recently watched 2 excellent drama films starred by Jennifer Connelly (the junkie in Requiem for a Dream) that I think I should recommend here.

House of Sand and Fog is a shaking story. You have a young woman that has partially lost her grip on life due to some personal problems, and a family of Iranian immigrants that aim to thrive in their exile to recover the status they enjoyed in the Shah period. Their lives intersect and tragedy bursts, as a small tragedy first, but then one more partially broken creature adds to the equation, and when you think a solution and happy ending could be quite close... a devastating turn will blow you away and leave you gasping. The performance by Ben Kingsley is also remarkable.

Reservation Road deals with common topics: on one side the lost of a loved one and spiralling downwards when failing to get over it and seeking revenge, on the other side: committing a huge mistake, the failure to amend it and how it all rots you from inside. At one moment the films seems like it could turn into a masterpiece, but it does not wind up developing so masterly. Anyhow, it's a really good film that deserves a good deal of attention.