Streamline translates its special syntax to vanilla JS with callbacks. So,
if you implement a function like
function foo(x, y, _) { ... }
Normal JS modules (not written with streamline) will be able to call it as:
foo(x, y, function(err, result) { ... });
Streamline is just a tool that helps you write your code. This tool
produces vanilla JS that follows the standard node callback conventions. So
you can publish it to NPM, you won't be forcing anyone else to use
streamline. That's like coding a module in CoffeeScript.
Regarding the stack traces, streamline reconstructs the "synchronous" stack
that led to the exception. This is a big plus as the callback stack is
usually not very helpful (and if you really want it, you have it with
ex.rawStack).
The error message that bugs you is a feature. It ensures that all the
yielding points are explicit.
Regarding performance, there is still a need for real benchmarks that
compare apples with apples (code that does flow control with code that does
flow control). Your half baked pseudo benches are just useless.
Bruno
On Tuesday, April 10, 2012 10:01:07 PM UTC+2, Joe Ferner wrote:
>
> I think I'm done writing benchmarks. Even if I come up with a
> benchmark that shows streamline is faster I'm still not going to use
> it and I couldn't recommend anyone else use it either. The community
> as a whole doesn't back that kind of syntax so I couldn't submit a
> module to npm if I wrote it using streamline. As I said before I can't
> easily run my unit tests or deploy to my server environment. From the
> little that I used it, it screws up the stack trace, you get weird
> errors like "Function contains async calls but does not have _
> parameter" which IMO shouldn't be an error at all. And it obscures
> what is really going on under the covers which you pointed out quite
> well in your most recent comments.
>
> On Apr 10, 3:24 pm, Bruno Jouhier <[email protected]> wrote:
> > Still, your bench is wrong because the two programs do different things:
> >
> > * The streamline program calls socket.write from the callback of the
> > previous socket.write. So it does proper flow control and it won't
> overflow
> > output buffers.
> > * The callback program calls socket.write in a loop, without chaining
> them
> > through the callbacks. No flow control here!
> >
> > So please, go back to the drawing board and come back with a fair bench.
> >
> > Hint: the callback version should not run the bench with a for loop, it
> > should transform the loop into a recursion (which is what streamline
> does).
> >
> >
> >
> >
> >
> >
> >
> > On Tuesday, April 10, 2012 5:32:45 PM UTC+2, Joe Ferner wrote:
> >
> > > On Apr 10, 11:12 am, Bruno Jouhier <[email protected]> wrote:
> > > > Your bench does not make sense. There is no async call at all. So
> there
> > > is no reason to have an _ in the streamline source.
> >
> > > > Streamline does not transform sync fonctions. So the Streamline
> version
> > > of this bench should take 3 ms.
> >
> > > > Callback != asynchronous
> >
> > > > Try again with an async call
> >
> > > I was trying to demonstrate the call overhead but here is an example
> > > with some async codehttps://gist.github.com/2352116again a bit
> > > contrived because I really didn't want to spend much time on this.
> >
> > > streamline did close the gap a bit which is what I suspected when I
> > > said "I will agree that for many real world cases this is a tiny piece
> > > of the overall time". But it was still twice as slow. (node 565ms and
> > > streamline 1049ms)
--
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
