Monday, 16 October 2017

Dictionaries, Keys and Hash Codes

It's (or should be) common knowledge that objects used as keys in Dictionaries/Maps (Objects that are based in hash tables...) must be immutable [1], [2]. In few words, the Hash code of an object being used as key will be used to obtain the index in the internal structure in the hash table to locate the object. If you mutate an object, its hash code should also change, so it will no longer work for finding the right bucket in the Hash table. You can read a .net centric explanation here

In .Net when using an object as Dictionary key, the GetHashCode method will be used, and in case of collision it'll move to the the Equals method (and you should have overriden both methods in your class as the default Object.GetHashCode is considered not fit for dictionaries). Something similar is done in Java and Python.

ES6 introduced the Map class, and one of its advantages over using plain Objects as dictionaries is that we can use any object as keys (and not just strings). Object.prototype does not have a "getHashCode" method, so well, it seems a bit strange. Checking the MDN documentation on Maps it says that key equality works according to the semantics of the === operator. This means that if you use as key an objec (other than a string or a number), the key comparison will be based on the memory address of the object, so if you mutate the object, it will continue to be valid for accessing the dictionary. I mean:

let myMap = new Map();

let key1 = {name: "aaa"};

myMap.set(key1, "this is a value");

console.log("first item: " + myMap.get(key1));
//output: this is a value

key1.name = "bbbb";

//the modified object that we use as key is still valid!!! 
//"===" semantics/reference equality is being used

console.log("first item: " + myMap.get(key1)); 
//output: this is a value

This seems like a rather bizzarre behaviour for a Map/Dictionary. You can see here how people implement a "more standard" one.

Notice that MDN says according to the semantics of ===. Obviously one expects access to a Map item to be O(1), so for sure the runtime is not going to traverse the whole Map comparing the keys with "===". To simulate "===" sematics and have instant access, I guess one possibility is to get the hash code of the memory address of the object used as key.

Related to this, given that JavaScript objects behave similarly to a Dictionary of string keys (you can add or remove items and the lookup is supposed to be almost immediate), one could assume that they would be implemented as a Hash Table. Hash Tables are very fast, but they are slower that property access in a other class based languages (C#, Java, C++...) where the access to a specific property will always use a same offset from the beginning of the object (so you save the time of running the "getHashCode" function). Well, I can read here that for example V8 uses dynamically created hidden classes, making property access as fast as in C++.

I noticed this sentence: A Map may be perform better in scenarios involving frequent addition and removal of key pairs. in the MDN comparison. It rather fits with the V8 policiy. Each time you add a new property to an Object I guess V8 needs to create a new hidden class, and that comes at a (small) cost that most of the times is pretty much compensated by the very fast property access that the new class provides. However, if you add/remove very frequently, maybe the time saved in property access does not compensate the time spent in the hidden class creation.

Sunday, 15 October 2017

Hendrik Beikirch Back in Toulouse

L'année dernière j'ai déjà écrit sur le magnifique et monumental fresque murale fait par Hendrik Beikirch à Toulouse (quartier Empalot). Comme je l'ai expliqué dans ce post, le bâtiment ignoble sur lequel le fresque a été fait, va être démoli. C'est pour ça que, et compte tenu que les habitants du quartier aiment bien cet fresque, la ville de Toulouse l'a invité à faire une autre fresque le mois dernier. Je suis allé voir le résultat ce weekend, et encore une fois, c'est magnifique!

Essayer d'écrire en Français m'épuise encore, je vais passer à l'anglais...

So another 12 stories building block 200 meters far from the one of the previous year was chosen to be gifted by this amazing piece:

In this picture you can see both murals:

Hendrik Beikirch had already visited Toulouse before these works in Empalot. In 2015 he took part in that year's edition of the Mister Freeze Urban Contemporary Art and Graffiti exhibition. He painted this not so massive but equally beautiful mural in the Mountaudran are. It's still in good health nowadays.

By the way, the Mister Freeze Urban Art festival has kept improving year after year. In 2015 it was good, in 2016 it was very good, and this year is's been just amazing. I should find some time to dedicate a post to this last edition.

Friday, 6 October 2017

Low-Rise Cities

I've ever loved skyscrappers. My first times in The City and Canary Dwarf in London I was amazed, and in my first visit to La Defense in Paris I was on the verge of extasis. When I visited Frankfurt, it was mainly cause it's nicknamed "Mainzhattan" :-). Gothick cathedrals have always captivated me, and I tend to see Skyscrappers as a continuation of them.
As of today, I continue to enjoy the view of a skyscrapper dominating a cityskype, but I've turned more selective. It's not that they need to be architectonic masterpieces, but there are some aesthetical minimums that if not reached turn the skyscrapper (or any high-rise building) into a real pain. It's not just a matter of materials, in some occasions I find more interesting some restored high-rise residential buildings of the 70's that some recent glass and steel buildings. For example some of the skyscrappers in Tallinn are pretty "untasty".

The other big change in my perception of skyscrappers is their location. In the past I absolutely loved huge concentrations of skyscrappers, now I tend to prefer isolated ones (1, 2 or 3) scattered over different points of one city. They act as reference points for the urban landscape and I pretty apreciate the contrast with the low or mid-rise surrounding buildings. Related to this also, I don't see the need (or the good taste) of going much higher than 200 meters. I pretty much like Brussels for example, with several towers between 80 and 150 meters spreading all over the cityscape, and with a "non oppressive" small concentration of them in the Gare du Nord area. I also quite like how it goes in Berlin.

Regarding high-rise buildings (I consider like that buildings between 40 and 80 meters), it's a bit the same. I like them a lot, but not massive concentrations of them. Coming from a city (Xixon) where there are no skyscrappers, but half of the city is made up of buildings above 40 meters, disorderly glued ones to others... I can understand that some people are not particulary fond of them (and if you've ever been to Vigo or A Corunha it's even easier to understand).

When I arrived to Toulouse I pretty missed (and continue to miss, waiting eagerly for the planned Tour d'Occitanie and the intended Tour Fenetre de Pista) having at least 1 skyscrapper, and this lack felt odd to me, I was not familiar with cities of this size and healthy economy that didn't have a single skyscrapper (at this moment no building rises above 70 meters). On the other side, I felt quite pleasant its low-rise nature. You find quite a few buildings between 10 and 15 stories, but there are not massive areas full of them, so putting aside that most of them are from the 60's/70's, are ugly and desperately need a total facade refurbishing, they work a bit as the reference points that I mentioned earlier. The low-rise nature of the city center and certain neighbourhoods is really nice, but I absolutely can not understand that they have been constructing tons of buildings of 3 or 4 stories in the last decade (hopefully as of late there seems to be a tendency to construct a bit higher). Low density means a crazy level of urban sprawl that means that you'll never manage to have an efficient public transport system. Just to give you an idea, the future third Metro line that will go from one end to another of the Metropolitan area (the one of 750.000 inhabitants, not the urban area of 1.250.000) will be 25 kms long!!! I think it should be forbidden to construct new buildings of less than 5-6 stories, and 7-9 ones should be the norm. Indeed, overtime I've started to appreciate the mid/high rise mess of my hometown (also because many of them have undergone an amazing facade renovation).

In general terms French people dislike mid/high-rise buildings, and deeply hate skyscrappers. I think it's a sort of trauma caused by how bad things have gone in the social housing states (cités) of the 70's. For me for sure architecture has nothing to do with this disaster. There are some housing states (at least in Toulouse) that are mainly low-rise (Les Izards) and that have ended up turned into no-go areas. It's not a matter of architecture, it's a matter of Islam, fake victimization and pure senseless hate for the old colonial power. There's also a sort of Tour Montparnasse syndrome. Most Parisians hate it; to the point that time ago one candidate to the mayor's office intended to demolish it! (fuck, J'adore cette tour!!!, it makes an amazing contrast with the perfect and so Parisian neighbourhoods around it). Another reason why it's pretty uncommon to see skyscrappers in the French landscape outside Paris it's that there are some very strict security rules. Buildings above 60 meters need to have a permanent unit of fireworkers, so this makes maintenance crazily expensive, and even for cities that seem to be more friendly to high rise buildings (like Marseille and Lyon) it's difficoult to get more than one skyscrapper per decade.

Ma si belle Tour de Montparnasse

I love cities, and I got quite interested in whether there are other relatively big cities that at this day lack any skyscrapper. From my trips, I could think of a few candidates, but I didn't know if maybe there would be some office building or some huge residential block in the outskirts. So I've been investigating in wikipedia and Emporis, and I've come up with a listing (for sure there can be errors, maybe outdated data or some skyscrapper in the metropolitan area that did not show up in the listings I've checked). Notice that I'm not including here churches, historical buildings or TV/Airport towers.

  • Washington DC. This pretty shocked me. The strong height restrictions that have always been in place cause that no building rises above 60 meters.
  • Dresden. It seems no building goes beyond 60 meters
  • Edimbourgh. Tallest building is 64 meters and is just an ugly tower block in a housing state. No proposed skyscrappers as far as I know.
  • Glasgow. Quite a few 70-60 meters towers in housing states. There's some proposal for going higher, but nothing confirmed so far.
  • Dublin. Seems the Irish are "very French" regarding buildings height. Right now the highest building is below 70 meters, but there are approved plans for some buildings between 90 and 70 meters (that have caused quite controversy).
  • Belfast. A couple of buildings around 80 meters.
  • Stuttgart. This one rather surprised me. In one of the most wealthy European cities just a couple of buildings reach 75 meters (hey, like my hometown!!!)
  • Athens. They have a 100 meters building done in the 70's leveraging one moment when they managed to skip the very strict law that prevents buildings from going above 40 meters!!!
  • Bremen. It has a recent office tower reaching 80 meters
  • Strasbourg. Its top is below 80 meters, no plans for rising higher.
  • Malaga. Right now nothing goes beyond 60 meters. There's a controversial proposal for a 130 meters hotel
  • Zaragoza. They have a couple of buildings around 80 meters.
  • Budapest. This beautiful, decadent city has an unintersting tower reaching 85 meters, for the rest is rather low-rise and skyscrappers remain a very controversial topic.
  • Helsinki. A not particularly interesting residencial building tops the city (that as a whole is not particularly beautiful) at 86 meters.
  • Copenhagen. A hospital in the suburbs reachs 120 meters. Then it has several towers between 100 and 80 meters (some of them very beautiful) scattered over the whole city. I pretty like its urban landscape.
  • Geneve. Pretty surprising for such an international city, even more when Zurich and Basel have been moving high in the last years. They just have an old, uninteresting, 90 meters residential building in a "cite".
  • Thesaloniki. Seems like nothing goes beyond 50 meters!
  • Nice. Quite similar to Toulouse. Contrary to Lyon, Nantes or Bordeaux, the 70's, when French laws were not so strict, did not gift them with a remarkable office tower or an ugly residential tower in a "Cité", that would rise beyond 70 meters. There does not seem to be plans for breaking this dynamic

I've also found quite a few other cities that just got their only (or very few) skyscrapper in the last years

  • Seville. They've built a pretty nice glass and steel tower in the last years. Other than that, no building seems above 60 meters.
  • Rome. They seem to have woken up lately, maybe trying to catch up with Milan and Naples.
  • Turin. It's been in the last years when the have had the luck to see the completion of 2 pretty beautiful towers (200 and 160 meters). Notice that before that the city's roof was a 100 meters building of 1933!!!.
  • Goteborg. One recent tower reaches 100 meters. Then a few towers of 80-70.
  • Bilbao. Well, this is a quite particular case. In the city proper there is a single building well above 100 meters (the beautiful Iberdrola Tower, 166 meters). Then there's a new, not particularly cute, residential tower next to the bus station, and then the city is full of mid/high rise buildings absolutely everywhere, so indeed it's a very vertical city. Notice that in Baracaldo (just next to Bilbao) you find the 100 meters BEC tower and some rather noticeable and interesting residential towers.
  • Marseille. The magnificent 150 meters CGA-CGM tower was completed in 2010, and the slightly shorter Jean Nouvel tower should be completed next year. These 2 towers aside, Marseille is very vertical for being a French city. The breathtaking views from La bonne Mere show tons of mid/high-rise buildings, reminding me of Bilbao

Sunday, 1 October 2017

Islamists and Delinquency

There's an evident link between radical Islam and delinquency. A big part of the Islamists that go to rape and enslave women in Syria have a background as dealers, common thieves and so on. The same goes for those committing attacks in Europe, indeed, in many cases these ones have not left behind their past as petty criminal, and have been dealing and committing robberies until the day before their attacks. One root reason why these bastards fall easily into Islamism is that they are most of the time very poorly educated people (better to smoke joints in the park than going to high school...) and in most cases they are not particularly smart individuals... This bunch of ignorant bastards are easy prey for any of those Saudi paid and educated imams managing the radical mosque of the neighbourhood, for the Video game style yihadist propaganda on the net or for a previously radicalised prison mate.

It's not only that petty criminals are easier to indoctrinate, it's also that the more criminality exists in one neighbourhood, the more isolated from the rest of the city it will become. The closer and more communitarist the area becomes, the easier it will for the disaffected population to be lured into the Islamist trap. So for the Islamist indoctrinators, every time the police is prevented from entering a "quartier sensible", or the firemen are attacked while trying to do their work, or an ambulance is set on fire (like last month in "Le Mirail" in Toulouse), or a teacher is silenced, insulted and even physically attacked, it's a step in the right direction. That's the main reason why these "thinking heads" of the islamization of Europe, while advocating a "society" where people will get an arm chopped for having committed a robery, approve and support delinquency in the neighbourhoods that they are trying to dominate.

The other day, reading an impressive and terrifying investigation in Charlie Hebdo about the Islamization of the High Schools in the Northern neighbourhoods of Marseille (it's even worse that I would expect), I came across with another motivation for Islamists to tolerate and get involved in delinquency. One High School director explains how in 2004 (yes, the islamization process to destroy our societies has been working from well before many people think) a group of dealers used to insult some young teachers, calling them bitches and infidels for wearing a skirt... After the intervention of the police there was some "negotiation" between the school and these pieces of crap to calm down the situation. The director was quite intrigued by how it was possible that these "very strict" Muslims would be involved in a vicious activity (drugs are forbidden in Islam, they are "haram") like dealing drugs, and discussing with them he learnt:

"They've sweared to me that they only sold drugs to "whites", the French youngsters, and that this was their way to practice jihad. To fuck their brain, their defenses, to break their shit society. That day, I understood that these guys, even if they were lying, were at war with you, with us, with me".

So they conduct jihad by poisonig "the infidels" with drugs. Quite in line with the last directives by Daech and other Islamist beasts, asking for poisoning water supplies, supermarket foods... they also ask for burning forests!!!

Just before publishing this post I learn with sadness about this new Islamist attack, this time in Marseille, in one of world's most beautiful train stations, a place that I particularly love. Hopefully the terrorist has been shot dead by the Security Forces.

More than ever, Let's hunt down (dead or dead) the Islamists

Friday, 29 September 2017

Expirable Promises

I'd read some samples of using Promise.race to implement timeouts for Promises (reject the promise if it has not finished after x time). You can see an example here. Looks good, but it's not what had come to my mind when thinking about this issue and not having had the race function into account.

Given that I can not reject and existing promise, I would have to create a new one, that would be rejected if the timeout expires, or resolved if the original promise finishes before the timeout. I call this new promise an "expirable promise". Let's see the code

function createExpirablePromise(pr, expirationTime){
		let nP = new Promise((resolve, reject) => {
			let timeout = setTimeout(() => {
				reject("timed out");
			}, expirationTime);
			pr.then((result) => {
				clearTimeout(timeout);
				resolve(result);
			});
		});
		return nP;
}

If we are given a function that returns a promise we can create a function that returns an expirable promise like this:

//fn is a function that returns a promise
//we return a function that retuns an "expirable promise"
function createExpirableFunction(fn, expirationTime){
	let expirableFn = (val) => {
		let pr = fn(val);
		return createExpirablePromise(pr, expirationTime);
	}
	return expirableFn;
}

With the joyful addition of async/await to the javascript arsenal, we can write a cute sample like this:

//example of a long running async operation
//function that returns a Promise
function formatter1Promisified(st){
	return new Promise((res, rej) => {
		console.log("formatter1 running");
		st = st.toUpperCase();
		setTimeout(() => {
			res(st);
		}, 3000);
	});
}


async function testUsingAsync(){
	let expirationTimes = [1000, 4000];
	for (let i=0; i < expirationTimes.length; i++){
		let timeout = expirationTimes[i];
		try{
			let res = await (createExpirableFunction(formatter1Promisified, timeout))("Hi"); //timeout expires("Hi"); 
			console.log(`succeeded with timeout: ${timeout}, result ${res}`);
			break;
		}
		catch (ex){
			console.log(`failed with timeout: ${timeout}`);
		}
	}
}



testUsingAsync();

Tuesday, 19 September 2017

Promises and Tasks

.Net Tasks and JavaScript Promises are rather similar, as both are used for the same. They hold a value that will be available at some point, moment at which they will invoke some code that we've provided to them as a continuation. There are differences though. In the multithreaded world of .Net the creation of a promise can involve the execution of another thread (when we do Task.Run for example), this is not the case with Promises, as at the Javascript level everything is single-threaded. Another difference is the parameter passed by to the (callback) function that will be executed as a continuation. While Promise.prototype.then will pass just the result of the precedent Promise, Task.ContinueWith will pass the Task itself. This stems from the fact that while we can access the result of a Task via the (blocking) Task.Result property, the only way to access the result of a Promise is by the Promise itself passing that result to us.

I've found another not so obvious difference that I'll share here. In .Net there was only a 2 years gap between the introduction of Tasks (.Net 4.0 in 2010) and the arrival of the magic async/await pair (C# 5 in 2012). In JavaScript the gap between Promises and the introduction of ES7 async/await in some environments (let's put aside libraries that simulated it via iterators) has been much bigger. This means that in .Net the exposure of programmers to ContinueWith has been rather low when compared to how much Javascript developers have dealt with then. To work with "then" we need to clearly interiorize this: Given a Promise P1, when we invoke then on it and obtain a P2 promise, if the callback/handler function that we have passed to then returns another promise (P3), then P2 will not be resolved until when P3 is resolved. This allows us to chain calls to "then" rather than nesting them. I mean (from Exploring ES6):


asyncFunc1()
.then(function (value1) {
    asyncFunc2()
    .then(function (value2) {
        ···
    });
})


The flat version looks like this:


asyncFunc1()
.then(function (value1) {
    return asyncFunc2();
})
.then(function (value2) {
    ···
})


The above is well explained in MDN:

A Promise in the pending status. The handler function (onFulfilled or onRejected) gets then called asynchronously (as soon as the stack is empty). After the invocation of the handler function, if the handler function:
...
• returns another pending promise object, the resolution/rejection of the promise returned by then will be subsequent to the resolution/rejection of the promise returned by the handler. Also, the value of the promise returned by then will be the same as the value of the promise returned by the handler.

In .NET the behaviour of ContinueWith when the delegate passed to it returns in turn a Task is not so straightforward. This internal Task can be either an Attached Child Task or a Detached Nested Task. By default it'll be a Detached Nested Task, meaning that the outer task does not need of this internal task to be finished to be finished on its own. So this behaviour is different from JavaScript. If we want that the completion of the outer task depends on the completion of the inner task, we have to create this inner task with the TaskCreationOptions.AttachedToParent flag. It is explained here and here.

... the Task being created registers with that parent Task as a child, leading to two additional behaviors: the parent Task won’t transition to a completed state until all of its children have completed as well, and any exceptions from faulted children will propagate up to the parent Task (unless the parent Task observes those exceptions before it completes).

I've tested it myself, but the code using Tasks is rather ugly and odd and won't upload it here. Hopefully using async/await abstracts us of all of this.

The Last Face

To make things clear from the beginning, forget all the crap reviews that you could have read, The last face is an excellent movie. Tough, touching, almost captivating, and the performances of Bardem and Charlize Theron are impressive.

When I found that there was a film directed by Sean Penn and starred by Bardem and Charlize Theron I assumed that it had many chances to be a good film. The plot: 2 doctors working on humanitarian missions in war ravaged Africa end up falling in love, but the relation proves to be too difficoult given their circumstance. Well, the "love story" thing is not my cup of tea, but the attrocities in the different African conflicts are of quite more interest to me, so all in all it still could be a good watch. Then I read the critics and felt shocked. Seems like all the "educated and intelectual critics" (and the so cool attendants to its premier in Cannes) were treating it like shit, mocking it and calling it "the laughing stock of Cannes" and "refugees porno"... I felt quite puzzled, so I decided to see by myself.

The film is amazing. Its 3 components: brutality of senseless conflicts in Africa, the risks taken by Humanitarian workers in their uncompromising devotion to saving unknown lives, and the difficoult (to say the least) love story between two of them, play together masterfully. There are many gripping moments like for example when a kid is being forced to shoot his father (that will literaly blow your head away), or the amazing speech of Charlize Theron in a fund raising event. Also when Charlize advocates for focusing efforts on trying to stop the conflicts and allowing development, questioning what sense it makes to try to save these human beings now, just to keep them living in biggest misery, and Bardem tells her that even in all this misery, they manage to find dignity and joy, loving their children and living on. This film is emotional and inspiring, and I really can't understand the bad reviews. Well, maybe I can.

It seems like much criticism comes from relating this film to the White Savior complex. So it seems portraying whites trying to save black lives is a sort of "neocolonial product". It's as if all these humanitarian heros were just trying to purge the "evil white man" culpability, and furthermore they have no right to fall in love (precisely people that show so much love for others sacrificing their comfortable lives as doctors in wealthy western countries to go deep in hell... ) Fuck off, all this criticism denotes all the stupid colonial shame so predominant in western (sort of) leftists. This film is not about colonialism (the past), it's about people dying now and people that will continue to die tomorrow... And by the way, sure many bad things were done in the past, but thinking that all the current misery is just a consequence of "evil white colonial powers" is an oversimplification and for sure will not help at all.

Maybe some "critics" will also dislike the introduction of the AIDS drama in the film by means of a white woman and not an African. I don't think the intent is to denounce how devastating AIDS is Africa, but to remember us that it's even one more threat stalking these doctors that do not doubt in getting soaked in the blood of a stranger to try to save his life.

Monday, 18 September 2017

Cool Neighbourhoods

When in Copenhagen last month I went for a stroll to Norrebro, a neighbourhood about which you'll hear quite different opinions. From Alternative, arty, multicultural paradise to non-integrated immigrants ghetto passing by Far-left stronghold. I was there just a few hours, but I guess there's a bit of true in each of those opinions. I mainly got the Alternative/Arty/leftwing cool side of the coin, but a shop with a "burkinis" advertisement also gave me a glimpse of the communitarist-islamist crap side. Anyway, the overall impression was nice, and the place reminded me a bit of Berlin's Kreuzberg (my lovely Kreuzberg)

I searched the net to see if this Norrebro-Kreuzberg link was a common impression and I ended up reaching this site ranking the best "Hipster" neighbourhoods in Europe. Notice that the terms Alternative and Hipster, while lacking of a clear and universal meaning, mean pretty different things to me. I guess I'm interested in "Alternative" (but not "too alternative", as I grow older I tend to enjoy a bit of gentrification and "boboization" and a decrease in the number of squats) and not that much in "Hipster", but the thing is that alternative areas tend to become targets for a Hipster invasion, so probably these Hipster neighbourhood should be quite interesting to me.

I've been to some of the places listed there. Some are amazing, but others did not leave any particularly remarkable impression in me when I was there, so I wondered about the criteria they used to rank a neighbourhood as "Hipster". At the same time, I wondered also about the criteria that (in good part unconciously) I use to put an area in my "list of cute alternative hoods". I'll give you a list of the criteria that I think I follow:

  • A tolerant, international, multicolor, multilanguage population
  • Stree Art everywhere
  • Community managed micro-gardens, pots lining the streets and climbing the buildings (Marseille!!!)
  • Aboundance of old buildings (early XX century is still OK) some beautifully restored, some still waiting for better times, but few abandoned ones. Being dotted with some ugly 60's/70's mid-rise buildings can be a plus (like in Kreusberg).
  • Independent Book stores, art shops
  • Creative spirit, social links among residents
  • Nice cafes with outdoor sitting
  • Affordable prices and availability of small studios so that a single person can pay the rent and live alone (like in France) rather than sharing the flat with strangers (like in UK)

There's an element that I have not put in the list cause it's so important that if not present the neighbourhood can not even be taken into consideration. The neighbourhood must be in a city (and hopefully a country) where islamism, racism, xenophobia, homophobia and nationalism are illnesses that have hardly affected the population (well, indeed, having some isolated cases of these scumheads can be nice to hunt them on the streets and inspire some reivindicative art and social awareness). An open society that won't pay attention to how much melanine you have, how you dress, who you fuck with, where you or your ancestors were born... This said, it would be very difficoult to me to consider cities in the USA or most of Eastern Europe as sound candidates to be high in an "alternative places" list. This also applies to the capacity of a city to attract creative minds. Sometime ago I felt shocked when I read somewhere that Warsaw was going to be the next Berlin in terms of creative industry and appeal for digital entrepenours. Come on, Warsaw has a nice skyline and a beautifully rebuilt downtown, but Polish society is in general very conservative and religious (old style Christianism, not the universalist and "altermundialist" kind of Christianism that we see with certain frequency in Western Europe), nationalistic and not particularly keen of people that are "different"... A place like that can not be a hotspot for creative minds.

Without meeting that premise, a place can for sure be still interesting to pay a visit, but won't be a "lovely place where I'd love to live for a while".

I can see here the criteria that they used for their rank. Basically it makes their cities list rather useless to me.
They don't mention at all anything regarding the tolerance and openness of the society... and use stuff that I could not care less, like Vintage fashion, vinyl shops, co-working spaces... Having being a vegetarian for half of my life I'm pretty happy to see that veganism has become more and more common, but seeing it associated to "trendiness and coolnes" rather kicks my balls... Also, I use my bike rather often to move around Toulouse, but I don't see the presence of "independent bike shops" as particularly important.

Saturday, 9 September 2017

Collioure

Collioure is quite of a hidden gem, or at least, given that I found it by chance and had not heard about it before, that's how it seems to me. During the summer there's a special train "Le train des plages" that for a reduced price (still not cheap, but trains in France are pretty expensive) takes you from Toulouse to different Mediterranean resorts spanning between Narbonne and the Spanish border. Over these years I've been several times in Leucate, that is 2 hours far from Toulouse, so it's pretty good for a day trip to the beach. There are 3 different beach villages in the area (La Franqui, Leucate Plage and Port Leucate), and a cute small village, Leucate Village, nice for taking a coffee in the "Place de la Republique", between a morning bath in La Franqui and several afternoon baths in Leucate Plage. These beachs are OK, but lack of any particular charm (they're mainly a simple touristic resort built from the 70's), but if you like swimming in calm and warm water, they are a nice option for a summer day in Occitanie.

Last year I visited one day in Port la Nouvelle, OK for some swimming, but the lack of any charm here is almost painful... So this year I decided to give it a try to some of the more distant locations (3 hours), I settled on Collioure mainly cause the village and the beach are just adjacent to the train station (no need to take a shuttle bus like in other destinations) and because one of the beachs had (at least partially) sand, rather than painful pebbles. I leveraged this first trip to stop for a couple of hours in Perpignan where I pretty enjoyed a fast stroll around the city center that was good to show me that the city well deserves a full day visit (I guess this autumn).

Once in Collioure I was immediately amazed. The narrow pedestrian streets of the city center with those 2 or 3 stories buildings in bright colors, with those nice art shops and the beautiful plants growing next to most buildings and climbing up their walls (I absolutely love this) really captivated me.

Then I got to the sea side to be confronted with the views of the Notre Dame des Anges church on one side and the imposing Chateau Royal on the other. As I hate pebbles (I guess I have delicate soles) I headed to the second beach (Port d'Avall), on the other side of the chateau (where part of the surface is sand). Wow, it's just beautiful. Swimming in the calm, warm water with the castle on your left and the nice buildings and nearby small mountains behind you is one of those memories that will be coming up to my mind every now and then.

It seems people have been mesmerized by this small village for quite a while, which made it one of the essential locations in the development of Fauvism. Matisse and Derain lived in the village for a while, producing here some of their main works.

Collioure also hosts the grave of the Spanish left-wing poet Antonio Machado, who died in exile in this village, few days after having crossed the border fleeing from the fascist beasts that were destroying his country and would keep it in the darkness for the ensuing 40 years.

On a related note, something pretty interesting in the portion of French coast going from Leucate to Marseille is the proliferation of lagoons between the coast line proper and the main land, it's what is called "etangs". The first time I noticed this was when going by train to Montpellier. When approaching Sete I could see water to both sides of the rail track! Sete sits just between the sea and the lagoon, being traversed by canals and bridges, and though it's not a "French Venice" or something of the sorts... is well worth a visit. When you take "le train des plages", the portion between Narbonne and Port la Nouvelle is pretty amazing, the train goes along a narrow land strip traversing the lagoon, which is surrounded by small mountains with some ugly factory on their feet and eolic parks on their tops.

Wednesday, 23 August 2017

Oresund Bridge

Maybe you know that there is a bridge that joins Denmark to Sweden, bridging the 16 kms gap between Copenhagen and Malmo. Maybe you've seen some pic like this:

A beautiful piece of engineering, for sure. But if you see a picture like this you'll probably be shocked!

What the fuck? A bridge to nowhere? This is a joke or what?

Well, I didn't go through that astonishment cause I had watched this documentary before. There they explain that the Oresund link is indeed a tunnel and a bridge.
The Copenhagen side of the link is just next to the Airport, and having started a high rise bridge there would have caused trouble with air traffic. A 16 kms tunnel would have been too expensive, so the solution was to mix both. A 4 kms tunnel starts in Copenhagen and goes up into an artificial island where the road/tracks run for 4 kms until reaching the 8 kms bridge that ends in the Swedish coast.

Crossing it by train as I recently did is pretty fast. When travelling from Denmark to Sweeden, when you emerge into the surface you'll see the so famous Turning Torso on your left, dominating the whole region of Scania.

By the way, I should write a post about this trip, but as maybe I won't find the time, I'll mention it here. Copenhagen is a really beautiful city. There's not any astonishing spot, but the city as a whole is really cute. I pretty loved the predominance of harmonious architecture, the main canal and its modern buildings, the imposing Christianborg, the lively, relaxed atmosphere...

Regarding Malmo, probably you've heard about it because of the Turning Torso skyscrapper. Well, honestly there is not much more to it. There are a few nice old buildings, but the old town is really, really small, and for the rest, there a few more nice modern buildings like Malmo live, the water front is OK, there is a small canal... but in general the city reminded me of Xixon, A Corunha or some of the cheap, modern and not particularly tasty areas of Toulouse... so, it's not bad, but for sure it's not too interesting.

Monday, 21 August 2017

Some C# dynamic coolness

In the last days I've found some interesting things regarding the use of C# dynamic. I'll put it here.

Implementing Multiple Dispatch. The common use of dynamic is calling a method in a dynamic object. We are getting runtime single dispatch based on the object on which the method is invoked. Either the object itself if it implements IDynamicMetaObjectProvider, or the runtime via reflection, will find the method to invoke. I was not aware that this also applies when the dynamic object is used as parameter. The runtime will check its type and if several methods with the same name exist but with different argument types, it will invoke the correct one based on the runtime type. You can find a cute example here. This is pretty interesting because the runtime will use Reflection to match types with methods, doing on your behalf something that in the almighty JavaScript you would have to do on your own. By the way, this brings to my mind this explanation by Eric Lippert of the differences between using Reflection "manually" and Dynamic

Dynamic and Anonymous Types. At the time of its inception (C# 3) Anonymous Types were pretty limited. The compiler will create a class for your Anonymous Type, but you have no access to its name (so you can not do a cast), meaning that you can only access "freely" to its fields inside the method where they are created (you'll declare it as var and the compiler will use the correct type inside that method). If you return an instance of an Anonymous Object from your method, you'll be returning just an Object (you can not cast them to an inteface nor anything), so in order to access its fields you'll have to use Reflection manually.
Well, we know that dynamic will take care of using Reflection of its own (and pretty effectively thanks to caching), so we can do this:

//It's just the same if we set the return type to "dynamic" or "object" in both cases the compiler will generate a method return "Object"
//static dynamic CreateObject(int flag)
static object CreateObject(int flag)
{
  return new {Name="Francois"};
}
    
static void Main(string[] args)
{
 dynamic ob = CreateObject(0);
 Console.WriteLine(ob.Name);
}

You should notice an important limitation. Fields in Anonymous Types are internal, and when dynamic uses Reflection it plays by the rules, so it won't work if the Anonymous Type was defined in another Assembly.

Json.Net, JValue and implicit conversions. Json.NET has had an excellent dynamic support since quite a few years. This makes accessing the tree of properties in a JObject a real bargain:

var jsonString = @"{
 ""city"" : {
  ""name"": ""Toulouse"",
  ""population"" : 466000
 },
 ""otherData"" : ""aaaa"" 
}";
dynamic obj = JObject.Parse(jsonString); //returns a JObject
string cityName = obj.city.name;
Console.WriteLine("City Name: " + cityName);   

JToken (from which the different JContaine, JObject, JValue objects inherit) supports the dynamic machinery by implementing IDynamicMetaObjectProvider and returning a DynamicProxyMetaObject<JToken> (that extends DynamicMetaObject). The use of dynamic for dynamically accessing properties (or methods) of an object is what we are used to, but when you get to the last element, the "name" in my sample, you have a JValue object, so how does the assignment of a JValue to a string work?
This has quite confused me. It seems like there should be some sort of implicit conversion. Well, the thing is that DynamicMetaObject provides a BindConvert method. I've been having a fast look into the Json.NET source code and honestly, I get a bit lost with all those proxies, metaObjects and binders, but I assume somehow the BindConvert somewhere is who is doing "the magic".

Friday, 18 August 2017

Covariance and Contravariance in Delegates

Delegates covariance and contravariance is a rather confusing topic and I'm not going to put any theory here, you can check any MSDN or stackoverflow response for that, I'll just put here a fast, personal reference. For an excellent approach to Variance in Programming languages, you should read this.
Short ago I talked about Converting from one delegate type to another different delegate type with the same signature. Covariance and contravariance in Delegates is a different topic, but we'll see that in one case it saves us having to do that conversion.

Since C# 2.0 covariance and contravariance applies to the rules that dictate that you can create a delegate of a certain type that points to a method of a certain return type and signature. We no longer need a perfect match between return types and the signature. You can read about it in Variance in Delegates.

What C# 4 brought to the table was covariance and contravariance between related generic delegates. Basically, now you have a relation between Func<Animal> and Func<Cat> and between Action<Cat> and Action<Animal>. It's explained in Variance in Generic and Non-Generic Delegates

I'll put some examples here for easy reference

Delegate Covariance (for return types)

If we have these custom delegate types and method:

  public delegate Animal CreateAnimalDelegate();
  public delegate Cat CreateCatDelegate();
    
  public static Cat CreateCat(){
   return new Cat();
  }

Since C# 2.0 (one MSDN article mentions 3.0, it's wrong) we can do this, bind a delegate type (returning an Animal) to a method returning a more derived type (Cat):

CreateAnimalDelegate animalCreator = CreateCat;

If we are using generic delegates we can do the same (this is not related to the out keyword introduced in C# 4), here this continues to be delegate binding.

Func<Animal> animalCreatorFunc = CreateCat;

C# 4 brought something new, you can point a variable of a certain delegate type to an instance of a delegate of a different but related type. From MSDN

In .NET Framework 4 or later you can enable implicit conversion between delegates, so that generic delegates that have different types specified by generic type parameters can be assigned to each other, if the types are inherited from each other as required by variance.

//so thanks to C# 4 I can do this assignment of a different delegate type, there is no conversion it's just type compability
Func<Cat> catCreatorFunc = CreateCat;
Func<Animal> animalCreatorFunc = catCreatorFunc;


//so in C# 4 there is type compability, but not really inheritance ("is" works, but "IsSubclassOf" does not)
Console.WriteLine("catCreatorFunc " + ((catCreatorFunc is Func<Animal>)? "IS" : "IS NOT" ) + " Func<Animal>"); //IS 
Console.WriteLine("Func<Cat> " + ((typeof(Func<Cat>).IsSubclassOf(typeof(Func<Animal>)))? "IS" : "IS NOT" ) + " Func<Animal>"); //IS NOT!!!

As you see in the example I can point a Func<Animal> to a Func<Cat>, it's as if they were in an inheritance hierarchy, but it's not really the case, cause while the is operator will tell us that Func<Cat> is a Func<Animal>, the IsSubclassOf will tell us that no inheritance exists.

All in all Covariance for return types seems pretty natural, same as we can do Animal an = new Cat(); , we can do Func<Animal> fAn = new Func<Cat>...;

Delegate Contravariance (for arguments)

Delegate Contravariance seems a bit less natural, cause basically we can do: Action<Cat> aCat = new Action<Animal>.... So it seems we are reversing the way we use type compability (a Cat is an Animal for sure, but here we seem to say that an Animal is a Cat). If we think that this applies to parameters it makes total sense. We invoke aCat passing a Cat to it. aCat points now to a function that expects an Animal, so if it receives a Cat it will behave nicely.

I'm putting here the equivalent contravariant samples for the ones above

public delegate void ManageAnimalDelegate(Animal an);
public delegate void ManageCatDelegate(Cat cat);
    
public static void ManageAnimal(Animal an){
 
}

Bind a delegate type (expecting a Cat) to a method expecting a less derived type (Animal):

ManageCatDelegate catManager = ManageAnimal;

If we are using generic delegates we can do the same (this is not related to the out keyword introduced in C# 4), here this continues to be delegate binding.

Action<Cat> catManagerAction = ManageAnimal; //this one looks a bit odd cause we are sort of doing Cat = Animal;

And what was added in C# 4

Action<Animal> animalManagerAction = ManageAnimal;
Action<Cat> catManagerAction = animalManagerAction;

Console.WriteLine("animalManagerAction " + ((animalManagerAction is Action<Cat>) ? "IS" : "IS NOT" ) + " Action<Cat>"); //IS
Console.WriteLine("Action<Animal> " + ((typeof(Action<Animal>).IsSubclassOf(typeof(Action<Cat>)))? "IS" : "IS NOT" ) + " Action<Cat>"); //IS NOT!!!

To finish this article, I'll mention that while return type covariance applies to delegates, unfortunately (in C#) it does not apply to overriden methods in a derived class (Java has support for this since a long while). For contravariant arguments, again it applies only to delegates. The feature is not available for methods in hardly any language.
To my surprise, I learn that Eiffel supports Covariance in method arguments

Thursday, 17 August 2017

After the Wedding

When I first watched After the Wedding some years ago, I quite liked it, but it was last week, when watching it for second time, when I really realised how excellent this film is. Susanne Bier is such a great director and (notice that I have not watched all her films, I particularly miss Open Hearts) this is so far my favorite.

The story (co-written by Susanne) is rather imaginative and becomes more and more powerful as it develops. It's always amazed me that citizens of happy and well-functioning societies like Denmark or Sweden have such a capacity to create dark and compelling dramas (the Scandinavian Noir of Camilla Lacberg and Asa Larsson particularly delight me due to those characters living sad, complex, tormeted existences). In After the Wedding we have these 2 characters meeting again "as if by chance" after 20 years of neglect. First there's some anger, then those old feelings that will never disappear and the maturity that time gives us as such a beautiful present, will heal the pain and make things move on. This short conversation (it's not a literal transcription) describes with such sharpness how easy it is to spoil our lives:

  • - Why didn't you come back?
  • - Cause I thought you would end up following me
  • - Why didn't you follow me?
  • - Cause I thought you would come back

The most impressive moment in the film is when the husband, this strong and succesful man that had kept his terminal illness hidden from his love ones and seemed to be putting up with it so well finally crumbles. At the moment when the physical damage starts to show and the end of the "game" (our only game) becomes a too close certitude, the strong man collapses in tears, embraced to his loving wife and crying "I don't want to die". A powerful reminder of how temporal all we have, all we are, is. A reminder of how precious every second is, of how costly any unsaid word or unexpressed feeling is.

The leading actor, Mads Mikkelsen is sort of a must in most of popular Danish films. His facial expression is pretty astonishing, sometimes it's difficult to know if he's laughing, crying or both. I've recently watched another rather good film of him, The Hunt.

Monday, 31 July 2017

Delegate Types Conversions

The (non) equivalence between different delegates with the same signature can be a source of confusion. I'm not going to talk in this post about another related source of confusion with delegates, Covariance and Contravariance (pointing delegates to methods with "similar" signatures), probably I'll dedicate another short post to that topic.

Since the advent of the Func and Action generic kind of delegates, it's quite unusual (and advised against) to create your own delegate types, but you will still find them, mainly coming from old code. So let's say that you want to assign an instance of a custom delegate type to one of the generic ones, like this:

delegate string FormatterDelegate(string st);
...
class Formatter
 {
  private string formatItem;
  
  public Formatter(string formatItem)
  {
   this.formatItem = formatItem;
  }
  public string Wrap(string st)
  {
   return this.formatItem + st + this.formatItem;
  }
}

var formatter = new Formatter("--");

FormatterDelegate formatterDeleg = formatter.Wrap;

//this line won't compile
Func<string, string> formatterDeleg2 = formatterDeleg;

The last line will not compile. Though their signatures are the same (receive a string an return a string), Func<string, string> and FormatterDelegate are completely different types and you can not assign one to another. So the obvious solution is to create a Func<string, string> delegate that calls to FormatterDelegate. I used to do this:

Option 1:

Func<string, string> formatterDeleg2 = (st) => formatterDeleg(st);

Somehow the other day I came across some discussions ([1] and [2]) on this topic and there are other similar ways to address this issue.

Option 2

Func<string, string> formatterDeleg2 = new Func<string, string>(formatterDeleg);

Option 3

Func<string, string> formatterDeleg2 = formatterDeleg.Invoke;

Option 3 made quite sense to me, but I have to admit that option 2 pretty surprised me. I didn't know that the compiler allowed to pass a delegate to a delegate constructor. In the end the compiler generates the same IL code for option 2 and option 3.

Both cases are similar in performance terms to Option 1. In all of them the call to the code in the original delegate goes through an additional level of indirection. This is clear for Option 1, where you are invoking an anonymous method that in turn calls to the original delegate. In Options 2 and 3 the MethodInfo of the Func delegate will point to the Invoke method of the original delegate, so you also have a "double hop". Option 1 creates a closure to hold the reference to the first delegate, so in the end will have some extra (but minimum) cost.

Option 4

. In the discussion they came up with a different technique that avoids the extra level of indirection:

formatterDeleg2 = (Func<string, string>) Delegate.CreateDelegate(typeof(Func<string, string>), formatterDeleg.Target, formatterDeleg.Method);

With Option 4 you directly assign the method referenced from the original delegate to the new delegate, so the indirection is avoided. Notice that they mention that this will cause problems with multicast delegates.

I was going to put up some test code as a gist in github, but it is down.

Friday, 28 July 2017

Enmerable/Iterable Comparison

I've been revisiting the way C#, JavaScript and Java approach Iteration (Enumeration in C# jargon), so I'll dump here a short summary.

The basis is the same for the 3 languages. In C#/Java you have a class that implements the IEnumerable/Iterable protocol providing you access to an IEnumerator/Iterator object that takes care of the iteration. In JavaScript your object implements the Iterable protocol by featuring a [Symbol.iterator] property that returns an object conforming to the Iterator protocol.

The main difference stems from the methods provided by the Iterator (Enumerator) object. Most times you should not be concerned about these differences, as you will be just using the specific loop structure provided by each language:
foreach (it in enumerable)
for(o : iterable)
for (variable of iterable)
But if you are using your iterable differently you should take some more things into account.

C#. You advance your position in the Enumerator by calling the MoveNext method, that returns false if it has passed the end of the collection. To access the current element you use the Current property, that will return "an undefined value" (which is quite an open and confusing idea) if you are either before the first element (you've never called MoveNext) or after the last element (the last MoveNext returned false)

JavaScript. Your iterator just provides you with a next method, that returns a [done, value] pair and moves to the following position.

Java. The iterator provides a hasNext method, that returns false if you are positioned at the last element, and a next method that moves to the next position and returns its value. If you were already at the last element, next will throw a NoSuchElementException.

These iterators present similarities and differences. C# and JavaScript are pretty similar. As we've seen both of them have a method (MoveNext/next) that advances the iterator if possible and returns a boolean indicating if it has reached the end. If the end has not been reached, in C# we access the current element via the Current property while in JavaScript that value has also been returned in the next method. I like the idea of being able to access the current element through a property.

Java is quite a bit different. I find the haveNext method rather strange. It tells you if there is a next element, but does not gather it (in C# MoveNext does not return the next element as such, but is supposed to assign it to the field backing the Current property). So after the hasNext you will have to call next to really obtain the element. On one side, this means that if there are several threads accessing the iterator you have to put hasNext and next inside a critical section, on the other side, depending on your iterator, checking for the existance of a next item and obtaining it could be costly operations, so there is a sort of redundancy. The iterator could internally obtain and cache the value when checking for existence of the value, but maybe the caching is not the intended behaviour. So all in all I find the Java design a bit odd.

InHuman Rights

This week I've been reminded of how stupid some "Human Rights" organizations can be. After the Iraki Army finally managed to liberate Mosul from the Daesh monstrosity, Human Rights Watch denounced that the Iraki forces had mistreated and executed Daesh "militants" (I hate when the media calls these beasts "militants" it's a word that seems to normalize them, they are not "militants", they are fascists beasts). OK, so the Iraki forces have executed some "individuals" that were part of an "organization" that rapes and sells women as slaves, that throws homosexuals from the roofs, that chops people's heads or burn them alive because of being infidels... So what? Should we just put them in prison waiting for them to be rehabilitated? Bullshit, we must punish them in accordance to their crimes, so of course they must be executed, and before that we should make them suffer at least a bit of the pain that they have caused to others. Yes, I'm saying what you think to have understood, I think that Daesh members that have been captured alive should be physically punished (yeah, I'm trying avoid the word "torture" to not sound so "aggressive"), before being executed, "eye for an eye...". This reminds me of the nice treatment given by Nasser to Sayyid Qutb one prominent IslamooFascist that has been a source of inspiration for Islamists worlwide.

The difference between people that like me defend the execution (and previous physical punishment) of these monsters, and Human Rights organizations that decide to defend these beasts, is our conception of Humanity. I consider myself an Humanist, and I think of "Human" as a moral attribute, an attribute that can be lost due to our inhuman actions. Human Rights organizations think of "Human" just as a biological attribute that as such can not be lost (a Human can not be converted into a dog, so he will ever be a Human regardless of his actions and hence will always be granted with Human rights, whatever he has done).

For me, when a Human being commits brutal acts against other living beings (humans or animals), these inhuman actions deprive him of his Humanity, and the moral rules that we use when dealing with other humans (and should be applied also to animals) should no longer apply. At that point that individual must be punished with as much vehemence as those affected by his crimes (or the society in general) decide. This punishment can involve for sure execution, but also different levels physical and/or psycological punishment.

Last year there was an opinion poll in France (I think French people love polls, you constantly find in the news headers like "60% of French people think that...") where a big percentage of the participants said to agree with the idea of torturing Islamist Terrorists to obtain information (this was just after the capture of the Salah Abdeslam bastard). Of course I agree with the idea of subjecting Abdeslam (or any Salafist scum) to very hard physical punishments, but not just for obtaining information, but for the sake of justice. I'm fed up of the idea of "rehabilitation". Sometimes people commit small crimes out of real need, and for sure these people must be helped. Other times people just make "acceptable" errors, that's an essential part of our human condition. In these cases the ideas of rehabilitation and punishment should go together. Be deprived of your freedom for some time as a punishment, and leverage that time to help you make up your mind and choose a different path. But when the crime is too brutal, too cruel, I don't think rehabilitation should play any role, the only thing that matters is punishment.

Friday, 14 July 2017

The Autopsy of Jane Doe

It has passed almost one year since I watched The Witch, and my attitude towards horror films has not changed, I continue to be no particularly interested on "Paranormal" Horror, but again, as with The Witch, The American Cosmograph has given me the opportunity to watch a really good one, The Autopsy of Jane Doe.

One father and son run proudly and professionally an "Autopsy business". One evening the police brings them a new "client", a young, beautiful, unidentified (hence the "Jane Doe" thing) woman found dead in unknown circunstances. They start the examination, and as it advances more an more odd findings stack up until the first paranormal events start. So far, the film was a bit gore, now it turns violent and claustrophobic, with some good jump scares. To round it off they manage to give it a nice source to all this supernatural mess (OK, it's paranormal stuff, don't thik of a rational explanation, but the idea is cool). Indeed, this is one more point that makes me relate this film and The Witch

The acting is pretty good, particularly Brian Cox, and the 90 minutes of the film pass too fast. There is one of those moments of 5 seconds when the screen goes completely black (there's a blackout), that is particularly good when you are watching the film in the huge screen of a cinema.

All in all, a very good cinema, that for sure will be on top ten of 2017 Horror films and that you should watch.

Friday, 7 July 2017

ES6 Proxies and getPrototypeOf

The other day, somehow came to my mind an old post about static methods in JavaScript, and I thought that similar to the "avoid overriding" reason that I mention in that post, another use case would be to prevent operations from being intercepted by a proxy. I immediately thought of key actions like getPrototypeOf as an action that is better to be sure that the real method is being called and not a replacement, so it's much better to have it as a static method than as an instance method. So to my surprise I found out that the Proxy API provides a trap for getPrototypeOf, that indeed intercepts all these operations:

  • Object.getPrototypeOf()
  • Reflect.getPrototypeOf()
  • __proto__
  • Object.prototype.isPrototypeOf()
  • instanceof

Seeing that list I thought, OK, it intercepts all those cases, but will it intercept the case when the runtime is traversing the prototype chain of an object?.

I've done a short test, and seems like the traversal of the prototype chain when the runtime searches for an item is not affected by the proxy trap.


class Person{
 constructor(name){
  this.name = name;
 }
 
 sayHi(){
  return "Hello I'm " + this.name;
 } 
}
 
let p1 = new Person("Francois");

let proxiedP1 = new Proxy(p1, {
  getPrototypeOf(target) {
 return null;
  }
});

console.log("- Operations with proxiedP1");

console.log("proxiedP1 instanceof Person: " + (proxiedP1 instanceof Person));
//false

proto = Reflect.getPrototypeOf(proxiedP1);
console.log("proto is " + (proto === null ? "NULL" : "NOT NULL"));
//proto is NULL


//INTERESTING, proxying getPrototypeOf does not have an effect in how the runtime itself gets access to the prototype chain, so the sayHi method continues to work, even if instanceof is now telling me that proxiedP1 is not a Person anymore
console.log(proxiedP1.sayHi());
//works fine

So if you run the code above you'll get that the internal prototype [[Prototype]] of proxiedP1 is null and that it is not an instance of Person, but the call to sayHi, that is not directly attached to the p1 object, but to its [[Prototype]], will work fine! So officially you are not a Person, but in fact you are...

I find the existance of this trap like a source of confusion, but well, you can read about some use case here.

This has raised some questions in my head. From the programmer perspective the access to a method in JavaScript is not based on Method Dispatch or Message Sending, it's just a property lookup. That property lookup just returns a function and then it's invoked (if it it does not exist the runtime will follow up the prototype chain to find it). I assumed that at the lower level it would be implemented like that, but this would means that the addition of proxies would have introduced a sort of conditional to any property access in any object in the system. The runtime would have to check if the object is a proxy and has a get trap to invoke that trap or just do the normal access. If this were this way, the introduction of proxies in ES6 engines would have had performance implications for any code (whether it uses proxies or not), so obviously there has to be much more to it.

Saturday, 1 July 2017

Generics and Dynamic

Time ago I saw somewhere a fragment of code that rather confused me. It was a line where a generic method was receiving dynamic as type parameter. "dynamic" is something at the C# compiler level, but at the MSIL level it does not exist, it just gets translated into callsite magic for accessing to its methods and properties. So, if you run this code:

  public static void DoSomething<T>()
  {
   Console.WriteLine("type: " + typeof(T).FullName);
  }
  
  static void Main(string[] args)
  {
    DoSomething<String>();
   
    DoSomething<Object>(); 
   
    DoSomething<dynamic>();
   
   //Output:
   // type: System.String
   // type: System.Object
   // type: System.Object
 }

You can see the passing dynamic or Object is just the same, in the method you are receiving T as an Object. If you decompile it and check the MSIL you'll see indeed the compiler is just replacing dynamic by Object in the call.

So from the point of view of the invoked method "dynamic" has no particular meaning, it's from the caller side where it can add semantic value to write DoSomething<dynamic> rather than DoSomething<Object>.

Another related case is when a method returns generic type of dynamic. For example, in Dapper we have this method:

public static IEnumerable<dynamic> Query (this IDbConnection cnn, string sql, object param = null, SqlTransaction transaction ...

Again, at the MSIL that dynamic is just an Object, you can check the MSIL:

Here the semantic value of using dynamic is particularly powerful. It's telling you that the method is returning an object that whatever its type, contains all the fields that you expect and so you can access them without a problem. You can consume it like this:

var rows = connection.Query(...); 

If they had just signed the method as returning IEnumerable<Object> you could write something like this:

IEnumerable<dynamic> rows = connection.Query(...); 

But obviously it's pretty much more semantic to have expressed this "duck typing" in the signature.

By the way, this Query method indeed returns DapperRow objects (a class implementing IDynamicMetaObjectProvider). One could think why they don't just return an anonymous type (then it's going to be accessed via dynamic anyway). One reason is performance, with an anonymous type the dynamic access would be using a Reflection (with a cache mechanism, so it works faster than normal Reflection, but it's Reflection anyway), a type implementing IDyamicMetaObjectProvider implements itmself the access and dispatch rules, so it should be faster. But there is another more fundamental reason, based on what you can read here

Anonymous objects are internal, which means their members are very restricted outside of the assembly that declares them. dynamic respects accessibility, so pretends not to be able to see those members.

Notice that when you use Reflection you can decide to ask access to non public items, but dynamic uses Reflection "as a good guy", trying to access only public items, so for this case where Dapper is in an assembly and your code in another, Anonymous Types + dynamic is not an option. On the contrary, for code living in the same assembly, like the one below, it's a good option.

static dynamic CreateObject()
{
 
 return new {Name="Francois"};
 
}
  
static void Main(string[] args)
{
 dynamic o1 = CreateObject();
 Console.WriteLine(o1.Name);
}

Monday, 26 June 2017

Local Functions and Async

Following my previous post on Local Functions and Iterator methods, it's time now to see what I've learnt about async thanks to local functions

When reading the last part of this article, this paragraph was a great finding.

This exhibits the same issue as the iterator method. This method doesn’t synchronously throw exceptions, because it is marked with the ‘async’ modifier. Instead, it will return a faulted task. That Task object contains the exception that caused the fault. Calling code will not observe the exception until the Task returned from this method is awaited (or its result is examined).

So, let's compare these 2 methods:

public static Task<string> DoProcess1(string st)
  {
   Console.WriteLine("DoProcess1method started in: " +  Thread.CurrentThread.ManagedThreadId);
   if (st.StartsWith("throw")){
    throw new Exception("Can not process invalid string");
   }
   Console.WriteLine("string is valid to be processed");
   
   
   var t1 = Task.Run(() => {
                      Console.WriteLine("Time consuming operation running in: " +  Thread.CurrentThread.ManagedThreadId);
                      Thread.Sleep(1000);
                      return st.ToUpper();
                     });
   return t1;
  
  }
  
  public static async Task<string> DoProcess2(string st)
  {
   Console.WriteLine("DoProcess2 method started in: " +  Thread.CurrentThread.ManagedThreadId);
   if (st.StartsWith("throw")){
    throw new Exception("Can not process invalid string");
   }
   Console.WriteLine("string is valid to be processed");
   
   
   var res = await Task.Run(() => {
                      Console.WriteLine("Time consuming operation running in: " +  Thread.CurrentThread.ManagedThreadId);
                      Thread.Sleep(1000);
                      return st.ToUpper();
                     });
   
   return res;
  
  }

Both methods are basically the same, but the second is using await and hence we've had to decorate it with the async keyword. In both cases the first lines of the method (until Task.Run) are executed by the thread from the caller method, but while in Process1, the exception will be thrown immediatelly, in Process2 the compiler generated code will capture the exception and won't throw it until the Result of the returned Task is accessed. Let's see:

try{
    t1 = ProcessingService3.DoProcess1("throw aaaa");
    
    //we DON't reach this line
    Console.WriteLine("after Process1 call");
    Console.WriteLine(t1.Result);
   }
   catch (Exception ex){
    Console.WriteLine("Exception: " + ex);
   }
   
   Console.WriteLine("----------------");
   
   try{
    t1 = ProcessingService3.DoProcess2("throw bbbb");
    
    //we reach this line
    Console.WriteLine("after Process1 call");
    //exception occurs in the line below, when accessing Result
    Console.WriteLine(t1.Result);
   }
   catch (Exception ex){
    Console.WriteLine("Exception: " + ex);
   }

This is interesting, in DoProcess1, 0 or 1 Task object is created (depending on whether we throw or not before reaching Task.Run). In a method marked as async, like DoProcess2 the compiler creates at least 1 "main" Task object. This main Task object is always created, it does not involve a particular thread, but is used to hold the Result/Exceptions of the different Tasks created inside the method, and is returned to the invoker of the method. If DoProcess2 does not throw an Exception then it reaches Task.Run, and the compiler will add an invocation to ContinueWith on that second task, and so on for as many "await" calls we could have inside the async method. For the last one the ContinueWith will set a Result in that main Task created at the beginning of the call. If at some point an exeption happens the exception will be added to the Main Task and no more code of the asynchronous method will be run.

OK, the explanation above is confusing and not really accurate, but it helps me to get an approximate idea of what is going on in a method marked as async. If you really want to understand it, check this amazing post.

As you can see in that glorious article, for each method marked as async the compiler will create a class that is basically a State Machine. This State Machine has a MoveNext method that orchestrates the sequence of asynchronous calls. Each await call that exists in the async method is like a step, and where each awaited Task is asked (via ContinueWith) to call into MoveNext once it's done.

It's amazing to see how similar this compiler generated State Machine is to the one generated for an Iterator method. In the end, both things are basically the same, the big difference is that for Iterators is the consumer of the iterator who will be calling to MoveNext, while for the async-await thing it's the asynchronous method who once finished will call to MoveNext. Just as a reminder, in ES6 (while waiting for the await keyword to be introduced in ES7) people have been leveraging generators to sort of simulate await and avoid the callback hell.

Saturday, 24 June 2017

Local Functions and Iterators

In the end I find the introduction of Local Functions in C# 6 really useful, as I have learnt a couple of things reading about their uses. Thanks to them I've got a refresh and improvement of my understanding of how the compiler manages Iterators and Async methods. As explained here, in both cases local functions provide a useful pattern to manage validation in Iterators and Async Methods. This post will focus on Iterators.

I've had since its inception a more or less clear a view of the magic used by the compiler when it comes across an Iterator method. It creates a class implementing both IEnumerable and IEnumerator and moves the code of the iterator method into the MoveNext method in that class (that acts as a sort of State Machine), replacing the "yield" keyword (that does not exist at MSIL level) with assignments to the "Current" support field. No need to enter into more details when you have a perfect explanation here.

The thing is that maybe one could think that when we have code like this:


public IEnumerablet<string> GetMainDocuments(string url)
{
 if (url == null){
  throw new Exception("Empty!");
 }
 for (var i=0; i<5; i++){
  yield return downloader.download(url + "/item/i");
 }
}

The compiler could put the code that goes before the loop in a separate method, not in the MoveNext. A method that would be executed before we started the iteration with MoveNext, just invoked from the constructor of the state machine for example. This would make sense for certain cases of validation code, where we could want an immediate crash rather than a delayed crash when we decided to iterate. But we have to be aware that one of the basis of iterators is "lazy evaluation/deferred execution". In a way they are a bit like "promises", we have a "promise of a sequence" but each of its items does not materialize until the moment when we ask for it in the next iteration step. Have this in mind, and think that there are many cases where the "pre-iteration" code should be done just at the moment of starting to iterate: maybe it returns values used during the iteration, maybe it's still a validation, but one that depends on dynamic factors and has to be done just at the moment of starting to iterate, not before. So as the compiler can not differenciate those cases, absolutely all the code in your iterator method is put inside the MoveNext of the state machine.

For example think about this case:

public IEnumerable<string> GetMainDocuments(string pattern, DBHelper dbHelper)
{
 if (pattern == null){
  throw new Exception("Empty!");
 }
 
 if (!dbHelper.IsDbUp()){
  throw new Exception("DB down!!!");
 }
 
 IEnumerable<string> documents = dbHelper.GetDocuments("whatever query " + pattern + " whatever");
 
 for (var i=0; i<5; i++){
  yield return downloader.download(url + "/item/i");
 }
}

For the first contitional it would be useful to do it in a no deferred way, but for the second conditional, it makes more sense to do it just at the moment when data start to be needed. And for the third, again it makes more sense to do it not deferred (or maybe you wanted a snapshot at the moment when GetMainDocuments was called?) Yes, there are many possibilities, and the compiler can not just guess. So just have to adapt to his rules. Anything, inside the iterator will be deferred, so if there is code that you don't want lazy you'll have to separate it yourself

public IEnumerable<string> GetMainDocuments(string url)
{
 IEnumerable<string> getDocuments(string url){
  for (var i=0; i<5; i++){
   yield return downloader.download(url + "/item/i");
  }
 }
 
 if (url == null){
  throw new Exception("Empty!");
 }
 return getDocuments(url);
}
 

I have no idea of how the different JavaScript engines manage generators, but the issue with deferred execution is the same. Nothing of the code in your generator function will be executed until you start to iterate the created generator object.


function* nameGenerator(){
 //this console.log won't be executed until the first call to "next"
 console.log("inside iteration");
 yield "xuan";
 yield "xana";
 yield "iyan";
};

let gen = nameGenerator();

console.log("generator created\n");

console.log("starting loop");
for(let name of gen){
 console.log(name);
} 

//output:

// generator created

// starting loop
// inside iteration
// xuan
// xana
// iyan

Wednesday, 21 June 2017

A Distaste For Expression Bodied Members

I really like to see programming languages evolve, getting new features version after version. Even if some of those features are not particularly useful or revolutionary, but just a way to make code less verbose, I appreciate them, as I like to see evolution and dynamism, being forced to learn something new. Microsoft has put quite a bit of effort in saving us to type repetitive code and do our code more concise. The introduction of Automatic properties was a huge step, and the improvements done in the last versions (default values for Automatic properties, read only auto properties, and both features combined) are pretty sweet.


//Automatic property with default value
public string FavoriteCity {get; set;} = "Paris";

//Read Only Automatic property (I'll be setting its value in the constructor
public string BirthCity {get;}
 
//Read Only Automatic property with default value
public DateTime BirthDate {get;} = DateTime.Now;
  

Another "big feature" in terms of type strokes saving has been Expression Bodied Mmembers. Honestly, this feature feels like a bit irritating to me.

So now you can write a method like this:

public int FormatString(string st) => $"---{st}---";

//rather than like this:
public int FormatString(string st){
return $"---{st}---";
}

I don't see it particularly helpful, but guess others will find it cool. The problem for me comes when we use it with Automatic Properties. Let's see:



public string FrenchFullName => $"{this.LastName.ToUpper()}, {this.Name}";


//is equivalent to:
public string FrenchFullName 
{
 get{ return $"{this.LastName.ToUpper()}, {this.Name}";}

}

//And here an identical method

public string GetFrenchFullName() => $"{this.LastName.ToUpper()}, {this.Name}";

So in the first line I have a property and in the last line a method. At first sight it's not easy to see if it's a method or a property, the only difference is the extra "()". If you follow the correct nomenclature, properties should be nouns and methods should be verbs, there's no room for confusion, but anyway, I feel a bit uneasy with this similarity.

Furthermore, this syntax can be applied to create local functions (added in C# 7). So you can write alocal function in any of these 2 ways:

public static void InternalFunctionTest()
        {
   string applyFormat(int num){
    return $"[{num.ToString()}]";
   }
   
   string applyFormat1(int num) =>  $"[{num.ToString()}]";
  }

If you use the second way, it looks a bit similar to what we would have done in the past if we wanted to avoid polluting the class with a function that is only used from a certain method, write it as a lambda:

Func<int, string> applyFormat2 = (int num) => $"[{num.ToString()}]";

Under the covers, this is quite different from the expression bodied local function. In this case we are creating a new object, a delegate, while with the local function such object creation is not needed. There are more differences in terms on where the compiler creates the underlying method and the use of closures, but I've read some contradictory informations about this, so I'll have to spend some time to get the complete idea.

The "=>" syntax has been a pretty bad choice in my opinion and probably the source for my distaste for Expression Bodied Members . It's linked in my mind to delegates, so it takes my brain some extra cycles to break that association each time I see this symbol.

Saturday, 17 June 2017

Current Directory

The Current Directory (or Working Directory or Current Working Directoy) of a process is one of those topics that I seem to clearly understand, but after a while I partially forget and have to strive to rebuild it in my head, so I'll do a dump it here after that last build. I'm talking only about Windows, I guess the behaviour in Linux and the different UI Shells will be similar.

Every windows process has an associated Current Directory. This is the folder that the process will use as root for any relative path that it tries to access. You can see it with Process Explorer. So, how does a process get its working directory assigned?

The CreateProcess Win32 API function has a parameter to set the Current Directory. If NULL, the Current Directory of the parent process will be inherited. Higher level mechanisms used to create processes (and that ultimately make use of CreateProcess) will usually give you the option to provide the Current dDrectory (like in .Net with ProcessStartInfo).

OK, the above is good to know when we are writing a program that will launch another process, but how have the writers of common OS components handle this? meaning, how does this work when a program is started from the command line or Windows Explorer?

The Windows command line. cmd.exe has as Current Directory the folder where it is currently located. If you do a cd, the Current Directory will get updated accordingly. When you start a process from the command line, the process will inherit the Current Directory from cmd. This means that if you do this:

c:\Temp>cd c:\myAppFolder
c:\myAppFolder> myApp.exe

myApp.exe will have as working directory c:\myAppFolder

But if you do this:

c:\Temp>c:\myAppFolder\myApp.exe

myApp.exe will have as working directory c:\Temp

Windows Explorer. There are several ways in which you can launch a process from Windows Explorer (explorer.exe). Browsing to the folder containing the .exe file and double clicking on it, or typing the path to the exe in the Windows->Run window, is the same, Explorer will set up as Current Directory the folder where the .exe file is located.

An additional way to launch process from Windows Explorer is through a shortcut. If you check the properties of a shortcut you'll see a Start in field. If filled, that value will be used as Current Directory. If emtpy, Explorer will set the program's Current Directory to the folder where the shortcut is located (quite commonly the Desktop).

A process can easily change its working directory while running, by using the SetCurrentDirectory Windows API function. From .Net you can use the Directory.SetCurrentDirectory method.

As far as I know there is not a public API for changing the Current Directory of another process. The option that I've seen is pretty hackerish, injecting a dll in that process and invoking SetCurrentDirectory from its entry point.

As far as I know, by default Windows Services get as Current Directory C:\Windows\System32\, I guess because they inherit it from services.exe

Finally, there's an interesting quirk to bear in mind with .NET applications. The standard configuration system (the old school System.Configuration.ConfigurationManager, previous to the introduction in .Net Core of the much more advanced Microsoft.Extensions.Configuration) is pretty smart and does not use the Current Directory to locate the myApp.config file that has to be located next to myApp.exe, it will get the folder containing our binary and search the app.config in it, so in terms of configuration you don't care about the Current Directory and whether your app is started via explorer or from the command line or from another process. If you move to using a different kind of config file placed also next to your binary, you'll have to start to consider that the Current Directory could have different values and is not a reliable way to get the file.