Sunday, 17 May 2020

Prevent Overfilling the Stack, Part 2

In my previous post I showed a technique to prevent overfilling the stack in deep recursion cases. In my example there I was using this technique for a recursive function that has no additional action to perform after the recursive call returns (that is, the case that would be optimized by Tail Calls if JavaScript implemented them). In this post we'll see how to apply this technique for recursive functions that perform additional actions after the child recursive call.

Let's say we have this recursive function:

function transformString (source){
    if (source.length === 1)
        return source.toUpperCase() + source;
    
    let curItem = source[0];
    let transformed = transformString(source.substring(1));
    return curItem.toUpperCase() + transformed + curItem;
}

let st = "helloworld";

console.log(transformString(st));

//Output:
//HELLOWORLDdlrowolleh

As you can see, after invoking the recursive function we still run an action with the returned value and a value obtained before invoking the recursion (curItem). When applying the technique of the previous post we no longer have the current stack frame for running this action (as we are no longer stacking stack frames), so we have to provide this "post action" to the recursive function. So basically, the adapted recursive function receives an array with all the post actions. Notice that these "post action" functions trap as closure variables the values that normally would be in their stack frames.

//postActions: array of functions where we stack the code to run after recursion ends
//resFn: Promise resolve function
function transformStringWithTimeout (source, counter = 0, postActions, resFn){
    let curItem;
    let postAction = transformed =>  curItem.toUpperCase() + transformed + curItem;
    
    //initial call 
 if (resFn === undefined){
        var pr = new Promise((res, rej) => resFn = res);
        postActions = [];
 }

    //end recursion
    if (source.length === 1){
        let initValue = source.toUpperCase() + source;
        //using reduceRight to run the stack of actions
        let result = postActions.reduceRight((accum, fn) => fn(accum), initValue);
        resFn(result);
    }
 else{
        curItem = source[0];
        postActions.push(postAction);
  //use this so low "recursion break" value for the sake of testing
  if (counter < 5){
   transformStringWithTimeout(source.substring(1), ++counter, postActions, resFn);
  }
  else{
            //let's release the stack
            setTimeout(() => {
                console.log("timeout handling");
                transformStringWithTimeout(source.substring(1), 0, postActions, resFn);
            }, 0);
            
  }
 }
 return pr;
}

(async () => {
    console.log("-- with timeout");
    let result = await transformStringWithTimeout("helloworld");
    console.log(result);
})();

//Output:
//HELLOWORLDdlrowolleh
//-- with timeout
//timeout handling
//HELLOWORLDdlrowolleh

As you see, I've moved into a function postAction the piece of code that in the original function we were running after the recursive call. I push those postActions in an array postActions that I keep passing over in ensuing calls. When we reach the end of the recursion we run these post actions in reverse order. Notice than rather than using a for-of and pop for executing these actions I'm using reduceRight, just for the pleasure of it :-)
You can get the full code here

Sunday, 10 May 2020

Prevent Overfilling the Stack

Recursion can be terribly useful, but there is a problem with it. A deep recursion involves having many function calls "alive" (waiting for the last one to complete and do the return path). Each of these calls is a new frame pushed on the stack, and programs limit the size a thread stack can reach, meaning that occasionally we can reach that limit before completing, crashing our program. When our recursive function has nothing pending to do once the child call returns (the recursive call is the last thing done in our function) an optimization can be done, reusing the same stack for all calls, I'm talking about Tail Call Optimizations. Indeed, as you can read here there are 2 related options: Tail Call Optimizations (TCO) and Proper Tail Calls (PTC). Current JavaScript engines do not implement any of them, so if we run into a deep recursion we are fucked, our code will throw a Maximum call stack size exceeded exception (at least in node.js).

To avoid this we need a way to release our current stack frame before doing the recursive call, so that its stack frame replaces the current frame rather than being pushed on top. We have an obvious way to invoke a function after the current function ends, delay its invokation with setTimeout. So let's see an example of how to transform a recursive function to use setTimeout and avoid overfilling the stack.

We can calculate the factorial of a number in 2 ways, the most common one being:

function factorial(n) {
 return (n !== 0) ? n * factorial(n - 1) : 1;
}

In the above, we leave an operation to be done after the recursive call is done. We can transform it so that nothing is left for doing after ther recursive call.

function tailFactorial(n, total = 1) {
    //console.trace();
    if (n === 0) {
        return total;
    }    // proper tail call
    return tailFactorial(n - 1, n * total);
}

If the JavaScript runtime implemented PTC, using the second factorial function the stack would not crash regardless of the number of calls, but we can see that this is not the case and when using a big enough number of recursions (largeValue) we crash the stack in both cases:

const smallValue = 100;
const largeValue = 50000;

function runFactorial(factorialFn){
 let res = factorialFn(smallValue);
 console.log("factorial: " + res);

 //stack overflow:
 try {
  res = factorialFn(largeValue);
  console.log("factorial: " + res);
 }
 catch (ex){
  console.log("Exception: " + ex.message);
  //Maximum call stack size exceeded
 }
}

[factorial, tailFactorial].forEach(fn => runFactorial(fn));

/* Output:
factorial: 9.33262154439441e+157
Exception: Maximum call stack size exceeded
factorial: 9.332621544394418e+157
Exception: Maximum call stack size exceeded
*/

As I mentioned before, we can fix this by delaying the function call with setTimeout (so that the current stack frame gets freed). I'm returning a Promise that will get resolved once the last recursion is done:

function factorialWithTimeoutAndPromise(n, total = 1, resFn){
 //initial call 
 if (resFn === undefined){
  var pr = new Promise((res, rej) => resFn = res);
 }
 if (n === 0){
  resFn(total);
 }
 else{
  setTimeout(() => factorialWithTimeoutAndPromise(n-1, n * total, resFn), 0);
 }
 return pr;
}

The above works fine, but even using a timeout of 0, the operation takes quite time (almost 1 minute on my laptop). From what I've read this setTimeout(0) can cause up to 4ms delay:
someone told me that setTimeout(0) creates, on average, a 4 ms delay. They claimed that’s the time it takes to pop the callback off the stack, onto the callback queue and back on the stack again.

So we better find a balance between normal recursion (to keep things fast), and setTimeout (to avoid overfilling the stack). In this version below I do normal recursive calls up to 50, then schedule the next call and clean the stack, and so on.

function factorialWithTimeoutAndPromiseImproved(n, total = 1, counter = 0, resFn){
 //initial call 
 if (resFn === undefined){
  var pr = new Promise((res, rej) => resFn = res);
 }
 if (n === 0){
  resFn(total);
 }
 else{
  if (counter < 50){
   factorialWithTimeoutAndPromiseImproved(n-1, n * total, ++counter, resFn);
  }
  else{
   setTimeout(() => factorialWithTimeoutAndPromiseImproved(n-1, n * total, 0, resFn), 0);
  }
 }
 return pr;
}

(async() => {
 console.log("-- using Timeout");

 let options = [
  { 
   name: "Not optimized",
   value: smallValue,
   fn: factorialWithTimeoutAndPromise
  },
  { 
   name: "Not optimized",
   value: largeValue,
   fn: factorialWithTimeoutAndPromise
  },
  { 
   name: "Optimized",
   value: smallValue,
   fn: factorialWithTimeoutAndPromiseImproved
  },
  { 
   name: "Optimized",
   value: largeValue,
   fn: factorialWithTimeoutAndPromiseImproved
  }
 ];
 
 for (let option of options) {
  console.log(option.name + " factorial for: " + option.value);
  let start = Date.now();
  let result = await option.fn(option.value);
  console.log("result: " + result);
  console.log("it took " + (Date.now() - start) + "\n");
 }

})();

/* Output:
Not optimized factorial for: 100
result: 9.332621544394418e+157
it took 132

Not optimized factorial for: 50000
result: Infinity
it took 57441

Optimized factorial for: 100
result: 9.332621544394418e+157
it took 2

Optimized factorial for: 50000
result: Infinity
it took 1187

*/

I've uploaded all the code into a gist

Monday, 4 May 2020

Question Mark in Programming

If you code in C# or TypeScript you should be aware that different kinds of "?" are showing up more and more often in code bases. As most of these developments are pretty recent I'll try to catch up with them here:

Ternary Operator. For sure this is nothing new, but what I think is becoming more common is to see it used in its nested form. I had always considered these nested cases very confusing, but if you write them in the right way, as explained here they can be pretty expressive and easy to follow.

 (conditionA)
    ? valueA
    : (conditionB)
    ? valueB
    : valueC

Null Coalescing operator "??" This has existed in C# since its first version, but has just been added to TypeScript (and should be featured by JavaScript in the future).

 string city = birthPlace ?? "Paris";

In C#: The null-coalescing operator ?? returns the value of its left-hand operand if it isn't null; otherwise, it evaluates the right-hand operand and returns its result.
In TypeScript it's just the same, only that it applies both to null and undefined (the "nullish" values). Notice that in TypeScript it comes as a replacement for the idiomatic use of "||" to provide default values (with the difference that || applies also to the falsy values: 0, "" and NaN, read more)

Null-coalescing assignment is much related to the above. It has been added to C# 8, but is missing from TypeScript so far.

 city ??= "Paris";
 //is equivalent to this:
 city = city ?? "Paris";

Safe Navigation operator I first saw this operator in Groovy (called Safe Dereferencing there) many years ago and I loved it so much that I wrote about how to try to emulate it at that time in C# and in JavaScript.
C# 6 added this little marvel to our toolbox, and TypeScript has recently added (it should make it into JavaScript in a near future).

 //both in C# and TypeScript 
 var street = person?.Address?.Street;

 //safe array access in C#
 var cityName = cities?[0]?.Name;

 //safe array access in TypeScript
 var cityName = cities?.[0]?.Name;

 //safe Dictionary access in C#
 var cityName = countriesDictionary?["France"];

 //safe property access via indexer in TypeScript
 var cityName = city?.["name"];

 
 //safe delegate invokation in C#
 myFn?.Invoke("a");

 //safe function invokation in TypeScript
 myFn?.("a");

As you can see there are some syntax differences when using it with arrays and with delegates/functions. For C# delegates we have to use ?.Invoke() rather than just ?(). For TypeScript we have to use that odd fn?.(), that likewise we also have to use for array indexes or accessing object properties via indexes (ar?.[0] or obj?.["key"])

Tuesday, 28 April 2020

Switch Expressions 2

Last year I did a short write-up about switch expressions, and I have now something to add.

In effect, C# 8 includes this feature, let's see:

var country = city switch
            {
                "Paris" => "France",
                "Berlin" => "Germany",
                "Stockholm" => "Sweden",
                _ => "France"
            };

Nice, but there's something that initially seemed a bit odd to me, the value-switch order. It would seem more natural to me to write country = switch city {. Well, there's one explanation for the order choice, chaining. Thanks to the value-switch order we can chain switch expressions like this:

            return city switch
            {
                "Paris" => "France",
                "Berlin" => "Germany",
                "Stockholm" => "Sweden",
                _ => "France"
            } 
            switch
            {
                "France" => "French",
                "Germany" => "German",
                "Sweden" => "Swedish",
                _ => "French"
            };

In my post from last year I had shown that though JavaScript lacks switch expressions we could write similar code via object literals like this:

let numStr = "TWO";
let num = {
        "ONE": 1,
        "TWO": 2,
        "THREE": 3
    }[numStr];

Something missing in the above code is a default case. In order to manage that I've generalized the above code into a function (switchFn):

function switchFn(value, body, defaultFn){
 let caseFn = body[value];
 return caseFn !== undefined
 ? caseFn(value)
 : (defaultFn)
 ? defaultFn(value)
 : null;
}

To be used like this:

stringValue = "ONE";
numValue = switchFn(stringValue,{
     "ONE": () => 1,
     "TWO":  () => 2,
     "THREE": () => 3
 },
 () => 10
);
console.log(`numeric value for ${stringValue} is ${numValue}`);

We can chain switchFn calls like this

stringValue = "ONE";
position = switchFn(
 switchFn(stringValue, 
 {
  "ONE": () => 1,
  "TWO":  () => 2,
  "THREE": () => 3
 }, () => 0),
 { 
  1: () => "First",
  2:  () => "Second",
  3: () => "Third"
 }, () => "Unknown"
);
console.log(`position value for ${stringValue} is ${position}`);

The above code is not too immediate to read. If we curry (via lodash) the switchFn function, apart from doing the selection logic reusable, we do the chaining a bit more clear. Notice that as we want to fix the second and third parameter to the partially applied function that we obtain, and keep the first parameter "free", we are using the _ placeholder for it (it's something that I have just learned):

let curriedSwitch = _.curry(switchFn);
let numberSelector = curriedSwitch(_, 
 {
  "ONE": () => 1,
  "TWO":  () => 2,
  "THREE": () => 3
 }, () => 0);

let positionSelector = curriedSwitch(_, 
 { 
  1: () => "First",
  2:  () => "Second",
  3: () => "Third"
 }, () => "Unknown");

stringValue = "TWO";

positionValue = positionSelector(numberSelector(stringValue));

console.log(`position value for ${stringValue} is ${positionValue}`);

Additionally, we can compose the selection functions with the lodash flow function.

let positionFromStringNumber = _.flow(numberSelector, positionSelector);
stringValue = "THREE";
positionValue = positionFromStringNumber(stringValue);
console.log(`position value for ${stringValue} is ${positionValue}`);

Monday, 13 April 2020

What keeps the Application running

Thinking a bit about the JavaScript Event Loop I realised of an interesting difference between 2 pieces of similar code in JavaScript - Node.js and .C# - Net.

Let's say I want a program that just does a http GET call and prints the retrieved string.

In JavaScript - Node we would write this:

async function getAndPrintText(){
    console.log("inside getAndPrintText");
    try{
  let response = await fetch("http://localhost:8080");
  if (!response.ok) {
   throw new Error('Network response was not ok');
  }
  let txt = await response.text();
  console.log("txt: " + txt);
 }
 catch(ex){
  console.log("something went wrong: " + ex.message);
 }
}

console.log("Started");
getAndPrintText();
console.log("After invoking GetAndPrintText");

//Output:
Started
inside getAndPrintText
After invoking GetAndPrintText
txt: "the returned html here"

Notice that I've not put an await for the getAndPrintText() call, so the "After invoking" is printed right after the call; before we obtain the result. That console.log is the last visible line in our script but anyway somehow the application waits for the http call to complete before it exits, how?
Well, it's the Event Loop. Node runs our script and then enters in the event loop to check for events coming from the asynchronous operations (and timeouts). The call to fetch() will be registered so that the event loop will be alive until it's completed.

The thing is a bit different in C# and .Net. Translating the above code to C# we would have:

    class Program
    {
        static HttpClient client = new HttpClient();

        static async Task GetAndPrintText()
        {
            Console.WriteLine("inside GetAndPrintText");
            try
            {
            HttpResponseMessage response = await client.GetAsync("http://localhost:8080/index.html");
            response.EnsureSuccessStatusCode();
            string responseBody = await response.Content.ReadAsStringAsync();

            Console.WriteLine("text: " + responseBody);
            }
            catch (Exception ex)
            {
                Console.WriteLine("something went wrong: " + ex.Message);
            }
        }

        static void Main(string[] args)
        {
            Console.WriteLine("Started");
            GetAndPrintText();
            Console.WriteLine("After invoking GetAndPrintText");
        }
}

Running the above the program will finish without printing the retrieve http content. The main application Thread finishes after doing the Console.WriteLine, and there's nothing to keep the application alive. A thread from the I/O TreadPool has been set to wait in the IOCP for the client.GetAsync to complete, but this is a background thread, so it won't keep the application alive if the main Thread reaches its end. You can read more about IOCP in this previous post

For the application to wait for the http call to complete we have to add an await in our Main (and turn it into an async Main), like this:

        static async Task Main(string[] args)
        {
            Console.WriteLine("Started");
            await GetAndPrintText();
            Console.WriteLine("After invoking GetAndPrintText");
        }

I already talked about async Main in the past. The main application Thread will be waiting in the hidden, compiler-generated application entry function for our async Main to complete, and our async Main is waiting for the http call. That's how the application is kept alive, nothing to do with an Event Loop as in Node.js

Saturday, 11 April 2020

Some Linux Tricks

There are some basic linux tricks that I occasionally need and that I'd like to share:

  • Passing the output of a program/command as argument to another program/command Notice that when using pipes "|" we are passing the stdout as stdin to second program. What I mean here is passing it as argument. Let's say we have a file that contains the path to a folder which contents we want to list. We have 2 ways to achive this, with the $() "operator" or with the xargs tool that seems to be installed in most modern systems:
    ls $(cat fileContainingPath.txt)
    cat fileContainingPath.txt | xargs ls
  • Find what application has a file open (one of the main reasons to make me launch SysInternals Process Explorer in Windows). It's that simple as doing:
    lsof filename
  • See the shared libraries (.os files, equivalent to Windows .dlls) loaded by a process. We'll use again lsof, this time like this:
    lsof -p PIDofTheProcess | grep '\.so$'
  • Find to what process does a window belong to* (this is another of the main reasons for me to launch Process Explorer in Windows):
    xprop | grep PID

Sunday, 5 April 2020

The French Connection

I've recently watched 2 really excellent crime films (or should I better call them "film noir"? well, I keep that for the experts). The French Connection and French Connection II are inspired by the real drug trafficking scheme operating between the 1930's and 1970's and that transported heroin from Turkey to France and from there to the USA. The 2 central cities in this trafficking were Marseille and New York.

The first film (from 1971) is really good, but the second one is just outstanding. The first installment has some scenes shot in Marseille but most of the story happens in New York. The second installment is 100% shot in Marseille. Given my love for the gorgeous Mediterranean city one can think that it plays a role in my predilection for the second film. Well, for sure it does, but anyway the story in the second film is much more aggressive, gripping, even extreme (the detective striving to overcome the heroin addiction forced on him by the gangsters). It also has some funny moments with the culture shock of the New York detective experiencing France.

For a Marseille lover like me that only knows the city (pretty well I think I can say, I've been there many times) since 2014, the images of 1975 Marseille are really interesting. On one side there are so many familiar things, the forts and the Vieux Port, some of those high-rise buildings that emerged in the 50's - 60's... On the other side the ugly port facilities right below the cathedral have disappeared (replaced by the rather interesting EuroMed development, indeed Marseille has become along with Bilbao one of the most reknown examples of tranformation of an ugly centrally located industrial area into a trendy, architecturally noteworthy space loved by its cicizens).

One obvious negative change that clearly slaps you in the face is the change in the population make up. In those images from the 70's one perceives a European society (where there is the normal and healthy gradient of skin colors from "very white" to "very black", but everyone seems to share a same culture). This has little to do with the current city where estimates say that more than a 30% of the population is Muslim, and even worse, most of them consider themselves Algerians rather than French...). The criminality levels have totally changed. In the 70's you had these criminal gangs importing, cooking and exporting heroin and for sure there was violence among them and against the police, certainly the drug addicts posed a problem... but that's nothing compared with the current massive violence exerted by the Islamists (mostly cultural violence, but also physical violence) and with the neighbourhoods controlled by the drug dealers and/or the Islamists...