Set [[Prototype]]

When years ago I first heard about the plans to add classes to ES6 I was terrified they could intend to mutate the language from its Prototype based nature to a standard Class based paradigm. Almost immediately I found comments explaining that the addition of classes would be just syntactic sugar, and these classes would be translated by the compiler into the prototype chains we are used to.

Now that ES6 as a standard is a reality, and hopefully most ES engines will be implementing it pretty soon, it feels like it's time to get ready for it. On one side you can read here how indeed classes are just syntactic sugar.

ES6 classes are a simple sugar over the prototype-based OO pattern.

But furthermore you can read here that a standard way has been added to set the [[Prototype]] (aka internal Prototype) of an Object, by means of the Object.setPrototypeOf(obj, proto) method. We will no longer need to use the non standard __proto__ property, neither for setting nor for getting (as since ES5 we've had Object.getPrototypeOf(obj)).

It's noteworthy though the warning in the MDN about how slow setPrototypeOf can be.

DLR vs InvokeDynamic

I found out the other day that PowerShell 3.0 makes use of the DLR. It came as a surprise, as after the abandonment by Microsoft of the Iron languages, I thought they were setting it aside, just keeping it in the framework but with no plans of using it for anything. Hopefully it's not like that, and I guess the reason for not hearing anything about changes or evolutions in the DLR in the last versions of the CLR is that it's complete enough and there's no pressing need for improvements.

This finding, along with this excellent article about invokedynamic in the Java Platform, made me think again of the differences between both approaches for speeding up dynamic languages in the JVM and the CLR. Last year I had already discussed in this previous article how Java 8 implements Lambdas by means of invokedynamic and generating at run time the classes needed to contain the state of the lambdas, on the other side either C#, Scala and Groovy (at least in the pre-Java 8 times) create these classes fully at compile time.

Let's forget about Java Lambdas and let's focus on the "dynamic performance boosting techniques". Both invokedynamic and the DLR make massive use of runtime code generation, but in rather different ways.

invokedynamic When the JVM interpreter first finds an invokedynamic bytecode instruction, it will call into a bootstrap method and will obtain a CallSite object wrapping a MethodHandle. So the invokedynamic instruction will be replaced by a call to that MethodHandle hosted in the CallSite. This call to the bootstrap happens only once for each invokedynamic instruction found. As the code evolves, the MethodHandle in the CallSite can be replaced by another MethodHandle. Regarding the bootstrapping process, I think this statement I found somewhere is pretty important for its understanding:

"the key thing about invokedynamic is that it's essentially a JVM-level macro that defers lambda translation strategy to LambdaMetaFactory which is a library class."

and from this other article:

Whenever a invokedynamic call site is created in bytecode, it references a so-called bootstrap method for deciding what method should be invoked. A bootstrap method is implemented in plain Java and serves as a lookup routine for locating the method that should be called for the invokedynamic instruction. This lookup is only performed a single time. It is however possible to manually rebind a dynamic call site at a later time.

So the key part now is understanding what a MethodHandle is. Well, it's basically an object containing a "method pointer". So, it's basically the same as a .net delegate? yes and no. In .net we have multiple delegate types, classes that inherit from System.MulticastDelegate. We create (well, since .net 2.0 we normally use the Action and Func ones provided by the Framework) delegate types for the different method signatures that we need. This way, the invokation of a delegate is type safe and fast, as the the type correctness is guaranteed at compile time. In Java we have a unique MethodHandle class, so this type safety is guaranteed differently. The JVM itself knows about MethodHandles, and they are invoked through what is known as a "polymorphic signature", so it allows to call MethodHandle.invokeExact with different parameters in the different call sites.

DLR. The procedure to improve .net as a host for dynamic languages did not entail the creation of any new bytecode instruction or changes to the Virtual Machine, but a rather smart use of existing features like Expression Trees, Delegates and LightWeight Code Generation. This series of posts about the DLR internals gives and excellent explanation. Summing it up, in those locations where a dynamic call is performed (for example through the use of a variable declared as dynamic in C#) the corresponding compiler will insert the creation of a CallSite object and will invoke the delegate referenced by its Target property. So, basically this sounds just very similar to the CallSite-MethodHandle combo in the Java Platform. The CallSite creation in .net is done at compile time and in Java at runtime, so looks like the Java approach has to be more dynamic. Well, not really, the CallSite creation in .net is the less important part, the juicy thing happens at runtime, when depending on what object we really have at that point each time, dynamic code generation is used to create a new delegate (doing heavy use of a cache system) to bind to the CallSite.Target. This is pretty sophisticated and is explained here. I assume the JVM uses a similar Cache and decision system for rebinding the MethodHandle in a CallSite, but I have not investigated about it.

I've read in some places that the JVM approach is better and hence it's better suited for dynamic languages. This is one of those sources. It basically says (I think) that in the JVM when finally native code is generated this can be inlined, but it's not like that for the CLR. Honestly, this is a too advanced topic for me, so I can not say how true and how an impact it really makes. Anyway, if not the best, I think the CLR + DLR have proved to be a rather good host for dynamic languages, and with this in mind (and with all their investment in TypeScript) I'd love to see Microsoft coming up with an implementation of ES5-ES6 for the CLR (like Oracle has done with Nashorn)

Solidarity with Heroes

When a state welcomes back heroes with charges of terrorism one can not feel more than contempt and despite for that state. The 2 Spanish Freedom Fighters that have been risking their lives for 6 months in Rojava confronting that gang of rapists, islamo-fascists and perverts called ISIS have been detained by the Spanish repressive apparatus. You can read about it here and already posted about how the Spanish government exercises its repressive role against far-left militants that had sided with the pro-russian side in Novorossiya. It seems they intend to use the same charges against these 2 Humanitarian Fighters, "joining a terrorist organization", and "putting at risk the interests of the 'Spanish nation'"...

Both accusations are demented and delusional and prove how rotten the Spanish government is. Considering the YPG/YPJ as a terrorist group is like saying that being vegetarian is a crime against humanity... The second accusation "risks for the interests of Spain" is particularly stupid, as it indicates that the Spanish government acknowledges the links between the Turkish state and ISIS. I assume that the Spanish government does not recognize ISIS as a state. So, which other states we have there?. Irak and Syria? Both of them are fighting against ISIS (OK, yes, Assad is against the Kurdish liberation process, but I guess that's not a concern for the Spanish government). We have one country left, Turkey. Oh, yes, we all know that Turkey and its IslamoNationalist government are big allies of the West... (sick world). For sure the Spanish government does not want to irritate Erdogan, that friendly murderer... So, what we can deduce from this is that they admit that fighting against ISIS can irritate Turkey, and hence there's a link between ISIS and the Erdogan beast... Thanks Rajoy, you are admitting what we already knew...

There are millions of proofs of how the Turkish government collaborates with ISIS, but this article explaining how the terrorists entered Kobane some weeks ago through the Turkish border is revolting. Maybe this was the best way Erdogan could find to take revenge against the ascent of the HDP, the left-wing pro-Kurdish party.

I really think Kurdish people in Europe should conduct actions against the interests of the Turkish government, something similar to what an Armenian organization did in the 70's and 80's.

AD Fast Querying

The other day at work I went through again a issue I had already experienced in previous occasions. Querying the Windows AD for some basic need can be terribly slow. I have no idea about why, but I've suffered this while querying different AD's (from different companies). So this time I've gone through an alternative route.

As far as I know the recommended way to query the AD from modern versios of .Net is using the classes in the System.DirectoryServices.AccountManagement namespace, like PrincipalContext and UserPrincipal, so if you want to get the AD groups a user is member of you would do something like this:

private static List<string> GetGroupNamesBasedOnPC(string userName, string domainName)
 {
  List<string> result;

  using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, domainName))
  {
   using (PrincipalSearchResult<.Principal> src = UserPrincipal.FindByIdentity(pc, userName).GetGroups(pc))
   {
    result = src.Select(sr => sr.SamAccountName).ToList();
   }
  }
  return result;
 }

The above code is terribly sloooooowwwwww.

Hopefully, there are alternatives (don't ask me why these alternatives are way faster, I have no clue).

• You can use the very fast net user command like this:
  net user userName /domain
  notice that it will search the current domain, so the "/domain" string is right that, you don't have to replace it by the domain name, I mean:
  net user francoise12 /domain
  The problem with that approach is that the returned string comes formatted for the Windows Console and some characters can be trimmed. So large group names will be trimmed and this command is not valid for general cases.
  
  
• Another option is using the gpresult command, as along with information about the installed gpo's it will also return the list a groups for the current user, and this time with no odd formatting causing trimming.
  gpresult /user ng3419a /r
  The problem with this is that it only works for the current user, you can't pass the user name as parameter
  
  
• And finally the good one:
  net group groupName /domain
  Here you'll get a listing with just the group names, one per row, so no trimming problems. The windows commandline is not that primitive as many people use to think (and yes, of course with PowerShell is really powerful), so if you just want to verify if a user belongs to a certain group you can pipe the output to the find command like this:
  net group groupName /domain | find /I /C userName
  If you want to run it from a .Net application you just do this (notice that net group is a command, not a program, so the process that you have to start is cmd.exe)

  string command = "/c net group /domain " + group + " | find /I /C \"" + user + "\"";
  Process process = new Process();
  process.StartInfo.FileName = "cmd.exe";
  process.StartInfo.Arguments = command;
  process.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
  //need these 2 lines in order to read from the stdout
  process.StartInfo.UseShellExecute = false;
  process.StartInfo.RedirectStandardOutput = true;
  process.Start();
  process.WaitForExit();// Waits here for the process to exit.
  string output = process.StandardOutput.ReadToEnd(); 
  bool belongsToGroup = output[0] == '1';