Wind.js is Jeffrey Zhao's effort to simplify async development in JavaScript, which comes with a compiler as well as a set of libraries.
Wear equipments
I'm a game developer, and please allow me to use "Wear equipments" as an example.
When some player wanner to wear an equipment, we will do following steps:
Load player data from database
Check if the player has equipped a equipment at the same slot, if so take it off first
Load equipment data from database
Check the status and ownership of the equipment
Mark the equipment to be "equipped", set the slot of player to the equipment id
Save equipment data to database
Save player data to database
The first workable version
Wow, it's really badly smelling!
A lot of "if (err) return cb(err)", callbacks in callbacks, so could this ugly code look better?
Our dream
Some really brilliant guys (just like Anders) are just wondering if it is possible that code in sync way but comes with async benefits, just like this:
01
02
03
04
05
06
07
08
09
10
11
12
13
function equip(characterId, equipmentId, slot) {
var character = characters.get(characterId);
if (character.equipments[slot]) takeOff(characterId, slot);
var equipment = equipment.get(equipmentId);
if (!rules.isCharacterCanWearEquipment(character, equipment)) throw "PlayerCannotWearEquipment";
The language designer of C#, Mr. Anders, introduced two new keywords in to C# 5.0, which realised the dream with compiler technology.
Some sync C# code like this:
1
2
3
4
5
void DownloadData() {
var client = new WebClient();
var text = client.DownloadString(url);
Console.WriteLine(text);
}
With just a little bit of modifications:
1
2
3
4
5
async Task DownloadData() {
var client = new WebClient();
var text = await client.DownloadStringAsync(url);
Console.WriteLine(text);
}
It's almost the same, but the smart C# 5.0 compiler will compile this into 2 functions, and the latter one will executed async after the load of http request.
Let's move back to Wind.js
Yes, as what you are guessing, Wind.js (by Jeffrey Zhao) has taken this awesome feature to JavaScript with a fully handwritten compiler as well as a set of async libraries.
We can now transform our code in this way:
01
02
03
04
05
06
07
08
09
10
11
12
13
var equip = eval(Wind.compile('async', function(characterId, equipmentId, slot) {
var character = $await(characters.get(characterId));
if (character.equipments[slot]) return $await(takeOff(characterId, slot));
var equipment = $await(equipment.get(equipmentId));
if (!rules.isCharacterCanWearEquipment(character, equipment)) throw "PlayerCannotWearEquipment";
function loadError(cb) {
setTimeout(function() { cb("Some error"); }, 5000);
}
var loadDataAsync = Wind.Async.Binding.fromStandard(loadData);
var loadErrorAsync = Wind.Async.Binding.fromStandard(loadError);
var someTestFunction = eval(Wind.compile('async', function() {
var data = $await(loadDataAsync());
console.log('Some Result: ' + data);
try {
$await(loadErrorAsync());
} catch(e) {
console.log('Some Error Occurred: " + e);
}
}));
someTestFunction().start();
Done!
eval === evil?
Almost all textbooks about JavaScript or any other dynamic language that has eval (just like Python) will tell you that: DO NOT USE eval, cos. it's dangerous, dirty and slow!
So why doesn't Wind.js remove the dependency to eval? Will this be dangerous or slow?
If you wanner a simple answer? It is NO, NO, NO, NO!
Let's look back to the origin of the danger of eval: It's mainly because eval is usually used to simplify some process to user input data.
When you work with Wind.js, all code are written by you (ok, there will be your mate's code), and then compiled with the wind compiler, and then eval for just ONCE.
So, you code is only "eval"ed ONCE, and under your control, it's safe and as fast as your handwritten code.
We need your help!
Currently this project's only contributor is its author Jeffrey Zhao, and we need some more people to join us to do the following work:
Compose documents (both in English and Chinese)
Use Wind.js ^.^
Bug reports and advices
We really appreciate all kinds of contributions.
I've been happily using that ever since that project of mine that analyzed
scientific data out of a mongodb database where classic asynchronous
scripting became unbareable soon enough for that use case.
On Sat, Aug 18, 2012 at 4:10 PM, Tony Huang <cnwz...@gmail.com> wrote:
> Brief Introduction
> Wind.js is Jeffrey Zhao's effort to simplify async development in
> JavaScript, which comes with a compiler as well as a set of libraries.
> Wear equipments
> I'm a game developer, and please allow me to use "Wear equipments" as an
> example.
> When some player wanner to wear an equipment, we will do following steps:
> 1. Load player data from database
> 2. Check if the player has equipped a equipment at the same slot, if
> so take it off first
> 3. Load equipment data from database
> 4. Check the status and ownership of the equipment
> 5. Mark the equipment to be "equipped", set the slot of player to the
> equipment id
> 6. Save equipment data to database
> 7. Save player data to database
> Wow, it's really badly smelling!
> A lot of "if (err) return cb(err)", callbacks in callbacks, so could this
> ugly code look better?
> Our dream
> Some really brilliant guys (just like Anders) are just wondering if it is
> possible that code in sync way but comes with async benefits, just like
> this:
> 01
> 02
> 03
> 04
> 05
> 06
> 07
> 08
> 09
> 10
> 11
> 12
> 13
> function equip(characterId, equipmentId, slot) {
> var character = characters.get(characterId);
> if (character.equipments[slot]) takeOff(characterId, slot);
> var equipment = equipment.get(equipmentId);
> if (!rules.isCharacterCanWearEquipment(character, equipment)) throw
> "PlayerCannotWearEquipment";
> Yes, they did it!
> C# 5.0 and async, await keywords
> The language designer of C#, Mr. Anders, introduced two new keywords in to
> C# 5.0, which realised the dream with compiler technology.
> Some sync C# code like this:
> 1
> 2
> 3
> 4
> 5
> void DownloadData() {
> var client = new WebClient();
> var text = client.DownloadString(url);
> Console.WriteLine(text);
> }
> With just a little bit of modifications:
> 1
> 2
> 3
> 4
> 5
> async Task DownloadData() {
> var client = new WebClient();
> var text = await client.DownloadStringAsync(url);
> Console.WriteLine(text);
> }
> It's almost the same, but the smart C# 5.0 compiler will compile this into
> 2 functions, and the latter one will executed async after the load of http
> request.
> Let's move back to Wind.js
> Yes, as what you are guessing, Wind.js (by Jeffrey Zhao) has taken this
> awesome feature to JavaScript with a fully handwritten compiler as well as
> a set of async libraries.
> We can now transform our code in this way:
> 01
> 02
> 03
> 04
> 05
> 06
> 07
> 08
> 09
> 10
> 11
> 12
> 13
> var equip = eval(Wind.compile('async', function(characterId,
> equipmentId, slot) {
> var character = $await(characters.get(characterId));
> if (character.equipments[slot]) return $await(takeOff(characterId,
> slot));
> var equipment = $await(equipment.get(equipmentId));
> if (!rules.isCharacterCanWearEquipment(character, equipment)) throw
> "PlayerCannotWearEquipment";
> Almost all textbooks about JavaScript or any other dynamic language that
> has eval (just like Python) will tell you that: DO NOT USE eval, cos. it's
> dangerous, dirty and slow!
> So why doesn't Wind.js remove the dependency to eval? Will this be
> dangerous or slow?
> If you wanner a simple answer? It is NO, NO, NO, NO!
> Let's look back to the origin of the danger of eval: It's mainly because
> eval is usually used to simplify some process to user input data.
> When you work with Wind.js, all code are written by you (ok, there will be
> your mate's code), and then compiled with the wind compiler, and then eval
> for just ONCE.
> So, you code is only "eval"ed ONCE, and under your control, it's safe and
> as fast as your handwritten code.
> We need your help!
> Currently this project's only contributor is its author Jeffrey Zhao, and
> we need some more people to join us to do the following work:
> 1. Compose documents (both in English and Chinese)
> 2. Use Wind.js ^.^
> 3. Bug reports and advices
> We really appreciate all kinds of contributions.
> Project Metadata
> I've been happily using that ever since that project of mine that analyzed scientific data out of a mongodb database where classic asynchronous scripting became unbareable soon enough for that use case.
> Kind regards, Axel
> On Sat, Aug 18, 2012 at 4:10 PM, Tony Huang <cnwz...@gmail.com> wrote:
> Brief Introduction
> Wind.js is Jeffrey Zhao's effort to simplify async development in JavaScript, which comes with a compiler as well as a set of libraries.
> Wear equipments
> I'm a game developer, and please allow me to use "Wear equipments" as an example.
> When some player wanner to wear an equipment, we will do following steps:
> Load player data from database
> Check if the player has equipped a equipment at the same slot, if so take it off first
> Load equipment data from database
> Check the status and ownership of the equipment
> Mark the equipment to be "equipped", set the slot of player to the equipment id
> Save equipment data to database
> Save player data to database
> The first workable version
> Ok, let's implement this feature.
> 01
> 02
> 03
> 04
> 05
> 06
> 07
> 08
> 09
> 10
> 11
> 12
> 13
> 14
> 15
> 16
> 17
> 18
> 19
> 20
> 21
> 22
> 23
> function equip(characterId, equipmentId, slot, cb) {
> }
> Wow, it's really badly smelling!
> A lot of "if (err) return cb(err)", callbacks in callbacks, so could this ugly code look better?
> Our dream
> Some really brilliant guys (just like Anders) are just wondering if it is possible that code in sync way but comes with async benefits, just like this:
> 01
> 02
> 03
> 04
> 05
> 06
> 07
> 08
> 09
> 10
> 11
> 12
> 13
> function equip(characterId, equipmentId, slot) {
> var character = characters.get(characterId);
> if (character.equipments[slot]) takeOff(characterId, slot);
> var equipment = equipment.get(equipmentId);
> if (!rules.isCharacterCanWearEquipment(character, equipment)) throw "PlayerCannotWearEquipment";
> equipment.isEquipped = true;
> character.equipments[slot] = equipment.id;
> equipments.save(equipment);
> characters.save(character);
> }
> Yes, they did it!
> C# 5.0 and async, await keywords
> The language designer of C#, Mr. Anders, introduced two new keywords in to C# 5.0, which realised the dream with compiler technology.
> Some sync C# code like this:
> 1
> 2
> 3
> 4
> 5
> void DownloadData() {
> var client = new WebClient();
> var text = client.DownloadString(url);
> Console.WriteLine(text);
> }
> With just a little bit of modifications:
> 1
> 2
> 3
> 4
> 5
> async Task DownloadData() {
> var client = new WebClient();
> var text = await client.DownloadStringAsync(url);
> Console.WriteLine(text);
> }
> It's almost the same, but the smart C# 5.0 compiler will compile this into 2 functions, and the latter one will executed async after the load of http request.
> Let's move back to Wind.js
> Yes, as what you are guessing, Wind.js (by Jeffrey Zhao) has taken this awesome feature to JavaScript with a fully handwritten compiler as well as a set of async libraries.
> We can now transform our code in this way:
> 01
> 02
> 03
> 04
> 05
> 06
> 07
> 08
> 09
> 10
> 11
> 12
> 13
> var equip = eval(Wind.compile('async', function(characterId, equipmentId, slot) {
> var character = $await(characters.get(characterId));
> if (character.equipments[slot]) return $await(takeOff(characterId, slot));
> var equipment = $await(equipment.get(equipmentId));
> if (!rules.isCharacterCanWearEquipment(character, equipment)) throw "PlayerCannotWearEquipment";
> equipment.isEquipped = true;
> character.equipments[slot] = equipment.id;
> $await(equipments.save(equipment));
> $await(characters.save(character));
> }));
> Isn't it amazing and beautiful?!
> Get started with Wind.js on Node.js
> First, you need to install wind package with the npm tools:
> 1
> npm install wind
> And then, import the wind module to your source file:
> 1
> var Wind = require('wind');
> Tips: due to the limitation of current version, you need to name the imported module with exactly 'Wind'
> var loadDataAsync = Wind.Async.Binding.fromStandard(loadData);
> var loadErrorAsync = Wind.Async.Binding.fromStandard(loadError);
> var someTestFunction = eval(Wind.compile('async', function() {
> var data = $await(loadDataAsync());
> console.log('Some Result: ' + data);
> try {
> $await(loadErrorAsync());
> } catch(e) {
> console.log('Some Error Occurred: " + e);
> }
> }));
> someTestFunction().start();
> Done!
> eval === evil?
> Almost all textbooks about JavaScript or any other dynamic language that has eval (just like Python) will tell you that: DO NOT USE eval, cos. it's dangerous, dirty and slow!
> So why doesn't Wind.js remove the dependency to eval? Will this be dangerous or slow?
> If you wanner a simple answer? It is NO, NO, NO, NO!
> Let's look back to the origin of the danger of eval: It's mainly because eval is usually used to simplify some process to user input data.
> When you work with Wind.js, all code are written by you (ok, there will be your mate's code), and then compiled with the wind compiler, and then eval for just ONCE.
> So, you code is only "eval"ed ONCE, and under your control, it's safe and as fast as your handwritten code.
> We need your help!
> Currently this project's only contributor is its author Jeffrey Zhao, and we need some more people to join us to do the following work:
> Compose documents (both in English and Chinese)
> Use Wind.js ^.^
> Bug reports and advices
> We really appreciate all kinds of contributions.
I’m the author of the library. The main difference between Wind.js and fiber is Wind.js don’t need any extensions to the JavaScript engine, so it works directly in Node.js and also all kinds of JavaScript environment like browsers.
The code is easy to debug by attaching a debugger (e.g., eclipse), but the stack trace of an error cannot provide enough information of the failed place right now. The problem looks easier to address in browser since the dev environment is better than Node.js. The code would stop whenever it’s failed, and we can even click on the error in the browser and go to the failed place. I’m still thinking about how to provide a better diagnostic hint.
From: JeanHuguesRobert Sent: Saturday, August 18, 2012 10:29 PM
To: nodejs@googlegroups.com Cc: je...@live.cn Subject: [nodejs] Re: Wind.js : An elegant approach to asynchronies JavaScript
That's cool.
await & defer are also available in IcedCoffeeScript.
This is an alternative to fibers. I wonder which one provides easier to debug code (ie useful stack traces, etc).
-- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
They are similar. Some of you guys may remember a project called “Jscex” in the group, that’s just Wind.js before renaming. After that I decided to focus on community in China so most of the contribution went to Chinese. Now more and more project in China are trying to adopt the project since the past year.
The main differences between Wind.js and streamline.js are:
1. Wind.js has code transformation in runtime, it doesn’t need to have a daemon process to monitor the change and generate the target again. Everything finished with the execution of your code.
2. Wind.js generates much more human readable code. Streamline.js generates state machines but Wind.js generates monadic code with input source code as comments. For example:
// Original: function (interval) { while (true) { drawClock(new Date()); $await(Wind.Async.sleep(interval)); } }
3. Wind.js supports different async models directly with different supporting builders/libraries. With the default “async” builder, we write codes target to the build-in task models. We can also use the “promise” builder (even with “async” builder in parallel), then we can “$await” with Promise/A objects, and the object generates by the compiled functions can also be a promise directly. It only requires <40 lines of code to support your own async models. With a different builder we can even has a iteration generator like in JavaScript 1.7 or in Python.
From: Axel Kittenberger Sent: Saturday, August 18, 2012 10:42 PM
To: nodejs@googlegroups.com Cc: je...@live.cn Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
I've been happily using that ever since that project of mine that analyzed scientific data out of a mongodb database where classic asynchronous scripting became unbareable soon enough for that use case.
Kind regards, Axel
On Sat, Aug 18, 2012 at 4:10 PM, Tony Huang <cnwz...@gmail.com> wrote:
Brief Introduction
Wind.js is Jeffrey Zhao's effort to simplify async development in JavaScript, which comes with a compiler as well as a set of libraries.
Wear equipments
I'm a game developer, and please allow me to use "Wear equipments" as an example.
When some player wanner to wear an equipment, we will do following steps:
1.. Load player data from database 2.. Check if the player has equipped a equipment at the same slot, if so take it off first 3.. Load equipment data from database 4.. Check the status and ownership of the equipment 5.. Mark the equipment to be "equipped", set the slot of player to the equipment id 6.. Save equipment data to database 7.. Save player data to database
The first workable version
Ok, let's implement this feature.
Wow, it's really badly smelling!
A lot of "if (err) return cb(err)", callbacks in callbacks, so could this ugly code look better?
Our dream
Some really brilliant guys (just like Anders) are just wondering if it is possible that code in sync way but comes with async benefits, just like this:
01
02
03
04
05
06
07
08
09
10
11
12
13 function equip(characterId, equipmentId, slot) {
var character = characters.get(characterId);
if (character.equipments[slot]) takeOff(characterId, slot);
var equipment = equipment.get(equipmentId);
if (!rules.isCharacterCanWearEquipment(character, equipment)) throw "PlayerCannotWearEquipment";
C# 5.0 and async, await keywords
The language designer of C#, Mr. Anders, introduced two new keywords in to C# 5.0, which realised the dream with compiler technology.
Some sync C# code like this:
1
2
3
4
5 void DownloadData() {
var client = new WebClient();
var text = client.DownloadString(url);
Console.WriteLine(text);
}
With just a little bit of modifications:
1
2
3
4
5 async Task DownloadData() {
var client = new WebClient();
var text = await client.DownloadStringAsync(url);
Console.WriteLine(text);
}
It's almost the same, but the smart C# 5.0 compiler will compile this into 2 functions, and the latter one will executed async after the load of http request.
Let's move back to Wind.js
Yes, as what you are guessing, Wind.js (by Jeffrey Zhao) has taken this awesome feature to JavaScript with a fully handwritten compiler as well as a set of async libraries.
We can now transform our code in this way:
01
02
03
04
05
06
07
08
09
10
11
12
13 var equip = eval(Wind.compile('async', function(characterId, equipmentId, slot) {
var character = $await(characters.get(characterId));
if (character.equipments[slot]) return $await(takeOff(characterId, slot));
var equipment = $await(equipment.get(equipmentId));
if (!rules.isCharacterCanWearEquipment(character, equipment)) throw "PlayerCannotWearEquipment";
var loadDataAsync = Wind.Async.Binding.fromStandard(loadData);
var loadErrorAsync = Wind.Async.Binding.fromStandard(loadError);
var someTestFunction = eval(Wind.compile('async', function() {
var data = $await(loadDataAsync());
console.log('Some Result: ' + data);
try {
$await(loadErrorAsync());
} catch(e) {
console.log('Some Error Occurred: " + e);
}
}));
someTestFunction().start();
Done!
eval === evil?
Almost all textbooks about JavaScript or any other dynamic language that has eval (just like Python) will tell you that: DO NOT USE eval, cos. it's dangerous, dirty and slow!
So why doesn't Wind.js remove the dependency to eval? Will this be dangerous or slow?
BTW, we can also use CoffeeScript with Wind.js since CoffeeScript would finally become JavaScript (only a little tricks need to be applied). We can also use IcedCoffeeScript for async features, but Wind.js provide more than normal async support as I described in a separated mail, explaining the differences between Wind.js and Streamline.js.
From: Tony Huang Sent: Saturday, August 18, 2012 10:48 PM
To: nodejs@googlegroups.com Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
Love to do that:
I. Compared with IcedCoffeeScript and Streamline
It doesn't need a pre_compiler nor an alternate interpreter.
II. Compared with IcedCoffeeScript
You don't need to learn a new language with completely different syntax compared to JavaScript
On Aug 18, 2012, at 10:42 PM, Axel Kittenberger <axk...@gmail.com> wrote:
I've been happily using that ever since that project of mine that analyzed scientific data out of a mongodb database where classic asynchronous scripting became unbareable soon enough for that use case.
Kind regards, Axel
On Sat, Aug 18, 2012 at 4:10 PM, Tony Huang <cnwz...@gmail.com> wrote:
Brief Introduction
Wind.js is Jeffrey Zhao's effort to simplify async development in JavaScript, which comes with a compiler as well as a set of libraries.
Wear equipments
I'm a game developer, and please allow me to use "Wear equipments" as an example.
When some player wanner to wear an equipment, we will do following steps:
1.. Load player data from database 2.. Check if the player has equipped a equipment at the same slot, if so take it off first 3.. Load equipment data from database 4.. Check the status and ownership of the equipment 5.. Mark the equipment to be "equipped", set the slot of player to the equipment id 6.. Save equipment data to database 7.. Save player data to database
The first workable version
Ok, let's implement this feature.
Wow, it's really badly smelling!
A lot of "if (err) return cb(err)", callbacks in callbacks, so could this ugly code look better?
Our dream
Some really brilliant guys (just like Anders) are just wondering if it is possible that code in sync way but comes with async benefits, just like this:
01
02
03
04
05
06
07
08
09
10
11
12
13 function equip(characterId, equipmentId, slot) {
var character = characters.get(characterId);
if (character.equipments[slot]) takeOff(characterId, slot);
var equipment = equipment.get(equipmentId);
if (!rules.isCharacterCanWearEquipment(character, equipment)) throw "PlayerCannotWearEquipment";
C# 5.0 and async, await keywords
The language designer of C#, Mr. Anders, introduced two new keywords in to C# 5.0, which realised the dream with compiler technology.
Some sync C# code like this:
1
2
3
4
5 void DownloadData() {
var client = new WebClient();
var text = client.DownloadString(url);
Console.WriteLine(text);
}
With just a little bit of modifications:
1
2
3
4
5 async Task DownloadData() {
var client = new WebClient();
var text = await client.DownloadStringAsync(url);
Console.WriteLine(text);
}
It's almost the same, but the smart C# 5.0 compiler will compile this into 2 functions, and the latter one will executed async after the load of http request.
Let's move back to Wind.js
Yes, as what you are guessing, Wind.js (by Jeffrey Zhao) has taken this awesome feature to JavaScript with a fully handwritten compiler as well as a set of async libraries.
We can now transform our code in this way:
01
02
03
04
05
06
07
08
09
10
11
12
13 var equip = eval(Wind.compile('async', function(characterId, equipmentId, slot) {
var character = $await(characters.get(characterId));
if (character.equipments[slot]) return $await(takeOff(characterId, slot));
var equipment = $await(equipment.get(equipmentId));
if (!rules.isCharacterCanWearEquipment(character, equipment)) throw "PlayerCannotWearEquipment";
var loadDataAsync = Wind.Async.Binding.fromStandard(loadData);
var loadErrorAsync = Wind.Async.Binding.fromStandard(loadError);
var someTestFunction = eval(Wind.compile('async', function() {
var data = $await(loadDataAsync());
console.log('Some Result: ' + data);
try {
$await(loadErrorAsync());
} catch(e) {
console.log('Some Error Occurred: " + e);
}
}));
someTestFunction().start();
Done!
eval === evil?
Almost all textbooks about JavaScript or any other dynamic language that has eval (just like Python) will tell you that: DO NOT USE eval, cos. it's dangerous, dirty and slow!
So why doesn't Wind.js remove the dependency to eval? Will this be dangerous or slow?
If you wanner a simple answer? It is NO, NO, NO, NO!
Let's look back to the origin of the danger of eval: It's mainly because eval is usually used to simplify some process to user input data.
When you work with Wind.js, all code are written by you (ok, there will be your mate's code), and then compiled with the wind compiler, and then eval for just ONCE.
So, you code is only "eval"ed ONCE, and under your control, it's safe and as fast as your handwritten code.
We need your help!
Currently this project's only contributor is its author Jeffrey Zhao, and we need some more people to join us to do the following work:
1.. Compose documents (both in English and Chinese) 2.. Use Wind.js ^.^ 3.. Bug reports and advices
We really appreciate all kinds of contributions.
-- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
mailto:nodejs%2Bunsubscribe@googlegroups.com
For more options, visit this group at
...
1) Streamline does not have any kind of daemon process to monitor changes or whatever. You run it like an interpreter: just give the ._js or ._coffee extension to your source file and run it with _node or _coffee. You can also write shell scripts with it (with a shebang). Very much like CoffeeScript (give .cs extension and run with coffee). And like CS it gives you the option to precompile but that's something people usually do only at deployment time, not in the standard dev/debugging cycle.
2) Streamline does not generate state machines. It generates callback patterns that are similar to the ones a programmer would write manually (except that he would probably give up on try/catch). So the generated code is readable. Try it live on http://sage.github.com/streamlinejs/examples/streamlineMe/streamlineM...
3) Streamline gives you the choice between 3 code generation options: callbacks, fibers and generators.
On Saturday, August 18, 2012 5:04:44 PM UTC+2, Jeffrey Zhao wrote:
> They are similar. Some of you guys may remember a project called > “Jscex” in the group, that’s just Wind.js before renaming. After that I > decided to focus on community in China so most of the contribution went to > Chinese. Now more and more project in China are trying to adopt the project > since the past year.
> The main differences between Wind.js and streamline.js are:
> 1. Wind.js has code transformation in runtime, it doesn’t need to have a > daemon process to monitor the change and generate the target again. > Everything finished with the execution of your code.
> 2. Wind.js generates much more human readable code. Streamline.js > generates state machines but Wind.js generates monadic code with input > source code as comments. For example:
> 3. Wind.js supports different async models directly with different > supporting builders/libraries. With the default “async” builder, we write > codes target to the build-in task models. We can also use the “promise” > builder (even with “async” builder in parallel), then we can “$await” with > Promise/A objects, and the object generates by the compiled functions can > also be a promise directly. It only requires <40 lines of code to support > your own async models. With a different builder we can even has a iteration > generator like in JavaScript 1.7 or in Python.
> I've been happily using that ever since that project of mine that analyzed > scientific data out of a mongodb database where classic asynchronous > scripting became unbareable soon enough for that use case.
> Kind regards, Axel
> On Sat, Aug 18, 2012 at 4:10 PM, Tony Huang <cnw...@gmail.com<javascript:>
> > wrote:
>> Brief Introduction
>> Wind.js is Jeffrey Zhao's effort to simplify async development in >> JavaScript, which comes with a compiler as well as a set of libraries.
>> Wear equipments
>> I'm a game developer, and please allow me to use "Wear equipments" as an >> example.
>> When some player wanner to wear an equipment, we will do following steps:
>> 1. Load player data from database >> 2. Check if the player has equipped a equipment at the same slot, if >> so take it off first >> 3. Load equipment data from database >> 4. Check the status and ownership of the equipment >> 5. Mark the equipment to be "equipped", set the slot of player to the >> equipment id >> 6. Save equipment data to database >> 7. Save player data to database
>> Wow, it's really badly smelling!
>> A lot of "if (err) return cb(err)", callbacks in callbacks, so could this >> ugly code look better?
>> Our dream
>> Some really brilliant guys (just like Anders) are just wondering if it is >> possible that code in sync way but comes with async benefits, just like >> this:
>> 01
>> 02
>> 03
>> 04
>> 05
>> 06
>> 07
>> 08
>> 09
>> 10
>> 11
>> 12
>> 13
>> function equip(characterId, equipmentId, slot) {
>> var character = characters.get(characterId);
>> if (character.equipments[slot]) takeOff(characterId, slot);
>> var equipment = equipment.get(equipmentId);
>> if (!rules.isCharacterCanWearEquipment(character, equipment)) throw >> "PlayerCannotWearEquipment";
>> Yes, they did it!
>> C# 5.0 and async, await keywords
>> The language designer of C#, Mr. Anders, introduced two new keywords in >> to C# 5.0, which realised the dream with compiler technology.
>> Some sync C# code like this:
>> 1
>> 2
>> 3
>> 4
>> 5
>> void DownloadData() {
>> var client = new WebClient();
>> var text = client.DownloadString(url);
>> Console.WriteLine(text);
>> }
>> With just a little bit of modifications:
>> 1
>> 2
>> 3
>> 4
>> 5
>> async Task DownloadData() {
>> var client = new WebClient();
>> var text = await client.DownloadStringAsync(url);
>> Console.WriteLine(text);
>> }
>> It's almost the same, but the smart C# 5.0 compiler will compile this >> into 2 functions, and the latter one will executed async after the load of >> http request.
>> Let's move back to Wind.js
>> Yes, as what you are guessing, Wind.js (by Jeffrey Zhao) has taken this >> awesome feature to JavaScript with a fully handwritten compiler as well as >> a set of async libraries.
>> We can now transform our code in this way:
>> 01
>> 02
>> 03
>> 04
>> 05
>> 06
>> 07
>> 08
>> 09
>> 10
>> 11
>> 12
>> 13
>> var equip = eval(Wind.compile('async', function(characterId, >> equipmentId, slot) {
>> var character = $await(characters.get(characterId));
>> if (character.equipments[slot]) return $await(takeOff(characterId, >> slot));
>> var equipment = $await(equipment.get(equipmentId));
>> if (!rules.isCharacterCanWearEquipment(character, equipment)) throw >> "PlayerCannotWearEquipment";
1) I just thought in a big picture with Node.js and browsers, but you’re definitely correct in Node.js-only scenarios.
2) Please checkout the gist: https://gist.github.com/3388096. For a simple algorithm “bubble sort” with two “for” loops and an “if”, the code generated are quite different. The monadic code generated by Wind.js has nearly the same structure with the input code and has the original input beside it.
3) That’s not what I talked about, what I mean is Wind.js can work with different async models, like:
var bubbleSort = eval(Wind.compile("async", function (array) {
for (var i = 0; i < array.length; i++) {
for (var j = 0; j < array.length - i - 1; j++) {
var r = $await(compareAsync(array[j], array[j + 1]));
if (r > 0) $await(swapAsync(array, j, j + 1));
}
}
}))
Now we are using “async” builder so the $await accepts build-in tasks and bubbleSort() produces the some type of task instaces. We can also:
var bubleSort = eval(Wind.compile("promise", function (array) {
for (var i = 0; i < array.length; i++) {
for (var j = 0; j < array.length - i - 1; j++) {
var r = $await(compareAsync(array[j], array[j + 1]));
if (r > 0) $await(swapAsync(array, j, j + 1));
}
}
}))
With the “promise” builder the $await accepts Promise/A objects and bubbleSort() also produces Promise/A objects. So if the users have existing codes with Promise/A (or any other ones) as their async model, Wind.js can work directly with it.
From: Bruno Jouhier Sent: Sunday, August 19, 2012 12:09 AM
To: nodejs@googlegroups.com Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
Hi Jeffrey,
A few corrections regarding streamline:
1) Streamline does not have any kind of daemon process to monitor changes or whatever. You run it like an interpreter: just give the ._js or ._coffee extension to your source file and run it with _node or _coffee. You can also write shell scripts with it (with a shebang). Very much like CoffeeScript (give .cs extension and run with coffee). And like CS it gives you the option to precompile but that's something people usually do only at deployment time, not in the standard dev/debugging cycle.
2) Streamline does not generate state machines. It generates callback patterns that are similar to the ones a programmer would write manually (except that he would probably give up on try/catch). So the generated code is readable. Try it live on http://sage.github.com/streamlinejs/examples/streamlineMe/streamlineM...
3) Streamline gives you the choice between 3 code generation options: callbacks, fibers and generators.
Bruno
On Saturday, August 18, 2012 5:04:44 PM UTC+2, Jeffrey Zhao wrote:
They are similar. Some of you guys may remember a project called “Jscex” in the group, that’s just Wind.js before renaming. After that I decided to focus on community in China so most of the contribution went to Chinese. Now more and more project in China are trying to adopt the project since the past year.
The main differences between Wind.js and streamline.js are:
1. Wind.js has code transformation in runtime, it doesn’t need to have a daemon process to monitor the change and generate the target again. Everything finished with the execution of your code.
2. Wind.js generates much more human readable code. Streamline.js generates state machines but Wind.js generates monadic code with input source code as comments. For example:
// Original: function (interval) { while (true) { drawClock(new Date()); $await(Wind.Async.sleep(interval)); } }
3. Wind.js supports different async models directly with different supporting builders/libraries. With the default “async” builder, we write codes target to the build-in task models. We can also use the “promise” builder (even with “async” builder in parallel), then we can “$await” with Promise/A objects, and the object generates by the compiled functions can also be a promise directly. It only requires <40 lines of code to support your own async models. With a different builder we can even has a iteration generator like in JavaScript 1.7 or in Python.
From: Axel Kittenberger Sent: Saturday, August 18, 2012 10:42 PM
To: nod...@googlegroups.com Cc: je...@live.cn Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
I've been happily using that ever since that project of mine that analyzed scientific data out of a mongodb database where classic asynchronous scripting became unbareable soon enough for that use case.
Kind regards, Axel
On Sat, Aug 18, 2012 at 4:10 PM, Tony Huang <cnw...@gmail.com> wrote:
Brief Introduction
Wind.js is Jeffrey Zhao's effort to simplify async development in JavaScript, which comes with a compiler as well as a set of libraries.
Wear equipments
I'm a game developer, and please allow me to use "Wear equipments" as an example.
When some player wanner to wear an equipment, we will do following steps:
1.. Load player data from database 2.. Check if the player has equipped a equipment at the same slot, if so take it off first 3.. Load equipment data from database 4.. Check the status and ownership of the equipment 5.. Mark the equipment to be "equipped", set the slot of player to the equipment id 6.. Save equipment data to database 7.. Save player data to database
The first workable version
Ok, let's implement this feature.
Wow, it's really badly smelling!
A lot of "if (err) return cb(err)", callbacks in callbacks, so could this ugly code look better?
Our dream
Some really brilliant guys (just like Anders) are just wondering if it is possible that code in sync way but comes with async benefits, just like this:
01
02
03
04
05
06
07
08
09
10
11
12
13 function equip(characterId, equipmentId, slot) {
var character = characters.get(characterId);
if (character.equipments[slot]) takeOff(characterId, slot);
var equipment = equipment.get(equipmentId);
if (!rules.isCharacterCanWearEquipment(character, equipment)) throw "PlayerCannotWearEquipment";
C# 5.0 and async, await keywords
The language designer of C#, Mr. Anders, introduced two new keywords in to C# 5.0, which realised the dream with compiler technology.
Some sync C# code like this:
1
2
3
4
5 void DownloadData() {
var client = new WebClient();
var text = client.DownloadString(url);
Console.WriteLine(text);
}
...
Regarding your point 1), there is no difference in the browser: streamline provides a transform API which is just equivalent to the Wind.compile API. I don't understand your point.
In callback mode streamline generates code that is a bit hairier but that's primarily because it sets up a trampoline. So nothing bad will happen if the callback is called synchronously. Does wind.js deal with this case? (async calls that call their callback synchronously)
With the --fibers options, the generated code is much more compact and readable than with either streamline/callbacks or wind.js:
for (var i = 0; i < array.length; i++) {
for (var j = 0; j < array.length - i - 1; j++) {
var r = fstreamline__.invoke(null, compareAsync, [array[j], array[j + 1], _], 2);
if (r > 0) fstreamline__.invoke(null, swapAsync, [array, j, j + 1, _], 3);
}
}
On Saturday, August 18, 2012 6:30:09 PM UTC+2, Jeffrey Zhao wrote:
> Thanks for the correction, Bruno!
> 1) I just thought in a big picture with Node.js and browsers, but you’re > definitely correct in Node.js-only scenarios.
> 2) Please checkout the gist: https://gist.github.com/3388096. For a > simple algorithm “bubble sort” with two “for” loops and an “if”, the code > generated are quite different. The monadic code generated by Wind.js has > nearly the same structure with the input code and has the original input > beside it.
> 3) That’s not what I talked about, what I mean is Wind.js can work with > different async models, like:
> var bubbleSort = eval(Wind.compile("async", function (array) {
> for (var i = 0; i < array.length; i++) {
> for (var j = 0; j < array.length - i - 1; j++) {
> var r = $await(compareAsync(array[j], array[j + 1]));
> if (r > 0) $await(swapAsync(array, j, j + 1));
> }
> }
> }))
> Now we are using “async” builder so the $await accepts build-in tasks and > bubbleSort() produces the some type of task instaces. We can also:
> var bubleSort = eval(Wind.compile("promise", function (array) {
> for (var i = 0; i < array.length; i++) {
> for (var j = 0; j < array.length - i - 1; j++) {
> var r = $await(compareAsync(array[j], array[j + 1]));
> if (r > 0) $await(swapAsync(array, j, j + 1));
> }
> }
> }))
> With the “promise” builder the $await accepts Promise/A objects and > bubbleSort() also produces Promise/A objects. So if the users have existing > codes with Promise/A (or any other ones) as their async model, Wind.js can > work directly with it.
> *From:* Bruno Jouhier <javascript:> > *Sent:* Sunday, August 19, 2012 12:09 AM
> *To:* nod...@googlegroups.com <javascript:> > *Subject:* Re: [nodejs] Wind.js : An elegant approach to asynchronies > JavaScript
> Hi Jeffrey,
> A few corrections regarding streamline:
> 1) Streamline does not have any kind of daemon process to monitor changes > or whatever. You run it like an interpreter: just give the ._js or ._coffee > extension to your source file and run it with _node or _coffee. You can > also write shell scripts with it (with a shebang). Very much like > CoffeeScript (give .cs extension and run with coffee). And like CS it gives > you the option to precompile but that's something people usually do only at > deployment time, not in the standard dev/debugging cycle.
> 2) Streamline does not generate state machines. It generates callback > patterns that are similar to the ones a programmer would write manually > (except that he would probably give up on try/catch). So the generated code > is readable. Try it live on > http://sage.github.com/streamlinejs/examples/streamlineMe/streamlineM...
> 3) Streamline gives you the choice between 3 code generation options: > callbacks, fibers and generators.
> Bruno
> On Saturday, August 18, 2012 5:04:44 PM UTC+2, Jeffrey Zhao wrote:
>> They are similar. Some of you guys may remember a project called >> “Jscex” in the group, that’s just Wind.js before renaming. After that I >> decided to focus on community in China so most of the contribution went to >> Chinese. Now more and more project in China are trying to adopt the project >> since the past year.
>> The main differences between Wind.js and streamline.js are:
>> 1. Wind.js has code transformation in runtime, it doesn’t need to have a >> daemon process to monitor the change and generate the target again. >> Everything finished with the execution of your code.
>> 2. Wind.js generates much more human readable code. Streamline.js >> generates state machines but Wind.js generates monadic code with input >> source code as comments. For example:
>> 3. Wind.js supports different async models directly with different >> supporting builders/libraries. With the default “async” builder, we write >> codes target to the build-in task models. We can also use the “promise” >> builder (even with “async” builder in parallel), then we can “$await” with >> Promise/A objects, and the object generates by the compiled functions can >> also be a promise directly. It only requires <40 lines of code to support >> your own async models. With a different builder we can even has a iteration >> generator like in JavaScript 1.7 or in Python.
>> I've been happily using that ever since that project of mine that >> analyzed scientific data out of a mongodb database where classic >> asynchronous scripting became unbareable soon enough for that use case.
>> Kind regards, Axel
>> On Sat, Aug 18, 2012 at 4:10 PM, Tony Huang <cnw...@gmail.com> wrote:
>>> Brief Introduction
>>> Wind.js is Jeffrey Zhao's effort to simplify async development in >>> JavaScript, which comes with a compiler as well as a set of libraries.
>>> Wear equipments
>>> I'm a game developer, and please allow me to use "Wear equipments" as an >>> example.
>>> When some player wanner to wear an equipment, we will do following steps:
>>> 1. Load player data from database >>> 2. Check if the player has equipped a equipment at the same slot, if >>> so take it off first >>> 3. Load equipment data from database >>> 4. Check the status and ownership of the equipment >>> 5. Mark the equipment to be "equipped", set the slot of player to >>> the equipment id >>> 6. Save equipment data to database >>> 7. Save player data to database
>>> Wow, it's really badly smelling!
>>> A lot of "if (err) return cb(err)", callbacks in callbacks, so could >>> this ugly code look better?
>>> Our dream
>>> Some really brilliant guys (just like Anders) are just wondering
}));
On Saturday, August 18, 2012 6:53:54 PM UTC+2, Bruno Jouhier wrote:
> Regarding your point 1), there is no difference in the browser: streamline > provides a transform API which is just equivalent to the Wind.compile API. > I don't understand your point.
> In callback mode streamline generates code that is a bit hairier but > that's primarily because it sets up a trampoline. So nothing bad will > happen if the callback is called synchronously. Does wind.js deal with this > case? (async calls that call their callback synchronously)
> With the --fibers options, the generated code is much more compact and > readable than with either streamline/callbacks or wind.js:
> for (var i = 0; i < array.length; i++) {
> for (var j = 0; j < array.length - i - 1; j++) {
> var r = fstreamline__.invoke(null, compareAsync, [array[j], > array[j + 1], _], 2);
> if (r > 0) fstreamline__.invoke(null, swapAsync, [array, j, j > + 1, _], 3);
> }
> }
> }, 1);
> }, 0).call(this, function(err) {
> if (err) throw err;
> }));
> Bruno
> On Saturday, August 18, 2012 6:30:09 PM UTC+2, Jeffrey Zhao wrote:
>> Thanks for the correction, Bruno!
>> 1) I just thought in a big picture with Node.js and browsers, but you’re >> definitely correct in Node.js-only scenarios.
>> 2) Please checkout the gist: https://gist.github.com/3388096. For a >> simple algorithm “bubble sort” with two “for” loops and an “if”, the code >> generated are quite different. The monadic code generated by Wind.js has >> nearly the same structure with the input code and has the original input >> beside it.
>> 3) That’s not what I talked about, what I mean is Wind.js can work with >> different async models, like:
>> var bubbleSort = eval(Wind.compile("async", function (array) {
>> for (var i = 0; i < array.length; i++) {
>> for (var j = 0; j < array.length - i - 1; j++) {
>> var r = $await(compareAsync(array[j], array[j + 1]));
>> if (r > 0) $await(swapAsync(array, j, j + 1));
>> }
>> }
>> }))
>> Now we are using “async” builder so the $await accepts build-in tasks and >> bubbleSort() produces the some type of task instaces. We can also:
>> var bubleSort = eval(Wind.compile("promise", function (array) {
>> for (var i = 0; i < array.length; i++) {
>> for (var j = 0; j < array.length - i - 1; j++) {
>> var r = $await(compareAsync(array[j], array[j + 1]));
>> if (r > 0) $await(swapAsync(array, j, j + 1));
>> }
>> }
>> }))
>> With the “promise” builder the $await accepts Promise/A objects and >> bubbleSort() also produces Promise/A objects. So if the users have existing >> codes with Promise/A (or any other ones) as their async model, Wind.js can >> work directly with it.
>> *From:* Bruno Jouhier >> *Sent:* Sunday, August 19, 2012 12:09 AM
>> *To:* nod...@googlegroups.com >> *Subject:* Re: [nodejs] Wind.js : An elegant approach to asynchronies >> JavaScript
>> Hi Jeffrey,
>> A few corrections regarding streamline:
>> 1) Streamline does not have any kind of daemon process to monitor changes >> or whatever. You run it like an interpreter: just give the ._js or ._coffee >> extension to your source file and run it with _node or _coffee. You can >> also write shell scripts with it (with a shebang). Very much like >> CoffeeScript (give .cs extension and run with coffee). And like CS it gives >> you the option to precompile but that's something people usually do only at >> deployment time, not in the standard dev/debugging cycle.
>> 2) Streamline does not generate state machines. It generates callback >> patterns that are similar to the ones a programmer would write manually >> (except that he would probably give up on try/catch). So the generated code >> is readable. Try it live on >> http://sage.github.com/streamlinejs/examples/streamlineMe/streamlineM...
>> 3) Streamline gives you the choice between 3 code generation options: >> callbacks, fibers and generators.
>> Bruno
>> On Saturday, August 18, 2012 5:04:44 PM UTC+2, Jeffrey Zhao wrote:
>>> They are similar. Some of you guys may remember a project called >>> “Jscex” in the group, that’s just Wind.js before renaming. After that I >>> decided to focus on community in China so most of the contribution went to >>> Chinese. Now more and more project in China are trying to adopt the project >>> since the past year.
>>> The main differences between Wind.js and streamline.js are:
>>> 1. Wind.js has code transformation in runtime, it doesn’t need to have a >>> daemon process to monitor the change and generate the target again. >>> Everything finished with the execution of your code.
>>> 2. Wind.js generates much more human readable code. Streamline.js >>> generates state machines but Wind.js generates monadic code with input >>> source code as comments. For example:
>>> 3. Wind.js supports different async models directly with different >>> supporting builders/libraries. With the default “async” builder, we write >>> codes target to the build-in task models. We can also use the “promise” >>> builder (even with “async” builder in parallel), then we can “$await” with >>> Promise/A objects, and the object generates by the compiled functions can >>> also be a promise directly. It only requires <40 lines of code to support >>> your own async models. With a different builder we can even has a iteration >>> generator like in JavaScript 1.7 or in Python.
>>> I've been happily using that ever since that project of mine that >>> analyzed scientific data out of a mongodb database where classic >>> asynchronous scripting became unbareable soon enough for that use case.
>>> Kind regards, Axel
>>> On Sat, Aug 18, 2012 at 4:10 PM, Tony Huang <cnw...@gmail.com> wrote:
>>>> Brief Introduction
>>>> Wind.js is Jeffrey Zhao's effort to simplify async development in >>>> JavaScript, which comes with a compiler as well as a set of libraries.
>>>> Wear equipments
>>>> I'm a game developer, and please allow me to use "Wear equipments" as >>>> an example.
>>>> When some player wanner to wear an equipment, we will do following >>>> steps:
>>>> 1. Load player data from database >>>> 2. Check if the player has equipped a equipment at the same slot, >>>> if so take it off first >>>> 3. Load equipment data from database >>>> 4. Check the status and ownership of the equipment >>>> 5. Mark the equipment to be "equipped", set the slot of player to >>>> the equipment id >>>> 6. Save equipment data to database >>>> 7. Save player data to database
On Sat, Aug 18, 2012 at 6:53 PM, Bruno Jouhier <bjouh...@gmail.com> wrote:
> Regarding your point 1), there is no difference in the browser: streamline
> provides a transform API which is just equivalent to the Wind.compile API.
> I don't understand your point.
I consider more diversity generally a good sign. For example regarding one
of my free software projects to my knowledge there is no other alive free
software project out there that uses a similar approach - to my dismay. One
or the other time something did blink up and when I noted it I took the
chance to analyze their code, and get new inspiration and ideas.
So wind got a eval() inside the code. Its not that a big thing to me,
certainly achievable with streamline as well, since its javascript
itself. Maybe in streamline we're missing a predefined or requireable
_eval() call to streamline generate/eval streamlined code on the fly? I
haven't yet felt the need for it, but it sounds like a completion to the
API.
Input source as comments - as far it isn't there it might be a useful idea
to some? I use streamline always as -lp to preserve lines, so for the
generated code you get a 1:1 relation to the source code.
Wrapping everything in effectively an eval() call has possibly its merrits,
since you can call node directly (with parameters to it, its possible with
streamline but needs a little more complicated call to node). Or code that
is not streamlined/(un)winded is not touched at all.
I wonder which tool produces the better stack traces? I consider the eval
call might be a drawback to that. Other than that still looking for a good
comperison that actually doesn't do the usual thing about streamline
telling stuff about it, thats just not true.
As far as I can tell, the differences between Jsex/Wind and Streamline (and
for that matter IcedCoffeeScript and TameJS) are largely superficial. The
tough part is the compiler, which you can only do so many ways; all other
features are just bells and whistles which could be implemented by a user
of any library. I prefer Streamline since it seems like Bruno has done a
really good job under the hood and it seems cleaner overall. Though
personally I just use Futures from node-fibers directly (I mean I'm the
author after all).
On Saturday, August 18, 2012, Axel Kittenberger wrote:
> On Sat, Aug 18, 2012 at 6:53 PM, Bruno Jouhier <bjouh...@gmail.com<javascript:_e({}, 'cvml', 'bjouh...@gmail.com');>
> > wrote:
>> Regarding your point 1), there is no difference in the browser:
>> streamline provides a transform API which is just equivalent to the
>> Wind.compile API. I don't understand your point.
> I consider more diversity generally a good sign. For example regarding one
> of my free software projects to my knowledge there is no other alive free
> software project out there that uses a similar approach - to my dismay. One
> or the other time something did blink up and when I noted it I took the
> chance to analyze their code, and get new inspiration and ideas.
> So wind got a eval() inside the code. Its not that a big thing to me,
> certainly achievable with streamline as well, since its javascript
> itself. Maybe in streamline we're missing a predefined or requireable
> _eval() call to streamline generate/eval streamlined code on the fly? I
> haven't yet felt the need for it, but it sounds like a completion to the
> API.
> Input source as comments - as far it isn't there it might be a useful idea
> to some? I use streamline always as -lp to preserve lines, so for the
> generated code you get a 1:1 relation to the source code.
> Wrapping everything in effectively an eval() call has possibly its
> merrits, since you can call node directly (with parameters to it, its
> possible with streamline but needs a little more complicated call to node).
> Or code that is not streamlined/(un)winded is not touched at all.
> I wonder which tool produces the better stack traces? I consider the eval
> call might be a drawback to that. Other than that still looking for a good
> comperison that actually doesn't do the usual thing about streamline
> telling stuff about it, thats just not true.
> --
> Job Board: http://jobs.nodejs.org/ > Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com<javascript:_e({}, 'cvml', 'nodejs@googlegroups.com');>
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml',
> 'nodejs%2Bunsubscribe@googlegroups.com');>
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
1) I don’t know there’s a transform API in streamline, sorry. If there’s one then using a eval() can do exactly the samething with Wind.js
2) What do you mean callback is called synchronously? If you don’t have any async operations in the method body, Wind.js would generate a async task which would be executed synchronously. And yes, with the filter support, we can generate much more compact and readable code. Considering the case of Node.js, I think we can easily add the support in Wind.js as an option.
From: Bruno Jouhier Sent: Sunday, August 19, 2012 12:53 AM
To: nodejs@googlegroups.com Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
Regarding your point 1), there is no difference in the browser: streamline provides a transform API which is just equivalent to the Wind.compile API. I don't understand your point.
In callback mode streamline generates code that is a bit hairier but that's primarily because it sets up a trampoline. So nothing bad will happen if the callback is called synchronously. Does wind.js deal with this case? (async calls that call their callback synchronously)
With the --fibers options, the generated code is much more compact and readable than with either streamline/callbacks or wind.js:
for (var i = 0; i < array.length; i++) {
for (var j = 0; j < array.length - i - 1; j++) {
var r = fstreamline__.invoke(null, compareAsync, [array[j], array[j + 1], _], 2);
if (r > 0) fstreamline__.invoke(null, swapAsync, [array, j, j + 1, _], 3);
}
}
}, 1);
}, 0).call(this, function(err) {
if (err) throw err;
}));
Bruno
On Saturday, August 18, 2012 6:30:09 PM UTC+2, Jeffrey Zhao wrote:
Thanks for the correction, Bruno!
1) I just thought in a big picture with Node.js and browsers, but you’re definitely correct in Node.js-only scenarios.
2) Please checkout the gist: https://gist.github.com/3388096. For a simple algorithm “bubble sort” with two “for” loops and an “if”, the code generated are quite different. The monadic code generated by Wind.js has nearly the same structure with the input code and has the original input beside it.
3) That’s not what I talked about, what I mean is Wind.js can work with different async models, like:
var bubbleSort = eval(Wind.compile("async", function (array) {
for (var i = 0; i < array.length; i++) {
for (var j = 0; j < array.length - i - 1; j++) {
var r = $await(compareAsync(array[j], array[j + 1]));
if (r > 0) $await(swapAsync(array, j, j + 1));
}
}
}))
Now we are using “async” builder so the $await accepts build-in tasks and bubbleSort() produces the some type of task instaces. We can also:
var bubleSort = eval(Wind.compile("promise", function (array) {
for (var i = 0; i < array.length; i++) {
for (var j = 0; j < array.length - i - 1; j++) {
var r = $await(compareAsync(array[j], array[j + 1]));
if (r > 0) $await(swapAsync(array, j, j + 1));
}
}
}))
With the “promise” builder the $await accepts Promise/A objects and bubbleSort() also produces Promise/A objects. So if the users have existing codes with Promise/A (or any other ones) as their async model, Wind.js can work directly with it.
From: Bruno Jouhier Sent: Sunday, August 19, 2012 12:09 AM
To: nod...@googlegroups.com Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
Hi Jeffrey,
A few corrections regarding streamline:
1) Streamline does not have any kind of daemon process to monitor changes or whatever. You run it like an interpreter: just give the ._js or ._coffee extension to your source file and run it with _node or _coffee. You can also write shell scripts with it (with a shebang). Very much like CoffeeScript (give .cs extension and run with coffee). And like CS it gives you the option to precompile but that's something people usually do only at deployment time, not in the standard dev/debugging cycle.
2) Streamline does not generate state machines. It generates callback patterns that are similar to the ones a programmer would write manually (except that he would probably give up on try/catch). So the generated code is readable. Try it live on http://sage.github.com/streamlinejs/examples/streamlineMe/streamlineM...
3) Streamline gives you the choice between 3 code generation options: callbacks, fibers and generators.
Bruno
On Saturday, August 18, 2012 5:04:44 PM UTC+2, Jeffrey Zhao wrote: They are similar. Some of you guys may remember a project called “Jscex” in the group, that’s just Wind.js before renaming. After that I decided to focus on community in China so most of the contribution went to Chinese. Now more and more project in China are trying to adopt the project since the past year.
The main differences between Wind.js and streamline.js are:
1. Wind.js has code transformation in runtime, it doesn’t need to have a daemon process to monitor the change and generate the target again. Everything finished with the execution of your code.
2. Wind.js generates much more human readable code. Streamline.js generates state machines but Wind.js generates monadic code with input source code as comments. For example:
// Original: function (interval) { while (true) { drawClock(new Date()); $await(Wind.Async.sleep(interval)); } }
3. Wind.js supports different async models directly with different supporting builders/libraries. With the default “async” builder, we write codes target to the build-in task models. We can also use the “promise” builder (even with “async” builder in parallel), then we can “$await” with Promise/A objects, and the object generates by the compiled functions can also be a promise directly. It only requires <40 lines of code to support your own async models. With a different builder we can even has a iteration generator like in JavaScript 1.7 or in Python.
From: Axel Kittenberger Sent: Saturday, August 18, 2012 10:42 PM
To: nod...@googlegroups.com Cc: je...@live.cn Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
I've been happily using that ever since that project of mine that analyzed scientific data out of a mongodb database where classic asynchronous scripting became unbareable soon enough for that use case.
Kind regards, Axel
On Sat, Aug 18, 2012 at 4:10 PM, Tony Huang <cnw...@gmail.com> wrote:
Brief Introduction
Wind.js is Jeffrey Zhao's effort to simplify async development in JavaScript, which comes with a compiler as well as a set of libraries.
Wear equipments
I'm a game developer, and please allow me to use "Wear equipments" as an example.
When some player wanner to wear an equipment, we will do following steps:
1.. Load player data from database 2.. Check if the player has equipped a equipment at the same slot, if so take it off first 3.. Load equipment data from database 4.. Check the status and ownership of the equipment 5.. Mark the equipment to be "equipped", set the slot of player to the equipment id 6.. Save equipment data to database 7.. Save player data to database
The first workable version
Ok, let's implement this feature.
1) Compared to Streamline, Wind.js has better syntax
It's easy to compare which one is more readable or native:
Streamline uses a lot of underlines which makes program less readable.
Instead, The await syntax of Wind.js is more like native language.
2) Compared to CoffeeScript/IcedCoffeeScript/Streamline, Wind.js doesn't
need pre-compilation process
One of the most awesome feature of node.js is it doesn't need compilation.
As a result, I can modify the code and test it without any delay, which
provide better productivity.
At the deploy time, it's easy to just create a tarball of current source
code, upload to the server, and deploy it.
If we use coffeescript or streamline, I have to do either:
a, Deploy _node to the server (only for streamline)
b, Precompile code into javascript
3) Wind.js has better compatibility
I develop my node.js project with the WebStrom IDE from JetBrains. The
implementation of Wind made it easy to work with any existing js IDEs. Code
completion is just working seamlessly.
At the same time, Wind.js is easily to take effect in existing codes. You
don't need to completely rewrite your code in CoffeeScript, or change the
file extension to _js
Hope this will be helpful, thank you.
On Sun, Aug 19, 2012 at 3:37 AM, Marcel Laverdet <mar...@laverdet.com>wrote:
> As far as I can tell, the differences between Jsex/Wind and Streamline
> (and for that matter IcedCoffeeScript and TameJS) are largely superficial.
> The tough part is the compiler, which you can only do so many ways; all
> other features are just bells and whistles which could be implemented by a
> user of any library. I prefer Streamline since it seems like Bruno has done
> a really good job under the hood and it seems cleaner overall. Though
> personally I just use Futures from node-fibers directly (I mean I'm the
> author after all).
> On Saturday, August 18, 2012, Axel Kittenberger wrote:
>> On Sat, Aug 18, 2012 at 6:53 PM, Bruno Jouhier <bjouh...@gmail.com>wrote:
>>> Regarding your point 1), there is no difference in the browser:
>>> streamline provides a transform API which is just equivalent to the
>>> Wind.compile API. I don't understand your point.
>> I consider more diversity generally a good sign. For example regarding
>> one of my free software projects to my knowledge there is no other alive
>> free software project out there that uses a similar approach - to my
>> dismay. One or the other time something did blink up and when I noted it I
>> took the chance to analyze their code, and get new inspiration and ideas.
>> So wind got a eval() inside the code. Its not that a big thing to me,
>> certainly achievable with streamline as well, since its javascript
>> itself. Maybe in streamline we're missing a predefined or requireable
>> _eval() call to streamline generate/eval streamlined code on the fly? I
>> haven't yet felt the need for it, but it sounds like a completion to the
>> API.
>> Input source as comments - as far it isn't there it might be a useful
>> idea to some? I use streamline always as -lp to preserve lines, so for the
>> generated code you get a 1:1 relation to the source code.
>> Wrapping everything in effectively an eval() call has possibly its
>> merrits, since you can call node directly (with parameters to it, its
>> possible with streamline but needs a little more complicated call to node).
>> Or code that is not streamlined/(un)winded is not touched at all.
>> I wonder which tool produces the better stack traces? I consider the eval
>> call might be a drawback to that. Other than that still looking for a good
>> comperison that actually doesn't do the usual thing about streamline
>> telling stuff about it, thats just not true.
> 1) Compared to Streamline, Wind.js has better syntax
> It's easy to compare which one is more readable or native:
> Streamline uses a lot of underlines which makes program less readable.
> Instead, The await syntax of Wind.js is more like native language.
> 2) Compared to CoffeeScript/IcedCoffeeScript/Streamline, Wind.js doesn't
> need pre-compilation process
> One of the most awesome feature of node.js is it doesn't need compilation.
> As a result, I can modify the code and test it without any delay, which
> provide better productivity.
> At the deploy time, it's easy to just create a tarball of current source
> code, upload to the server, and deploy it.
> If we use coffeescript or streamline, I have to do either:
> a, Deploy _node to the server (only for streamline)
> b, Precompile code into javascript
> 3) Wind.js has better compatibility
> I develop my node.js project with the WebStrom IDE from JetBrains. The
> implementation of Wind made it easy to work with any existing js IDEs. Code
> completion is just working seamlessly.
> At the same time, Wind.js is easily to take effect in existing codes. You
> don't need to completely rewrite your code in CoffeeScript, or change the
> file extension to _js
> Hope this will be helpful, thank you.
> On Sun, Aug 19, 2012 at 3:37 AM, Marcel Laverdet <mar...@laverdet.com>wrote:
> > As far as I can tell, the differences between Jsex/Wind and Streamline
> > (and for that matter IcedCoffeeScript and TameJS) are largely superficial.
> > The tough part is the compiler, which you can only do so many ways; all
> > other features are just bells and whistles which could be implemented by a
> > user of any library. I prefer Streamline since it seems like Bruno has done
> > a really good job under the hood and it seems cleaner overall. Though
> > personally I just use Futures from node-fibers directly (I mean I'm the
> > author after all).
> > On Saturday, August 18, 2012, Axel Kittenberger wrote:
> >> On Sat, Aug 18, 2012 at 6:53 PM, Bruno Jouhier <bjouh...@gmail.com>wrote:
> >>> Regarding your point 1), there is no difference in the browser:
> >>> streamline provides a transform API which is just equivalent to the
> >>> Wind.compile API. I don't understand your point.
> >> I consider more diversity generally a good sign. For example regarding
> >> one of my free software projects to my knowledge there is no other alive
> >> free software project out there that uses a similar approach - to my
> >> dismay. One or the other time something did blink up and when I noted it I
> >> took the chance to analyze their code, and get new inspiration and ideas.
> >> So wind got a eval() inside the code. Its not that a big thing to me,
> >> certainly achievable with streamline as well, since its javascript
> >> itself. Maybe in streamline we're missing a predefined or requireable
> >> _eval() call to streamline generate/eval streamlined code on the fly? I
> >> haven't yet felt the need for it, but it sounds like a completion to the
> >> API.
> >> Input source as comments - as far it isn't there it might be a useful
> >> idea to some? I use streamline always as -lp to preserve lines, so for the
> >> generated code you get a 1:1 relation to the source code.
> >> Wrapping everything in effectively an eval() call has possibly its
> >> merrits, since you can call node directly (with parameters to it, its
> >> possible with streamline but needs a little more complicated call to node).
> >> Or code that is not streamlined/(un)winded is not touched at all.
> >> I wonder which tool produces the better stack traces? I consider the eval
> >> call might be a drawback to that. Other than that still looking for a good
> >> comperison that actually doesn't do the usual thing about streamline
> >> telling stuff about it, thats just not true.
On Sun, Aug 19, 2012 at 3:24 AM, Jeffrey Zhao <je...@live.com> wrote:
> 1) I don’t know there’s a transform API in streamline, sorry. If
> there’s one then using a eval() can do exactly the samething with Wind.js
For example using callbacks:
-----
var transform = require('streamline/lib/callbacks/transform');
x( function( err, ret ) {
if (err) { throw err; }
console.log('return: ' + ret);
});
-------
> 2) What do you mean callback is called synchronously? If you don’t have
> any async operations in the method body, Wind.js ould generate a async task
> which would be executed synchronously.
Sometimes callback implementations call the callback before they return,
for example when they got the answer cached. streamline uses the clever
trampoling approach to optimize for that. So in case you got an API that
caches, streamline generates more effective code than a normal human coder
would (I know there are some people like Tim who are really so good to do
it themselves, but for the normal being this is a bon)
And yes, with the filter support, we can generate much more compact and
> readable code. Considering the case of Node.js, I think we can easily add
> the support in Wind.js as an option.
For one see 2) if you leave away the trampoline it gets compacter, but is
less effective. Also I'd like to see a side-by-side comparison of some
examples to objectively see what can be improved. I for one don't look at
the generated code at all, since it got 1:1 line any error messages make
sense in themselves. Streamline also generates stacktraces that match the
original source, which is also quite nice.
> 2) Compared to CoffeeScript/IcedCoffeeScript/Streamline, Wind.js doesn't
> need pre-compilation process One of the most awesome feature of node.js is it doesn't need compilation.
Seriously it makes a pre-compilation just like the other tools, the
only difference is you call it in an eval rightaway, which can be done
with the others as well if you want to. I suppose you lose correct
linenumbers and filenames in backtraces and errormessage due to this,
don't you?
> As a result, I can modify the code and test it without any delay, which
> provide better productivity.
because calling _node instead of node is a delay?
> At the deploy time, it's easy to just create a tarball of current source
> code, upload to the server, and deploy it.
> If we use coffeescript or streamline, I have to do either:
> a, Deploy _node to the server (only for streamline)
> b, Precompile code into javascript
you need the package in node_modules, thats all about it and is the
same for all tools. And no you don't need it to be globally installed.
> 3) Wind.js has better compatibility
> I develop my node.js project with the WebStrom IDE from JetBrains. The
> implementation of Wind made it easy to work with any existing js IDEs. Code
> completion is just working seamlessly.
> At the same time, Wind.js is easily to take effect in existing codes. You
> don't need to completely rewrite your code in CoffeeScript, or change the
> file extension to _js
To call a file extension a loss in compatiblity is an overstatement,
you do not have to call them _js if you dont want to, it works with
normal .js just as well. It has been a step forward to convince Bruno
to use _js since it isn't exactly javascript anymore, but a mostly
extended javascript alike, which is true for wind.js as well.
function loadResources(_, names) {
var resources = [];
for (var i = 0; i < names.length; i++) resources[i] = loadResource(_, name[i]);
return resources;
}
The first time you call loadResources, things will be fine because loadResource will execute asynchronously. But if you call it again with a long list of names that have already been loaded before you may blow the stack (because the loop has been turned into a recursion).
Streamline handles this with a trampoline. The problem can also be solved by asking the developer to insert a process.nextTick call into loadResource so that it always returns asynchronously but this is more error prone and less efficient.
On Sunday, August 19, 2012 3:24:19 AM UTC+2, Jeffrey Zhao wrote:
> 1) I don’t know there’s a transform API in streamline, sorry. If > there’s one then using a eval() can do exactly the samething with Wind.js
> 2) What do you mean callback is called synchronously? If you don’t have > any async operations in the method body, Wind.js would generate a async > task which would be executed synchronously. And yes, with the filter > support, we can generate much more compact and readable code. Considering > the case of Node.js, I think we can easily add the support in Wind.js as an > option.
> *From:* Bruno Jouhier <javascript:> > *Sent:* Sunday, August 19, 2012 12:53 AM
> *To:* nod...@googlegroups.com <javascript:> > *Subject:* Re: [nodejs] Wind.js : An elegant approach to asynchronies > JavaScript
> Regarding your point 1), there is no difference in the browser: streamline > provides a transform API which is just equivalent to the Wind.compile API. > I don't understand your point.
> In callback mode streamline generates code that is a bit hairier but > that's primarily because it sets up a trampoline. So nothing bad will > happen if the callback is called synchronously. Does wind.js deal with this > case? (async calls that call their callback synchronously)
> With the --fibers options, the generated code is much more compact and > readable than with either streamline/callbacks or wind.js:
> for (var i = 0; i < array.length; i++) {
> for (var j = 0; j < array.length - i - 1; j++) {
> var r = fstreamline__.invoke(null, compareAsync, [array[j], > array[j + 1], _], 2);
> if (r > 0) fstreamline__.invoke(null, swapAsync, [array, j, j > + 1, _], 3);
> }
> }
> }, 1);
> }, 0).call(this, function(err) {
> if (err) throw err;
> }));
> Bruno
> On Saturday, August 18, 2012 6:30:09 PM UTC+2, Jeffrey Zhao wrote:
>> Thanks for the correction, Bruno!
>> 1) I just thought in a big picture with Node.js and browsers, but you’re >> definitely correct in Node.js-only scenarios.
>> 2) Please checkout the gist: https://gist.github.com/3388096. For a >> simple algorithm “bubble sort” with two “for” loops and an “if”, the code >> generated are quite different. The monadic code generated by Wind.js has >> nearly the same structure with the input code and has the original input >> beside it.
>> 3) That’s not what I talked about, what I mean is Wind.js can work with >> different async models, like:
>> var bubbleSort = eval(Wind.compile("async", function (array) {
>> for (var i = 0; i < array.length; i++) {
>> for (var j = 0; j < array.length - i - 1; j++) {
>> var r = $await(compareAsync(array[j], array[j + 1]));
>> if (r > 0) $await(swapAsync(array, j, j + 1));
>> }
>> }
>> }))
>> Now we are using “async” builder so the $await accepts build-in tasks and >> bubbleSort() produces the some type of task instaces. We can also:
>> var bubleSort = eval(Wind.compile("promise", function (array) {
>> for (var i = 0; i < array.length; i++) {
>> for (var j = 0; j < array.length - i - 1; j++) {
>> var r = $await(compareAsync(array[j], array[j + 1]));
>> if (r > 0) $await(swapAsync(array, j, j + 1));
>> }
>> }
>> }))
>> With the “promise” builder the $await accepts Promise/A objects and >> bubbleSort() also produces Promise/A objects. So if the users have existing >> codes with Promise/A (or any other ones) as their async model, Wind.js can >> work directly with it.
>> *From:* Bruno Jouhier >> *Sent:* Sunday, August 19, 2012 12:09 AM
>> *To:* nod...@googlegroups.com >> *Subject:* Re: [nodejs] Wind.js : An elegant approach to asynchronies >> JavaScript
>> Hi Jeffrey,
>> A few corrections regarding streamline:
>> 1) Streamline does not have any kind of daemon process to monitor changes >> or whatever. You run it like an interpreter: just give the ._js or ._coffee >> extension to your source file and run it with _node or _coffee. You can >> also write shell scripts with it (with a shebang). Very much like >> CoffeeScript (give .cs extension and run with coffee). And like CS it gives >> you the option to precompile but that's something people usually do only at >> deployment time, not in the standard dev/debugging cycle.
>> 2) Streamline does not generate state machines. It generates callback >> patterns that are similar to the ones a programmer would write manually >> (except that he would probably give up on try/catch). So the generated code >> is readable. Try it live on >> http://sage.github.com/streamlinejs/examples/streamlineMe/streamlineM...
>> 3) Streamline gives you the choice between 3 code generation options: >> callbacks, fibers and generators.
>> Bruno
>> On Saturday, August 18, 2012 5:04:44 PM UTC+2, Jeffrey Zhao wrote:
>>> They are similar. Some of you guys may remember a project called >>> “Jscex” in the group, that’s just Wind.js before renaming. After that I >>> decided to focus on community in China so most of the contribution went to >>> Chinese. Now more and more project in China are trying to adopt the project >>> since the past year.
>>> The main differences between Wind.js and streamline.js are:
>>> 1. Wind.js has code transformation in runtime, it doesn’t need to have a >>> daemon process to monitor the change and generate the target again. >>> Everything finished with the execution of your code.
>>> 2. Wind.js generates much more human readable code. Streamline.js >>> generates state machines but Wind.js generates monadic code with input >>> source code as comments. For example:
>>> 3. Wind.js supports different async models directly with different >>> supporting builders/libraries. With the default “async” builder, we write >>> codes target to the build-in task models. We can also use the “promise” >>> builder (even with “async” builder in parallel), then we can “$await” with >>> Promise/A objects, and the object generates by the compiled functions can >>> also be a promise directly. It only requires <40 lines of code to support >>> your own async models. With a different builder we can even has a iteration >>> generator like in JavaScript 1.7 or in Python.
>>> I've been happily using that ever since that project of mine that >>> analyzed scientific data out of a mongodb database where classic >>> asynchronous scripting became unbareable soon enough for that use case.
>>> Kind regards, Axel
>>> On Sat, Aug 18, 2012 at 4:10 PM, Tony Huang <cnw...@gmail.com> wrote:
>>>> Brief Introduction
>>>> Wind.js is Jeffrey Zhao's effort to simplify async development in >>>> JavaScript, which comes with a compiler as well as a set of libraries.
>>>> Wear equipments
In Wind.js, if the execute path don’t have any async steps/$await in it, it would be completed synchronously. For example:
function abc(i) {
if (i >= 0) {
$await(process(i));
} else {
return i + 1;
}
}
For all the i smaller than zero, the method would be synchronous, or the method completes asynchonously (strickly speaking, the task inside $await also needs to be async). There wouldn’t be unnecessary callbacks. This behavior is handled by the “async” builder with the build-in task type. Wind.js has a foundational compiling pattern but all of the rest is built as libraries so it’s easy to extend or customize.
From: Bruno Jouhier Sent: Sunday, August 19, 2012 6:53 PM
To: nodejs@googlegroups.com Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
The typical scenario for #2 is caching. Consider the following code:
function loadResources(_, names) {
var resources = [];
for (var i = 0; i < names.length; i++) resources[i] = loadResource(_, name[i]);
return resources;
}
The first time you call loadResources, things will be fine because loadResource will execute asynchronously. But if you call it again with a long list of names that have already been loaded before you may blow the stack (because the loop has been turned into a recursion).
Streamline handles this with a trampoline. The problem can also be solved by asking the developer to insert a process.nextTick call into loadResource so that it always returns asynchronously but this is more error prone and less efficient.
Bruno
On Sunday, August 19, 2012 3:24:19 AM UTC+2, Jeffrey Zhao wrote:
1) I don’t know there’s a transform API in streamline, sorry. If there’s one then using a eval() can do exactly the samething with Wind.js
2) What do you mean callback is called synchronously? If you don’t have any async operations in the method body, Wind.js would generate a async task which would be executed synchronously. And yes, with the filter support, we can generate much more compact and readable code. Considering the case of Node.js, I think we can easily add the support in Wind.js as an option.
From: Bruno Jouhier Sent: Sunday, August 19, 2012 12:53 AM
To: nod...@googlegroups.com Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
Regarding your point 1), there is no difference in the browser: streamline provides a transform API which is just equivalent to the Wind.compile API. I don't understand your point.
In callback mode streamline generates code that is a bit hairier but that's primarily because it sets up a trampoline. So nothing bad will happen if the callback is called synchronously. Does wind.js deal with this case? (async calls that call their callback synchronously)
With the --fibers options, the generated code is much more compact and readable than with either streamline/callbacks or wind.js:
for (var i = 0; i < array.length; i++) {
for (var j = 0; j < array.length - i - 1; j++) {
var r = fstreamline__.invoke(null, compareAsync, [array[j], array[j + 1], _], 2);
if (r > 0) fstreamline__.invoke(null, swapAsync, [array, j, j + 1, _], 3);
}
}
}, 1);
}, 0).call(this, function(err) {
if (err) throw err;
}));
Bruno
On Saturday, August 18, 2012 6:30:09 PM UTC+2, Jeffrey Zhao wrote: Thanks for the correction, Bruno!
1) I just thought in a big picture with Node.js and browsers, but you’re definitely correct in Node.js-only scenarios.
2) Please checkout the gist: https://gist.github.com/3388096. For a simple algorithm “bubble sort” with two “for” loops and an “if”, the code generated are quite different. The monadic code generated by Wind.js has nearly the same structure with the input code and has the original input beside it.
3) That’s not what I talked about, what I mean is Wind.js can work with different async models, like:
var bubbleSort = eval(Wind.compile("async", function (array) {
for (var i = 0; i < array.length; i++) {
for (var j = 0; j < array.length - i - 1; j++) {
var r = $await(compareAsync(array[j], array[j + 1]));
if (r > 0) $await(swapAsync(array, j, j + 1));
}
}
}))
Now we are using “async” builder so the $await accepts build-in tasks and bubbleSort() produces the some type of task instaces. We can also:
var bubleSort = eval(Wind.compile("promise", function (array) {
for (var i = 0; i < array.length; i++) {
for (var j = 0; j < array.length - i - 1; j++) {
var r = $await(compareAsync(array[j], array[j + 1]));
if (r > 0) $await(swapAsync(array, j, j + 1));
}
}
}))
With the “promise” builder the $await accepts Promise/A objects and bubbleSort() also produces Promise/A objects. So if the users have existing codes with Promise/A (or any other ones) as their async model, Wind.js can work directly with it.
From: Bruno Jouhier Sent: Sunday, August 19, 2012 12:09 AM
To: nod...@googlegroups.com Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
Hi Jeffrey,
A few corrections regarding streamline:
1) Streamline does not have any kind of daemon process to monitor changes or whatever. You run it like an interpreter: just give the ._js or ._coffee extension to your source file and run it with _node or _coffee. You can also write shell scripts with it (with a shebang). Very much like CoffeeScript (give .cs extension and run with coffee). And like CS it gives you the option to precompile but that's something people usually do only at deployment time, not in the standard dev/debugging cycle.
2) Streamline does not generate state machines. It generates callback patterns that are similar to the ones a programmer would write manually (except that he would probably give up on try/catch). So the generated code is readable. Try it live on http://sage.github.com/streamlinejs/examples/streamlineMe/streamlineM...
3) Streamline gives you the choice between 3 code generation options: callbacks, fibers and generators.
Bruno
On Saturday, August 18, 2012 5:04:44 PM UTC+2, Jeffrey Zhao wrote: They are similar. Some of you guys may remember a project called “Jscex” in the group, that’s just Wind.js before renaming. After that I decided to focus on community in China so most of the contribution went to Chinese. Now more and more project in China are trying to adopt the project since the past year.
The main differences between Wind.js and streamline.js are:
1. Wind.js has code transformation in runtime, it doesn’t need to have a daemon process to monitor the change and generate the target again. Everything finished with the execution of your code.
2. Wind.js generates much more human readable code. Streamline.js generates state machines but Wind.js generates monadic code with input source code as comments. For example:
// Original: function (interval) { while (true) { drawClock(new Date()); $await(Wind.Async.sleep(interval)); } }
3. Wind.js supports different async models directly with different supporting builders/libraries. With the default “async” builder, we write codes target to the build-in task models. We can also use the “promise” builder (even with “async” builder in parallel), then we can “$await” with Promise/A objects, and the object generates by the compiled functions can also be a promise directly. It only requires <40 lines of code to support your own async models. With a different builder we can even has a iteration generator like in JavaScript 1.7 or in Python.
From: Axel Kittenberger Sent: Saturday, August 18, 2012 10:42 PM
To: nod...@googlegroups.com Cc: je...@live.cn Subject: Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript
On Sun, Aug 19, 2012 at 3:00 PM, Jeffrey Zhao <je...@live.com> wrote:
> In Wind.js, if the execute path don’t have any async steps/$await in
> it, it would be completed synchronously. For example:
> function abc(i) {
> if (i >= 0) {
> $await(process(i));
> } else {
> return i + 1;
> }
> }
> For all the i smaller than zero, the method would be synchronous, or the
> method completes asynchonously (strickly speaking, the task inside $await
> also needs to be async). There wouldn’t be unnecessary callbacks. This
> behavior is handled by the “async” builder with the build-in task type.
> Wind.js has a foundational compiling pattern but all of the rest is built
> as libraries so it’s easy to extend or customize.
> function loadResources(_, names) {
> var resources = [];
> for (var i = 0; i < names.length; i++)
> resources[i] = loadResource(_, name[i]);
> return resources;
> }
> The first time you call loadResources, things will be fine because
> loadResource will execute asynchronously. But if you call it again with a
> long list of names that have already been loaded before you may blow the
> stack (because the loop has been turned into a recursion).
> Streamline handles this with a trampoline. The problem can also be solved
> by asking the developer to insert a process.nextTick call into loadResource
> so that it always returns asynchronously but this is more error prone and
> less efficient.
> Bruno
> On Sunday, August 19, 2012 3:24:19 AM UTC+2, Jeffrey Zhao wrote:
>> 1) I don’t know there’s a transform API in streamline, sorry. If
>> there’s one then using a eval() can do exactly the samething with Wind.js
>> 2) What do you mean callback is called synchronously? If you don’t have
>> any async operations in the method body, Wind.js would generate a async
>> task which would be executed synchronously. And yes, with the filter
>> support, we can generate much more compact and readable code. Considering
>> the case of Node.js, I think we can easily add the support in Wind.js as an
>> option.
>> *From:* Bruno Jouhier
>> *Sent:* Sunday, August 19, 2012 12:53 AM
>> *To:* nod...@googlegroups.com
>> *Subject:* Re: [nodejs] Wind.js : An elegant approach to asynchronies
>> JavaScript
>> Regarding your point 1), there is no difference in the browser:
>> streamline provides a transform API which is just equivalent to the
>> Wind.compile API. I don't understand your point.
>> In callback mode streamline generates code that is a bit hairier but
>> that's primarily because it sets up a trampoline. So nothing bad will
>> happen if the callback is called synchronously. Does wind.js deal with this
>> case? (async calls that call their callback synchronously)
>> With the --fibers options, the generated code is much more compact and
>> readable than with either streamline/callbacks or wind.js:
>> for (var i = 0; i < array.length; i++) {
>> for (var j = 0; j < array.length - i - 1; j++) {
>> var r = fstreamline__.invoke(null, compareAsync, [array[j],
>> array[j + 1], _], 2);
>> if (r > 0) fstreamline__.invoke(null, swapAsync, [array, j, j
>> + 1, _], 3);
>> }
>> }
>> }, 1);
>> }, 0).call(this, function(err) {
>> if (err) throw err;
>> }));
>> Bruno
>> On Saturday, August 18, 2012 6:30:09 PM UTC+2, Jeffrey Zhao wrote:
>>> Thanks for the correction, Bruno!
>>> 1) I just thought in a big picture with Node.js and browsers, but you’re
>>> definitely correct in Node.js-only scenarios.
>>> 2) Please checkout the gist: https://gist.github.com/**3388096<https://gist.github.com/3388096>.
>>> For a simple algorithm “bubble sort” with two “for” loops and an “if”, the
>>> code generated are quite different. The monadic code generated by Wind.js
>>> has nearly the same structure with the input code and has the original
>>> input beside it.
>>> 3) That’s not what I talked about, what I mean is Wind.js can work with
>>> different async models, like:
>>> var bubbleSort = eval(Wind.compile("async", function (array) {
>>> for (var i = 0; i < array.length; i++) {
>>> for (var j = 0; j < array.length - i - 1; j++) {
>>> var r = $await(compareAsync(array[j], array[j + 1]));
>>> if (r > 0) $await(swapAsync(array, j, j + 1));
>>> }
>>> }
>>> }))
>>> Now we are using “async” builder so the $await accepts build-in tasks
>>> and bubbleSort() produces the some type of task instaces. We can also:
>>> var bubleSort = eval(Wind.compile("promise", function (array) {
>>> for (var i = 0; i < array.length; i++) {
>>> for (var j = 0; j < array.length - i - 1; j++) {
>>> var r = $await(compareAsync(array[j], array[j + 1]));
>>> if (r > 0) $await(swapAsync(array, j, j + 1));
>>> }
>>> }
>>> }))
>>> With the “promise” builder the $await accepts Promise/A objects and
>>> bubbleSort() also produces Promise/A objects. So if the users have existing
>>> codes with Promise/A (or any other ones) as their async model, Wind.js can
>>> work directly with it.
>>> *From:* Bruno Jouhier
>>> *Sent:* Sunday, August 19, 2012 12:09 AM
>>> *To:* nod...@googlegroups.com
>>> *Subject:* Re: [nodejs] Wind.js : An elegant approach to asynchronies
>>> JavaScript
>>> Hi Jeffrey,
>>> A few corrections regarding streamline:
>>> 1) Streamline does not have any kind of daemon process to monitor
>>> changes or whatever. You run it like an interpreter: just give the ._js or
>>> ._coffee extension to your source file and run it with _node or _coffee.
>>> You can also write shell scripts with it (with a shebang). Very much like
>>> CoffeeScript (give .cs extension and run with coffee). And like CS it gives
>>> you the option to precompile but that's something people usually do only at
>>> deployment time, not in the standard dev/debugging cycle.
>>> 2) Streamline does not generate state machines. It generates callback
>>> patterns that are similar to the ones a programmer would write manually
>>> (except that he would probably give up on try/catch). So the generated code
>>> is readable. Try it live on http://sage.github.com/** >>> streamlinejs/examples/**streamlineMe/streamlineMe.html<http://sage.github.com/streamlinejs/examples/streamlineMe/streamlineM...>
>>> 3) Streamline gives you the choice between 3 code generation options:
>>> callbacks, fibers and generators.
>>> Bruno
>>> On Saturday, August 18, 2012 5:04:44 PM UTC+2, Jeffrey Zhao wrote:
>>>> They are similar. Some of you guys may remember a project called
>>>> “Jscex” in the group, that’s just Wind.js before renaming. After that I
>>>> decided to focus on community in China so most of the contribution went to
>>>> Chinese. Now more and more project in China are trying to adopt the project
>>>> since the past year.
>>>> The main differences between Wind.js and streamline.js are:
>>>> 1. Wind.js has code transformation in runtime, it doesn’t need to have
>>>> a daemon process to monitor the change and generate the target again.
>>>> Everything finished with the execution of your code.
>>>> 2. Wind.js generates much more human readable code. Streamline.js
>>>> generates state machines but Wind.js generates monadic code with input
>>>> source code as comments. For example:
>>>> 3. Wind.js supports different async models directly with different
>>>> supporting builders/libraries. With the default “async” builder, we write
>>>> codes target to the build-in task models. We can also use the “promise”
>>>> builder (even with “async” builder in parallel), then we
I'm transforming my game server into Wind.js style. And it's really
painless and smooth.
Wind.js has already provided the Wind.Async.Bindings.fromStandard and
Wind.Async.Bindings.fromCallback stubs to help you integrate existing codes.
For instance, I already have a EntityStore class which provides standard
style interface:
EntityStore.prototype = {
'get': function(cb) {
//...
},
'save': function(entity,cb) {
//...
}
};
In order to make it usable in Wind.js, I just added following codes at the
end of the module:
['get', 'save'].forEach(function(method) {
EntityStore.prototype[method + 'Async'] =
Wind.Async.Binding.fromStandard(EntityStore.prototype[method]);
});
As a result, I can access these methods in Wind.js easily in this way:
var users = new EntityStore('user');
var currentUser = $await(users.get(userId));
It's quite easy.
But in the other hand, Wind.js hasn't provide the reverse operation, so I
added 2 method to the library:
- Wind.Async.Binding.toStandard
- Wind.Async.Binding.toCallback
So I can replace my code method by method without any overhead:
My original code might be:
function wearEquipment(characterId, equipmentId, cb) {
//..... deep levels of callbacks
}
After refactoring, my code comes to:
var wearEquipmentAsync = eval(Wind.compile('async', function(characterId,
equipmentId) {
// code in synchronised style
});
var wearEquipment = Wind.Async.Binding.toStandard(wearEquipmentAsync);
Completely the same interface, the same function, but better-looking code.
On Thu, Aug 23, 2012 at 11:31 PM, Tony Huang <cnwz...@gmail.com> wrote:
> I'm transforming my game server into Wind.js style. And it's really
> painless and smooth.
> Wind.js has already provided the Wind.Async.Bindings.fromStandard and
> Wind.Async.Bindings.fromCallback stubs to help you integrate existing codes.
> For instance, I already have a EntityStore class which provides standard
> style interface:
> EntityStore.prototype = {
> 'get': function(cb) {
> //...
> },
> 'save': function(entity,cb) {
> //...
> }
> };
> In order to make it usable in Wind.js, I just added following codes at the
> end of the module:
> ['get', 'save'].forEach(function(method) {
> EntityStore.prototype[method + 'Async'] =
> Wind.Async.Binding.fromStandard(EntityStore.prototype[method]);
> });
> As a result, I can access these methods in Wind.js easily in this way:
> var users = new EntityStore('user');
> var currentUser = $await(users.get(userId));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
should be:
var currentUser = $await(users.getAsync(userId));
> But in the other hand, Wind.js hasn't provide the reverse operation, so I
> added 2 method to the library:
> - Wind.Async.Binding.toStandard
> - Wind.Async.Binding.toCallback
> So I can replace my code method by method without any overhead:
> My original code might be:
> function wearEquipment(characterId, equipmentId, cb) {
> //..... deep levels of callbacks
> }
> After refactoring, my code comes to:
> var wearEquipmentAsync = eval(Wind.compile('async', function(characterId,
> equipmentId) {
> // code in synchronised style
> });
> var wearEquipment = Wind.Async.Binding.toStandard(wearEquipmentAsync);
> Completely the same interface, the same function, but better-looking code.
> On Thu, Aug 23, 2012 at 12:55 AM, Bruno Jouhier <bjouh...@gmail.com>wrote:
>> On Wednesday, August 22, 2012 12:55:41 PM UTC+2, Dominic wrote:
>>> this is all very clever, but do code transformations really make
>>> callbacks easier?
