I'm not looking for async stack trace. If I were, I'd probably pick up "trycatch" module instead.
What I'm asking is that what is the point of writing _javascript_ if you can't use it without compiling?
If you can use a compiler, you can use typescript, iced coffee and a dozen languages better than _javascript_. If you don't want to use a compiler, fibers and generators will help without any streamline stuff. So what is the point...
-----
I'm using callbacks only. People who don't understand them just can't work with node, so I have no regrets about that. The biggest drawback so far was that debugger can't step in async calls, don't know what to do about it.
If I wanted to write sync-like code, I'd probably turn to generators and "co" module. It looks nice, but I didn't actually manage to try it, since generators aren't on by default even in 0.11.x...
// alex
08.01.2014, 11:37, "Bruno Jouhier" <[email protected]>:
--The async stack is reconstructed when you *catch* the exception (would be very inefficient otherwise). The normal pattern is to have at least one try catch in your high level HTTP dispatcher. You actually automatically get one if you use the companion streamline-streams or ez-streams companion libraries.
Try the following:
function a(_) { return b(_); }
function b(_) { return c(_); }
function c(_) { return d(_); }
function d(_) {
setTimeout(_, 1000);
throw new Error("xx");
}
try { a(_); }
catch (ex) { throw ex.stack; }
Output:
Error: xx
<<< async stack >>>
at d (/Users/bruno/dev/syracuse/junk/stack._js:7:18)
at c (/Users/bruno/dev/syracuse/junk/stack._js:3:23)
at b (/Users/bruno/dev/syracuse/junk/stack._js:2:23)
at a (/Users/bruno/dev/syracuse/junk/stack._js:1:23)
at main (/Users/bruno/dev/syracuse/junk/stack._js:10:6)
<<< raw stack >>>
at __$d (/Users/bruno/dev/syracuse/junk/stack._js:7:18)
at ___ [as _onTimeout] (/Users/bruno/dev/syracuse/node_modules/streamline/lib/callbacks/runtime.js:100:13)
at Timer.listOnTimeout (timers.js:124:15)
On Wednesday, January 8, 2014 3:45:25 AM UTC+1, Alex Kocharin wrote:I run "node_ test._js", then "node debug -p `pidof node`" (node_ doesn't have debug option), and that's the code I see:```debug> c
break in test._js:4
2 debugger ;
3 return setTimeout(__cb(_, __frame, 2, 0, function __$main() {
4 debugger ;
5 console.log("... world"); _(); }, true), 10000); });}).call(this, __trap);
6 });
```And this is an example stack trace:```Error: xx
at __$main (/tmp/node_modules/zz/test._js:5:16)
at ___ [as _onTimeout] (/tmp/node_modules/streamline/lib/callbacks/runtime.js:100:13)
at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)
```Needless to say, I don't remember writing any of these underscore methods. And as I said earlier, I avoid compilers for this exact reason. Personally, I'd much rather stick to the callbacks and not trade writing time for debugging time. But if you're using a compiler anyway, I'd rather look for await/defer features of IcedCoffeeScript because it comes with much more obvious syntax.PS: yes I know, it's possible to use fibers or generators or whatever with streamline. But I can use them without streamline just as well, and it'd be much easier.08.01.2014, 05:55, "Seth Pollack" <[email protected]>:Hi Alex, please see my comment below about not trolling for more "my control flow is better than your control flow" debates ;-)All joking aside, there are many innovative approaches out there -- an embarrassment of riches. For folks who are into coffee script, streamline has full support for that as well.Also, i may not have been clear enough about the debugging experience under streamline. The code in the editor and debugger are the same.Seth
On Tuesday, January 7, 2014 4:49:42 PM UTC-8, Alex Kocharin wrote:I wonder how having different code in the editor and in the debugger helps productivity.Oh come on... If you're using a compiler anyway, why not move to iced coffee or something? I'm avoiding it recently, but it's still better than streamline.07.01.2014, 22:53, "Seth Pollack" <[email protected]>:I've written up a blog post here http://bit.ly/KtMIYS that explains why we've chosen Node.js plus Streamline as our platform for our product (www.rivaliq.com).
We are all Node fans in this forum, but i'm guessing that fewer folks have given Streamline (https://github.com/Sage/streamlinejs) a spin. We have found significant developer productivity (and happiness!) benefits by making the switch to using it. I'm not saying that here to troll for more "my control flow is better than your control flow" debates, but rather to share our experiences in order to hopefully help others. Please give it a read, and I welcome your comments on the blog.
Seth
--
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
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
