Map and parseInt

It was quite a long time that I didn't stumble upon with some JavaScript unexpected behaviour. Well, indeed this is not one issue with the language itself, but a the combination of 2 unfrequently used parameters in 2 frequently used functions.

I was using Array.prototype.map and parseInt and was getting some crazy outputs:

let items = [1.2, 0.3, 2.4, 3.7];
console.log(items.map(parseInt).join(" - "));
//1 - NaN - NaN - NaN

Even more crazy, when using an arrow function invoking parseInt it was working as expected:

console.log(items.map(it => parseInt(it)).join(" - "));
//1 - 0 - 2 - 3

So what? Well, a first google search brought up this explanation. Just read it, but summing up, I was missing that parseInt receives a second parameter, radix, (that we rarely need) and was missing that map (same as filter, foreach...) passes over a second parameter (index) that in many cases we don't need. Both of them combined we get this unexpected behaviour.

One can come up with more examples where we could get similar unexpected behaviours, for example with a format function recieving an optional second parameter:

const format = (st, wrapSt) => (wrapSt || "") +  st.toUpperCase() + (wrapSt || "");
console.log(format("bonjour"));
//bonjour
console.log(format("bonjour", "|"));
//|bonjour|

items = ["bonjour", "ca va", "hey"];
console.log(items.map(format).join(" - "));
//BONJOUR - 1CA VA1 - 2HEY2

WebAssembly Update

Somehow the other day I came across some article talking about WebAssembly. I had some far memories of having read about this thing some years ago and even posting about it. Well, it seems like in this 4 years WebAssembly has changed and evolved a lot. What I explain in that post about the webassembly binaries describing an AST that at runtime would be compiled into bytecodes for the same Virtual Machine that runs the JavaScript code no longer applies at all. Now the WebAssembly binaries contain bytecodes for a stack based VM, that is different from the VM that runs the JavaScript code. Notice that all modern JavaScript engines are register based.

This series about JavaScript and WebAssembly is a really excellent reading, particularly this entry.

Once it reaches the browser, JavaScript source gets parsed into an Abstract Syntax Tree.

Browsers often do this lazily, only parsing what they really need to at first and just creating stubs for functions which haven’t been called yet.

From there, the AST is converted to an intermediate representation (called bytecode) that is specific to that JS engine.

In contrast, WebAssembly doesn’t need to go through this transformation because it is already an intermediate representation. It just needs to be decoded and validated to make sure there aren’t any errors in it.

In my first paragraph I've just said that all modern JavaScript engines/VMs are register based. So far for me the term engine and VM were interchangeable. The thing is that after reading this article, maybe that's not always correct. The article is mainly about V8 adding an interpreter to its combination of baseline and optimized JIT compilers, but what I find really important is the picture where it seems to say that when not using the interpreter the JavaScript code gets parsed and JIT compiled to native code without passing through a bytecode representation. So I guess we should not talk about a VM. This has quite surprised me cause it's a new scenario to add to the 2 ones that were familiar to me:

• Source code (C#, java) gets compiled to bytecodes for a stack based virtual machine (and stored in an assembly or javac file) before running the code. Then the runtime either interprets and JIT's (JVM HotSpot) or only JIT's (.NET) those bytecodes.
• The runtime parses the (JavaScript) sourcecode into a bytecodes representation (for a register based VM), and then interprets or JITs those bytecodes.

And now we have that the V8 runtime can directly JIT compile from JavaScript to Native code without going through a bytecodes Intermediate Representation, interesting... By the way, in this post from some years ago I explain the interpreter, basic/optimized JIT combinations that JavaScript runtimes were using at that time.

Generic Builder

At the beginning of this previous post I showed one common pattern for Immutable classes in C#, having a setPropertyX method in the immutable class that returns a copy of the object with the new property value (I think this is called chained setters). Another more basic approach is using the Builder pattern. I think this is more basic because you are not changing certain properties, you are passing the values for all the properties. This means we'll have constructors that can have a large number of parameters, and this is one of the use cases of the Builder pattern. You can see a Java example here, and I put my own C# sample below:

using System;

namespace Builder
{
    
public class Person
    {
        public string Name {get; private set;}
        public int Age {get; private set;}

        public Person(string name, int age)
        {
            this.Name = name;
            this.Age = age;
        }
    }

public class PersonBuilder
    {
        private string Name;
        private int Age;

        public PersonBuilder SetName(string name)
        {
            this.Name = name;
            return this;
        }

        public PersonBuilder SetAge(int age)
        {
            this.Age = age;
            return this;
        }

        public Person Build()
        {
            return new Person(this.Name, this.Age);
        }
    }

var person = new PersonBuilder()
                .SetAge(20)
                .SetName("Xuan")
                .Build();

Manually writing a Builder class for each immutable class that you want in your application can be a bit of a repetitive pain so, could we have something more generic? Well, here's my try at building a GenericBuilder in C#.

   public class GenericBuilder<T>
    {
        private Dictionary parametersDic = new Dictionary<string, object>();

        public GenericBuilder<T> SetValue(string key, object param)
        {
            //the values are given in PascalCase but the constructor params are obviously in CamelCase
            this.parametersDic[this.toCamelCase(key)] = param;
            return this;
        }

        public T Build()
        {
            var ctors = typeof(T).GetConstructors();
            var ctor = ctors.FirstOrDefault(it => it.GetParameters().Length == this.parametersDic.Count);
            if (ctor != null)
            {
                var orderedParams = new List<object>();
                foreach (var param in ctor.GetParameters())
                {
                    orderedParams.Add(this.parametersDic[param.Name]);
                }
                return (T) ctor.Invoke(orderedParams.ToArray());
            }
            else
            {
                throw new Exception("Not Suitable Constructor Found");
            }
        } 

        private string toCamelCase(string st) => char.ToLower(st[0])+ st.Substring(1);
	}
	

That we can use like this to build an instance of the aforementioned Person class:

		
	var person =  new GenericBuilder<Person>()
	.SetValue("Age", 1)
	.SetValue("Name", "Francois")
	.Build();

We set values passing the property/field name and the value and store it in a Dictionary. When we finally want to create the object we invoke the constructor via reflection passing the values in the correct order expected by the constructor.

This is the first time that I make use of ConstructorInfo to create an object, so far I'd always used Activator.CreateInstance. For this case, we need to use GetConstructors to obtain the constructor, cause we don't know the parameters order and hence we can not use Activator.CreateInstace. In other cases both options would be equally valid, for example:

//Factory method creating an object that expects a string as parameter to its constructor
        public static T ItemFactory1<T>(string id)
        {
            return (T) Activator.CreateInstance(typeof(T), new [] {id});
        }

        public static T ItemFactory2<T>(string id)
        {	
            return (T) typeof(T).GetConstructor(new [] {typeof(string)})
                .Invoke(new [] {id});
        }

I guess Activator.CreateInstance has to locate the constructor in the same (costly) way that GetConstructor does, and it has to do it each time we want to create an object. If we use GetConstructor, we can call it once and store it for ensuing calls, so if we are going to create multiple objects it's a better option. It is is mentioned in one of the comments here.

Millennium IV Film

I was (indeed I am) a big fan of the Millennium books written by Stieg Larsson. In 2009, when Millennium 1 had already become a best seller in Spain, I watched the Swedish film adaptation, and I liked it a lot. After that I furiously read the 3 books, they absolutely hooked me. Then I watched the Swedish film adaptation of the second and third book. I did not like them much, cause having read the books first the films seemed to miss many things (which is normal, you would have needed a series rather than a film). Also, I felt rather disappointed by the fact that in the third film there are moments when Lisbeth seems to be scared and not in control of the situation, when in the book this is never the case, shes always in command of whatever crappy situation she's in.

The character of Lisbeth Salander is for sure the main reason (I guess its the same for most fans of the trilogy) that got me so hooked into the story. This said, I always though that Stieg Larsson had made some mistakes when creating the character. He depicts Lisbeth as an antiauthoritarian woman with a punk-gothic look. In a country like Sweden this should have gone beyond aesthetics and she should have been a member of the real punk scene, and hence she should be vegetarian or vegan, go to concerts, wear a Mob-47 t-shirt... Anyway the character is captivating, and I think Noomi Rapace makes an amazing work in these films, indeed I've become a huge fan of her and I try to watch any film she plays in.

The USA remake of the first Millennium book seems pretty good to me also, and indeed it quite bothered me that they did not continue with a second and third installment.

Last summer I read the fourth book, the first one written by David Lagercrantz It did not hook me like the ones by Larsson, but I quite liked it and think it makes a rather decent follow up to Larsson's work. Right now I'm in the process of reading the fifth book. This book made me realize of another error in the Lisbeth character. I think that as an ultra-smart person in constant search of knowledge and empowered by it, her crappy diet makes no sense at all. Apart from a computer hacker she should be a "health hacker" taking all sort of healthy foods, smoothies, super nutrients, vitamin complements, herbal remedies and complements. This thing of surviving on junk food or taking expired antibiotics seems a bit senseless...

Last week I watched the USA film allegedly based on the fourth book. The film is entertaining, and the aesthetics are really good, but it has hardly any relation with the book other than the presence of Lisbeth Salander and the names of the other characters (just the names, because their aspect, age... does not match at all). This is not a matter of the difficulty to compress a book into a movie, its just that they are telling a different story. It's really shocking, even the relation between Lisbeth, Camilla and their father is utterly altered!

There's another thing that really bothered me. I like traveling, I love cities, and for me the city where a film is set is pretty important. If it's a city where that I've already visited I enjoy a lot seeing locations where I've been (hey, mum, I was there!) and the memories that it brings up. If it's a city where I've never set foot, the film will help me to discover it. As in the book (they did no dare to change the location from Sweden to California... which would have been quite in line with the total lack of adherence to the book...) the film is set in Stockholm. I've never been there yet, but yes, the buildings, the islands, looked like what I remember from other films or documentaries... so I suddenly was shocked when I saw Lisbeth drive to Teufelsberg, in the outskirts of Berlin! Checking the wikipedia article I find that this is not the only "fake Stockholm" in the film. The iconic bridge where she faces Camilla is in Hamburg! and even the airport is not in Scandinavia, but in Leipzig... I can accept that some generic urban scenes get recorded in a different (but similar) city, but you can not use 2 pretty well known locations of one city and make them pass as if they were in another city... it really irritates me.

Final point in my bashing against the film, the actress playing Lisbeth, Claire Foy lacks any trace of attractiveness! In the books Lisbeth is skinny, with a childish complexion, she has this punk-gothic look that can scare some people, but she's never described as ugly. In the previous films she is played by two beautiful women. Yeah, I have to concede that Noomi Rapace probably does not match everyone's idea of beauty, but for me she's extremely hot. As for Rooney Mara, what should I say?

In this film Claire Foy does a real effort to look absolutely ugly. Her haircut is just ridiculous (it's not a punk-gothic thing, it's just wearing your hair in the ugliest way you can think of). As I've said, this is not how Lisbeth is supposed to look, well, another free interpretation of the assholes that did this "adaptation".

Immutability via Proxies

There are many of the recent programming trends that feel quite odd to me and that I hardly manage to find appealing. Immutability is in part one of them. For sure it has its cases, but it's not easy to me to understand all the hype around it. This said, the other day I read a pretty interesting explanation about Angular, Interceptors and why they designed HttpRequest and HttpResponse as mainly immutable:

Although interceptors are capable of mutating requests and responses, the HttpRequest and HttpResponse instance properties are readonly, rendering them largely immutable.

They are immutable for a good reason: the app may retry a request several times before it succeeds, which means that the interceptor chain may re-process the same request multiple times. If an interceptor could modify the original request object, the re-tried operation would start from the modified request rather than the original. Immutability ensures that interceptors see the same request for each try.

There are multiple libraries and patterns to work with immutable objects. One simple pattern that I saw some time ago was something like this:

class Person
{
        public string Name {get;}
        public int Age {get;}
        
        public Person (string name, int age)
        {
            this.Name = name;
            this.Age = age;
        }
        
        public Person SetName(string name){
            return new Person(name, this.Age);
        }
        
        public Person SetAge(int age){
            return new Person(this.Name, age);
        }
}

//Main
var p1 = new Person("Francois", 25);

var p2 = p1.SetName("Xuan");

Automatic Properties in C# create a private backing field. In JavaScript this pattern becomes a bit more complex as there is no real privacy, so we would have to add some additional technique to the mix, like having the backing fields in a closure...

What seemed interesting to me was creating an immutable wrapper around a normal object. If we could trap the access to set and get operations on the existing object... well, seems like in JavaScript land proxies are a perfect fit!

So the idea is to have a function that receives an object and creates a proxy with that object as target. The Proxy has a set trap that prevents assignments from happening, and a get trap that when receiving an request for a set_XXX property (that indeed is a call to a set_XXX method, as you know in JavaScript method invokation involves 2 steps, getting the function and invoking it) will accept this as a valid assignment, creating a copy of the existing object with the new assigned value and wrapping it in a proxy so that ensuing set operations behave in the same way. The get trap does indeed return a function that when invoked does the cloning, assignment and proxy wrapping.

Well, you better check the code to understand what I'm trying to explain. Voila the function.

function createImmutable(item){
	let handler = {
		set: function(target, property, value){
			//do nothing, this object is no longer "directly" mutable
			console.log("hey, I'm immutable, you can't set me like this");
		},

		//object is mutable only by invoking a "set_XXXX" method
		//we trap that get and return a function that will create the new object with the mutated property
		//and returns a proxy around the new object, so that immutability continues to work in ensuing assignments
		get: function(target, property, receiver){
			if (property.startsWith("set_")){
				let propName = property.substring(4);
				console.log("assigning to " + propName + " via proxy");
				return function(value){
					//either use the trapped target or "this"
					//let newItem = new target.constructor();  
					let newItem = new this.constructor();
					Object.assign(newItem, target);
					//notice I've just doing shallow cloning
					newItem[propName] = value;
					return new Proxy(newItem, handler);
				}

			}
			else{
				return target[property];
			}
			
		}
	};

	return new Proxy(item, handler);
}

And below how to use it:

class Person{
	constructor(name){
		this.name = name;
	}
	
	say(word){
		return `${word}, I'm ${this.name}`; 
  }
}


console.log("started");
let p1 = new Person("Francois");

console.log("p1 says: " + p1.say("hi"));

let immutableP1 = createImmutable(p1);

console.log("immutableP1" + JSON.stringify(immutableP1));
immutableP1.name = "Xuan";
console.log("immutableP1" + JSON.stringify(immutableP1));

let immutableP2 = immutableP1.set_name("Xuan");
console.log("immutableP2" + JSON.stringify(immutableP2));

console.log(immutableP2.say("hi"));

let immutableP3 = immutableP2.set_name("Emmanuel");
console.log("immutableP3" + JSON.stringify(immutableP3));

I've uploaded the code to a gist

IOCP and Tasks

When years ago I read this so detailed article about the low level internals of async calls in Windows I was fascinated. I still think that the article is essential, but after reading more on the topic I would say there is a small inaccuracy in it, related to its main statement "There is no Thread".

After reading a bit about IOCP and Managed Thread Pools, I came across this question and its excellent answer, that adds some additional wisdom to the initial article.

There is no actual user mode thread from your process involved in any of this operation (beyond just the initial asynchronous call). If you want to act on the fact that your data has arrived (which I assume you do when you're reading from a socket!), then you have to dequeue the completed items from your IOCP.

The point of IOCPs is that you can bind thousands of IO handles (sockets, files, ...) to a single IOCP. You can then use a single thread to drive those thousands of asynchronous processes in parallel.

Yes, that one thread doing the GetQueuedCompletionStatus is blocked while there is no completion pending on the IOCP, so that's probably where your confusion came from. But the point of IOCPs is that you block that one thread while you can have hundreds of thousands of network operations pending at any given time, all serviced by your one thread. You would never do a 1-to-1-to-1 mapping between IO handle/IOCP/Servicing Thread, because then you would lose any benefit from being asynchronous, and you might as well just use synchronous IO.

So I'll try to summarize how I understand it. When your code invokes and asynchronous I/O operation and you await for the returned Task, there will be a thread waiting for the Task to complete, but it's a Thread from the I/O ThreadPool, so it's not a new thread created just for this specific operation, but an existing thread from the pool that is being reused (well, obviously if it's the first usage of the IO Thread Pool by the process, the thread does not exist yet and has to be created, but then it will be reused multiple times). The "There is not thread" really means "There is not a new thread specific just to this operation". When the I/O operation is completed a message is posted to the IOCP and an I/O Thread will pick up the message. If the code that had launched the async operation had a SynchronizationContext, this will have been captured by the Task, and then this I/O Thread will dispatch the execution (of the continuation) to this SynchronizationContext, that in turn will use the original thread that had started the operation to run the continuation, else, the I/O Thread itself will run the continuation (the "asynchronous callback" as it's also called).

We can know if one thread belongs to the ThreadPool (Thread.CurrentThread.IsThreadPoolThread) or not, but it seems like there's no way to know if if it belongs to the Worker Thread Pool or the I/O Thread Pool.

North Korea Documentary

DW, the English language German channel that has the nice habit of releasing some excellent documentaries, put out a few days ago the best documentary about North Korea that I've ever watched. All the dictator's men explores the topic of how a country suffering a devastating economical blockage can afford a Nuclear Program (not even keeping the standard of living of its population extremely low would seem enough...). You should watch the documentary, but long in short we can say that by exporting workers to other countries (Mongolia, China, Eastern Europe) where they'll work hard for a salary that will go directly to the pocket of the North Korean government! so yes, basically they are exporting slaves...

The second half of the documentary is also particularly interesting but in a totally different sense. This time (almost for the first time in a Western documentary) they give us a not so gloomy perspective of life in Pyongang. In the last years there's been a construction boom to try to better accommodate the population, and there seems to be a real scientific elite. Scientific development in North Korea would be a really interesting topic for another documentary. From what I read somewhere time ago, due to the sanctions, North Korea is supposed to design and build good part of the technological gadgets (TV Screens, smartphones, laptops...) used by the population. Also, they are supposed to have "an army of hackers ready to attack the West..." Regardless of how real this "cyber-army" is, I think the country has an important level of know-how in multiple matters.

I won't end this article without short mention to my thoughts about the North Korean nuclear program. For sure I don't like them to have nuclear weapons, as I don't like that any other country possesses them. This said, until the day that all the other Nuclear Powers decide to destroy all their weapons, I think they are in their perfect right to develop a Nuclear Program. Furthermore, I don't understand why the world is so worried about North Korea developing these weapons. Whatever I think of their dictator, I don't see North Korea as a crazy society willing to annihilate the rest of the planet. What really should worry, scare and drive us crazy is the fact that a Fundamentalist, medieval country like Pakistan joined the group of Nuclear Powers many years ago. At any point some "religious" leader could decide to wipe out the infidels from the face of the Earth...