Saturday, 27 July 2013

JavaScript Function Overloading

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.

I've uploaded it here.

//prompted by: http://ejohn.org/blog/javascript-method-overloading/

//baseFn: function that will be used when the overloaded function is invoked with a non matching number of parameters
function overload(baseFn /*, overload1, overload2...*/){
 //returns an overload aware function
 function buildOverload(baseFn){
  var overloads = {
   "default": baseFn
  };
  overloads[baseFn.length] = baseFn;
  var overloadedFn = function(){
   if (!overloads[arguments.length])
    return overloads.default.apply(this, arguments);
   else
    return overloads[arguments.length].apply(this, arguments);
  };
  overloadedFn.overloaded = true;
  overloadedFn.add = function(fn){
   overloads[fn.length] = fn;
  };
  overloadedFn.remove = function(fnLength){
   delete overloads[fnLength];
  };
  return overloadedFn;
 };

 baseFn = baseFn || function(){};

 if (!baseFn.overloaded)
  baseFn = buildOverload(baseFn);
 overloads = [].slice.call(arguments, 1);//obtain array from arguments pseudoarray removing the first element 
 for(var i=0; i≶overloads.length; i++){
  baseFn.add(overloads[i]);
 } 
 return baseFn;
}

if (typeof module !== "undefined" && module.exports){
 exports.overload = overload;
}


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

The Devil's Advocate

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!

I've found the discourse here:

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".

By the way, Hocico used this speech as a sampler, and the result was excellent..

Sunday, 21 July 2013

The Odd Case of the Dual-core Netbook

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.

Windows Device Manager:

Windows Task Manager:

However, the Lubuntu Task Manager (lxtaskmanager) tells me it's a Single Core machine, pretty odd:

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

Some Thoughts on Iterator.Remove

In my last article I mentioned that Java's Itearator<>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

Modify while iterating

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:

for (var i=cities.length-1; i>= 0; i--){
 if (condition(cities[i]))
  cities.splice(i, 1);
}

other people prefer to stick to the forward iteration and carefully update the indexer when a removal is done:

for (var i=0; i≶cities.length; i++){
 if (condition(cities[i])){
  cities.splice(i, 1);
  i--;
 }

.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≶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:

foreach (string st in myList.ToList())
{
if (condition)
myList.Remove(...);
}

foreach(string key in myDictionary.Keys().ToList())
{
if (condition)
myDictionary.Remove(...);
}

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).

Iterator<Integer> iter = l.iterator();
while (iter.hasNext()) {
    if (condition(iter.next())) {
        iter.remove();
    }
}

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?

cities.forEach(function(city, index, arr){
 if (condition(city))
  arr.splice(index, 1);
});

Again, it works nicely.

Jennifer Connelly

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.

Sunday, 23 June 2013

Some Notes on IDisposable and Finalizers

Every now and then I still find myself scratching my head when adding a finalizer to a class or implementing IDisposable in a C# application, so I thought I would do a fast write up that sure could come handy the next time. By the way, I love JavaScript and firmly think one can write incredibly beautiful and complex code with it, but at the same time it keeps you so shut down from Resource Management or Concurrency that basic knowledge on these areas all of a sudden looks like "hardcore programming".

There are tons of resources around about this, but this is one of the most complete ones. From that and many other articles, we should know that the common pattern for a class implementing IDisposable and containing a Finalizer is something like this:

public class DisposableClass : IDisposable
{
    ~DisposableClass()
    {
        Dispose(false);
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // Clean up all managed resources
        }
            
        // Clean up all native resources
    }
}

So far so good. I'm not going to explain how the above works, or how the GC and Finalization work, it's explained in detail in thousands of places (indeed I also wrote about .Net's GC before [1] and [2], I'll just recap below a few points that seem useful to me:

  1. So, when should I care about implementing such pattern in my own classes?
    Basically, if your class directly owns an unmanaged resource (a Windows handle mainly) you'll need to write a finalizer that takes care of releasing such unmanaged resource.
  2. OK, and then, does having a Finalizer mean that my class has to implement IDisposable?
    In short, Yes. Well, when you write a Finalizer you make sure that the unmanaged resources will be eventually released by the GC-Finalizer maphia. As GCs take place in a non deterministic way you could play better with the whole system by allowing consumers (owners) of your objects to release these resources when they are done with your objects. For this, you should implement IDisposable, so that these other guys can directly call to you Dispose() method (or indirectly by means of the using clause). Notice that as reflected on the code above, such Dispose should invoke GC.SuppressFinalize, this way your object is removed from the finalization queue, and the GC-Finalization will work faster.
    This said, someone noted in StackOverflow that there are a few classes in the Framework (e.g. Threading.Thread and WeakReference) which have finalizers but do not implement IDisposable.
  3. Understood, but one more thing, does it make sense to implement IDisposable but not having a finalizer?
    Yes it does. If your class does not hold unmanaged resources, it won't have a finalizer, but it could hold instances of other IDisposable classes. In that case, you must implement IDisposable and invoke the Dispose() on those instances from your own Dispose(). Furthermore, your objects could want to run some other final actions when they are no longer needed (write to a log...) so that should also go in your Dispose, and well behaved consumers would remember to invoke it.

An important point to reckon is being careful in our finalizers not to invoke actions in other objects that could no longer be valid (cause their finalizers have run earlier than ours). I mentioned it here saying that you should refrain from calling a finalizable object from your finalizer. Well, indeed it's not just calling into finalizable objects, it's calling to any object implementing IDisposable what you have to avoid.
Let's say we have:

  • class A has a finalizer, is IDisposable and holds a reference to class B.
  • class B has no finalizer, but is IDisposable cause it has a reference to class C
  • class C has a finalizer and is IDisposable
If A's finalizer called to a method in B, it could be that such method would invoke some functionality in C. If C's finalizer had already run (which could be as finalizers are run in an undetermined order), we would have a problem there.

Before ending this post I'd like to mention how the special syntax (~MyFinalizer) defined by the C# team to facilitate the writing of Finalizers can add some confusion to people with some C++ background.

Annotation (Joe Duffy): Earlier in the .NET Framework’s lifetime, finalizers were consistently referred to as destructors by C# programmers. As we become smarter over time, we are trying to come to terms with the fact that the Dispose method is really more equivalent to a C++ destructor (deterministic), while the finalizer is something entirely separate (nondeterministic). The fact that C# borrowed the C++ destructor syntax (i.e. ~T()) surely had at least a little to do with the development of this misnomer. Confusing the two has been unhealthy in general for the platform, and as we move forward the clear distinction between resource and object lifetime needs to take firm root in each and every managed software engineer’s head.