Any particular reason why uptime() is not on the core ChildProcess? It's
pretty much necessary for any decent layer on top of cluster or any other
process management type things, so most people are tacking it on anyways.
On Friday, August 17, 2012 6:49:14 PM UTC-7, Jimb Esser wrote:
In actuality, fs.exists *only* has an err argument... or really a not
err argument. fs.exists is just not fs.stat. If you want fs.exists
to have an error as the first argument, do my_fs_exists = fs.stat, and
it'll have
Have you looked at:
http://nodejs.org/docs/latest/api/cluster.html
--
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
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:
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.,
When I write beyond the end of a `Buffer`, nothing bad happens. I'm expecting a
earth-shattering kaboom, or at least an exception. I'm happier with the do
nothing behavior, but I'm wondering if there was any debate about whether or not
an exception should be raised when an is out of range. If so,
On Thu, Aug 09, 2012 at 06:34:45PM -0700, Martin Cooper wrote:
On Thu, Aug 9, 2012 at 5:13 PM, Alan Gutierrez a...@prettyrobots.com wrote:
Have you ever written Node.js code that counts on the implementation
specific
Object behavior that mantains the insertion order of properties?
It
When you write past the length of a buffer, you're not actually
writing to the underlying C buffer, you're just adding new numerical
properties to the Buffer Javascript wrapper object.
On Sat, Aug 18, 2012 at 7:57 AM, Alan Gutierrez a...@prettyrobots.com wrote:
When I write beyond the end of a
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
On Sat, Aug 18, 2012 at 10:31:32AM -0700, Nathan Rajlich wrote:
On Sat, Aug 18, 2012 at 7:57 AM, Alan Gutierrez a...@prettyrobots.com wrote:
When I write beyond the end of a `Buffer`, nothing bad happens. I'm
expecting a
earth-shattering kaboom, or at least an exception. I'm happier with
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
I prefer Wind.js for following reasons:
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)
it's called coroutines, skip the syntactic BS
On Aug 18, 6:44 pm, Tony Huang cnwz...@gmail.com wrote:
I prefer Wind.js for following reasons:
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
13 matches
Mail list logo
