[nodejs] [go-async] Generator based async/await blocks with support for abortion, form of TCO and fast synchronous execution

https://github.com/eldargab/go-async -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are sub

[nodejs] [ANN] agent-next - Simple, flexible, fun to use HTTP request library

Please checkout https://github.com/eldargab/agent-next. -- -- 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 grou

[nodejs] Re: [Poll/RFC] Remove the built-in debugger

Built-in debugger is the only debugger I used. Typically I just set a breakpoint and inspect some vars and that's all. Things like node-inspector are not worth launching for such sort of things. вторник, 12 ноября 2013 г., 19:38:36 UTC+4 пользователь Ben Noordhuis написал: > > The built-in debu

[nodejs] Re: Recursive process.nextTick crash

There were semantic changes in process.nextTick() in 0.10. This warning was placed to make developers kinda aware about that. However it is already removed on master. понедельник, 9 сентября 2013 г., 13:40:36 UTC+4 пользователь Eldar написал: > > set process.maxTickDepth to In

[nodejs] Re: Recursive process.nextTick crash

set process.maxTickDepth to Infinity понедельник, 9 сентября 2013 г., 11:44:49 UTC+4 пользователь Jules написал: > > Since upgrading from 0.8 to 0.10, we're occasionally see these crashes in > production: > > (node) warning: Recursive process.nextTick detected. This will break in >> the next ver

Re: [nodejs] Re: Downside to not wrapping sync callbacks in nextTick()?

Also about process.nextTick "standard". You might be surprised, but I very rarely see sync callbacks deferring in modules which our app uses. directly or not. пятница, 23 августа 2013 г., 0:02:36 UTC+4 пользователь Eldar написал: > > I am sorry, I had to write more detailed e

Re: [nodejs] Re: Downside to not wrapping sync callbacks in nextTick()?

ing and patched their code to use new setImmediate() function instead. Loosing performance of new process.nextTick and adding a junk to their code. Hope, now my claims look more sane and making sens. четверг, 22 августа 2013 г., 22:32:28 UTC+4 пользователь Scott González написал: > >

Re: [nodejs] Re: Downside to not wrapping sync callbacks in nextTick()?

ive in > what you send, be liberal in what you accept. > > If you're implementing an API, you should be consistent. If you're > consuming the API, you should be defensive. But honestly, people writing > node modules should follow the node patterns and never mix sync and

[nodejs] Re: Downside to not wrapping sync callbacks in nextTick()?

I always followed the simple rule "callback may be called at any time" and I was pretty happy so far. The resulting code is more portable and simpler. Just use tail recursive algorithms and be happy. вторник, 20 августа 2013 г., 21:47:22 UTC+4 пользователь Bryan Donovan написал: > > I have been

[nodejs] Re: memory leak on http chunked fs.createReadStream().pipe(res)

See this thread https://groups.google.com/forum/#!topic/nodejs/A8wbaaPmmBQ And the correct way to pipe is something like here https://groups.google.com/forum/#!topic/nodejs/wtmIzV0lh8o понедельник, 19 августа 2013 г., 22:44:00 UTC+4 пользователь Davis Ford написал: > > I have the following code

[nodejs] Re: The future of node streams. We need to talk

ght exception and leak on socket hang up, because "close" not an "error" event will be emitted. среда, 14 августа 2013 г., 13:47:14 UTC+4 пользователь Floby написал: > > file.pipe(res) does clean the resources on error because node completely > shuts down, doesn'

[nodejs] Re: The Future of Programming in Node.js

that you indeed deeply understand him, learned all his arguments but have in mind something he didn't know and educate about that. There are not so much people not able to understand others and place themselves to other's side. That's all. Regards, Eldar. вторник, 13 августа 2

Re: [nodejs] Re: The future of node streams. We need to talk

about " `.pipe()` doesn't cleanup any >> resources. >> Everything works fine until the streaming process completes successfully. >> " >> >> Is there an example where that becomes obvious? >> >> On Monday, 12 August 2013 18:05:02 UTC+

[nodejs] Re: The future of node streams. We need to talk

h other > wouldn't they? > > On Tuesday, August 13, 2013 4:05:02 AM UTC+12, Eldar wrote: >> >> If you want to create some function which accepts a stream and can affect >> it's state you should be able to destroy the given stream on demand >> e.g. when somet

[nodejs] Re: The future of node streams. We need to talk

s there an example where that becomes obvious? > > On Monday, 12 August 2013 18:05:02 UTC+2, Eldar wrote: >> >> If you want to create some function which accepts a stream and can affect >> it's state you should be able to destroy the given stream on demand

[nodejs] The future of node streams. We need to talk

If you want to create some function which accepts a stream and can affect it's state you should be able to destroy the given stream on demand e.g. when something went wrong and/or you are not interested in receiving data anymore. Unfortunately that's impossible with current node readable stre

[nodejs] Re: Async read handling for streams2

I came to the value that the best thing to deal with node streams is not deal with them at all. Wrap them as soon as possible, do not pass them around, do not build abstractions on top of them. It is a super complected thing capable of what? You even can't do `send(file)`. Just can't. There are

[nodejs] Re: read streams leak memory?

This is not an answer to your question, but just in case, doing fs.createReadStream(fpath).pipe(res); is not safe. Any error on response during streaming will lead to leak as a file will remain opened. So in production you should destroy stream explicitly. The full pipe operation is something l

[nodejs] Re: Announcing JS-Git and related projects.

Really nice streaming API! On Thursday, June 13, 2013 11:54:14 PM UTC+4, Tim Caswell wrote: > > As some of you know, and many of you do not, I've been spending the last > few months working on implementing git in javascript. > > I started out with a small, but successful [kickstarter] that enable

[nodejs] Re: Module naming

I migrated to components for both client and server side, though my motivation is different: *1) node_modules is a weak structuring pattern* The most common approach for applications is to have a bunch of local modules without package.jsons and a huge root package.json with all external depend

[nodejs] Re: what are the merits / demerits of require.extensions?

> > i envision that i will put a standardized, constant index.js in each of my > module folders that will do the bootstrap transpiling business quite > transparently > That's wrong because 1. That means that additional typically huge dependency must be added 2. Compiler may just don't wo

Re: [nodejs] what are the merits / demerits of require.extensions?

It doesn't matter if there is no problem mentioned by @Ben On Friday, May 10, 2013 6:43:20 PM UTC+4, Sam Roberts wrote: > > On Fri, May 10, 2013 at 7:02 AM, Eldar > > wrote: > > No one argues about modules for npm. What about apps? What about > components &g

Re: [nodejs] what are the merits / demerits of require.extensions?

No one argues about modules for npm. What about apps? What about components private for organization? There is never any need for additional filetype extensions. Node runs > JavaScript. Ultimately, you have to compile it to JS before it runs * > anyway*, so you may as well do that up front, rath

[nodejs] Re: what are the merits / demerits of require.extensions?

I also don't get what's cool about compiling in advance for private modules. It's just an addition of pain and complexity. All reasons for deprecation of require.extensions are illegal for me. If core team decided to fight against coffescript modules in npm they can do that in many other ways.

[nodejs] Re: What libraries are available to parse web pages?

Perhaps the best option for now is jsdom . It can't handle all pages in the web but it's quite forgiving. I used this lib for the same purposes half an year ago and found experience somewhat buggy but it worked. -- -- Job Board: http://jobs.nodejs.org/ Posting

[nodejs] Re: callback slower than promises?

Huh, and don't use setTimeout() yourself :) Basically, you should just make all your benchmarks sync. e.g. var d = new Promise d.then(noop) d.resolve() That will give you right numbers. On Tuesday, April 30, 2013 8:51:23 PM UTC+4, mgutz wrote: > > Does anybody see anything wrong with the logic

[nodejs] Re: callback slower than promises?

There is a bug in benchmark.js (the lib behind jsperf) that makes all your async tests to be a setTimeout() benchmark :) The bug is fixed in master now, but I should note that even with patched version I still get very strange async results for some cases #42

[nodejs] Re: Questions about objects performance

1) You don't need to save length property in a for loop. That gives you nothing. 2) If you curious about performance just do benchmarks! E.g with http://benchmarkjs.com/. 3) Don't bother with performance unless you really know context. I.e. impact of procedure in question on overall performanc

[nodejs] Re: AngularJS inspired dependency injection in Node (feedback?)

You might find easy-app also interesting. -- -- 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" g

[nodejs] Re: Dependency injection for Node.js. What do you think?

That was a crazy idea and my goal was to find simple and clear way to swap * fs* for *mkdirp* On Saturday, April 20, 2013 9:23:50 PM UTC+4, Scott Corgan wrote: > > Easier? https://github.com/scottcorgan/Injector > > On Friday, July 27, 2012 7:45:48 AM UTC-7, Eldar wrote: >> >

Re: [nodejs] Re: Should I use asynchronous callbacks for non-I/O tasks?

h. > > The better solution there is to create a child process to do the work > (or use a uv_work request in a C++ binding). And, of course, profile > and simplify your algorithm to make it so that you have to do less > work. If it's not worth doing those things, then it&#x

[nodejs] Re: Should I use asynchronous callbacks for non-I/O tasks?

No, you get it all wrong. Callbacks you use for `for-loops` (array.forEach() I guess) are not async at all. The forEach() method is actually nothing but: // simplified Array.prototype.forEach = function (cb) { for (var i = 0; i < this.length; i++) { cb(this[i]) } } So it just performs

Re: [nodejs] Promises vs Async vs Stepdown vs etc... Request for non-trivial implementation ideas.

Or if your call to third party. And may be there is no bugs, but you passed wrong args... On Tuesday, April 2, 2013 12:42:31 PM UTC+4, Bruno Jouhier wrote: > > > > On Tuesday, April 2, 2013 4:01:59 AM UTC+2, Alexey Petrushin wrote: >> >> > error coalescing is listed as a major benefit of promises

[nodejs] Re: Promises vs Async vs Stepdown vs etc... Request for non-trivial implementation ideas.

You can have a look at https://github.com/eldargab/make-flow -- -- 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

Re: [nodejs] Re: node server getting stuck

Yeah, with wrk everything is fine, thanks! On Saturday, March 23, 2013 11:28:26 PM UTC+4, Ben Noordhuis wrote: > > On Sat, Mar 23, 2013 at 8:13 PM, Eldar > > wrote: > > I recently benchmarked node.js hello world server on OS X 10.8.3 and > > observed the following

[nodejs] Re: node server getting stuck

I recently benchmarked node.js hello world server on OS X 10.8.3 and observed the following: $ node hello-world.js & $ ab -n 1000 -c 10 -k -q http://127.0.0.1:8000/ # OK $ ab -n 2000 -c 10 -k -q http://127.0.0.1:8000/ # OK $ ab -n 5000 -c 10 -k -q http://127.0.0.1:8000/ # Hang out! That's probab

[nodejs] Re: I finished some important JS Specifications, welcome to discuss...

Javascript require system just unpaired. What's the point of this spec? Bundle format? Have a look at components in case you haven't. On Friday, February 22, 2013 7:38:11 AM UTC+4, fengchu...@gmail.com wrote: > > visit URL is: https://github.com

[nodejs] Re: Dependency-driven asynchronous request processing?

You can have a look at easy-app . It does exactly what you described. It is a container but it's trivial to marry it with express or build your own web framework around it. Personally I chose the second option cause you actually need just a few http helpers

[nodejs] Re: Breaking away from the procedural structure of method calling

I mean that I would structure everything in a completely different way. In general It would look like the gist above except without inessential noise. On Friday, February 1, 2013 11:48:28 PM UTC+4, Eldar wrote: > > Here is alternative take on a problem https://gist.github.com/4

[nodejs] Re: Breaking away from the procedural structure of method calling

Here is alternative take on a problem https://gist.github.com/4693486. Though that approach would be right only if applied to the whole app, but that's an another story. On Friday, February 1, 2013 8:10:35 PM UTC+4, Thomas Gray wrote: > > Hi guys > > Let me start out here with a disclaimer. I am

[nodejs] Re: [Idea]: npm as a dependancy injector.

Node module system is locked and is never going to change anyway. Think about it as a static linking system and nothing more. Even with hacks like you suggested it is still insufficient for dynamic linking. The advice is: 1) Do not rely on require system if you want runtime configuration, des

[nodejs] [ANN] easy-app - Nice home for your application

https://github.com/eldargab/easy-app. Nice container giving your applications simple and powerful structure. -- 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

Re: [nodejs] Re: Dependency based asynchronous flow

this is what happens when communities get big. > > I'll move discussion of graphflow to github. > > > On Thu, Jan 10, 2013 at 7:04 PM, Eldar >wrote: > >> nope, that's wrong >> >> >> On Thursday, January 10, 2013 9:28:40 PM UTC+4, Tatumizer wrote:

[nodejs] Re: Dependency based asynchronous flow

nope, that's wrong On Thursday, January 10, 2013 9:28:40 PM UTC+4, Tatumizer wrote: > > @eldar: sure, any honest person prefers his own lib :) > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You

[nodejs] Re: Dependency based asynchronous flow

Wow, how many similar libs appeared simultaneously. But, hey guys to be honest, make-flow is the most javascript-ish and the only practical out there :) On Thursday, January 10, 2013 1:13:14 AM UTC+4, Tom Wieland wrote: > > Hi everyone, > > I've created a

[nodejs] [ANN] make-flow - Make style control flow. Excellent for complex functions.

https://github.com/eldargab/make-flow -- 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 nodej

Re: [nodejs] Re: new concept for structured asynchronous programming

@Raynos, @greelgorke I would recommend reading Out of the tarpit. It argues that traditional imperative approach with control flow being messed with logic leads to complex unmaintainable just ugly software. On Saturday, December 29, 2012 11:39:28 AM UTC

[nodejs] Re: new concept for structured asynchronous programming

I have something similar called make-flow. Details are not documented yet but an example from circuit's Readme looks like // definition var app = Flow() .def('sum1', function (done) { add(1, 2, done) }) .def('sum2', function (done) { add(3, 4, do

[nodejs] Re: MVC / flow control structure - Please review and comment

y it's better to create object-method for such use case function DoSomething (data) { this.data = data } DoSomething.prototype.a = function () { // body... } DoSomething.prototype.b = function () { // body... } On Monday, October 15, 2012 11:18:37 AM UTC+4, Mil Werns wrote: > > @Tim:

[nodejs] Re: MVC / flow control structure - Please review and comment

What about code, the goal "* Focus is writing maintainable, clean and easy to understand code!" *is not satisfied IMHO. On Sunday, October 14, 2012 1:58:31 PM UTC+4, Mil Werns wrote: > > Hi, > > I want to implement a REST API with node.js and restify. Because it is my > first node.js project, I

[nodejs] Re: MVC / flow control structure - Please review and comment

I recommend to have a look at the-box just because it suggests build systems style computational model which is definitely worth to consider. Also there is an interesting "Out of the tar pit" article. It's not directly related to node but it mentions an id

[nodejs] [ANN] the-box - An interesting approach to creating high modular, elegant apps

https://github.com/eldargab/the-box#readme -- 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] Re: Feature poll: Do you use the clientError event?

4 On Thursday, August 30, 2012 3:07:23 AM UTC+4, Isaac Schlueter wrote: > > Do you use the clientError event? > > Please choose one: > > 1. Yes, I use it all the time. Please don't change it ever, thank you. > > 2. I don't use it, but I'm aware of it, and I think I might someday. > > 3. I don

[nodejs] Re: Dependency injection for Node.js. What do you think?

Yeah, the topic's name is completely wrong. I realized it just right after posting but couldn't fix. What I actually mean is: Look, require('foo') is nothing but global var 'foo' except that it is scoped on module's level. Typically "it is set" by Node depending on your dirs layout. But why

Re: [nodejs] Dependency injection for Node.js. What do you think?

nt programmatic hooks into > the initialization and attachment process of the module. > > On Fri, Jul 27, 2012 at 2:57 PM, Joshua Holbrook > wrote: > >> You might like this, Eldar: >> >> https://github.com/flatiron/broadway >> >> It gives you dependency in

Re: [nodejs] Dependency injection for Node.js. What do you think?

o bake in support to this as part of the require system seems like > asking for trouble, keep it explicit, keep it as needed and let the > goodness follow. > > My two cents. > > > On Fri, Jul 27, 2012 at 4:45 PM, Eldar wrote: > >> Do we need this in Node? >>

[nodejs] Dependency injection for Node.js. What do you think?

Do we need this in Node? My answer is yes we need some (simple) way to specify the app level dependencies at runtime. Here is my take on this. Please checkout and let me know how do you feel about. But the idea is very simple: // inside any index.jsv

[nodejs] Re: installing Node.js 0.8.1 with n

Just in case. "n latest" installs the latest version from unstable brunch. It's not a 0.8.1. To install the latest stable version you should use "n stable". This currently wouldn't work either because there is RC for 0.8.2 already uploaded to http://nodejs.org/dist and "n" considers it as a late

[nodejs] Re: Node version 0.8.0

Exactly this - https://github.com/visionmedia/n. On Monday, June 25, 2012 9:36:54 PM UTC+4, Mark Hahn wrote: > > What is the best way to install 0.8 on ubuntu linux? > > On Monday, June 25, 2012 8:01:13 AM UTC-7, Isaac Schlueter wrote: >> >> I am thrilled to announce the arrival of a new stable v

Re: [nodejs] Re: Node version 0.8.0

The best way to install node is https://github.com/visionmedia/n On Monday, June 25, 2012 9:34:32 PM UTC+4, Mark Hahn wrote: > > What is the best way to install 0.8 on ubuntu linux? > > On Mon, Jun 25, 2012 at 8:23 AM, Thomas Fritz wrote: > >> Great Release. >> Big thanks to all developers for th

[nodejs] [ANN] connect-views: Serve your jades, markdowns, styluses, etc like a static files

connect-views - middleware for rendering templates in a static manner, capable to handle clean request paths with omitted extensions, has built in support for several template engine. Example: var express = require('express')var Views = require('conn

[nodejs] Re: xls / xlsx parsing?

I did parsing of xlsx from scratch. In our project we have to be able to import-export data from predefined templates. Result documents contained just a text (though with arbitrary formatting applied) I didn't attempt to mirror native Excel API, but had an collection of functions manipulating t

[nodejs] Re: How to avoid callback hell?

There are many kinds of application domains. One is a system programming. Node's core and the majority of npm modules belong to such domain. In system programming whether function performing IO, blocking or not is important matter. Assuming that any kind of faux blocking enabled let's consider

[nodejs] Re: Efficiently list, compare and rate javascript packages | Maintaining packages by the community

> > there is no real place/tool to help achieve this overlook (apart from some > simple lists) > There is. It is https://github.com/. Just select any popular module from simple lists available, for example connect. Then dig it's source code until you def

[nodejs] Re: How to measure quality of modules

For me github is awesome. Generaly 5-10 minutes of digging through the code is enough do decide whether you like it or not and if you like it you don't care so much about popularity, battle testing and other boring stuff. You just confident. Otherwise when code is bad no matter how many forks an

[nodejs] Re: Best way to organize modules which has dependencies

nt in general. But that's all about the rule - do not create required objects within application code. Any module should receive ready to use instance of required object On Saturday, March 24, 2012 1:23:18 PM UTC+4, Martin Lundberg wrote: > > On Saturday, March 24, 2012 6:29

[nodejs] Re: Getting started with testing and using stubs

As far as I know sinon.js is the best util for doing such kind of things. -- 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] Re: Best way to organize modules which has dependencies

For now I would refactor your module in this way: // authentication var repo = require('user-repo') module.exports = function authenticate (email, password, cb) { ... } // user repository var db = require('db') module.exports = { get: function () { }, ... } // database var MysqlClient = re

[nodejs] Easy table - nice and simple text table for Node.js

Hi. I wrote a little utility for rendering text tables with javascript. Probably someone else will find it useful. The brief example is: var Table = require('easy-table'); var data = [ { id: 123123, desc: 'Something awesome', price: 1000.00 }, { i