From 9dc38456a83ae3775c3cd767aa3a546b92c1b723 Mon Sep 17 00:00:00 2001 From: "Lucio M. Tato" Date: Mon, 26 Aug 2013 22:47:56 -0300 Subject: [PATCH 1/5] Create Lucio M. Tato.markdown --- authors/Lucio M. Tato.markdown | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 authors/Lucio M. Tato.markdown diff --git a/authors/Lucio M. Tato.markdown b/authors/Lucio M. Tato.markdown new file mode 100644 index 0000000..e523171 --- /dev/null +++ b/authors/Lucio M. Tato.markdown @@ -0,0 +1,10 @@ +Github: luciotato +Email: ltato@prosart.com +Company: http://tecnogob.com/ +Consulting: http://prosart.com/ +Location: Pilar, Buenos Aires, Argentina + +I've started programming at age 12, even before owning a computer. My first computer was a ZX-Spectrum. I've programmed +from Z80 assembly and x86 assembly years ago to .NET and node.js today, with everything in between. +I own a company which provides services to country governments and large organizations in Argentina, also I'm on the board +of Prosart Development Studio, also located in Argentina, specialized in tackling challenging projects. From 1264cfcc8d6d8125bb057e4a6ab89890a5910951 Mon Sep 17 00:00:00 2001 From: "Lucio M. Tato" Date: Mon, 26 Aug 2013 23:18:30 -0300 Subject: [PATCH 2/5] Create sequential programming for node.js --- articles/sequential programming for node.js | 100 ++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 articles/sequential programming for node.js diff --git a/articles/sequential programming for node.js b/articles/sequential programming for node.js new file mode 100644 index 0000000..28c52ac --- /dev/null +++ b/articles/sequential programming for node.js @@ -0,0 +1,100 @@ +Wait.for +======= + +Node.js unavoidable style is to make everything that could **even begin to think about blocking** into a async function. +This ir a core node trait. You can avoid it, you can side-step it, Node will not forgive you. + +But... wouldn't be great to be able to call all this great async functions in a sequential/sync mode when the need arises? + +Specially the need of not to foll into callback hell? + +I believe async is great, and obviouslly there are no other way to program blocking or long-running functions in Node. +But sometimes, like when you're progarmming business DB access logic, a sync-non blocking mode to call asnyc functions come very handy. + +That's why I've developed a very small, simple lib, which bassically provides the programmer with a ***wait.for*** function. + +What does wait.for does? +-- + +wait.for waits for the async function to callback, before continuing to the next line, and it does it WITHOUT blocking node. +In order to acheive this, there are two version based on different thechonolgies under the hood. + +* one is [wait.for based on node-fibers](https://github.com/luciotato/waitfor) + +* other is [wait.for based in the upcoming ES6-Harmony generators](https://github.com/luciotato/waitfor-ES6) + +I've coded [wait.for based on node-fibers](https://github.com/luciotato/waitfor), two weeks ago. +After uploading the original **wait.for** based on node-fibers, several people ask me: "why not base it on ES6-Harmony generators?". So I started looking for information on such a migration. +After a quick search, the migration did not seem possible: +(According to this: http://stackoverflow.com/questions/18293563/can-node-fibers-be-implemented-using-es6-generators +and this: http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web) + +However, the basic building blocks of ES6 generators are the same for the concept of fibers, +so I started trying to port **wait.for** to ES6... + +It didn't looked good, ***but it went much better than expected!*** + +***The funny thing is***, the implementation of the core function ***wait.for(async,arg...)***, using ES6 generators is: + +```javascript +wait.for = function( asyncFn ) { return arguments; } +``` +Yes, just return arguments. + +Compare it to **wait.for** based on node-fibers: + +```javascript +wait.for = function(asyncFn){ + var newargs=Array.prototype.slice.call(arguments,1); // remove function from args + return Wait.applyAndWait(null,fn,newargs); + } +``` + +**wait.for** based on node-fibers *actually does something*: calls ***Wait.applyAndWait*** + +In contrast ES6 based implementation of **wait.for(asyncFn)** does basically nothing (the magic control flow resides in *yield*) + +You use ***wait.for*** inside a generator (function*) in conjunction with new JS/ES6 ***yield*** keyword, as in: + +```javascript +var data = yield wait.for ( fs.readFile, '/etc/somefile' ); +``` + +

Surprisingly, ES6 generators-based implementation of function wait.for(asyncFn) +is almost a no-op, you can even completely omit it calling it...

+ +Given that evaluating ***wait.for*** return its arguments, the call can be replaced with an object literal, which is an array-like object. It results that: +```javascript + +wait.for( asyncFn, arg1, arg2 ) // return arguments +=== {0:asyncFn, 1:arg1, 2:arg2 } // is equivalent to... +~= [ asyncFn, arg1, arg2 ] // is similar to... +``` +so, the following two snippets are equivalent (inside a generator launched via ***wait.launchFiber(generator)***): + +```javascript +// call an async function and wait for results, (wait.for syntax): +console.log( yield wait.for ( fs.readFile, '/etc/somefile', 'utf8' ) ); + +// call an async function and wait for results, (fancy syntax): +console.log( yield [ fs.readFile, '/etc/passwd', 'utf8' ] ); +``` + +Check both repositories: + +* [wait.for based on node-fibers](https://github.com/luciotato/waitfor) + +* [wait.for based in the upcoming ES6-Harmony generators](https://github.com/luciotato/waitfor-ES6) + + +Advantages of wait.for +--- + +* Avoid callback hell / pyramid of doom +* Simpler, sequential programming when required, without blocking node's event loop (thanks to fibers) +* Simpler, try-catch exception programming. (default callback handler is: if (err) throw err; else return data) +* You can also launch multiple parallel non-concurrent fibers. +* No multi-threaded debugging nightmares, only one fiber running at a given time (thanks to fibers) +* Can use any node-standard async function with callback(err,data) as last parameter. +* Plays along with node programming style. Write your async functions with callback(err,data), but use them in sequential/SYNC mode when required. +* Plays along with node cluster. You design for one thread/processor, then scale with cluster on multicores. From 8361bd7abe0c974ae21b9cd9cf905f22911cbca6 Mon Sep 17 00:00:00 2001 From: "Lucio M. Tato" Date: Mon, 26 Aug 2013 23:20:44 -0300 Subject: [PATCH 3/5] Rename sequential programming for node.js to sequential-programming-for-node.js.markdown --- ...ng for node.js => sequential-programming-for-node.js.markdown} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename articles/{sequential programming for node.js => sequential-programming-for-node.js.markdown} (100%) diff --git a/articles/sequential programming for node.js b/articles/sequential-programming-for-node.js.markdown similarity index 100% rename from articles/sequential programming for node.js rename to articles/sequential-programming-for-node.js.markdown From 02da1aab14d13937293571e40b266904a80096f4 Mon Sep 17 00:00:00 2001 From: "Lucio M. Tato" Date: Mon, 26 Aug 2013 23:39:18 -0300 Subject: [PATCH 4/5] Update sequential-programming-for-node.js.markdown --- ...equential-programming-for-node.js.markdown | 27 +++++++++++-------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/articles/sequential-programming-for-node.js.markdown b/articles/sequential-programming-for-node.js.markdown index 28c52ac..a68ad25 100644 --- a/articles/sequential-programming-for-node.js.markdown +++ b/articles/sequential-programming-for-node.js.markdown @@ -2,29 +2,33 @@ Wait.for ======= Node.js unavoidable style is to make everything that could **even begin to think about blocking** into a async function. -This ir a core node trait. You can avoid it, you can side-step it, Node will not forgive you. +This is a core node trait. You can't avoid it, you can't side-step it, Node will not forgive you. But... wouldn't be great to be able to call all this great async functions in a sequential/sync mode when the need arises? -Specially the need of not to foll into callback hell? +Specially the need not to fall into callback hell? I believe async is great, and obviouslly there are no other way to program blocking or long-running functions in Node. -But sometimes, like when you're progarmming business DB access logic, a sync-non blocking mode to call asnyc functions come very handy. +But sometimes, when you're coding business DB access logic, as example, +a sync-non blocking mode to call asnyc functions is very handy. -That's why I've developed a very small, simple lib, which bassically provides the programmer with a ***wait.for*** function. +That's why I've developed a very small, simple lib called ***wait.for***, -I mean ***simple***, not future promises, I mean ***simple*** now. - ;) + +Wait.for, as it name imples, bassically provides the programmer with a ***wait.for*** function. What does wait.for does? -- wait.for waits for the async function to callback, before continuing to the next line, and it does it WITHOUT blocking node. -In order to acheive this, there are two version based on different thechonolgies under the hood. -* one is [wait.for based on node-fibers](https://github.com/luciotato/waitfor) +I've developed two versions of ***Wait.for*** based on different thechonolgies under the hood. + +* one is [wait.for based on node-fibers](https://github.com/luciotato/waitfor) (github repo) -* other is [wait.for based in the upcoming ES6-Harmony generators](https://github.com/luciotato/waitfor-ES6) +* other is [wait.for based in the upcoming ES6-Harmony generators](https://github.com/luciotato/waitfor-ES6) (github repo) I've coded [wait.for based on node-fibers](https://github.com/luciotato/waitfor), two weeks ago. -After uploading the original **wait.for** based on node-fibers, several people ask me: "why not base it on ES6-Harmony generators?". So I started looking for information on such a migration. +After publishing it, several people ask me: "why not base it on ES6-Harmony generators?". So I started looking for information on such a migration. After a quick search, the migration did not seem possible: (According to this: http://stackoverflow.com/questions/18293563/can-node-fibers-be-implemented-using-es6-generators and this: http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web) @@ -50,11 +54,12 @@ wait.for = function(asyncFn){ } ``` -**wait.for** based on node-fibers *actually does something*: calls ***Wait.applyAndWait*** +**wait.for** based on node-fibers *actually does something*: calls ***Wait.applyAndWait***, which in turn uses node-fibers to handle the async call. -In contrast ES6 based implementation of **wait.for(asyncFn)** does basically nothing (the magic control flow resides in *yield*) +In contrast ES6 based implementation of **wait.for(asyncFn)** does basically nothing +(the magic control flow resides in ***yield***) -You use ***wait.for*** inside a generator (function*) in conjunction with new JS/ES6 ***yield*** keyword, as in: +You can use ***wait.for*** inside a generator (function*) in conjunction with new JS/ES6 ***yield*** keyword, as in: ```javascript var data = yield wait.for ( fs.readFile, '/etc/somefile' ); From 5e821a727ce7cfca8cd23c7dedb04b0a67ab6250 Mon Sep 17 00:00:00 2001 From: "Lucio M. Tato" Date: Mon, 26 Aug 2013 23:40:13 -0300 Subject: [PATCH 5/5] Update sequential-programming-for-node.js.markdown --- articles/sequential-programming-for-node.js.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/articles/sequential-programming-for-node.js.markdown b/articles/sequential-programming-for-node.js.markdown index a68ad25..e97f008 100644 --- a/articles/sequential-programming-for-node.js.markdown +++ b/articles/sequential-programming-for-node.js.markdown @@ -1,7 +1,7 @@ Wait.for ======= -Node.js unavoidable style is to make everything that could **even begin to think about blocking** into a async function. +Node.js unavoidable style is to make everything that could **even begin to think about blocking** into an async function. This is a core node trait. You can't avoid it, you can't side-step it, Node will not forgive you. But... wouldn't be great to be able to call all this great async functions in a sequential/sync mode when the need arises?