Re: [nodejs] Re: fibers 0.5; say "no" callbacks (when it makes sense in your application)

[Marcel Laverdet]

> When things get complex, issues like race conditions and deadlocks
sometimes become really hard to debug.

Race conditions and deadlocks are not a pitfall of cooperative
multitasking. There are plenty of legit reasons to not use Fibers but I
don't think this is one of them.


On Fri, Nov 9, 2012 at 7:47 PM, JeanHuguesRobert  wrote:

> Le samedi 10 novembre 2012 01:12:18 UTC+1, Alexey Petrushin a écrit :
>
> Why there are so many negative responses about fibers?
>>
>
> Using fibers (or threads) is not always as easy at it first seems. When
> things get complex, issues like race conditions and deadlocks sometimes
> become really hard to debug.
>
> Sticking to the "single thread event loop + callbacks" of Javascript is
> respectable "safe" option, with well known drawbacks.
>
> This whole "fibers vs callback" stuff reminds me of what happened with
> "remote objects". There were attempts to "hide" the "remote nature" of
> remote objects, to make them look like "local objects", typically using
> "proxi objects". This is still a popular option. However, the failure of
> solutions like Corba, Soap or java's wsdl, is a clear indication that
> "hiding" the remote nature of remote objects does not work so well in
> practice. "ro.xx()" looks nice but does not deal so well with network
> issues (timeouts, deconnections/reconnections, retries, etc).
>
> Fibers are a similar attempt to "hide" the asynchronous nature of some
> functions. It looks nice but does not deal so well
> with synchronization issues. However things can get better if some higher
> level lib is used to handle these issues.
>
> But this is true with callbacks too. There are a lot of "flow
> control libraries" available.
>
> As a matter of fact I am developing one right now. It should look familiar
> to those used to similar libraries based on threads.
>
> With this lib, the "infamous" "pipe" example from the start of this google
> thread looks like this:
>
>   function pipe( inStream, outStream, callback ){
>   l8.begin
> .repeat( function(){ l8
>   .step( function(){ inStream.read( l8.next) })
>   .step( function( err, data ){
> if( err )  throw err;
> if( !data) l8.break;
> outStream.write( data, l8.next);
>   })
>   .step( function( err ){ if( err ) throw err; })
> })
> .success( function(){  callback() })
> .failure( function( err ){ callback( err) })
>   .end}
>
> It's nicer using CoffeeScript:
>
>   pipe = l8.scope (in,out,cb) ->
> @repeat ->
>   @step -> in.read @next
>   @step (err, data) ->
> throw err if err
> @break if !data
> out.write data, @next
>   @step (err) -> throw err if err
> @success -> cb()
> @failure -> cb @error
>
> This is not the shortest version ever published, yet it is reasonably
> readable and does not try to "hide" the asynchronous nature of .read() &
> .write()
>
> More details here: https://github.com/JeanHuguesRobert/l8
>
> My lib is not ready yet, but I am sure that you can find some other
> ones easily.
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] How to properly pass Local as function param?

[Marcel Laverdet]

You should probably just be using Handle<> in most of your function
parameters. The only reason to specify Local<> or Persistent<> instead of
the more generic superclass Handle<> is when you need to manage the
lifetime of the object. It's generally not the callee's job to manage the
memory of the underlying handle, so it doesn't need to know if a given
handle is local or persistent.

If it's async you should still probably use Handle<> for the argument, but
then you can create your own persistent reference to it via
Persistent<>::New(handle).


On Sun, Nov 11, 2012 at 7:34 PM, Ryan Cole  wrote:

> Ok thanks for the help. I think through this code I'm writing I've at
> least nailed down when to use those two handle types. Thanks again!
>
> Ryan
>
> On Sunday, November 11, 2012 9:19:44 PM UTC-6, Ben Noordhuis wrote:
>
>> On Mon, Nov 12, 2012 at 4:16 AM, Ryan Cole  wrote:
>> > Ok awesome, thanks for the reads. Also, just to deliberately ask, what
>> about
>> > in async function calls? I'm assuming I'd not use Local? For
>> > example, if I were using the baton pattern, would my baton struct use a
>> > Local? I've seen examples for callback functions that use
>> > Persistent, so that makes me think I'd use Persistent
>> to
>> > cross those function calls?
>>
>> Yes, Persistent.
>>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] where is interval id in 0.8.14?

[Marcel Laverdet]

Seems that this /could/ create issues if you did something like this:

var timers = {};
var timer = setTimeout(function() { ... }, 100);
timers[timer] = timer;
for (var ii in timers) {
  clearTimeout(ii);
  unset(timers[ii]);
}

The spec does specify that it must be a number, however this was likely a
calculated deviation because the possible performance benefits of using a
non-scalar seem pretty clear.

On Wed, Nov 21, 2012 at 11:34 PM, Shigeki Ohtsu  wrote:

> Timers on browsers are defined in HTML5 spec.
> http://www.whatwg.org/specs/**web-apps/current-work/**
> multipage/timers.html#timers
>
> So setInterval() of Chrome returns  a long integer as a handle, however,
>  that of Node returns an object which need not follow the HTML5 spec.
>
>
> (2012/11/22 12:44), kuno wrote:
>
>> I just noticed that the return value of setInterval function in
>> chrome/node are different.
>>
>> In chrome the setInterval function returns a integer as the id, but in
>> node 0.8.14, it return a object like this:
>> ```
>> { ontimeout: [Function] }
>> ```
>>
>> and the ontimeout function itself look like this:
>> ```
>> function () {
>> callback.apply(timer, args);
>>   }
>> ```
>>
>> Can someone kind enough to explain me, why?
>>
>> --
>> 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
>>
>
> --
> 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
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] "this" and that

[Marcel Laverdet]

> var myobj = require( the-file );
> eval( 'myobjs.' + file-name = myobj;');

How has no one commented on the fact that you're doing
numeric arithmetic on a bunch of strings? All this is going to do is give
you a parse error, and when you fix that you're just doing require(NaN).

With all due respect to your 25 years of software I do think you need to
take a step back and start with the basics here until you build up a good
foundation. I don't think you're in the position right now to fully reason
whether eval() is evil or not. You can trust Rick, he is a JS oracle.

On Wed, Dec 12, 2012 at 9:43 PM, Rick Waldron wrote:

>
> On Wednesday, December 12, 2012 at 8:09 PM, Jorge Chamorro wrote:
>
> On 13/12/2012, at 01:47, Rick Waldron wrote:
>
>
> On Wed, Dec 12, 2012 at 7:20 PM, Jorge Chamorro 
> wrote:
> On 12/12/2012, at 18:37, Rick Waldron wrote:
>
>
> On Wed, Dec 12, 2012 at 2:17 AM, Isaac Schlueter  wrote:
> On Tue, Dec 11, 2012 at 7:18 PM, spqr  wrote:
>
> maybe my question should have been "why does JavaScript have eval()?" ;-)
>
>
> I think a lot of people have wondered the same thing.
>
> Yes, it has its uses, but at this point, I don't know of any that
> aren't better served using some other mechanism. eval() has weird
> optimization-destroying semantics that cannot ever be changed, due to
> the fact that JavaScript must be backwards compatible forever.
>
>
> Runtime code generation? new Function( thecode ) works just as well, I
> guess
>
>
> ...sometimes:
>
> (function (p) {
>
> eval("(function(){console.log(p)})")();
>
> try {
> Function("console.log(p)")();
> }
> catch (e) {
> console.log("FAIL -> "+ e.message);
> }
>
> })("OK");
>
> OK
> FAIL -> Can't find variable: p
>
>
> Of course not, but that's not what I was talking about, is it? I
> definitely said "Runtime code generation", by which I meant "the entire
> program" is first generated, by some means, into a string, which is then
> eval'ed. See also: Traceur, CoffeeScript (anything the compiles something
> else into JavaScript at runtime)
>
>
>
> (Sorry I hit send too soon)
>
> Well put, simple as that, I completely agree.
>
> What eval() is: a call right to the compiler as in compile(program), which
> is -no matter what they say- a very nice -power- feature to have.
>
> And a footgun? Perhaps *sometimes*, yes, so? Beware and don't be fool!
>
> Yet the fools are foolish and there's little to do about that, neither
> eval() *nor*the*threads* are evil, nor the culprits.
>
>
> I agree with every single word and all of the sentiments they imply.
>
> Rick
>
> --
> Jorge.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Inconsistent method names?

[Marcel Laverdet]

As for readdir (and many other functions in the fs module) they are named
to match the underlying POSIX function name. For instance:
http://linux.die.net/man/3/readdir

readFile is an abstraction created by Node so it adheres to naming
standards.

On Thu, Dec 27, 2012 at 12:02 PM, David Habereder  wrote:

> Hi,
>
> I am quite new to node.js.
>
> As far as I can see the method names aren't very consistent. Take the
> methods from File System for example: http://nodejs.org/api/fs.html
> It is ".readFile" (Camelcase)
> But it is ".readdir" (all lowercase)
>
> There are a few more such cases where I don't see a pattern when camelcase
> is used and when not.
>
> You could say that this is absolutely irrelevant and you would be right.
> But it annoys me :-(
> And it reminds me of PHP syntax garbage.
>
> Is there any interest in getting all method names either camelcase or
> lowercase, or will this just stay as is?
>
> ~dave
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] One complicated SQL query or many smaller ones

[Marcel Laverdet]

This is not always true. It's much easier to add more database clients than
it is to add database servers. Offloading work from a hot database server
to a web cluster can be just as good of an idea.. it depends a lot on your
infrastructure and there's no golden bullet for this guy.

On Wed, Dec 26, 2012 at 5:23 PM, Jonathan Chayce Dickinson <
jonathand...@gmail.com> wrote:

> it's usually good to offload as much work to SQL as possible

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Coping with invalid http headers

[Marcel Laverdet]

Apply this patch:
https://gist.github.com/4487528

Node shouldn't be barfing on anything a browser can display and should
really be more tolerant of these failures. I should submit a PR.. but not
sure if this will cause other issues down the road.

On Tue, Jan 8, 2013 at 12:42 PM, Matt  wrote:

> We're doing web scraping using node and coming across an issue that we
> cannot fetch a particular URL on a particular web site, because it sends
> back: "Content-Length: 1234,1234"
>
> I totally understand that node's http parser doesn't deal with this, and
> throws an error, but is there any way we can intercept this and fix it up?
> The only way I can think of is using a proxy written in another language,
> which seems like a sucky solution.
>
> Thoughts?
>
> Here's some test code to demonstrate this:
>
> var assert = require('assert');
> var http = require('http');
>
> var seen_req = false;
>
> var server = http.createServer(function(req, res) {
>   assert.equal('GET', req.method);
>   assert.equal('/foo?bar', req.url);
>   res.writeHead(200, {'Content-Type': 'text/plain', 'Content-Length':
> '6,6'});
>   res.write('hello\n');
>   res.end();
>   server.close();
>   seen_req = true;
> });
>
> server.listen(12345, function() {
>   http.get('http://127.0.0.1:' + 12345 + '/foo?bar');
> });
>
> process.on('exit', function() {
>   assert(seen_req);
> });
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Coping with invalid http headers

[Marcel Laverdet]

omg I can't believe you've done this.

Obviously this won't work if the server doesn't send
"Content-Length" capitalized like you have here, but if you're only
designing against one service that's not a huge issue. You should be aware
though that this may fail in certain rare circumstances, or under heavy
load. If the response header is received in two TCP segments the parsing
here will fail. Parsing is difficult and half assing it will come back to
bite you in the future.

On Tue, Jan 8, 2013 at 3:01 PM, Matt  wrote:

> Rather than go into patching anything, I managed to get this to work:
>
> r.on('request', function (req) {
> req.on('socket', function () {
> var oldOnData = req.socket.ondata;
> var first_packet = true;
> req.socket.ondata = function (d, start, end) {
> if (first_packet) {
> first_packet = false;
> var pos = d.indexOf("Content-Length:", start);
> if (pos === -1) {
> return oldOnData.apply(req.socket, arguments);
> }
> var seen_comma = false;
> var i = pos + start + 15;
> while (i < end && d[i] !== 0x0a) {
> console.log("Saw: " + String.fromCharCode(d[i]) +
> " (" + d[i] + ") at pos: " + i, "blue");
> if (d[i] === 44) {
> seen_comma = true;
> }
> if (seen_comma) {
> d[i] = 32; // set to space
> }
> i++;
> }
> }
> return oldOnData.apply(req.socket, arguments);
> }
> })
> })
>
> Hacky and a bit nasty, but works, at least with node 0.6 (have to check if
> the same process applies on 0.8).
>
>
> On Tue, Jan 8, 2013 at 3:18 PM, Marcel Laverdet wrote:
>
>> Apply this patch:
>> https://gist.github.com/4487528
>>
>> Node shouldn't be barfing on anything a browser can display and should
>> really be more tolerant of these failures. I should submit a PR.. but not
>> sure if this will cause other issues down the road.
>>
>> On Tue, Jan 8, 2013 at 12:42 PM, Matt  wrote:
>>
>>>  We're doing web scraping using node and coming across an issue that we
>>> cannot fetch a particular URL on a particular web site, because it sends
>>> back: "Content-Length: 1234,1234"
>>>
>>>  I totally understand that node's http parser doesn't deal with this,
>>> and throws an error, but is there any way we can intercept this and fix it
>>> up? The only way I can think of is using a proxy written in another
>>> language, which seems like a sucky solution.
>>>
>>> Thoughts?
>>>
>>> Here's some test code to demonstrate this:
>>>
>>> var assert = require('assert');
>>> var http = require('http');
>>>
>>> var seen_req = false;
>>>
>>> var server = http.createServer(function(req, res) {
>>>   assert.equal('GET', req.method);
>>>   assert.equal('/foo?bar', req.url);
>>>   res.writeHead(200, {'Content-Type': 'text/plain', 'Content-Length':
>>> '6,6'});
>>>   res.write('hello\n');
>>>   res.end();
>>>   server.close();
>>>   seen_req = true;
>>> });
>>>
>>> server.listen(12345, function() {
>>>   http.get('http://127.0.0.1:' + 12345 + '/foo?bar');
>>> });
>>>
>>> process.on('exit', function() {
>>>   assert(seen_req);
>>> });
>>>
>>>  --
>>> 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+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>
>>
>>  --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Maili

Re: [nodejs] Coping with invalid http headers

[Marcel Laverdet]

By heavy load I'm talking about network traffic, either on your end, their
end, or any hop in between. "In the first packet" is certainly *not*
something I'd recommend anyone to depend on, as that depends on a whole lot
of things.

The monkey patching is gross, but hey it works. The only thing here that's
going to come back at you is making assumptions about TCP segments. I urge
you to rework that hack to search character-by-character and over packet
boundaries.

On Tue, Jan 8, 2013 at 3:49 PM, Matt  wrote:

> Exactly, it's designed for this one service which always sends the
> Content-Length capitalized like this, and screwed up with the comma, and in
> the first packet. If there's other screwy things in the future we can deal
> with them then. Believe me I know all about parsing headers (I had to write
> the parser for SMTP headers by hand for Haraka). It's far easier to fix
> this in JS code than to have to remember to patch node every time we
> upgrade.
>
> Not sure what you're thinking about with "under heavy load" - I can't
> imagine why that would affect anything. Got some way to elaborate on that?
>
>
> On Tue, Jan 8, 2013 at 4:42 PM, Marcel Laverdet wrote:
>
>> omg I can't believe you've done this.
>>
>> Obviously this won't work if the server doesn't send
>> "Content-Length" capitalized like you have here, but if you're only
>> designing against one service that's not a huge issue. You should be aware
>> though that this may fail in certain rare circumstances, or under heavy
>> load. If the response header is received in two TCP segments the parsing
>> here will fail. Parsing is difficult and half assing it will come back to
>> bite you in the future.
>>
>>
>> On Tue, Jan 8, 2013 at 3:01 PM, Matt  wrote:
>>
>>> Rather than go into patching anything, I managed to get this to work:
>>>
>>> r.on('request', function (req) {
>>> req.on('socket', function () {
>>> var oldOnData = req.socket.ondata;
>>> var first_packet = true;
>>> req.socket.ondata = function (d, start, end) {
>>> if (first_packet) {
>>> first_packet = false;
>>> var pos = d.indexOf("Content-Length:", start);
>>> if (pos === -1) {
>>> return oldOnData.apply(req.socket, arguments);
>>> }
>>> var seen_comma = false;
>>> var i = pos + start + 15;
>>> while (i < end && d[i] !== 0x0a) {
>>> console.log("Saw: " + String.fromCharCode(d[i])
>>> + " (" + d[i] + ") at pos: " + i, "blue");
>>> if (d[i] === 44) {
>>> seen_comma = true;
>>> }
>>> if (seen_comma) {
>>> d[i] = 32; // set to space
>>> }
>>> i++;
>>> }
>>> }
>>> return oldOnData.apply(req.socket, arguments);
>>> }
>>> })
>>> })
>>>
>>> Hacky and a bit nasty, but works, at least with node 0.6 (have to check
>>> if the same process applies on 0.8).
>>>
>>>
>>> On Tue, Jan 8, 2013 at 3:18 PM, Marcel Laverdet wrote:
>>>
>>>> Apply this patch:
>>>> https://gist.github.com/4487528
>>>>
>>>> Node shouldn't be barfing on anything a browser can display and should
>>>> really be more tolerant of these failures. I should submit a PR.. but not
>>>> sure if this will cause other issues down the road.
>>>>
>>>> On Tue, Jan 8, 2013 at 12:42 PM, Matt  wrote:
>>>>
>>>>>  We're doing web scraping using node and coming across an issue that
>>>>> we cannot fetch a particular URL on a particular web site, because it 
>>>>> sends
>>>>> back: "Content-Length: 1234,1234"
>>>>>
>>>>>  I totally understand that node's http parser doesn't deal with this,
>>>>> and throws an error, but is there any way we can intercept this and fix it
>>>>> up? The only way I can think of is using a proxy written in another
>>>>> langua

Re: [nodejs] Coping with invalid http headers

[Marcel Laverdet]

"First packet" may not always be the first packet, given Connection:
keep-alive. Basically what I'm saying is that there are no guarantees that
this will continue working, or work consistently. You seem to have a good
understanding of the risks involved, but for me I'd sooner use
child_process.spawn('curl', [url]) over the monkey patch.

On Tue, Jan 8, 2013 at 7:34 PM, Matt  wrote:

> On Tue, Jan 8, 2013 at 5:24 PM, Marcel Laverdet wrote:
>
>> By heavy load I'm talking about network traffic, either on your end,
>> their end, or any hop in between. "In the first packet" is certainly *not*
>> something I'd recommend anyone to depend on, as that depends on a whole lot
>> of things.
>>
>
> Not really - TCP is more reliable that way than you think. No matter the
> load, that first "packet" isn't going to get fragmented to any smaller
> parts. Especially since it's actually SSL, so it's not even really a
> packet, but an event in node happening, with buffering already taking place.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Healthcare needs the help of the Node.js Community

[Marcel Laverdet]

Rob,

>From your articles it's not clear exactly what call to action you're trying
to make. I scanned over them, particularly part 3, and it seems like
progress is already pretty far along? You've got access to your DB in
NodeJS.. Are you looking for assistance in writing a Mumps VM that can run
Mumps code side-by-side with JS?

Additionally, have you heard of Harmony proxies? Based on what it looks
like you're trying to do with your GlobalNode API it seems like it would
make the whole thing much easier to consume. Proxies should be available
right now in Node by running with the --harmony-proxies flag.

On Sat, Jan 26, 2013 at 5:33 AM, rtweed  wrote:

> Please see:
>
>
> http://robtweed.wordpress.com/2013/01/26/to-the-node-js-community-healthcare-needs-your-help/
>
>
>  --
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
>
>

-- 
-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Healthcare needs the help of the Node.js Community

[Marcel Laverdet]

>  I've not heard of Harmony proxies but I'll take a look and see what
you're suggesting.

You really should. They basically give you "catch all" methods on objects
which would let you make an API that more closely resembles the simplicity
of Mumps that you're going for. Here's the operations you get:
proxy[name]: handler.get(proxy, name)
proxy[name] = val: handler.set(proxy, name, val)
name in proxy: handler.has(name)
delete proxy[name]: handler.delete(name)
for (var name in proxy) {...}: handler.iterate()
Object.keys(proxy): handler.keys()

So instead of that setValue() function or whatever you had, you could just
use regular JS.

I think Eric's idea for writing a Mumps interpreter isn't a bad idea. I
looked over the wikipedia pages for this language and it doesn't seem very
complex at all. I don't have an intimate understanding of the language but
it seems possible to write a source-to-source transformation into JS as a
weekend project. Seems like this would drastically reduce the complexity of
your infrastructure, and you get all the speed and research that went into
v8. The biggest thing you need to reconcile (and a question you really need
to think about) is the difference between Mumps' synchronous design and
Node's async design. I hate to be "that guy" but Fibers might be an answer
to that (disclosure: I wrote Fibers).

On Mon, Jan 28, 2013 at 4:16 AM, rtweed  wrote:

> Marcel
>
> As you note, from the basic technical point of view, the key building
> blocks are now in place.  I've not heard of Harmony proxies but I'll take a
> look and see what you're suggesting.
>
> I think I'm trying to make several things happen:
>
> - wake up the current vendors of Mumps-based healthcare applications to
> Node.js as a way for them to attract new blood into their development
> community.  In particular the US Dept of Veterans Affairs, the US Dept of
> Defense and the Indian Health Service need to see this as a solution to a
> long-term problem they've never previously had a sensible way of
> addressing.  They need to learn about Node.js and start focusing their
> minds on moving away from the Mumps language and towards Javascript (and
> stop messing about with other, lesser and inappropriate technologies which
> is what has tended to happen in the past).
>
> - wake up the Node.js community to the opportunity afforded by this huge
> healthcare IT sector.  To this end, a good first step will be striking up a
> dialogue with Luis Ibanez (who has posted in this thread) and using the
> resources of OSEHRA to find out more about how to get into this marketplace
> (Luis is doing a lot of work getting training courses and tutorials
> developed) and how to find out more about Mumps-based applications such as
> VistA.  As Luis has said, this marketplace requires thousands of new
> developers instead of the relative handful of developers it now employs.
>
> - get others in the Node.js community to build on what I've already
> created.  Much of that work, at least initially, will critically require a
> coming-together of the mindsets of the Mumps and Node.js developer
> communities.  The extensive real-world experience of the Mumps development
> community (who understand how to best use Global Storage for healthcare
> application use) needs to come together with the new and modern ideas and
> development approaches of the Node.js community in a way that brings the
> best out of both - both sides need to understand and recognise the skills
> and benefits of the other: it's going to be a fine balance, at least to
> begin with.  What I've created is merely a start, but it has the benefit of
> having been developed by someone who understands the mindset of the Mumps
> developer AND the Node.js developer and, I believe, correctly bridges those
> two communities.
>
> One example of a necessary next step: in VistA, almost all of the database
> access is done indirectly via an extensive set of APIs known as the Fileman
> APIs.  Very little direct access to the underlying Globals is done by VistA
> developers.  Those Fileman APIs need abstracting and encapsulating in
> Javascript so they make sense to Node.js developers.  This is clearly an
> area where experienced Mumps/Fileman developers need to come together with
> Node.js developers and figure out the correct way to do it - it's not an
> area of expertise for me, but I'd be happy to help get the two sides come
> together to make it happen.
>
> By the way, a good, rapid way in for the Node.js developer is to download
> and fire up the dEWDrop VM (http://www.fourthwatchsoftware.com) which is
> a pre-built, pre-configured, ready-to-run, fully Open Source, GT.M-based
> VM, all set up with the NodeM interface and my OO projection.  It also has
> a complete implementation of VistA, pre-configured with in-patient and
> out-patient clinics/wards etc, and complete with a fair amount of test
> patient data.  Probably about $3b-worth of software, if you were to base it
> on development co

Re: [nodejs] Healthcare needs the help of the Node.js Community

[Marcel Laverdet]

> I can't say your suggested Harmony proxies look any more natural to me
than the APIs I've suggested - maybe I'm missing something.

Well, this:
var desc = patient.$('conditions').$(0).$('description')._value;

Could just be this:
var desc = patient.conditions[0].description;

And the whole `_fixProperties()` madness would go away entirely.


> If you expect the code to work in one years time, don't use harmony
proxies.

Idk it seems like Proxies are certainly something that TC39 is pretty
confident will make it in some form. The surface area in the face of a
changing API should be pretty low, but yeah obviously he should use them at
his own risk.

> Last time I looked, fibres wasn't available for Windows which is why I
didn't pursue is as the basis for ewdGateway2 - is this still the case or
have things moved on?

It works on Windows.

On Mon, Jan 28, 2013 at 6:17 PM, rtweed  wrote:

> Marcel
>
> I can't say your suggested Harmony proxies look any more natural to me
> than the APIs I've suggested - maybe I'm missing something.
>
> As to the need for something to overcome the synchronous nature of the
> interface to Mumps, fibres may be an answer, but meanwhile I've onwardly
> developed my original Q-Oper8 Node.js module and morphed it into my
> ewdGateway2 module.  I've not introduced it or documented it yet, but it
> provides the basis of a full-blown web app framework for Mumps-based apps,
> based around my EWD technology.  More information will follow soon.
>
> Last time I looked, fibres wasn't available for Windows which is why I
> didn't pursue is as the basis for ewdGateway2 - is this still the case or
> have things moved on?
>
> Rob
>
>
>
> On Monday, January 28, 2013 11:57:11 PM UTC, Marcel wrote:
>
>> >  I've not heard of Harmony proxies but I'll take a look and see what
>> you're suggesting.
>>
>> You really should. They basically give you "catch all" methods on objects
>> which would let you make an API that more closely resembles the simplicity
>> of Mumps that you're going for. Here's the operations you get:
>> proxy[name]: handler.get(**proxy, name)
>> proxy[name] = val: handler.set(proxy, name, val)
>> name in proxy: handler.has(name)
>> delete proxy[name]: handler.delete(**name)
>> for (var name in proxy) {...}: handler.iterate()
>> Object.keys(proxy): handler.**keys()
>>
>> So instead of that setValue() function or whatever you had, you could
>> just use regular JS.
>>
>> I think Eric's idea for writing a Mumps interpreter isn't a bad idea. I
>> looked over the wikipedia pages for this language and it doesn't seem very
>> complex at all. I don't have an intimate understanding of the language but
>> it seems possible to write a source-to-source transformation into JS as a
>> weekend project. Seems like this would drastically reduce the complexity of
>> your infrastructure, and you get all the speed and research that went into
>> v8. The biggest thing you need to reconcile (and a question you really need
>> to think about) is the difference between Mumps' synchronous design and
>> Node's async design. I hate to be "that guy" but Fibers might be an answer
>> to that (disclosure: I wrote Fibers).
>>
>> On Mon, Jan 28, 2013 at 4:16 AM, rtweed  wrote:
>>
>>> Marcel
>>>
>>> As you note, from the basic technical point of view, the key building
>>> blocks are now in place.  I've not heard of Harmony proxies but I'll take a
>>> look and see what you're suggesting.
>>>
>>> I think I'm trying to make several things happen:
>>>
>>> - wake up the current vendors of Mumps-based healthcare applications to
>>> Node.js as a way for them to attract new blood into their development
>>> community.  In particular the US Dept of Veterans Affairs, the US Dept of
>>> Defense and the Indian Health Service need to see this as a solution to a
>>> long-term problem they've never previously had a sensible way of
>>> addressing.  They need to learn about Node.js and start focusing their
>>> minds on moving away from the Mumps language and towards Javascript (and
>>> stop messing about with other, lesser and inappropriate technologies which
>>> is what has tended to happen in the past).
>>>
>>> - wake up the Node.js community to the opportunity afforded by this huge
>>> healthcare IT sector.  To this end, a good first step will be striking up a
>>> dialogue with Luis Ibanez (who has posted in this thread) and using the
>>> resources of OSEHRA to find out more about how to get into this marketplace
>>> (Luis is doing a lot of work getting training courses and tutorials
>>> developed) and how to find out more about Mumps-based applications such as
>>> VistA.  As Luis has said, this marketplace requires thousands of new
>>> developers instead of the relative handful of developers it now employs.
>>>
>>> - get others in the Node.js community to build on what I've already
>>> created.  Much of that work, at least initially, will critically require a
>>> coming-together of the mindsets of the Mumps and Node.js developer
>>> 

Re: [nodejs] Re: advice on try/catch implementation

[Marcel Laverdet]

My race condition would like to have a talk with you.

On Sat, Feb 2, 2013 at 9:37 PM, Paul Vencill  wrote:

> I wouldn't do the try..catch at all, I'd just do a fs.exists(..) call to
> see if the files were there before requiring them.
>
>
> On Wednesday, January 30, 2013 5:45:01 AM UTC-5, Norman Khine wrote:
>>
>> i have this code from an node.js/express application i am trying to
>> develop:
>>
>> var blade = require('blade')
>> ,express = require('express')
>> ,http = require('http')
>> ,https = require('https')
>> ,fs = require('fs')
>> ,nowjs = require('now')
>> ,City = require('geoip').City,json;
>>
>> var city = new City('data/GeoLiteCity.dat' );
>>
>> var GOOGLE_API_KEY = process.env.GOOGLE_API_KEY;
>>
>> var TABLE_ID = "**1epTUiUlv5NQK5x4sgdy1K47ACDTpH**H60hbng1qw";
>> //var TABLE_ID ="**1obpi0bmSDILX1cIQcVRNi1lUkm2K5**xBFztmRFiM"
>>
>> var GOOGLE_PATH = "/fusiontables/v1/query?sql=**
>> SELECT%20*%20FROM%20"+TABLE_**ID+"&key="+GOOGLE_API_KEY;
>> var GOOGLE_DRIVE_PATH = "/drive/v2/files/"+TABLE_ID+"?**
>> key="+GOOGLE_API_KEY;
>>
>> var options = {
>> hostname: 'www.googleapis.com'
>> ,port: 443
>> ,method: 'GET'
>> };
>>
>> var lastModifiedDate = '';
>>
>> TZMNetwork(TABLE_ID);
>>
>> function TZMNetwork(fileId) {
>> if (fs.existsSync("data/chapters.**json")) {
>> var x = '';
>> options["path"] = GOOGLE_DRIVE_PATH;
>> var req = https.request(options, function(res) {
>>   res.on('data', function(d) {
>>   x += d.toString();
>>   //console.log(d.toString());
>>   }).on('end', next);
>> });
>> req.end();
>>
>> req.on('error', function(e) {
>>   console.error(e);
>> });
>>
>> function next() {
>> var l = JSON.parse(x);
>> var modifiedDate = l.modifiedDate.toString();
>> if (!lastModifiedDate === modifiedDate) {
>> console.log('chapters.json is out of date');
>> getChapters();
>> }
>> //console.log(l.modifiedDate);
>> //options['modifiedDate'] = l.modifiedDate.toString();
>> lastModifiedDate += l.modifiedDate.toString();
>> }
>> console.log('OK');
>> } else {
>> getChapters();
>> }
>> }
>>
>> function getChapters() {
>> options["path"] = GOOGLE_PATH;
>> var file = fs.createWriteStream("data/**chapters.json");
>> var req = https.request(options, function(res) {
>>   res.on('data', function(data) {
>>   file.write(data);
>>   }).on('end', function() {
>>   file.end();
>>   console.log("chapters.json created");
>>   });
>> });
>> req.end();
>>
>> req.on('error', function(e) {
>>   console.error(e);
>> });
>> }
>>
>> function dumpError(err) {
>>   if (typeof err === 'object') {
>> if (err.message) {
>>   console.log('\nMessage: ' + err.message)
>> }
>> if (err.stack) {
>>   console.log('\nStacktrace:')
>>   console.log('=**===')
>>   console.log(err.stack);
>> }
>>   } else {
>> console.log('dumpError :: argument is not an object');
>>   }
>> }
>>
>> var app = express();
>> app.use(blade.middleware(__**dirname + '/views') ); //for client-side
>> templates
>> app.use(express.favicon(__**dirname + '/public/images/favicon.ico'))**;
>> app.use(express.static(__**dirname + '/public') ); //maybe we have some
>> static files
>> //app.use(blade.middleware(__**dirname + '/views') ); //for client-side
>> templates
>> app.use(express.static(__**dirname + "/public") ); //maybe we have some
>> static files
>> app.set('views', __dirname + '/views'); //tells Express where our views
>> are stored
>> try {
>> app.set('translation', require(__dirname + '/public/locales/dev/**
>> translation.json'));
>> app.set('chapters', require(__dirname + '/data/chapters.json'));
>> } catch(err) {
>>   dumpError(err);
>>   console.log('there is no /data/chapters.json');
>>   app.set('chapters', []);
>> }
>> app.set('view engine', 'blade'); //Yes! Blade works with Express out of
>> the box!
>> app.get('/', function(req, res, next) {
>> TZMNetwork(TABLE_ID);
>> console.log(lastModifiedDate);
>> res.render('index');
>> });
>> app.get( '/map', function( req, res, next ) {
>> var ip = ( req.connection.remoteAddress !== "127.0.0.1" )?
>> req.connection.remoteAddress: "72.196.192.58";
>> city.lookup( ip, function( err, loc ) {
>> if ( err ) {
>> loc = {};
>> }
>> res.render( 'map', { loc: loc } );
>> });
>> });
>>
>> app.locals.pretty=true;
>> app.listen(29080);
>> console.log('Server running at http://127.0.0.1:29080/');
>>
>>
>> basically when the applications starts, i have this try/catch:
>>
>> try {
>> app.set('translation', require(__dirname + '/public/locales/dev/**
>> translation.json'));
>> app.set('chapters', require(__dirname + '/data/chapter

Re: [nodejs] Re: why fallocate is not exposed?

[Marcel Laverdet]

> Sorry if I was unclear but I'm asking about specific use cases, i.e. what
are _you_ going to use it for?

I think this is one of those cases where the potential uses are actually
fairly clear and non-theoretical. For instance, I built a quick & dirty
version of Facebook's Haystack service in Node, and it would benefit
greatly from fallocate()
https://www.facebook.com/note.php?note_id=76191543919

You could benefit from this with large file uploads, loud log files, and
others. Really this is something that might just be better off in fs-ext
(which I'm already using for flock) if you can't emulate it in Windows.

On Sat, Feb 23, 2013 at 8:27 AM, Ben Noordhuis  wrote:

> On Sat, Feb 23, 2013 at 10:36 AM, funny_falcon 
> wrote:
> > Fallocate is prooved to be useful when you are dealing with huge
> > amount of ondisk data.
> > Especially when you need to separately grow hundreds of thousand
> > files, and then be sure it doesn't lead to huge fragmentation.
>
> Sorry if I was unclear but I'm asking about specific use cases, i.e.
> what are _you_ going to use it for?
>
> Requests for obscure features come up regularly.  The conversation
> usually goes something like this:
>
>   "Hey, can you add support for X?"
>   "Sure.  What is X good for?"
>   "Oh, it's absolutely essential when you ."
>   "Duly noted.  What are you building that you need X?"
>   "Um, nothing.  But I read about it on Hacker News and it sounded really
> cool."
>
> (I'm only half-joking, sadly.)
>
> Back on topic, fallocate() is a Linux-ism that we can only partially
> emulate on other platforms.  Unless you can present some really
> compelling reasons why it should be part of core libuv / node.js, I
> will probably tell you to implement it as an add-on.
>
> --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Immediately-Invoked Function Expressions Demystified

[Marcel Laverdet]

This doesn't do too much to demystify anything, imo.

> Now how that works... I have no idea, but I do believe that it's more
aesthetic and so that's how I write my code. I won't argue if you feel
differently.

It works because (foo)() is identical to foo().

> The only reason that that even works at all is because there's magic
going on behind the scenes that hoists the anonymous function up to the top
(just like with variables) and then calls that function reference.

What am I reading? Function expression are not hoisted.

Also setTimeout() takes optional parameters to pass to the callback:

setTimeout(function(a) { console.log(a) }, 0, 'hello')
hello

Also there's Function.prototype.bind()

On Tue, Mar 19, 2013 at 7:48 PM, Jake Verbaten  wrote:

> Is there any good reason to ever use IIFE given that commonJS wraps my
> file in a closure.
>
> Can't every use-case for IIFE be replaced with write more smaller modules.
> At least I havn't used them in months.
>
>
> On Tue, Mar 19, 2013 at 11:44 AM, AJ ONeal  wrote:
>
>> Yeah, it's a good read.
>>
>> I wouldn't say the one precludes the other. We're both explaining a
>> thing, but in the context of different other things (my focus is on the
>> safety benefits).
>>
>> AJ ONeal
>>
>> On Tue, Mar 19, 2013 at 12:16 PM, Rick Waldron wrote:
>>
>>> See also
>>>
>>> http://benalman.com/news/2010/11/immediately-invoked-function-expression/
>>>
>>> Not trying to rain on any parades, but Ben coined the term and his
>>> article is comprehensive
>>>
>>> Rick
>>>
>>>
>>>
>>>
>>> On Tue, Mar 19, 2013 at 2:07 PM, AJ ONeal  wrote:
>>>
 Article + Screencast


 http://blog.coolaj86.com/articles/how-and-why-auto-executing-function.html

 AJ ONeal


>>  --
>> --
>> 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+unsubscr...@googlegroups.com
>> 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 nodejs+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Immediately-Invoked Function Expressions Demystified

[Marcel Laverdet]

> Dude. Type `function () {} ()` into a browser console and hit enter.
That's my point. It's an error. That's why I say it's not equivalent. You
MUST have the parens.

I hate to be that guy but you really need to read the spec. It's not just a
joke that people say, it's actually really quite well-written and helpful.
I know I've spent probably a full day of my life looking at that damn PDF.
Specifically, check out the differences between a FunctionExpression and a
FunctionDeclaration. One is hoisted, one is by definition never hoisted.
Also listen to Rick, I can assure you he knows what he's talking about.

> Yes "hoisted". That function is not created there in the loop. It is
created at the top just like

You are wrong and it's not hoisted. You are creating multiple copies of the
same function.

> It behaves as if hoisted.

No, it doesn't.

var foo = [];
for (var ii = 0; ii < 2; ++ii) {
  foo.push(function() {});
}
console.log(foo[0] === foo[1]);

`false`

On Wed, Mar 20, 2013 at 1:10 AM, AJ ONeal  wrote:

> So foo() is NOT identical to (foo)() where foo is function () {}.
>
>>
>> Yes, they are.
>>
>
> Dude. Type `function () {} ()` into a browser console and hit enter.
> That's my point. It's an error. That's why I say it's not equivalent. You
> MUST have the parens.
>
>
>> No, FunctionExpression (assignments) _do_ _not_ get hoisted.
>>
>
> I wasn't referring to the assignment. I was referring to the reference in
> the first place.
>
>  What actually happens is this
>>>
>>> function something() {console.log};
>>> for () {
>>>   x = something;
>>> }
>>>
>>
>>  No, the FunctionExpression assignment _does_ _not_ magically become a
>> FunctionDeclaration.
>>
>
>
>>
>> console.log( "x" in this );
>> for ( var i = 0; i < 1; i++ ) {
>>   x = function () { console.log(i) }; // <--- NOT hoisted
>> }
>> false
>>
>
> Yes "hoisted". That function is not created there in the loop. It is
> created at the top just like
>
> function foo() {
> }
>
> And then the reference is what's used in the loop.
>
> By the strictest technical sense you can argue that it's not real
> hoisting, but in essence, it is. It behaves as if hoisted. Otherwise the
> naive example of
>
> for (i; i < len; i += 1) {
>   fns.push(function () { console.log(i) });
> }
>
> would work. It doesn't work because the function isn't created there. It's
> just a reference to the hoisted function. It's hoisted anonymously, but
> it's still hoisted.
>
>  setTimeout(function(a) { console.log(a) }, 0, 'hello')
 hello

>>>
>>> Well, duh. Anyone with years of JavaScript experience knows that!
>>>
>>
>> Are you sure? His point was that you were creating the IIFE in a loop
>> instead of passing the argument explicitly—which you can.
>>
>> for ( var i = 0; i < 5; i++ ) {
>>   setTimeout(function(a) { console.log(a); }, 0, i);
>> }
>>
>
> Yeah. I know that. And you know that. But, and I quote:
>
> "And when that doesn't work (because it prints *10* ten times) they find
> some crazy example online that tells them to do this nonsense:"
>
> I already agree that it's not the good solution. I'm just saying that it's
> a common
>
>
>
>
>
> --
> AJ ONeal
> (317) 426-6525
>
>  --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Immediately-Invoked Function Expressions Demystified

[Marcel Laverdet]

It is fairly tricky, all things considered. It's one of
two syntactic "ambiguities" in the language that are, rather
unconventionally, resolved with a one-off rule. Basically the rule here is
that "no statement may begin with a FunctionExpression". Consider that:

This works:
foo();
function foo(){};

This doesn't:
foo();
!function foo(){};

One is an ExpressionStatement, the other is a FunctionStatement.

The other ambiguity is curly braces being overloaded for both block
statements and object literals. That too is resolved with a one-off rule of
"no statement may begin with an object literal".

On Thu, Mar 21, 2013 at 5:47 AM, AJ ONeal  wrote:

> First, I concede to the empirical evidence disproving my assertion that
> the expression was hoisted. I have been shown the light (in a way such that
> it has spoken unto mine own understanding) and I now believe. Thanks
> Geerten.
>
> This is why the paren placement boggles me:
>
> 42.toString() // Errorinated
> (42).toString() // Successified
> (42.toString()) // BELETED
>
> I would expect the same behavior here
>
> function () {} ().toString()
> (function () {}).toString()
> (function () {}.toString()) // WORKS !?!?!
>
> That's why I find it odd that the placement of the parens is unimportant.
>
> I don't know what the spec says about it, but the behavior appears
> inconsistent and therefore unintuitive.
>
> AJ ONeal
>
> --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Re: V8 team will start working on generators

[Marcel Laverdet]

?_? node has had generators since early 2011.

;) ;) ;)


On Fri, Mar 29, 2013 at 9:53 PM, Bruno Jouhier  wrote:

> Good news!
>
> For us the migration be a one line code change! Will be interesting to
> compare the performance between generators and callbacks.
>
> Bruno
>
>
> On Thursday, March 28, 2013 8:17:30 PM UTC+1, cpprototypes wrote:
>>
>> Source: 
>> http://code.google.com/p/v8/**issues/detail?id=2355
>>
>> I think generators have the potential to greatly change how node.js code
>> is written (for example it could look like this http://taskjs.org).
>> However, it depends on many factors:
>>
>> 1) How easy will it be to migrate existing node.js code?  It seems that
>> most of the community has decided that a simple async library (
>> https://github.com/caolan/**async ) is
>> good enough instead of promises.  So it may be difficult to migrate that to
>> something like tasks.js or anything else using generators.
>>
>> 2) Since node.js developers are used to chaining callbacks and using
>> async library, there may be a lot of inertia to overcome before generators
>> can have much impact.
>>
>> 3) What kind of impact, if any, will generators have on the core node.js
>> API?
>>
>>
>>  --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Re: V8 team will start working on generators

[Marcel Laverdet]

https://github.com/laverdet/node-fibers

(only slightly trolling)


On Sat, Mar 30, 2013 at 3:49 PM, Mark Hahn  wrote:

> > node has had generators since early 2011
>
> Reference please?
>
>
> On Fri, Mar 29, 2013 at 9:22 PM, Marcel Laverdet wrote:
>
>> ?_? node has had generators since early 2011.
>>
>> ;) ;) ;)
>>
>>
>> On Fri, Mar 29, 2013 at 9:53 PM, Bruno Jouhier wrote:
>>
>>> Good news!
>>>
>>> For us the migration be a one line code change! Will be interesting to
>>> compare the performance between generators and callbacks.
>>>
>>> Bruno
>>>
>>>
>>> On Thursday, March 28, 2013 8:17:30 PM UTC+1, cpprototypes wrote:
>>>>
>>>> Source: 
>>>> http://code.google.com/p/v8/**issues/detail?id=2355<http://code.google.com/p/v8/issues/detail?id=2355>
>>>>
>>>> I think generators have the potential to greatly change how node.js
>>>> code is written (for example it could look like this http://taskjs.org).
>>>> However, it depends on many factors:
>>>>
>>>> 1) How easy will it be to migrate existing node.js code?  It seems that
>>>> most of the community has decided that a simple async library (
>>>> https://github.com/caolan/**async <https://github.com/caolan/async>)
>>>> is good enough instead of promises.  So it may be difficult to migrate that
>>>> to something like tasks.js or anything else using generators.
>>>>
>>>> 2) Since node.js developers are used to chaining callbacks and using
>>>> async library, there may be a lot of inertia to overcome before generators
>>>> can have much impact.
>>>>
>>>> 3) What kind of impact, if any, will generators have on the core
>>>> node.js API?
>>>>
>>>>
>>>>  --
>>> --
>>> 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+unsubscr...@googlegroups.com
>>> 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 nodejs+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>  --
>> --
>> 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+unsubscr...@googlegroups.com
>> 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 nodejs+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] How to copy Value in different thread?

[Marcel Laverdet]

You need to grab a Persistent handle, not a Local one. Local handles are
only valid in the current scope, once the current HandleScope unwinds the
handle is invalid. In the case of threads, this is what you are running
into.

Your problem can be fixed as easily as doing:
Persistent handle = Persistent::New(local_handle);

Where local_handle is whatever you have now. You *must* be sure to call
handle.Dispose() on this persistent handle when you're done with it, or it
will never garbage collect. Additionally you still must use the Locker API
or you will run into access violations, even if your thread is read-only.

If you want to actually *copy* the object, that is a little bit more tricky
:)


On Thu, Apr 11, 2013 at 1:28 AM, Jerry Yin  wrote:

> Thanks for your reply. I used locks.
>
> My question is how to share a v8::Local between thread?
>
>
> On Thursday, April 11, 2013 4:24:45 PM UTC+8, Floby wrote:
>>
>> Anything you touch from multiple thread must get a lock
>> http://msdn.microsoft.com/en-**us/magazine/cc163744.aspx#S3
>>
>>>
 H.-

 On 4/10/13 11:45 PM, Jerry Yin wrote:
 > Hi,
 >
 > I worked on an addon and tried to put some Value in a global
 > std::vector, and try to use it later in another thread.
 >
 > While when I try to access the Value, it will throw some error
 related thin> to isolation.
 >
 > How to make the value accessible in another thread?
 >
 > Thanks.
 > Jerry
 > --
 >

  --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Algorithm help

[Marcel Laverdet]

You appear to be trying to implement a linear search? If `line[0]` is a
string you could just use an Object which I believe is implemented as some
kind of hash table in v8.

var table = Object.create(null);
var item = table[line[0]];
if (item && item[0] === line[0]) {
  table[line[0]] = line;
}

If `line[0]` isn't scalar please look in to something like a "binary
search" or "trie" if you can.

On Fri, Jun 15, 2012 at 9:20 PM, vitoa  wrote:

> Hi, I me working one a algorithm that is not performing well :/
> First I receive an serial data an event to hanle it
> sp.on('data',function)... this data is stored in array line.
> First field of data contain a unique id and than some values, sometimes
> receive dat from same id and others from diferent id, and i need to put it
> in a table, refresh or add.
> I'm trying to find a record in table, and if it is not found i wish to
> append it to table. However if it find it I want to update it.
>
>
>   z=table.length;
>   while(tempo
>
> if(table[tempo][0] == line[0] )
>  {
> table[tempo]=line;
> console.log('table[tempo] :' + table[tempo] + 'line '+ line);
> tempo=0;
> break;
> }
>
> if(table[tempo][0] != line[0] ){
>
> tempo=tempo+1;
> if(tempo==z){
> console.log('xxx :' + tempo + 'table
> length:'+ z);
> tempo=0;
> break;
> }
> }
>
> }
>
> I dont know why onl can record on id, than all new id are stored in last
> id position and not added to table.
>
> An ideia?
> Regards,
> Vitor
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Algorithm help

[Marcel Laverdet]

Sorry that's your job man..

On Fri, Jun 15, 2012 at 9:30 PM, vitoa  wrote:

> Tanks a lot for quick reply
> Could you help me implemnet that on my posted algorithm?
>
> Regards,
> Vitor
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: Algorithm help

[Marcel Laverdet]

Please keep in mind that getting the "size" of an object like this is NOT a
constant time operation, as it would be with an array.  If you are using
the size frequently you should consider keeping a separate variable with
the length yourself, instead of doing Object.keys(table).length every time.

You can iterate over the table with:
for (var key in table) {
  console.log(key, table[key]);
}

On Sat, Jun 16, 2012 at 12:05 PM, Mark Hahn  wrote:

> I highly recommend using underscore.  _.size and _.keys will get you what
> you want.
>
>
> On Sat, Jun 16, 2012 at 9:41 AM, dolphin 278  wrote:
>
>> You can use Object.keys("yourobjectvariable") to get array of object
>> fields.
>> In your example Object.keys("yourobjectvariable").length will be 2.
>> -
>> Boris Egorov
>> skype/gtalk/nickname: dolphin278
>> mobile: +7 905 728 1543
>>
>>
>>
>> On Sat, Jun 16, 2012 at 8:25 PM, vitoa  wrote:
>>
>>> Tanks a lot for the Object sugestion that works great :)
>>> One more question.
>>> How can I list all indexs in this object or the size, are there any
>>> methods?
>>>
>>> for example I have
>>> table
>>> { xxx: [ 'xxx', 'aaa', '123' ], zzz: [ 'zzz', 'aaa', '12' ] }
>>>
>>> How can I have the length of this table(should be 2) and show all
>>> indexs available
>>> I found that I only can acess the data if I have index name like
>>> table['xxx']
>>>
>>> Regards,
>>> Vitor
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>
>>
>>  --
>> 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+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: remove "engines" from package.json?

[Marcel Laverdet]

"Broken metadata is just broken metadata"

This hits the nail on the head. This fix to me feels very short-sighted and
PHP-y to me. If this is a bad problem I feel the correct solution would be
to add a flag to npm install such that you could skip the engines check:
`npm install --force some-legacy-package`.

Regarding engines, I'm using it in node-fibers.. "node":">=0.5.2". There
are older versions of fibers that work with older versions of node, and
those are also marked correctly in their metadata.

On Wed, Jun 27, 2012 at 8:09 PM, Vitaly Puzrin  wrote:

> You try to make magic in place, where it is scrictly unwelcome.
>
> Broken metadata is just broken metadata, but not the problem, that should
> be solved in npm.
> If package is not updated for ages and has wrong dependencies - just let
> him die.
>
> среда, 27 июня 2012 г., 21:45:51 UTC+4 пользователь Isaac Schlueter
> написал:
>
>> Thanks for the feedback, everyone.
>>
>> It seems like we can achieve the optimum balance like this:
>>
>> 1. add an "engines-strict" config, default false
>> 2. If "engines-strict" == true, then the current behavior.
>> 3. if "engines-strict" == false, then it's a warning
>>
>> Then Heroku and Azure and the like can set the flag in their envs if
>> they want to (or just look at the engines value and do whatever they
>> want with it), and users will be alerted about the need to upgrade
>> (but without being forced to, or as is more often the case, forced NOT
>> to.)
>>
>> Adding checking for "or higher" would seem to be too subtle a change
>> to me.  Ie, if your package says `"engines":"0.4.x"`, and I have node
>> 0.8, do you *really* mean >=0.6.0?  Or do you mean that you rely on
>> listenFD, which is gone in 0.6, and reimplemented in 0.8, but somewhat
>> differently?
>>
>> It seems like the better option is just to warn you that it might
>> break, and then let it break.
>>
>> Another option might be to let authors add an "enginesStrict" boolean
>> flag in their package.json which would say, "No, seriously, this WILL
>> NOT WORK except with the specified versions, so don't even try to use
>> it."
>>
>> What we're seeing in practice is just weird and broken behavior,
>> usually because an old version of something (say, a package from 2
>> years ago, which doesn't work on modern node) might have no engines
>> specified, but a newer version of the same package (which works fine
>> on 0.8) has "engines":{"node":"0.6.x"} specified.  So, npm tries to
>> find the most recent version that it thinks will work, and it gets
>> 0.1.2 (which is broken and old) instead of 4.8.12 (which is new, and
>> works).  That's the opposite of the intent.  A nag would be more
>> appropriate in that case, I think.
>>
>>
>>
>> On Wed, Jun 27, 2012 at 8:50 AM, Glenn Block 
>> wrote:
>> > We were just about to take a dependency on it for Azure. Is there an
>> > alternative recommended approach? I believe Heroku uses this as well.
>> >
>> > Sent from my Windows Phone
>> > __**__
>> > From: Bradley Meck
>> > Sent: 6/26/2012 10:09 PM
>> > To: nodejs@googlegroups.com
>> > Subject: [nodejs] Re: remove "engines" from package.json?
>> >
>> > At least some PaaS use it. I think it it were tied to tests in some way
>> it
>> > would be more meaningful for the average user, but for now it most
>> commonly
>> > used for PaaS deploys.
>> >
>> > On Wednesday, June 27, 2012 12:06:52 AM UTC-5, Isaac Schlueter wrote:
>> >>
>> >> Do people actually rely on the "engines" hash being respected in npm
>> >> installs any more?  It was super essential in the early days when the
>> >> API was changing constantly, but now, it seems like it just makes it
>> >> unnecessarily difficult to upgrade stuff.
>> >>
>> >> If no one is relying on this right now, I'm going to reduce it to a
>> >> warning.  If in time, people start complaining that the warning is to
>> >> warny, we can remove it, and just let "engines" be a thing of the
>> >> past.  (Note that `npm init` already doesn't bother with it, and for a
>> >> while has just defaulted to {"node":"*"}.)
>> >>
>> >> Please let me know what you think.  Thanks :)
>> >
>> > --
>> > 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
>> >
>> > --
>> > Job Board: http://jobs.nodejs.org/
>> > Posting guidelines:
>> > https://github.com/joyent/**node/wiki/Mailing-List-**Posting-Guidelines
>>

Re: [nodejs] best practices for debugging a c++ add-in

[Marcel Laverdet]

> GetPort() needs a HandleScope and you need to pass the return
value through scope.Close(...).

This is false. v8 builds a HandleScope for you automatically when a
function or accessor is called through JS. You only need to use HandleScope
at the very very top level (node.cc, or stuff like fibers and
threads-a-gogo). You may also want to use HandleScope if you want to manage
your handle lifetimes manually when doing lots of work in v8 c++ land.

On Wed, Jun 27, 2012 at 8:11 AM, Ben Noordhuis  wrote:

> On Wed, Jun 27, 2012 at 7:19 AM, Dave Horton  wrote:
> > Any suggestions along these lines welcome.  I'm writing my first C++
> add-in
> > and struggling with a couple of things:
> >
> > 1) I can use gdb to set breakpoints in my code, but node-gyp by default
> > doesn't include symbols and I haven't been able to figure out how to get
> it
> > to generate debug code (non optimized, no symbols).  I tried "defines":
> > ['DEBUG'] but that didn't work
> >
> > 2) I tried putting simple printf's in my code to stdout or stderr but
> they
> > don't appear so I assume they are being gobbled up by node some how.
> >
> > For a first exercise, I am simply trying to create a module that returns
> a
> > wrapped C++ object, with a property which when accessed in JS triggers a
> C++
> > getter.  I can compile the module ok, and my test script can create an
> > instance, but it appears my getter is never called for some reason (it
> > should return an integer value of 5060 but it returns undefined).  For
> > anyone willing to point out what I assume is an obvious flaw, I have
> posted
> > a gist here: git://gist.github.com/3001626.git
> >
> > I've read the docs on nodejs.org on the basics of creating modules, but
> if
> > anyone knows of useful sample code for a newbie to node (knowledgeable of
> > javascript and C++) I'd appreciate the pointer.  Thanks
>
> I just tried your example and it works for me, i.e. ua.port == 5060.
> That it works may be accidental, though - there is at least one bug.
> :-)
>
> GetPort() needs a HandleScope and you need to pass the return value
> through scope.Close(...).
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: remove "engines" from package.json?

[Marcel Laverdet]

ould have to be >={semver}, and if
> it is <= or =, then it'd have to be >{semver}.
>
> So, then you'd have a set of maximums, and find the max of those?  So,
> for the range above, >{range} would mean >0.9.4.
>
> In other words, version ranges are not necessarily contiguous or
> differentiable.  They have gaps.  We can decide what "greater than a
> range" means, but it's not quite as trivial as just skipping the
> question entirely, and I'm not sure that the benefit is a big enough
> deal to matter.
>
>
> On Wed, Jun 27, 2012 at 11:04 PM, Vitaly Puzrin 
> wrote:
> > From the other hand, users never read warnings. If i've marked my module
> as
> >>= 0.6,
> > then i'll get complains now, that it produces strange bugs under 0.4.
>
> Vitaly, I think some of your foreboding is a bit extreme here.  I get
> more node bugs landing in my inbox than probably anyone else on this
> list.  0.4 is dead.  Virtually no one is using it, and the people that
> ARE using it, are using it specifically because they're not upgrading
> everything or doing new work.  This is not a real concern, and if it
> ever becomes one, it won't be all that hard to address.
>
>
> On Wed, Jun 27, 2012 at 7:26 PM, Marcel Laverdet 
> wrote:
> > If this is a bad problem I feel the correct solution would be
> > to add a flag to npm install such that you could skip the engines check:
> > `npm install --force some-legacy-package`.
>
> Marcel, the fact that you suggest we "add" this is proof to me that it
> is insufficient.  --force has behaved this way for many months now.
>
> > Regarding engines, I'm using it in node-fibers.. "node":">=0.5.2". There
> are
> > older versions of fibers that work with older versions of node, and those
> > are also marked correctly in their metadata.
>
> The current version of npm requires node 0.6, and breaks super badly
> on node 0.4.  So really, this is a question about how node will change
> moving forward.  (New thread coming soon, regarding our stance on
> future api breakage, stay tuned.)
>
>
> If it causes massive problems, we can just revert it.  It's not THAT
> big of a deal.  The main issue is that `npm init` was for several
> versions too restrictive about the defualt "engines" value, and people
> didn't even realize that they were making work for themselves in the
> future.  (And in nodes <=0.4, it was a much greater need to specify
> the working engine precisely.)  Since I removed a default engine from
> `npm init`, most people don't even use it, and it's usually just a
> silly reason to not upgrade.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: remove "engines" from package.json?

[Marcel Laverdet]

In that case wouldn't it also be possible to just change all instances of
"0.6.x" to ">=0.6.0" within npm itself and then throw an error if you try
to publish with "0.6.x"? The problem here never was a bad feature, it was
bad metadata. All the metadata is in one central repository for the most
part..

On Sat, Jun 30, 2012 at 2:43 AM, Isaac Schlueter  wrote:

> Brandon,
>
> That's a good question.  I think the answer is, "It depends."
>
> In some cases, you CAN just take whatever the risk is, see what
> happens, then revert the change.  Historically, I've done that a lot
> in the npm client.  However, when the problem ends up in lots of
> persistent places, that can turn malignant (qv,
> "engines":{"node":"0.6.x"} or require('sys').)
>
> Then fixing it involves either (a) use a time machine to change the
> past, (b) get the whole world to update their stuff, or (c) accept
> that we have made a mistake we can't fully correct.  To my knowledge,
> (a) was never an option.  (b) is only an option if you're takling
> about a small userbase, and we no longer are.  So you either have to
> decide to be ok with it, or come up with an approach that doesn't make
> things worse.
>
> When `npm install` breaks, we can just fix it in the next version.  A
> few people will get annoyed, but the problem will be isolated.  But if
> `npm publish` or (in this case) `npm init` do something wrong, then it
> can sometimes cause issues much later and affect many more users.
>
> So, if a temporary problem in npm init or publish causes a bunch of
> garbage metadata to end up in the registry, and we can fix this by
> changing the behavior of `npm install` slightly, that can be a pretty
> good approach.
>
>
> On Fri, Jun 29, 2012 at 11:47 PM, Brandon Benvie
>  wrote:
> > This is an honest curious question because I don't know the answer or
> have a preconceived notion. Is it possible to just try a change and then
> reactively revert it if it breaks enough stuff? What I do see here and in
> recent compat issues is a bike load of buttshedding and only a handful of
> people citing actual incidents. On either side all it amounts to are
> opinions and many, perhaps most, are based on speculation of "if this
> happens". I would guess many or most of those opinions have little relation
> to the actual outcome and are mostly based on whatever opinion the person
> has on the behavior being discussed.
> >
> > If actual breakage is the concern then maybe things need to be broken
> when it seems plausible, just long enough to determine whether to reverse
> the break or not. For certain, when it IS broken, the feedback will be
> immediate and sincere.
> >
> > --
> > 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+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Sandboxing using 'vm' module & wrapping require()/process.binding()

[Marcel Laverdet]

With all do respect you are in over your head :)

If you want to take a stab at this for real take a peek at google-caja

On Mon, Jul 2, 2012 at 9:27 PM, Will Riley  wrote:

> Hi,
>
> Right now I'm working on a sandbox library for node.js. I'd most likely be
> using vm.runInNewContext to prevent any unwanted methods (eg process.kill)
> from becoming accessible, and the untrusted code would run in a different
> node process.
>
> I'm looking into the possibility of enabling code to call a wrapped
> 'require()' for loading a restricted set of modules (eg 'crypto' or
> 'util'), or even exposing wrapped versions of 'net' or 'fs' that restrict
> their use to certain paths/addresses. This is mainly for performance
> reasons, otherwise I'd do I/O in the main process.
>
> I'm a bit concerned that somehow, 'process.binding()' is going to become
> accessible to the untrusted code if I expose a module to it. Is this an
> irrational concern, or would it be more secure to wrap process.binding in
> the global scope of my sandbox before running the untrusted code?
>
> Thanks again!
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Compiling JS for Safe vm.runInNewContext()

[Marcel Laverdet]

Look at Google Caja, this does exactly what you describe. It's a very
complicated problem.

On Wednesday, July 11, 2012, Angel Java Lopez wrote:

> I presented a project (idea, no code yet) that needs that feature, too.
>
> Game server (as a service?) that accepts logic code from game tenants.
> Another project needs something like this (it's like
> https://github.com/ryanb/ruby-warrior/ )
>
> So, thanks for the question, and for any answer!
>
> Angel "Java" Lopez
>
> On Wed, Jul 11, 2012 at 1:52 PM, Kevin O 
> 
> > wrote:
>
>> We are working on an app where we want to give users the ability to
>> upload JS scripts to process their data in our app.
>>
>> Insane, right? :)  Well we are going to do it in a sane way or not do it
>> at all. We understand the risks.
>>
>> I want to take raw JS input from the user, generate an AST,
>> cleanse/evaluate/mangle it, then "re-compile" to minified JS *only* when
>> we know is safe. If the script is doing unsafe things, we'll return
>> compiler errors. Our compiler needs to be able to limit the JS globals to a
>> short "whitelist". i.e. stuff like eval() is not available within the
>> script.
>>
>> Scripts will be run in our node app using vm.runInNewContext(). We will
>> pass in a context object with the data that the user will be processing
>> with their script.
>>
>> Has anyone done something like this? I have a small bit of code started
>> using uglify but am wondering if there are some other projects or design
>> ideas I can pluck from before getting to deep into the weeds.
>>
>> Thanks
>>
>> Kevin
>>
>> --
>> 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> 'nodejs@googlegroups.com');>
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com > 'nodejs%2bunsubscr...@googlegroups.com');>
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>
>  --
> 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+unsubscr...@googlegroups.com  'nodejs%2bunsubscr...@googlegroups.com');>
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Compiling JS for Safe vm.runInNewContext()

[Marcel Laverdet]

"Too robust" is not a thing. This is a problem that is very complex. As
mentioned in later replies by the Caja team and others since node is using
a very modern version of v8 you can run Caja with minimal translations that
are all done in pure-JS.

With regards to infinite loops you've got another thing on your hands. You
will need to write some C++ code for this, but it's certainly possible to
write a version of vm.runInNextContext() that has a timeout. Alternatively
you could use a node process for each instance, and terminate with a
SIGKILL.

On Wed, Jul 11, 2012 at 1:24 PM, Kevin O  wrote:

> Thanks for the suggestion. Caja does seem like it's pretty robust but
> maybe more than I need. Plus, I would have to call out to a service every
> time I compile or re-implement the whole thing in node to use it. Neither
> is really an option, unfortunately.
>
> On Wednesday, 11 July 2012 13:17:23 UTC-4, Marcel wrote:
>>
>> Look at Google Caja, this does exactly what you describe. It's a very
>> complicated problem.
>>
>> On Wednesday, July 11, 2012, Angel Java Lopez wrote:
>>
>>> I presented a project (idea, no code yet) that needs that feature, too.
>>>
>>> Game server (as a service?) that accepts logic code from game tenants.
>>> Another project needs something like this (it's like
>>> https://github.com/ryanb/ruby-**warrior/
>>>  )
>>>
>>> So, thanks for the question, and for any answer!
>>>
>>> Angel "Java" Lopez
>>>
>>> On Wed, Jul 11, 2012 at 1:52 PM, Kevin O  wrote:
>>>
 We are working on an app where we want to give users the ability to
 upload JS scripts to process their data in our app.

 Insane, right? :)  Well we are going to do it in a sane way or not do
 it at all. We understand the risks.

 I want to take raw JS input from the user, generate an AST,
 cleanse/evaluate/mangle it, then "re-compile" to minified JS *only*when we 
 know is safe. If the script is doing unsafe things, we'll return
 compiler errors. Our compiler needs to be able to limit the JS globals to a
 short "whitelist". i.e. stuff like eval() is not available within the
 script.

 Scripts will be run in our node app using vm.runInNewContext(). We will
 pass in a context object with the data that the user will be processing
 with their script.

 Has anyone done something like this? I have a small bit of code started
 using uglify but am wondering if there are some other projects or design
 ideas I can pluck from before getting to deep into the weeds.

 Thanks

 Kevin

 --
 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

>>>
>>>  --
>>> 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
>>>
>>
> On Wednesday, 11 July 2012 13:17:23 UTC-4, Marcel wrote:
>>
>> Look at Google Caja, this does exactly what you describe. It's a very
>> complicated problem.
>>
>> On Wednesday, July 11, 2012, Angel Java Lopez wrote:
>>
>>> I presented a project (idea, no code yet) that needs that feature, too.
>>>
>>> Game server (as a service?) that accepts logic code from game tenants.
>>> Another project needs something like this (it's like
>>> https://github.com/ryanb/ruby-**warrior/
>>>  )
>>>
>>> So, thanks for the question, and for any answer!
>>>
>>> Angel "Java" Lopez
>>>
>>> On Wed, Jul 11, 2012 at 1:52 PM, Kevin O  wrote:
>>>
 We are working on an app where we want to give users the ability to
 upload JS scripts to process their data in our app.

 Insane, right? :)  Well we are going to do it in a sane way or not do
 it at all. We understand the risks.

 I want to take raw JS input from the user, generate an AST,
 cleanse/evaluate/mangle it, then "re-compile" to minified JS *only*when we 
 know is safe. If the script i

Re: [nodejs] decodeURIComponent vs. binary Buffer.toString() + UTF-8 replacement chars

[Marcel Laverdet]

What version of node? This is what I get:

> var moji1 = (new Buffer('\xf0\x9f\x8d\x94', 'binary')).toString('utf-8');
> var moji2 = (new Buffer('\u00f0\u009f\u008d\u0094',
'binary')).toString('utf-8');
> var moji3 = decodeURIComponent('%F0%9F%8D%94');
> moji1 == moji2
true
> moji2 == moji3
true


On Fri, Jul 20, 2012 at 1:48 PM, Taylor Hughes  wrote:

> Hi nodejs group!
>
> I was just wrestling with a bug in our app — concerning an iPhone emoji =>
> multipart POST to a node.js backend (decoding with formidible library) —
> and came across the following Interesting Case™.
>
> The bug was: emoji chars POSTed from an iPhone, as part of a multipart
> request, were being converted into \ufffd (UTF-8 replacement) chars,
> whereas with form-encoded POSTs they were not.
>
> From this behavior I isolated the following interesting snippet:
>
> // This is an emoji character POSTed by an iPhone:
> var binary = '\u00f0\u009f\u008d\u0094';
> // The same binary string, urlencoded byte for byte (what you get with a
> form-encoded POST of the same thing):
> var urlencoded = '%F0%9F%8D%94';
>
> // Convert from the binary string
> var utf8 = new Buffer(binary, 'binary').toString('utf-8');
>
> // Convert from the urlencoded version of the same thing
> var utf8uri = decodeURIComponent(urlencoded);
>
> // Results are not the same:
> utf8 == utf8uri // false
>
> // utf8=> "\ufffd" (UTF-8 replacement character)
> // utf8uri => "\ud83c\udf54" (characters the iPhone can understand as the
> original emoji)
>
>
> (Note that normal multibyte UTF-8 characters go through both the same way,
> and seem to come out fine in both cases.)
>
> I'm mostly curious about why this happens — namely why
> decodeURIComponent() is seemingly more permissive with UTF-8 decoding than
> other mechanisms like StringDecoder() and Buffer.toString() — and if
> there's a way to preserve strange UTF-8 characters using those mechanisms
> too.
>
> Thanks!
> Taylor
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] --max-old-space-size v8 options not working with sizes>1900 in v0.8.x

[Marcel Laverdet]

> I am definately on a x86_64 machine. So higher limits should work.

Are you running 64 bit node? What does `process.arch` return for you?

On Fri, Aug 3, 2012 at 9:36 AM, Thomas Fritz  wrote:

> Hi,
>
> I just tried to increase the heap size of v8.
>
> 
> node --max-old-space-size=4096 script.js
> 
>
> Every size above about 1900 is ignored.
> I am definately on a x86_64 machine. So higher limits should work.
> Has this behaviour maybe changed in the past. It is described to be
> working here
> http://blog.caustik.com/2012/04/11/escape-the-1-4gb-v8-heap-limit-in-node-js/
> at least.
>
> I tried it with v0.8.4 and v0.8.5. I installed the versions with nvm.
>
> Has anyone the same behaviour?
>
>
> Kind regards
>
> ---
>
> Thomas FRITZ
> web http://fritzthomas.com
> twitter http://twitter.com/thomasf
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: Simple Memcached server in Javascript with 100 lines of code

[Marcel Laverdet]

Yes adding --nouse-idle-notification to your node flags is definitely the
first thing you should try. You may also try avoiding objects with large
numbers of keys (like a million seems to be my ceiling).

On Fri, Aug 3, 2012 at 8:35 PM, Jimb Esser  wrote:

> Best thing to try, add --nouse_idle_notification to the node command line,
> this disables the full garbage collects when node tells V8 it thinks its
> idle, but V8's garbage collection it does on every allocation should still
> take care of collecting garbage.  Give that a try, watch the RSS in top or
> your favorite process monitor to make sure it's still garbage collecting
> (doesn't just leak), and hopefully the stalls will also go away.  We found
> this totally eliminated the giant garbage collect stalls and did not
> noticeably impact process memory usage in our application.
>
>
> On Thursday, August 2, 2012 11:48:15 PM UTC-7, sunjoy wrote:
>>
>> Hi guys,
>>
>> I am studying node.js. It is a wonderful utility to write network-based
>> application.
>>
>> Now, I have written a memcached server using node.js.  You can have a
>> look at https://gist.github.com/**3244607
>>
>> I tested the program, and found it could reach 12000/s throughput.
>> However, during the test, I found sometimes the speed suddenly decreased
>> due to the GC pause from my mind.
>>
>>
>> Is there a way to improve my code ?
>>
>>
>>
>> Thanks
>>
>> Junyi
>>
>>
>>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] A method to get memory profiles that works?

[Marcel Laverdet]

RES stands for resident, not reserved. "Reserved" sounds closer to virtual
memory. RSS/RES should be meaningful representations of the physical amount
of memory your application needs.

On Sat, Aug 4, 2012 at 3:37 PM, Axel Kittenberger  wrote:

> > Can somebody explain me the possibilities of a discrepancy in memory
> > use?
>
> Never mind me. I shouldn't treat a garbage collected language like I
> used to the days with classical memory management. With --expose-gc
> and calling gc() in strategic places during startup at my discretion
> reduces the resulting reserved memory use to 27mb instead of the
> default 100mb. Lesson learned: reserved memory means nothing nowadays,
> everything was just fine.
>
> Kind regards, Axel
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Wind.js : An elegant approach to asynchronies JavaScript

[Marcel Laverdet]

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 
> 
> > 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
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com  'nodejs%2bunsubscr...@googlegroups.com');>
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>


-- 
Sent from My iPhone

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Node.js for small in-house app (should not need much maintenance)

[Marcel Laverdet]

Definitely a job for Google Docs. Not to say NodeJS isn't suitable it's
just going to take a lot longer.

On Sun, Aug 19, 2012 at 9:53 AM, Felix E. Klee  wrote:

> A friend asked me to write a guest-list app for a club, something like
> A-LIST [1]. Guests (VIP) are maintained in a list per event. Plus, there
> is a list of permanent guests, which are copied to each new event. The
> app is password protected to the outside world.
>
> I am currently investigating several options:
>
>  1. Use Google Spreadsheets + Scripting: I have no experience with it.
>
>  2. PHP (with Symfony for MVC): I'm well versed with that. So it would
> be the most logical decision, and their web hoster supports PHP.
>
>  3. Node.js (with Express.js for MVC): Although it would take me longer,
> I would love to do that because I enjoy JavaScript and I want to
> strengthen my Node.js skills (which I also need for another
> project).
>
> Now, one of those totally subjective questions, simply because I need
> some food for thought:
>
> What is your opinion? Do you think using Node.js / Express.js is
> robust enough already?
>
> Consider that once the app is installed, we don't want to change it all
> the time because Nodejitsu or whatever web hoster deprecates support for
> a certain version of Node.js. PHP is very stable in that respect:
> Changes to the fundamental API are rare. Also, there is always someone
> around knowing at least a little PHP (for better or worse). Hm... I'd
> like to go with option 3, but all logic speaks for option 2.
>
> [1]: http://www.a-listsoftware.net/
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[nodejs] What the hell is travis4all?

[Marcel Laverdet]

Did anyone just get a kind of spammy pull request on github from
"travis4all"?

https://github.com/travis4all 1,334 repos and counting. Is this just a bot
that is going through github and issuing automatic pull requests for all
nodejs projects or what?

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] shrouding the javascript source via encryption

[Marcel Laverdet]

https://groups.google.com/d/topic/nodejs/mPIcq5mHihM

On Wed, Aug 22, 2012 at 9:11 PM, Marty Leisner  wrote:

> I'm new to nodejs (and javascript).
>
> I want to be able to shroud the javascript source running into node.
>
> I figured if the javascript is read in as a memory image before its
> parsed/interpreted, I could
> decrypt it in between reading and parsing (is it parsed as its read?)
>
> The decryption algorithm is within the binary (along with the keys).   The
> binary is distributed with
> the application, so this approach could work.
>
> I've looked at node running in gdb and I can't see where this is cleanly
> defined.  Help/advice would be
> appreciated.
>
> Marty
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] [Ann] UglifyJS 2.0

[Marcel Laverdet]

Just curious why you need the comments in the AST at all? If you've got the
start position & length of every token in the AST (much easier to do) you
implicitly have the comments as well. The "fiber" engine in Streamline (
https://github.com/Sage/streamlinejs/blob/master/lib/fibers/transform.js)
does this with really good results.

On Wed, Aug 29, 2012 at 8:37 AM, Mihai Călin Bazon wrote:

> Well, the code generator doesn't yet have an option to keep comments,
> but I can add it easily; the harder part was having them in the AST,
> and that's done.
>
> What exactly are you trying to achieve?  My understanding is that you
> compile Lisp to JS (cool!), do you want to be able to do the reverse
> transform?  If so, perhaps a better idea is to generate a source map.
> (not sure what you need to do though, just guessing)
>
> Cheers,
> -Mihai
>
> On Wed, Aug 29, 2012 at 1:52 PM, Scott Taylor 
> wrote:
> > Wonderful!  I've been working on a project that is sort of like
> parenscript
> > - but much more of a straight javascript in lisp/scheme clothes with a
> > define-syntax macro system.
> >
> > https://github.com/smtlaissezfaire/loop
> >
> > I've been hacking on the 1x source of uglify to translate javascript
> into a
> > lispy type system (and back) - but inline comments have been a cause of
> > concern.  Where is the 2.x source at this point?
> >
> > Cheers,
> >
> > Scott
> >
> > On Aug 28, 2012, at 12:56 PM, Mihai Călin Bazon wrote:
> >
> > On Tue, Aug 28, 2012 at 5:33 AM, Scott Taylor 
> wrote:
> >
> > Very cool.  What comments in the AST are you going to preserve?
> >
> >
> > The new AST is able to store all comments, and the compressor and code
> > generator will be able to keep most of them.  However, I suspect that
> > in general people will only need to store copyright notices, and those
> > usually start with some special marker like "/*!".  It'll be easy to
> > add a configuration option to keep such comments, as long as they're
> > not in code that's going to be dropped (for example dead code, like,
> > code that follows a return, throw, break or continue statement).
> >
> > Cheers,
> > --
> > Mihai Bazon,
> > http://mihai.bazon.net/blog
> >
> > --
> > 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+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/nodejs?hl=en?hl=en
> >
> >
> > --
> > 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+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
>
> --
> Mihai Bazon,
> http://mihai.bazon.net/blog
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] [Ann] UglifyJS 2.0

[Marcel Laverdet]

Yeah I understand the purpose of maintaining comments; I've actually
written a lot of source-to-source transformations myself. The reason I ask
is that I always found it cumbersome to stick non-AST information on the
AST itself. For instance, "for /* this is my loop */ (/* this is my
initializer */ var ii = 0 /* there it is! */;;)". I tortured myself for a
long time messing with maintaining comments and whitespace when I found
that the solution is actually implicit in the token start/end positions.

If you're rendering the AST to string and you've got the source tokens
attached to each node, you can just look at the original source string to
find the comments and whitespace. Like I said, you should check out the
fibers transformation in Streamline. It does a source-to-source
transformation while maintaining *all* non-semantic source data (whitespace
& comments).

The other solution I've seen is to maintain a "lastDocBlock" variable in
your tokenizer state. Then when the parser parses a function, you just
attach `lastDocBlock` to the node that way. That's a pretty simple and easy
to implement solution and it handles concerns about maintaining copyright
information, but it won't maintain whitespace or esoteric comments which is
desirable in many situations.

On Wed, Aug 29, 2012 at 8:07 PM, Scott Taylor  wrote:

> Obviously it depends what you are trying to do.  Usually compiled
> programming languages strip them out in the tokenizer; for source to source
> translations sometimes you want to keep them in (for instance a header with
> copyright notice when compressing or *all* of them in a case like mine)
>
> Best
>
> Scott
>
> On Aug 29, 2012, at 2:27 PM, Marcel Laverdet  wrote:
>
> Just curious why you need the comments in the AST at all? If you've got
> the start position & length of every token in the AST (much easier to do)
> you implicitly have the comments as well. The "fiber" engine in Streamline (
> https://github.com/Sage/streamlinejs/blob/master/lib/fibers/transform.js)
> does this with really good results.
>
> On Wed, Aug 29, 2012 at 8:37 AM, Mihai Călin Bazon 
> wrote:
>
>> Well, the code generator doesn't yet have an option to keep comments,
>> but I can add it easily; the harder part was having them in the AST,
>> and that's done.
>>
>> What exactly are you trying to achieve?  My understanding is that you
>> compile Lisp to JS (cool!), do you want to be able to do the reverse
>> transform?  If so, perhaps a better idea is to generate a source map.
>> (not sure what you need to do though, just guessing)
>>
>> Cheers,
>> -Mihai
>>
>> On Wed, Aug 29, 2012 at 1:52 PM, Scott Taylor 
>> wrote:
>> > Wonderful!  I've been working on a project that is sort of like
>> parenscript
>> > - but much more of a straight javascript in lisp/scheme clothes with a
>> > define-syntax macro system.
>> >
>> > https://github.com/smtlaissezfaire/loop
>> >
>> > I've been hacking on the 1x source of uglify to translate javascript
>> into a
>> > lispy type system (and back) - but inline comments have been a cause of
>> > concern.  Where is the 2.x source at this point?
>> >
>> > Cheers,
>> >
>> > Scott
>> >
>> > On Aug 28, 2012, at 12:56 PM, Mihai Călin Bazon wrote:
>> >
>> > On Tue, Aug 28, 2012 at 5:33 AM, Scott Taylor 
>> wrote:
>> >
>> > Very cool.  What comments in the AST are you going to preserve?
>> >
>> >
>> > The new AST is able to store all comments, and the compressor and code
>> > generator will be able to keep most of them.  However, I suspect that
>> > in general people will only need to store copyright notices, and those
>> > usually start with some special marker like "/*!".  It'll be easy to
>> > add a configuration option to keep such comments, as long as they're
>> > not in code that's going to be dropped (for example dead code, like,
>> > code that follows a return, throw, break or continue statement).
>> >
>> > Cheers,
>> > --
>> > Mihai Bazon,
>> > http://mihai.bazon.net/blog
>> >
>> > --
>> > 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
>&g

Re: [nodejs] [Ann] UglifyJS 2.0

[Marcel Laverdet]

Not sure where a good place to start is. They're no different than ASTs for
any other language. uglify-js dumps out a big nested array which is a
pretty good start if you want to see about what is going on.

I got started in meta-programming with Bison which is a C parser and Flex
which is a C scanner. (I mean, they don't parse and scan C, they are
general purpose parsers which happen to be written in C). Basically you
just take a source file and run it through a scanner which turns it into a
bunch of "tokens" which are just one step up from raw source (parse
something like "var hello = 1" into [t_VAR', 'hello', t_EQ, 1]), and then
the parser takes those tokens and turns them into a meaningful tree.

On Thu, Aug 30, 2012 at 2:23 PM, Dan Milon  wrote:

> Out of topic, but you gave me the clues.
> Do you know where i can read up about AST trees for javascript?
>
> Thanks a ton,
> danmilon.
>
>
> On 08/30/2012 12:27 AM, Marcel Laverdet wrote:
>
>> Just curious why you need the comments in the AST at all? If you've got
>> the start position & length of every token in the AST (much easier to do)
>> you implicitly have the comments as well. The "fiber" engine in Streamline (
>> https://github.com/Sage/**streamlinejs/blob/master/lib/**
>> fibers/transform.js<https://github.com/Sage/streamlinejs/blob/master/lib/fibers/transform.js>)
>> does this with really good results.
>>
>> On Wed, Aug 29, 2012 at 8:37 AM, Mihai Călin Bazon 
>> > mihai.ba...@gmail.com>**> wrote:
>>
>> Well, the code generator doesn't yet have an option to keep comments,
>> but I can add it easily; the harder part was having them in the AST,
>> and that's done.
>>
>> What exactly are you trying to achieve?  My understanding is that you
>> compile Lisp to JS (cool!), do you want to be able to do the reverse
>> transform?  If so, perhaps a better idea is to generate a source map.
>> (not sure what you need to do though, just guessing)
>>
>> Cheers,
>> -Mihai
>>
>> On Wed, Aug 29, 2012 at 1:52 PM, Scott Taylor
>> mailto:sc...@railsnewbie.com>**> wrote:
>> > Wonderful!  I've been working on a project that is sort of like
>> parenscript
>> > - but much more of a straight javascript in lisp/scheme clothes
>> with a
>> > define-syntax macro system.
>> >
>> > 
>> https://github.com/**smtlaissezfaire/loop<https://github.com/smtlaissezfaire/loop>
>> >
>> > I've been hacking on the 1x source of uglify to translate
>> javascript into a
>> > lispy type system (and back) - but inline comments have been a
>> cause of
>> > concern.  Where is the 2.x source at this point?
>> >
>> > Cheers,
>> >
>> > Scott
>> >
>> > On Aug 28, 2012, at 12:56 PM, Mihai Călin Bazon wrote:
>> >
>> > On Tue, Aug 28, 2012 at 5:33 AM, Scott Taylor
>> mailto:sc...@railsnewbie.com>**> wrote:
>> >
>> > Very cool.  What comments in the AST are you going to preserve?
>> >
>> >
>> > The new AST is able to store all comments, and the compressor
>> and code
>> > generator will be able to keep most of them.  However, I suspect
>> that
>> > in general people will only need to store copyright notices, and
>> those
>> > usually start with some special marker like "/*!".  It'll be easy to
>> > add a configuration option to keep such comments, as long as they're
>> > not in code that's going to be dropped (for example dead code, like,
>> > code that follows a return, throw, break or continue statement).
>> >
>> > Cheers,
>> > --
>> > Mihai Bazon,
>> > http://mihai.bazon.net/blog
>> >
>> > --
>> > Job Board: http://jobs.nodejs.org/
>> > Posting guidelines:
>> > https://github.com/joyent/**node/wiki/Mailing-List-**
>> 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
>> <mailto:nodejs@googlegroups.**com >
>>
>> > To unsubscribe from this group, send email to
>> > 
>> 

Re: [nodejs] Unload entire module

[Marcel Laverdet]

> we have some very long running apps we are trying to reduce the footprint
on and unloading certain modules seems to be a good start

To be honest, that doesn't sound like a very good start. If your long
applications have a growing footprint then you are leaking memory
somewhere. "Cleaning up" modules you're not using anymore will save you
maybe 10mb flat.

On Mon, Sep 3, 2012 at 3:49 PM, Ben Noordhuis  wrote:

> On Mon, Sep 3, 2012 at 9:02 PM, Bradley Meck 
> wrote:
> > How do people unload entire modules after they are done using them, we
> have
> > some very long running apps we are trying to reduce the footprint on and
> > unloading certain modules seems to be a good start. For example if we
> could
> > eventually end up with something like:
> >
> > require.unload('nconf') after the configuration phase of startup.
>
> delete require.cache['nconf']?
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] psutil library for node

[Marcel Laverdet]

Never never never never never never never put "using namespace" in a header
file. Or before *any* #include.

On Thu, Sep 6, 2012 at 8:36 AM, christkv  wrote:

> I'm slowly working on rewriting the python lib psutil for node but I'm
> running into a problem on linux. It builds perfectly with clang++ but fails
> to link correctly with g++. The code is here
>
> https://github.com/christkv/node-psutil
>
> I would really really appreciate it if anyone could shed some light on the
> problem as I've pretty much wasted a couple of days trying to figure out
> and I'm sure it's something stupid I've forgot to add in the gyp file.
>
> I published it under psutil on npm so just grab latest if you want to try
> it out. It's a bit barebones right now and only supports linux and darwin
> but I'll keep adding to it over time to have a proper full port in due time.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] nodejs memcached client

[Marcel Laverdet]

I use node-memcache, it's perfect.

> The `node-memcache` cant reconnect the memcache, if memcache service
restarted.

Why can't you manually reconnect? It's not the library's responsibility to
try and clean up errors that you may want to handle some other way.

On Tue, Aug 21, 2012 at 4:35 AM, jason.桂林  wrote:

> I am looking for a good memcached client.
>
> node-memcached  https://github.com/3rd-Eden/node-memcached
> node-memcachehttps://github.com/elbart/node-memcache
>
> The `node-memcached` has a big bug of  'All the connections in the
> memcached pool are busy'
>
> The `node-memcache` cant reconnect the memcache, if memcache service
> restarted.
>
> Any other good options?
>
> --
> Best regards,
>
> 桂林 (Gui Lin)
>
> guileen@twitter
> 桂糊涂@weibo
> guileen@github
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Listing all Pads + full text search

[Marcel Laverdet]

Is this about NodeJS? Am I the only one who has no idea what's going on?

On Saturday, September 29, 2012, Dan wrote:

> Hi,
>
> first of all I want to thank you all for that amazing project :)
>
> I'm really missing an index or a list of all available pads. I think that
> can be achieved quite easily by implementing a plugin that uses a hook that
> is called whenever a new pad is created. Then storing the name of the pad
> in a simple list in the db. E.g. { 'key' : 'pad_index': ['pad_1',
> 'pad_2',...] }. The plugin can then list all available pads quite
> effective. The problem is, that I could not find any hook that will call me
> when new pads are added. Would it be possible to implement that hook so
> that I can write the plugin?
>
> The second feature that I'm missing is a global full text search. Since
> its quite inefficient to search in the key/value table I'm thinking of
> creating my own fulltext index that consists of the most recent pad
> versions. Would that be possible in an plugin?
>
> Kind regards,
> Dan
>
>  --
> 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+unsubscr...@googlegroups.com  'nodejs%2bunsubscr...@googlegroups.com');>
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>


-- 
Sent from My iPhone

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] ANN: Spoon

[Marcel Laverdet]

You have no idea what you've done.

On Mon, Oct 1, 2012 at 2:11 PM, Fedor Indutny  wrote:

> Hey people,
>
> Let me introduce you The Spoon: https://github.com/indutny/spoon
>
> It's a JavaScript to CFG (Control-Flow Graph) transpiler and additionally
> a CPS (Continuation Passing Style) transpiler too.
>
> Basically, it lets you to rewrite code like this:
>
> var data = 'prefix: ' + fs.read('file')
>
>  To this:
>
> var data;
> fs.read('file', function(err, result) {
>   data = 'prefix: ' + result;
> });
>
> Please check the readme, if you're interested.
>
> Cheers,
> Fedor.
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Retrieving values asynchroniously

[Marcel Laverdet]

I'm rolling in my grave.

On Wednesday, April 24, 2013, greelgorke wrote:

> where's the fibers guy? :D
>
> Am Dienstag, 23. April 2013 22:31:57 UTC+2 schrieb azer:
>>
>> I wrote a guide for defining async values previously;
>> https://github.com/azer/**declarative-js
>>
>> On Tue, Apr 23, 2013 at 9:23 AM, Bruno Jouhier 
>> wrote:
>> > With streamline.js 
>> > (https://github.com/Sage/**streamlinejs),
>> you just need one
>> > line of code:
>> >
>> > var result = (Object1.retrieveNum1(_) + Object2.retrieveNum2(_)) /
>> > Object3.retrieveNum3(_);
>> >
>> >
>> > On Monday, April 22, 2013 9:54:50 PM UTC+2, Slobodan Blazeski wrote:
>> >>
>> >> Hi All
>> >>
>> >> I'm looking for suggestions of how to retrieve values asynchronously:
>> >>
>> >> In the synchronous world I have
>> >>
>> >> var num1 =  Object1.retrieveNum1();
>> >> var num2 = Object2.retrieveNum2();
>> >> var num3 = Object3.retrieveNum3();
>> >>
>> >> var result = (num1 + num2) /  num3;
>> >>
>> >>
>> >> but since functions  Object1.retrieveNum1,Object2.**retrieveNum2 &
>> >> Object3.retrieveNum3
>> >> retrieve data from the database or represent long calculation I need
>> to
>> >> pass callbacks,
>> >> that leads me to below
>> >>
>> >>  Object1.retrieveNum1Async(**function(num1){
>> >>   Object2.retrieveNum2Async(**function(num2){
>> >> Object3.retrieveNum3Async(**function(num3){
>> >>  var result = (num1 + num2) /  num3;
>> >> });
>> >>   });
>> >> });
>> >>
>> >> is this the idiomatic way of doing this or there is something better
>> >>
>> >>
>> >> thanks
>> >> Bobi
>> >>
>> >>
>> >>
>> >>
>> > --
>> > --
>> > 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 nod...@googlegroups.com
>> > To unsubscribe from this group, send email to
>> > nodejs+un...@**googlegroups.com
>> > 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 nodejs+un...@**googlegroups.com.
>> > For more options, visit 
>> > https://groups.google.com/**groups/opt_out.
>>
>> >
>> >
>>
>  --
> --
> 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+unsubscr...@googlegroups.com  'nodejs%2bunsubscr...@googlegroups.com');>
> 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 nodejs+unsubscr...@googlegroups.com  'nodejs%2bunsubscr...@googlegroups.com');>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
Sent from My iPhone

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Retrieving values asynchroniously

[Marcel Laverdet]

I think the distinction between *doing* node and *using* is good call. I
wrote a tampering HTTP proxy server in node; I used streams and callbacks.
I wrote a web application with lots of waiting on database and filesystem
chatter; I used fibers w/ futures.


On Sun, Apr 28, 2013 at 11:22 PM, Bruno Jouhier  wrote:

> Hi Nuno,
>
> Your post is helpful. I'll try to challenge it in a constructive way. I
> think that most of disagreement comes from a different perspective on means
> and ends.
>
> From your perspective, node is an end in itself: you **do** node; you
> build streams; you write callbacks; etc. For you, adherence to node's core
> philosophy is paramount.
>
> From my perspective, node is just a means to an end: we **use** node. For
> us, the end is to more our product forwards. Node is just one piece of the
> puzzle we are assembling (an important one). For us, node's core philosophy
> is "interesting" but it is not binding.
>
> Our team is growing and when I'm bringing new people on board I'm not
> teaching them callbacks and streams; I'm teaching them streamline. This is
> because I need them to get up to speed quickly and I also need to have a
> code base which is simple, robust, easy to maintain and homogeneous. They
> can still learn callbacks and streams on their own and I'm encouraging them
> to be curious but our internal coding standard is streamline.
>
> Also, I considered node's philosophy when architecting our new system. But
> I have difficulties to fit what we are doing into the streams and pipes
> paradigm. It does not feel "natural" and I don't see what benefits I would
> gain. For me, it is much more natural to architect our system as classical
> modules that **consume** streams than as streams that would be piped into
> each other. I find the pure asynchronous nature of node very appealing but
> I find the streams & pipes philosophy less appealing. Maybe there is also a
> question of maturity: the asynchronous APIs are something we can very
> easily build upon today (in part thanks to streamline); the streams & pipes
> looks more like an experiment in progress, which may turn out to be a real
> breakthrough but which would be introducing too much complexity for us
> today.
>
> I also have a different perspective on node's APIs. I followed the
> discussions on the new streams API and I was always amazed by the very
> strong focus on the "building streams" side. I find this very complex and
> fragile. In our system, we very rarely build a stream but we consume a lot
> of streams. So we have a small wrapper that gives us a very simple API to
> consume streams. We are not following the core philosophy but it does not
> really matter for us. What matters is that we can build our product.
>
> Now, when a person comes the the mailing list with a question, I wonder
> what his perspective is. Does he want to **do** node, or is he just trying
> to **use** node to build something? If his goal is to **do** node, then
> yes, Mikeal is right with his hard line: people should not blur the message
> and give him advice that may distract him from node's philosophy. But what
> if all he wants is to **use** node, maybe in ways that are not completely
> aligned with node's core philosophy, like we do? should we stick to the
> hard line, or should we let him explore "other ways" that may be a better
> answer to his needs.
>
> The node ecosystem is growing fast, with people that **do** node, and I
> don't want to disrupt this. But I feel that there is a great opportunity
> for node to go more mainstream (like PHP and RoR). I don't think that node
> will go mainstream by trying to convert mainstream developers to the
> callbacks and streams paradigm, simply because it is too hard. I think that
> it can do so by being open and letting people just **use** node, and this
> is where alternate tools may help.
>
> I don't have a good answer to what the line of conduct should be on the
> mailing list. But I don't think that excluding discordant voices is the
> right solution (in this specific case but also in general).
>
> Bruno.
>
>
> On Sunday, April 28, 2013 3:01:05 AM UTC+2, Nuno Job wrote:
>>
>> Node means a certain set of things, and part of those things are
>> callbacks and streams.
>>
>> Callbacks and streams are hard to learn because its a new
>> programming paradigm you don't learn in school. It was hard for me too and
>> I did it when this was still up for discussion. And I had good friends to
>> teach me that really knew node.
>>
>> Developers will always try to fast track to their already understood
>> paradigms; but that is not node. This existing paradigm makes sense to
>> build network proxies; which node is awesome for. To node programs are
>> proxies.
>>
>> A person should always start with callbacks and streams until he
>> understands them, closures, and the event loop. Then he can make informed
>> decisions on what to use when.
>>
>> However node is not the solution to all problems and if yo

Re: [nodejs] You're going to have to rewrite it anyway

[Marcel Laverdet]

I don't understand why you hate C++ so much? If you're trying to convert
v8's C++ API into a C API you're going to need a lot of ref/unref action
which isn't necessary given C++'s scoping semantics. They built the API in
C++ for a reason. I'm not even sure the API you're conjuring up here is
even possible without adding in non-trivial CPU & memory overhead?


On Tue, Jul 9, 2013 at 1:04 PM, Tim Caswell  wrote:

>
>
>
> On Tue, Jul 9, 2013 at 12:39 PM, Micheil Smith wrote:
>
>> How would a asynchronous libuv schedule example look?
>>
>
> Not entirely sure what you mean.  I did add support for external pointers
> (for things like uv_handle_t and uv_ref_t) and a way to add arbitrary js
> values to the set of GC roots (for storage in some C struct passed to the C
> callback later on).  That should be enough to wrap the various libuv apis.
>
>
>>
>> – Micheil
>>
>> On 09/07/2013, at 6:08 PM, Tim Caswell  wrote:
>>
>>
>>
>>
>> On Tue, Jul 9, 2013 at 4:16 AM, Floby  wrote:
>>
>>> Tim's examples are pretty nice.
>>> The only things missing for all my use cases are storing pointers in JS
>>> objects so I can get them back when I need it.
>>>
>>> something like
>>>
>>> js_set_pointer(C, myObject, pointer);
>>> myType *pointer = js_get_pointer(C, myObject);
>>>
>>
>> Ok, now the proposed API has a more complete feature set including an
>> example of how to embed C structs inside JS objects.
>> https://gist.github.com/creationix/5954513#file-point-c (Also I ran all
>> the code through gcc and clang with -pendantic to make sure my header is
>> valid code)
>>
>> #include "js_api.h"
>> #include  // malloc, free
>>
>>
>> // Suppose I want to create a point type that's backed by a real C struct 
>> for points.
>>
>> typedef struct {
>>
>>   double x;
>>   double y;
>>
>> } my_point;
>>
>> void cleanup_point(void* point, const char* type) {
>>
>>   free(point);
>> }
>>
>> bool create_point(js_context* C) {
>>
>>   my_point* point = (my_point*)malloc(sizeof(my_point));
>>
>>   point->x = js_to_double(C, 1);
>>
>>   point->y = js_to_double(C, 2);
>>
>>   int proto = js_named_read_ref(C, "my_point_proto");
>>
>>   return js_return_external_pointer_with_proto(C, point, "my_point", proto, 
>> cleanup_point);
>>
>> }
>>
>> bool add_method(js_context* C) {
>>
>>   my_point* point = (my_point*)js_to_pointer(C, 0, "my_point");
>>
>>   if (!point) {
>> return js_throw_type_error(C, "Expected this to be 'my_point' instance");
>>
>>   }
>>   return js_return_double(C, point->x * point->y);
>>
>> }
>>
>> bool export_point(js_context* C) {
>>
>>   int proto = js_create_object(C);
>>
>>   js_set_function(C, proto, "add", add_method);
>>
>>   js_named_ref(C, proto, "my_point_proto");
>>
>>   return js_return_function(C, create_point);
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> On Monday, 8 July 2013 20:35:36 UTC+2, Timothy J Fontaine wrote:

 [cross post from http://atxconsulting.com/**
 2013/07/06/rewrite-it-anyway/
 ]

 Node v1.0 is approaching, and v0.12 is imminent (as far as that goes
 for FOSS
 projects). As we work towards getting v0.12 out the door, there have
 been a lot
 of changes happening for node's primary dependency v8. Ben is working
 on moving
 us to the 3.20 branch, follow his progress
 [here](https://github.com/**joyent/node/pull/5804
 ).

 As you can tell this is a signficant change to the API, which requires
 a touch
  of virtually every file in our `src/`, this has been a huge headache
 for him,
 and will ultimately cause a huge headache for developers of binary
 addons.

 You're going to have to `#ifdef` around significant portions of the API
 to keep
 your module working across different version of node, this is going to
 cause
 endless amounts of pain and issues for node and developers who have for
 the
 most part been accepting of the churn in our underspecified addon API.

 This one is going to hurt.

 A lot.

 ## TL;DR -- A modest proposal

 Since you're going to have to rewrite your module anyway, it's time for
 node to
 specify and export the API we are going to "bless" for addons. That is,
 just
 what API we are going to support and make sure continues to work from
 minor and
 major releases, as well as a deprecation policy.

 More specifically I think we should be exporting a separate (and not
 equal)
 wrapper around (at the very least) javascript object creation, get/set,
 function
 calling.

  Additionally we should package and distribute (if possible in npm) a
 transitional library/headers which module authors can target today
 which will
 allow their module to compile and work from v0.8 through v1.0

 ## The Platform Problem

 We currently allow platforms/distributors to build a

Re: [nodejs] Future of asynchronous programming in node

[Marcel Laverdet]

Mikeal correct me if I'm wrong as I haven't thought about it that much, but
even with ES6 generators a function *must* run to completion before a turn
of the event loop unless it's explicitly marked as a generator itself
(function*). This isn't a guideline but a technical limitation as
generators are single-frame (in contrast to fibers which don't follow
your terrestrial rules). Thus you're not going to run into the case where
innocent client code is waylaid down the stack by a generator. The only
functions that need to worry about reentrancy are those that are explicitly
marked as function*.


On Mon, Aug 5, 2013 at 4:40 PM, Mikeal Rogers wrote:

> I don't think you understand what I'm saying, I'll try to be clearer.
>
> Callbacks that use node's standard callback interface are resolved exactly
> once. From the point at which they begin to when they end the author can
> assume that any code they are running is the *only* code running in the VM
> and that state will only mutate between other callbacks passed to other
> APIs before resolving the callback they were given. In other words, state
> mutation boundaries are visible, explicit and consistent.
>
> Generators iterate over data in an iterable manor but because they cannot
> yield between turns of the event loop their condition is assumed to be
> resolved in one stack. For instance, if I offer you a generator my
> assumption is that if you present an API to another consumer that consumer
> will *also* call yield on your API to consume it iterably or consumer the
> entire generator until completion.
>
> While it is certainly *possible* that someone might decide not to offer a
> yield API and instead to turn the event loop before I'm finished and keep
> the generator yielded between cycles, I would bet that most people assume
> it won't happen and won't make attempts to be safe between concurrent
> iterations of the same generator.
>
> My concern is not that generators are "magical" but that the current
> implementation *appears* to offer assurances that *we* will go out and
> break.
>
> Similar problems have crept in to node libraries that called asynchronous
> iterators "forEach" and their consumers assumed that this blocked the VM
> since Array.forEach blocks the VM until completion.
>
> If 95% of the time generator authors don't have to worry about maintaining
> safety between concurrent iterations of the same generator history shows
> that a good number of them never will and will just break at scale in
> really fun (horrendous) to debug ways.
>
> -Mikeal
>
> On Aug 5, 2013, at 2:18PM, Christopher Probst <
> foxnet.develo...@googlemail.com> wrote:
>
> The generators are not magical. They do basically the same as callbacks
> but they invert the inversion of control optically.
>
> --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegrou

Re: [nodejs] Re: Future of asynchronous programming in node

[Marcel Laverdet]

> We were running it in "callbacks" mode before and we switched to
"fibers-fast" mode recently. It made a big difference: the application is
now 5 times faster and it uses 2 or 3 times less memory!!

Niice. I had a strong feeling that would be the case. Sometimes
powerful tools have to be dangerous as well.


On Sat, Aug 10, 2013 at 7:26 AM, Bruno Jouhier  wrote:

> Good job Gorgi.
>
> You have tested a single function making several async calls. It would be
> interesting to also test with several layers of async calls (async f1
> calling async f2 calling async f3 ...). My guess is that you will see a
> significant difference in the way fibers compares with the other solutions
> (also it would be interesting to include Marcel's futures library in the
> bench)
>
> We have recently started to benchmark our application. Our app is now
> about 100 klocs and it is all written in streamline.js. We were running it
> in "callbacks" mode before and we switched to "fibers-fast" mode recently.
> It made a big difference: the application is now 5 times faster and it uses
> 2 or 3 times less memory!!
>
> Why is that? This is because we have a lot more streamline-to-streamline
> calls than streamline-to-nativeio calls in our app. In fibers-fast mode,
> the streamline-to-streamline callls are *not* transformed at all: there are
> no wrappers around async function definitions and there are no callback
> closures allocated for these calls: an async function calling another async
> function is just as lean and efficient as a sync function calling another
> sync function. You only get the overhead of closures and fibers at the
> boundaries: when node is calling our code (a fiber gets allocated) and when
> our code calls node libraries (yield + allocation of a closure). My guess
> is that most of the speedup comes from the fact that we got rid of all the
> intermediate wrappers and callback closures: a lot less memory allocation
> => a lot less time spent in the GC. All this thanks to deep continuations.
>
> We haven't stress tested the real app in generators mode yet because we
> deploy it on 0.10.x but I did a quick bench of the multi-layer call
> scenario to compare callbacks, fibers and generators a while ago (
> https://gist.github.com/bjouhier/5554200). Note that this bench was run
> with the very first brew of generators (V8 3.19); generators are probably
> faster now and will probably get faster in the future (is Crankshaft
> enabled today??). So these early results should be taken with a pinch of
> salt.
>
> I'm not saying that fibers will outperform in all scenarios but there are
> application scenarios where they shine.
>
> Bruno
>
>
> 7:11:22 PM UTC+2, spion wrote:
>>
>> I just finished writing an analysis of many node async patterns (with
>> special attention given to generator  patterns):
>>
>> http://spion.github.io/posts/**analysis-generators-and-other-**
>> async-patterns-node.html
>>
>> There are comparisons for code complexity, performance, memory usage and
>> debuggability.
>>
>> Hope you find it useful and informative.
>>
>  --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Re: Callbacks as our Generations' Go To Statement - Miguel de Icaza

[Marcel Laverdet]

> Even the current generator/yield implementations are essentially
accomplished via CPS transforms.

This is untrue. Fibers uses a new stack and a long jump. Haven't looked at
the implementation for generators in v8 but I'd be surprised if it was
anything more exotic than a stack frame allocated on the heap and a context
switch.


On Mon, Aug 19, 2013 at 1:34 PM, jmar777  wrote:

> > I'm assuming you mean "system thread". But in effect, isn't it very much
> like a green thread ?
>
> Async/await (or generators/yield if you prefer) are very different from
> green threads.  Green threads are still preemptive and managed by the VM.
>  Async/await, on the other hand, is basically a nice syntax addition that
> allows for a more expressive form of cooperative multi-tasking.  As Andrew
> already said, there's nothing that you can do with async/await that you
> couldn't *exactly* replicate using regular ol' callbacks.
>
> It's too early to say this authoritatively, but it seems that async/await
> will likely sit on top of Promises; that alone should indicate that we
> won't be seeing any departures from current async semantics.  Even the
> current generator/yield implementations are essentially accomplished via
> CPS transforms.  In short, preemption would be pretty devastating to
> JavaScript.
>
>
>
>
> On Monday, August 19, 2013 8:36:08 AM UTC-4, Floby wrote:
>>
>> >other functions can resume and run within the same thread
>>
>> I'm assuming you mean "system thread". But in effect, isn't it very much
>> like a green thread ? (userspace managed ?)
>>
>> On Sunday, 18 August 2013 08:18:55 UTC+2, Andrew Gaspar wrote:
>>>
>>> On Sat, Aug 17, 2013 at 6:14 AM, Floby  **wrote:
>>>
 I've read that article too.

 It seems to me that async/wait is a more elegant approach than twisting
 the yield semantics.
 However I don't quite see how this differs from blocking I/O calls and
 threads.

 These are cooperative threads, wihch were also an acceptable
 programming model in the 60's


>>> Async/await doesn't block a thread. That's the point. It's *exactly*like 
>>> node - other functions can resume and run within the same thread while
>>> another asynchronous action is being awaited. You could essentially rewrite
>>> all await code to use callbacks and have the exact same functionality - it
>>> just reduces code complexity.
>>>
>>  --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] Is it possible to break v8's memory limitation?

[Marcel Laverdet]

Why hasn't anyone posted  --max-old-space-size= yet? Just do
that w/ 8192 for instance, for 8gb.


On Thu, Aug 22, 2013 at 1:48 AM, NStal Loit  wrote:

> Thank you peter, C++ binding is another choice I would consider, if I make
> sure it's hard to remove v8 heap limit right now or in near future and
> split process has unacceptable overhead.
>
>
>
>
> On Thursday, August 22, 2013 1:23:21 PM UTC+8, Peter Rust wrote:
>>
>> > as well as quite a few others on npm: https://npmjs.org/search?**
>> q=hashtable .
>>
>> Ok, maybe not "quite a few" -- most of the other ones are implemented in
>> Javascript. The only C++ ones I could find were
>>
>>
>>- 
>> https://npmjs.org/package/**hashtable
>> 
>> (https://github.com/**isaacbwagner/node-hashtable
>>)
>>- https://npmjs.org/package/dht **(https://github.com/tilgovi/**
>>node-dht )
>>
>> A github search for "hash table" returns 107 C hits and 64 C++ hits, so
>> there are a lot to choose from, you would just need to write node
>> bindings . Here are some pages that
>> may be helpful if you're interested in picking & choosing:
>>
>>- a great breakdown of the performance characteristics of the top
>>hash table 
>> implementations
>>- a detailed comparison of a Judy Array and a fine-tuned hash 
>> table
>>- a different comparison of hash table 
>> libraries
>>.
>>
>> -- peter
>>
>> On Wednesday, August 21, 2013 10:04:17 PM UTC-7, Peter Rust wrote:
>>>
>>> If all you need is a hash table, there are a lot of hash table C/C++
>>> libraries that you could integrate with Node (like 
>>> Judy)
>>> and there are a few that have already been integrated, like
>>> https://npmjs.org/**package/hashtable 
>>> (that
>>> specifically lives outside of v8's memory constraints)
>>>
>>> > The hash strategy behind the scenes must be interesting
>>>
>>> I found this page that describes (at least some of) what's happening
>>> behind the scenes: https://developers.**google.com/v8/design?hl=sv&**
>>> csw=1#prop_access.
>>> v8 is creating a new dynamic behind-the-scenes class when you add
>>> properties. As someone on the v8 users list 
>>> says:
>>> "in general JS objects in V8 are not optimized to be used as large hash
>>> tables. Most likely, it would be best to implement your own hash table data
>>> structure using an array as a backing store instead of using a JS object as
>>> a hash table".
>>>
>>> Best of luck!
>>>
>>> -- peter
>>>
>>>
>>>  --
> --
> 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+unsubscr...@googlegroups.com
> 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 nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [nodejs] addon string type cast

[Marcel Laverdet]

Ken,

Your function doesn't handle strings with null bytes in them correctly.
Plus you are now dealing with a char* instead of a std::string, you will
have much less headaches dealing with a std::string. You'll also be
protected by RAII so it will be impossible to leak memory.

If your function is performance critical you should just dereference the
Utf8Value directly in your function so no extra copy is performed.

On Wed, Feb 1, 2012 at 10:21 AM, Kenneth Shaw  wrote:

> I do this:
>
> // convert a v8::String to a (char*) -- any call to this should later be
> free'd
> static inline char *TO_CHAR(Handle val) {
>String::Utf8Value utf8(val->ToString());
>
>int len = utf8.length() + 1;
>char *str = (char *) calloc(sizeof(char), len);
>strncpy(str, *utf8, len);
>
>return str;
> }
>
> Then, anywhere in your code, you can do this:
>
> char *x = TO_CHAR(v8_str);
> printf("%s", x);
> free(x);
>
> -Ken
>
>
>
> On Sun, Jan 29, 2012 at 6:30 PM, Ben Noordhuis  wrote:
> > On Mon, Jan 30, 2012 at 00:22, Mark Volkmann 
> wrote:
> >> Is this the best way to get a C string from a Local that is
> really a
> >> Local?
> >>
> >> if (value->IsString()) {
> >>   String::Utf8Value utfStr(value);
> >>   char* s = (char*) *utfStr;
> >> }
> >
> > Depends on what you do with s, it becomes a dangling pointer the
> > moment utfStr goes out of scope. Otherwise it's fine.
> >
> > --
> > 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+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] addon string type cast

[Marcel Laverdet]

Yes, Ben's implementation will fail with null characters as well.

std::string FlattenString(v8::Handle v8str) {
  v8::String::Utf8Value utf8str(v8str);
  return std::string(*utf8str, utf8str.length());
}

On Thu, Feb 2, 2012 at 12:48 PM, Nathan Rajlich wrote:

> Ben, would you also want to get the Utf8Length() and pass it as a second
> param to std::string()? (I've only used std::string like once).
>
>
> On Thu, Feb 2, 2012 at 10:03 AM, Ben Noordhuis  wrote:
>
>> On Thu, Feb 2, 2012 at 18:52, Mark Volkmann 
>> wrote:
>> > Can you share how to create a std::string from a Local?
>>
>> Easy as pie:
>>
>>  std::string MakeString(Handle str) {
>>String::Utf8Value s(str);
>>std::string ss(*s);
>>return ss;
>>   }
>>
>> --
>> 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+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: How to continuously read a file while the file is been writing

[Marcel Laverdet]

You can do this easily with fs.watchFile() and fs.read(). I have a gist
which uses fs.watchFile() on a MySQL binlog to stream off queries as they
are written to the binary log:

https://gist.github.com/958588

The file handling logic starts at line 174. I don't see why everyone is so
quick to load up tail when you can write this in pure node in 12 lines or
so.

On Thu, Feb 2, 2012 at 2:00 PM, fent  wrote:

> BTW, I was thinking of coding some type of service like this that lets
> users download files as they're being uploaded. Would like to see what
> you have if you don't mind.
>
> On Feb 2, 3:30 am, 宓俊  wrote:
> > I want the user to be able to download a file while it is uploading. So I
> > write this code to test.
> >
> > var fs = require('fs');
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > var writeStream = fs.createWriteStream(__dirname + "/uploading.txt");
> > > writeStream.on('open', function(){
> > >   console.log('Write stream has open');
> > >   //Write a number every 1 second.
> > >   var i = 1;
> > >   var repeat = function(){
> > > writeStream.write(i);
> > > console.log('Number ' + i + ' has been write to the file');
> > > i = i + 1;
> > > setTimeout(repeat, 1000);
> > >   };
> > >   repeat();
> > >   var readStream = fs.ReadStream(__dirname + "/uploading.txt");
> > >   readStream.on('data', function(data){
> > > console.log('Data is coming: ' + data);
> > >   });
> > >   readStream.on('end', function(){
> > > console.log('Stream END');
> > >   });
> > > });
> >
> > But the result is like this
> >
> > Write stream has open
> >
> > > Number 1 has been write to the file
> > > Data is coming: 1
> > > Stream END
> > > Number 2 has been write to the file
> > > Number 3 has been write to the file
> > > Number 4 has been write to the file
> >
> > When the reading speed is faster than the writing speed, I will receive a
> > 'end' signal, rather than paused.
> >
> > So how to deal with this problem?
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: How to continuously read a file while the file is been writing

[Marcel Laverdet]

Seriously what you want is 12 lines with fs.watchFile(), just try it you
will be shocked by how easy it is to get this running.

On Thu, Feb 2, 2012 at 10:31 PM, Mi Jun  wrote:

> I am using formidable to upload files, so I can access to
> file.bytesReceived and file.bytesExpected.
>
> I think tail is not a good solution. Since I have to pipe the readStream
> to response, I have to end the response when the file is completely
> uploaded, rather than continuously reading.
>
> node-growing-file only support end by timeout. If it support end
> by bytesExpected, this will be great. I will see if I can submit a patch.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: How to continuously read a file while the file is been writing

[Marcel Laverdet]

Shin, I commented on your gist with code you can use. You just need to
modify it to catchup with existing data. Please treat this only as a proof
of concept, and be aware you need to handle error unexpected errors like
truncated files, deleted files, and so on. Also keep in mind that on OS X
fs.watchFile() is still kind of slow, on Linux you will get much faster
results.

On Mon, Feb 6, 2012 at 1:39 AM, Shin Suzuki  wrote:

> Marcel,
>
> I wrote a simple code with 12 lines to read newly added lines of a file
> when changes happen, as you do in the previous sample.
>
> https://gist.github.com/1750489
>
> However, it couldn't read newly added data (Node v0.6.9, macOS X).
>
> Is something wrong with my code?
> How can your code work without re-opening the file?
>
>
>
> 2012/2/3 Mi Jun 
>
>> Using fs.watchFile() and fs.read() will force me to re-implement
>> stream.pipe(response) again. Using fs.createReadStream(path,
>> {start:offset}) is much more easier.
>>
>> --
>> 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+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: How to continuously read a file while the file is been writing

[Marcel Laverdet]

Matt keeps screaming race condition because conditions stated to not be
handled are not handled.

On Wed, Feb 8, 2012 at 5:09 PM, Mark Hahn  wrote:

> That's not really a race, just a condition not covered.
>
>
> On Wed, Feb 8, 2012 at 3:08 PM, Matt  wrote:
>
>> There's a race between when you get the results from stat and re-open the
>> file. You know it's changed, you assume it has grown, so you re-open at
>> "last-byte-read" position. But what if between that time, the file got
>> truncated to zero, meaning you need to read from the start of the file?
>>
>> On Wed, Feb 8, 2012 at 4:36 PM, Adam Pritchard 
>> wrote:
>>
>>> Can you elaborate? I'm pretty new to JS/Node, so maybe I'm not seeing it.
>>>
>>> I recognize that the file reading isn't one-to-one with the
>>> notifications (i.e., many rapid file modifications will probably be
>>> processed in a single file read, and then following notifications won't
>>> have an effect until the file grows again), but I don't see that that's a
>>> problem -- the data should still get processed in a timely fashion.
>>>
>>> On the other hand... my tests aren't running through successfully on two
>>> of three OSes, so there's certainly something not right...
>>>
>>> I'd appreciate any bugs or flaws you can point out.
>>>
>>> Adam
>>>
>>>
>>> On Wed, Feb 8, 2012 at 11:40 AM, Matt  wrote:
>>>
 Still has a race condition in it.


 On Tue, Feb 7, 2012 at 8:20 PM, Adam Pritchard <
 pritchard.a...@gmail.com> wrote:

> I've also been working on a little log-file-following (tail -f) node
> module.
>
> https://github.com/adam-p/text-file-follower/blob/master/lib/index.coffee
>
> I need it to work on Windows, so it's cross-platform. It works okay
> already, but I still have some stuff to do.
>
> The behaviour of fs.watch is a bit sketchy. For example...
> https://github.com/joyent/node/issues/search?q=fs.watch&state=open
>
> If I didn't need/want to support Windows I'd probably use fs.watchFile.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

  --
 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+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/nodejs?hl=en?hl=en

>>>
>>>  --
>>> 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+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>
>>
>>  --
>> 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+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: How to continuously read a file while the file is been writing

[Marcel Laverdet]

You certainly can do this without reopening the file. I'm using very
similar code to tail MySQL's binlogs. Are you sure that you're appending to
the file? Like others mentioned this does not handle reopening the file in
the case it's removed or whatever. If that is a constraint you will have to
handle it accordingly.

I'm running the code I posted on your gist on OS X just fine. I'm running
it on a file and then in another terminal session running "echo hello >>
file" and then seeing the output in the other terminal. There is a two
second delay or so.

On Wed, Feb 8, 2012 at 9:37 PM, Shin Suzuki  wrote:

> Marcel,
>
> Thanks for the sample code.
> Unfortunately, it didn't work in my environment (Mac OS X and CentOS).
> Essentially the code you've shown and my code is the same, in that both
> don't re-open the file.
> It seems we cannot fetch the added data without re-opening,
> Considering the overhead of opening the file in each "change" event, just
> spawning "tail -f" would be better as Matt says.
> What's difficult is that we cannot know at which line the child process of
> "tail -f" starts to read when the file is growing.
>
>
> 2012/2/9 Marcel Laverdet 
>
>> Matt keeps screaming race condition because conditions stated to not be
>> handled are not handled.
>>
>>
>> On Wed, Feb 8, 2012 at 5:09 PM, Mark Hahn  wrote:
>>
>>> That's not really a race, just a condition not covered.
>>>
>>>
>>> On Wed, Feb 8, 2012 at 3:08 PM, Matt  wrote:
>>>
>>>> There's a race between when you get the results from stat and re-open
>>>> the file. You know it's changed, you assume it has grown, so you re-open at
>>>> "last-byte-read" position. But what if between that time, the file got
>>>> truncated to zero, meaning you need to read from the start of the file?
>>>>
>>>> On Wed, Feb 8, 2012 at 4:36 PM, Adam Pritchard <
>>>> pritchard.a...@gmail.com> wrote:
>>>>
>>>>> Can you elaborate? I'm pretty new to JS/Node, so maybe I'm not seeing
>>>>> it.
>>>>>
>>>>> I recognize that the file reading isn't one-to-one with the
>>>>> notifications (i.e., many rapid file modifications will probably be
>>>>> processed in a single file read, and then following notifications won't
>>>>> have an effect until the file grows again), but I don't see that that's a
>>>>> problem -- the data should still get processed in a timely fashion.
>>>>>
>>>>> On the other hand... my tests aren't running through successfully on
>>>>> two of three OSes, so there's certainly something not right...
>>>>>
>>>>> I'd appreciate any bugs or flaws you can point out.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On Wed, Feb 8, 2012 at 11:40 AM, Matt  wrote:
>>>>>
>>>>>> Still has a race condition in it.
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 7, 2012 at 8:20 PM, Adam Pritchard <
>>>>>> pritchard.a...@gmail.com> wrote:
>>>>>>
>>>>>>> I've also been working on a little log-file-following (tail -f) node
>>>>>>> module.
>>>>>>>
>>>>>>> https://github.com/adam-p/text-file-follower/blob/master/lib/index.coffee
>>>>>>>
>>>>>>> I need it to work on Windows, so it's cross-platform. It works okay
>>>>>>> already, but I still have some stuff to do.
>>>>>>>
>>>>>>> The behaviour of fs.watch is a bit sketchy. For example...
>>>>>>> https://github.com/joyent/node/issues/search?q=fs.watch&state=open
>>>>>>>
>>>>>>> If I didn't need/want to support Windows I'd probably use
>>>>>>> fs.watchFile.
>>>>>>>
>>>>>>> --
>>>>>>> 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

Re: [nodejs] Re: How to continuously read a file while the file is been writing

[Marcel Laverdet]

Yeah if the file is being replaced or truncated you will need to handle
that differently. The code I posted is fine for the simple case of a unique
file being uploaded, but obviously your case may be more complex. This is
enough to get you started though! Gambate~

On Wed, Feb 8, 2012 at 10:14 PM, Shin Suzuki  wrote:

> Sorry, I mistook it. It went fine.
> In some programs, they replace a file instead of appending...
>
>
> 2012/2/9 Marcel Laverdet 
>
>> You certainly can do this without reopening the file. I'm using very
>> similar code to tail MySQL's binlogs. Are you sure that you're appending to
>> the file? Like others mentioned this does not handle reopening the file in
>> the case it's removed or whatever. If that is a constraint you will have to
>> handle it accordingly.
>>
>> I'm running the code I posted on your gist on OS X just fine. I'm running
>> it on a file and then in another terminal session running "echo hello >>
>> file" and then seeing the output in the other terminal. There is a two
>> second delay or so.
>>
>>
>> On Wed, Feb 8, 2012 at 9:37 PM, Shin Suzuki  wrote:
>>
>>> Marcel,
>>>
>>> Thanks for the sample code.
>>> Unfortunately, it didn't work in my environment (Mac OS X and CentOS).
>>> Essentially the code you've shown and my code is the same, in that both
>>> don't re-open the file.
>>> It seems we cannot fetch the added data without re-opening,
>>> Considering the overhead of opening the file in each "change" event,
>>> just spawning "tail -f" would be better as Matt says.
>>> What's difficult is that we cannot know at which line the child process
>>> of "tail -f" starts to read when the file is growing.
>>>
>>>
>>> 2012/2/9 Marcel Laverdet 
>>>
>>>> Matt keeps screaming race condition because conditions stated to not be
>>>> handled are not handled.
>>>>
>>>>
>>>> On Wed, Feb 8, 2012 at 5:09 PM, Mark Hahn  wrote:
>>>>
>>>>> That's not really a race, just a condition not covered.
>>>>>
>>>>>
>>>>> On Wed, Feb 8, 2012 at 3:08 PM, Matt  wrote:
>>>>>
>>>>>> There's a race between when you get the results from stat and re-open
>>>>>> the file. You know it's changed, you assume it has grown, so you re-open 
>>>>>> at
>>>>>> "last-byte-read" position. But what if between that time, the file got
>>>>>> truncated to zero, meaning you need to read from the start of the file?
>>>>>>
>>>>>> On Wed, Feb 8, 2012 at 4:36 PM, Adam Pritchard <
>>>>>> pritchard.a...@gmail.com> wrote:
>>>>>>
>>>>>>> Can you elaborate? I'm pretty new to JS/Node, so maybe I'm not
>>>>>>> seeing it.
>>>>>>>
>>>>>>> I recognize that the file reading isn't one-to-one with the
>>>>>>> notifications (i.e., many rapid file modifications will probably be
>>>>>>> processed in a single file read, and then following notifications won't
>>>>>>> have an effect until the file grows again), but I don't see that that's 
>>>>>>> a
>>>>>>> problem -- the data should still get processed in a timely fashion.
>>>>>>>
>>>>>>> On the other hand... my tests aren't running through successfully on
>>>>>>> two of three OSes, so there's certainly something not right...
>>>>>>>
>>>>>>> I'd appreciate any bugs or flaws you can point out.
>>>>>>>
>>>>>>> Adam
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 8, 2012 at 11:40 AM, Matt  wrote:
>>>>>>>
>>>>>>>> Still has a race condition in it.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 7, 2012 at 8:20 PM, Adam Pritchard <
>>>>>>>> pritchard.a...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I've also been working on a little log-file-following (tail -f)
>>>>>>>>> node module.
>>>>>>>>>
>>>>>>>>> https://github.com/adam-p/text-file-follower/blob/m

Re: [nodejs] Re: node-fibers or generators

[Marcel Laverdet]

2) As of node 0.6.0, node-fibers is just a module. It never was a fork, but
in node 0.4.0 it was much more of a hack. In node 0.6.0 it works just like
any other module, you install it, require it, and use it.

3) Depending on how you use fibers, it may be possible to rewrite your code
using generators, it may not be. Fibers will give you a superset of
functionality and it's up to you to look at what generators will be and
build your code to support them in the future if that's what you want.

On Fri, Feb 10, 2012 at 12:55 PM, Mikeal Rogers wrote:

> fibers and generators (as described in harmony) have a large delta between
> them.
>
> if you read the harmony spec for generators you'll notice that the yield
> statement pushes it's way all the way up the call stack so you can't
> abstract it away the same way common-node does with fibers.
>
> what you should probably do is just use normal node, the way 99% of the
> community does :)
>
>
> On Feb 10, 2012, at February 10, 20121:35 PM, Marco Rogers wrote:
>
> 1) node will support harmony generators the second they are stable in v8.
> The language evolves with v8, node doesn't touch it.
>
> 2) To my knowledge, node-fibers is a fork of node with patches to both
> node and v8 to enable fibers. So you can't just run node, you have to run
> node-fibers.
>
> 3) I think it would be very easy to paint yourself into a corner here. But
> there are lots of abstractions on top of fibers that could possibly be
> implemented later with generators instead. Keep in mind that when you dig
> into the details, fibers seem to allow deeper semantic changes in node than
> the version of generators in harmony. I'm not the best person to explain
> the difference, but I've understood enough of the talk to know they are not
> equivalent paradigms. Generators enable a subset of functionality that
> fibers does.
>
> Hope this helps.
>
> :Marco
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] how to write for-each loop in JavaScript properly

[Marcel Laverdet]

This is one of those old Crockfordisms that I definitely don't agree with.
How about instead you just don't add garbage to Object.prototype? Or if you
do make them DontEnum. Do you really write two-line loop headers every time
you want a loop??

On Sun, Feb 12, 2012 at 6:42 AM, Shimon Doodkin wrote:

> for (var key in myobj) must be accompanied with
> if(Object.hasOwnProperty.call(myobj,key))
>
> example:
>
> for (var key in myobject) {
>  if(Object.hasOwnProperty.call(myobject,key)){
> ...
>  }
>}
>
> myobject.forEach(function(){...}) already does this.
>
>
> more:
>
> You could do :  myobj.hasOwnProperty(key) But then if myobj is NULL it
> will throw an error.
> So you use the method hasOwnProperty from the prototype object.
> and you call it with changing the this object of it to your object.
>
> Object.hasOwnProperty.call(myobj,key)
>
> Most of you probably know this, but sometimes I encounter modules that
> don't do this.
> And they do unexpected errors.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] how to write for-each loop in JavaScript properly

[Marcel Laverdet]

No one augments Object.prototype in the browser because if you do
everything dies. "Don't use Object.prototype" is a much better rule than
"write ridiculous guards on every loop". Libraries don't just sneak into
your project you have to put them there and it will be very apparent if you
ever run across one that touches O.proto. And it also won't be a very
popular library. And it will also be easy to fix.

On Sun, Feb 12, 2012 at 11:14 PM, Martin Cooper  wrote:

> On Sun, Feb 12, 2012 at 12:09 PM, Marcel Laverdet 
> wrote:
> > This is one of those old Crockfordisms that I definitely don't agree
> with.
> > How about instead you just don't add garbage to Object.prototype?
>
> Depends on how much control you have over all the code in your
> environment. Things are somewhat better in Node land, but in browser
> land, all it takes is some library you're using that augments
> Object.prototype and you're hosed unless you protect your own
> enumerations from such augmentation.
>
> --
> Martin Cooper
>
>
> > Or if you
> > do make them DontEnum. Do you really write two-line loop headers every
> time
> > you want a loop??
> >
> >
> > On Sun, Feb 12, 2012 at 6:42 AM, Shimon Doodkin 
> > wrote:
> >>
> >> for (var key in myobj) must be accompanied with
> >> if(Object.hasOwnProperty.call(myobj,key))
> >>
> >> example:
> >>
> >> for (var key in myobject) {
> >>  if(Object.hasOwnProperty.call(myobject,key)){
> >> ...
> >>  }
> >>}
> >>
> >> myobject.forEach(function(){...}) already does this.
> >>
> >>
> >> more:
> >>
> >> You could do :  myobj.hasOwnProperty(key) But then if myobj is NULL it
> >> will throw an error.
> >> So you use the method hasOwnProperty from the prototype object.
> >> and you call it with changing the this object of it to your object.
> >>
> >> Object.hasOwnProperty.call(myobj,key)
> >>
> >> Most of you probably know this, but sometimes I encounter modules that
> >> don't do this.
> >> And they do unexpected errors.
> >>
> >> --
> >> 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+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/nodejs?hl=en?hl=en
> >
> >
> > --
> > 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+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[nodejs] XML literals in NodeJS and IE6

[Marcel Laverdet]

Just wanted to ping the list and let everyone know a more mature of version
of xml-literals is available to install if anyone is interested in checking
it out. I sent out my work to the Node list more than a year ago, but
didn't bother making it too accessible to the greater community. C++ and
boost were required and it wasn't even in npm so it was pretty hard to work
with, but that's no longer true! In that time I've been using xml-literals
in my own project working out bugs as I found them.

Basically xml-literals gives you a safe and easy way to generate XML (or
HTML) documents. For example:

var name = uri.query.name;
var greeting = Hello, {name}. Good to meet you.;
response.write(greeting.toString());

XML literals can span multiple lines and you can insert arbitrary data via
JS expressions in {}'s.

If you're familiar with E4X (put down your pitchforks!) you could consider
it "E4X: The Good Parts". Or if you've heard of Facebook's XHP you could
consider it XHP for JS.

Advantages:
- Context-sensitive escaping, no XSS
- Easy to write, directly represents what will be sent to the browser, no
quotes and +'s required
- Functional decomposition is a breeze with document fragments and DOM
manipulation (appendChild, insertBefore, etc)
- Can be applied to client-side JS, directly creating DOM nodes

Disadvantages:
- "Not Javascript"
- Relies on code transformation
- Your text editor might freak out (vim does fine unless you use quotes or
apostrophes in raw html)

A full example w/ http server can be found here:
https://raw.github.com/laverdet/js-xml-literal/master/example/main.js

Install with:
npm install xml-literals

github:
https://github.com/laverdet/js-xml-literal

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] parseInt bug

[Marcel Laverdet]

I just use Number() [note, no `new` ctor]. No idiomatic operator soup, just
an expressive conversion. Floats are preserved.

> Number('08') === 8
true
> Number('1.2') === 1.2
true

On Tue, Feb 21, 2012 at 7:10 PM, Louis Santillan  wrote:

> Thomas Fuchs recommends using double tilda (~~) for string conversion.
> Safer and just as fast (
> http://mir.aculo.us/2010/05/12/adventures-in-javascript-number-parsing/).
>
> -L
>
>
> On Tuesday, February 21, 2012, Murvin Lai wrote:
>
>> proper use of parseInt is do that. parseInt(number, 10)  for 10-base.
>>
>> On Tue, Feb 21, 2012 at 2:16 PM, Andrew Chilton wrote:
>>
>>> On 22 February 2012 10:46, Tim Caswell  wrote:
>>> > While it's annoying, it's a good idea to always specify the radix (the
>>> > second argument to parseInt) when parsing numbers and you know the
>>> > radix. This is why jslint yells at you if you leave this "optional"
>>> argument
>>> > off.
>>>
>>> On a slightly different note, another good way (which Crockford also
>>> suggests) is instead of using parseInt(), coerce the string into
>>> number by using +'08'. This will give you the number 8.
>>>
>>> Note that in your case this may not be what you want since it gives a
>>> number, not an integer. This is fine if you know your string contains
>>> a round number, but not if your string can contain a decimal point.
>>> e.g. +'08.5' will give you the number 8.5.
>>>
>>> If you ever use this in a calculation of some sort, it's also good to
>>> put parens around your coerce. For example:
>>>
>>>var x = something + (+'08') + whatever;
>>>
>>> Cheers,
>>> Andy
>>>
>>> --
>>> Andrew Chilton
>>> e: chi...@appsattic.com
>>> w: http://www.appsattic.com/
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>
>>
>>  --
>> 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+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>
>
> --
> Sent from Gmail Mobile
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] parseInt bug

[Marcel Laverdet]

Yeah it's identical to prefix +, just more "english" and doesn't blend in
with string concatenation. It's totally a matter of preference. I
personally find that while writing software I'm rarely blocked by raw
typing speed so I use Number() because it makes +'s less ambiguous when I'm
reading my code later.

On Tue, Feb 21, 2012 at 7:46 PM, Mark Hahn  wrote:

> >  I just use Number()
>
> Doesn't + do the same thing?  I'm a lazy typist.
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: JSLint or not?

[Marcel Laverdet]

Doesn't every modern JS-minifier kill trailing commas?

On Thu, Feb 23, 2012 at 3:27 AM, cole gillespie  wrote:

> one thing that i use it for mainly is to catch trailing commas of death --
> IE is a bitch. JSHint helps with checking for simple human errors. I agree
> with TJ 100%
>
>
> On Thu, Feb 23, 2012 at 3:23 AM, tjholowaychuk wrote:
>
>> use it for things that actually matter, like discovering unwanted
>> global vars etc, but ignore all the style crap
>>
>> On Feb 22, 12:34 pm, "P. Douglas Reeder"  wrote:
>> > @Douglas, have you compared it with JSHint?
>> >
>> > I've tried to configure JSLint to not throw errors, but it's too
>> > finicky.  I found it very easy to configure Miller's Javascript lint
>> > to not returning spurious errors, and it catches additional real
>> > errors like functions sometimes reurning   a value and sometimes not,
>> > and variables not being declared as local.
>> >
>> > I haven't tried JSHint -- it does sound more usable.  Does it catch
>> > all the errors that Miller's Javascript Lint does?
>> >
>> > On Feb 21, 6:25 am, Mark Volkmann  wrote:
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > > I understand you don't like JSLint, but in what way is it less useful
>> > > for routine usage than any other lint tool?
>> >
>> > > ---
>> > > R. Mark Volkmann
>> > > Object Computing, Inc.
>> >
>> > > On Feb 20, 2012, at 10:58 PM, "P. Douglas Reeder" <
>> reeder...@gmail.com> wrote:
>> >
>> > > > Crockford's JSLint is designed for occasional use, to nudge
>> > > > programmers toward better code. It's neither designed for nor works
>> > > > well as a routine part of your toolchain.
>> >
>> > > > Miller's JavaScript Lint (http://www.javascriptlint.com/) is
>> > > > configurable for your project's style, and is a part of my
>> toolchain.
>> >
>> > > > --
>> > > > 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 tonod...@googlegroups.com
>> > > > To unsubscribe from this group, send email to
>> > > >nodejs+unsubscr...@googlegroups.com
>> > > > For more options, visit this group at
>> > > >http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> --
>> 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+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: parseInt bug

[Marcel Laverdet]

You could extend String.prototype if you wanted to but it's probably one of
the less common ways to do this kind of thing. It has disadvantages like
portability, and it will ONLY works on strings. Using Number() or + on
something that's not a string (undefined, an object, a number) will work
fine, but your prototype idea will fail. If you did want to go this way I'd
recommend calling it `toNumber` to match the `toString` convention.

On Fri, Feb 24, 2012 at 7:35 AM, Lothar Pfeiler wrote:

> Yes, you're right. I am new to a JS group. So, mixing integers and
> floats is a new experience to me. This competition of typing less, was
> something I took part in back in the 90s and I thought it's gone
> because of the auto completion feature of today's editors. And because
> of today's processors and libraries I thought the performance
> discussions are gone, too.
>
> I think the dos and don'ts of a language are more important, which
> brings me to my question regarding string-to-integer conversion.
> Is it ok to extent the String object for some oo-style?
>
> e.g.:
> String.prototype.intValue = function () {
>   return parseInt(this, 10);
> };
>
> var area = width.intValue() * height.intValue();
>
> Lothar
>
> On Feb 23, 8:20 pm, Marco Rogers  wrote:
> > You guys should stop trolling each other and try to be helpful. This is
> an
> > area of js fraught with both FUD and wtfjs. Better to educate than to
> spout
> > personal anecdotes and one off edge cases. Mark has the right idea by
> > saying pick the technique that "does what you want". But you have to know
> > the difference in order to do that. And you can't assume that what you
> want
> > is what everyone always wants. This is an implementation detail.
> >
> > And finally don't ignore the most obvious and important difference.
> > parseInt... parses integers! It will always try to give you back an
> > integer. Whatever your value is, you will get an integer or you will get
> > NaN. It will try to do this with improperly formatted strings as long as
> > they start with a parse-able number, e.g. "100px". This is either a nice
> > feature, or something to be avoided, depending on how well you've
> validated
> > your input. On the other hand, number conversion is part of the standard
> > language grammar. It uses well defined (but not necessarily intuitive)
> > rules to take a value and give you a number that may or may not have a
> > decimal component, or if it can't, it'll give you NaN. But it also
> respects
> > alternate number formats that are valid like exponential notation, e.g.
> > Number("10e2") === 1000. Using the unary "+" operator in front of a value
> > is strictly equivalent to calling Number().
> >
> > Now, all of that being said, I think it's clear that both of these
> violate
> > principle of least surprise once you get into edge cases. They will both
> > screw you at some point or another if you don't control your input and
> > validate your output. So which one you should use isn't an "always" thing
> > and it has nothing do with what you find "more readable". Understand them
> > both, and pick the one that works for what you're doing.
> >
> > :Marco
> >
> >
> >
> >
> >
> >
> >
> > On Wednesday, February 22, 2012 10:18:57 AM UTC-8, Mark Hahn wrote:
> >
> > > >  +'123 px'
> > > >  NaN
> >
> > > And that is exactly correct.  '123 px'  is not a number.   Using that
> > > "feature" is worse than trusting type coercion.  I would never trust
> that
> > > in my code, just as I always use === instead of ==.  Well actually I
> use
> > > "is" in coffee, but that is a different subject.
> >
> > > What if your string was accidentally "100%" instead of "100 px"?
> >
> > > You said nothing is right for me.  I'm just pointing out that was an
> > > overly broad statement.  Using + instead of parseInt *is* exactly
> right for
> > > me.
> >
> > > If you want to be able to use '010' to represent 8 and '1xyz' to
> represent
> > > 1, then more power to you.  I myself will never use parseInt.  Not
> only for
> > > the behavior but because it takes too much typing, is less succinct and
> > > therefore is less readable.
> >
> > > Compare...
> > > area = +w * +h
> > > To ...
> > >  area = parseInt(w, 10) * parseInt(h, 10)
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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

Re: [nodejs] Re: parseInt bug

[Marcel Laverdet]

So? That's nothing we haven't covered here. Personally I'd recommend:
String.prototype.toNumber = function() { return Number(this) };

Actually I wouldn't recommend it, I'd recommend just using Number() or +
without touching the prototype.

On Fri, Feb 24, 2012 at 1:46 PM, Jorge  wrote:

> On Feb 24, 2012, at 8:37 PM, Marcel Laverdet wrote:
>
> > You could extend String.prototype if you wanted to but it's probably one
> of the less common ways to do this kind of thing. It has disadvantages like
> portability, and it will ONLY works on strings. Using Number() or + on
> something that's not a string (undefined, an object, a number) will work
> fine, but your prototype idea will fail. If you did want to go this way I'd
> recommend calling it `toNumber` to match the `toString` convention.
>
> String.prototype.toInt= function toInt () { return parseInt(this, 10) };
> "123 px".toInt()
> 123
> --
> Jorge.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: Thinking asynchronously

[Marcel Laverdet]

Yeah fibers as a crutch isn't recommended. It should be a tool, but not
until you can do it without the tool :)

On Sun, Feb 26, 2012 at 4:19 PM, Oliver Leics wrote:

> On Sun, Feb 26, 2012 at 11:07 PM, Chris Scribner  wrote:
> > If you have a lot of logic like this in your app and don't mind adding
> > a dependency on fibers, you could use one of these libraries to write
> > in a form you're more used to. I also think it'll be easier to
> > maintain in the long run.
> >
> > https://github.com/scriby/asyncblock (my pet project)
> > https://github.com/0ctave/node-sync
>
> But before you can go into the long run, you have to understand the
> basic principles of walking.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: Thinking asynchronously

[Marcel Laverdet]

Well you need to understand what's going on under the hood at least to some
degree, or someone on your team does to enforce best practices and so
you'll have someone to go when things go wrong. When things go wrong and
Fibers are involved, if you don't know what's going on then you're up a
shit creek. Anyway, wasn't trying to turn this thread into something it's
not! Recommend starting a new fibers thread if you want to talk about
fibers [and I do love talking about fibers :) ]

On Sun, Feb 26, 2012 at 9:35 PM, Chris Scribner  wrote:

> > Yeah fibers as a crutch isn't recommended. It should be a tool, but not
> > until you can do it without the tool :)
>
> It feels odd for me to disagree with the person who wrote fibers, but
> I'll present another viewpoint. I've seen these sort of comments often
> when I bring up fibers, and I think they unnecessarily conflate node's
> threading model with writing code in Continuation Passing Style.
>
> The best way I've always learned a new language or framework is just
> to jump in and get something working. There's so many details I don't
> know yet -- I need some small bits that I can focus on first.
>
> I think it's completely reasonable someone could jump into node and
> use fibers to remove the complexity of writing code in CPS. It's a
> gentler introduction to coding in node, as they can more readily apply
> knowledge they likely already have of c style languages.
>
> They can learn CPS when needed -- which at first would just be for
> reading others' code.
>
> Whether you use fibers or CPS, you still have to learn node's
> threading model and how it handles I/O. This is really the heart of
> node, and it's the same knowledge for both cases. There's no intrinsic
> link between async I/O and writing code in CPS.
>
> In Scheme and LISP it's not uncommon to use CPS form when writing
> synchronous code. In .NET 5 the async and await keywords, which are
> similar to the fibers approach, are available.
>
> I wouldn't feel that I need to tell a .NET coder to learn the old way
> of doing async first (unless I just wanted him to feel my pain),
> because using async / await will be much more straightforward. And I
> feel exactly the same way about fibers in node.
>
> Chris
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: Buffer concatenation - why does it work?

[Marcel Laverdet]

There's nothing magic happening here, it's just the toString() method
behaving as normal:

marcel@air ~ $ cat foo.js
var foo = {toString: function() { return 'foo' }};
console.log(foo + foo);

marcel@air ~ $ node foo.js
foofoo

On Tue, Feb 28, 2012 at 1:56 PM, billywhizz  wrote:

> from some initial tests, it seems 20 be about 30% faster to do s =
> a.toString + b.toString() instead of s = a + b
>
> On Feb 28, 11:41 pm, billywhizz  wrote:
> > I'm struggling to understand why the following works when
> > concatenating two buffers into strings:
> >
> > var a = new Buffer("0123456789");
> > var b = new Buffer("0123456789");
> > var s = a + b;
> > console.log(s);
> >
> > is the addition operator overloaded in some way to coerce a buffer
> > into a string when used with two buffers? if so, does it always do a
> > conversion to utf8 or ascii? is this a bad way of doing things
> > generally?
> >
> > thanks for any info.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: enable/disable assertion

[Marcel Laverdet]

> de&&bug( msg) is much faster when traces are disabled

Is this a true statement?

On Wed, Feb 29, 2012 at 7:36 AM, JeanHuguesRobert <
jeanhuguesrob...@gmail.com> wrote:

> On 29 fév, 00:33, Phoscur  wrote:
> > How is this better than:
> > function debug(msg) {
> > if (DEBUG_ON) {
> > console.log(msg);
> > }}
> >
> > ?
>
> de&&bug( msg) is much faster when traces are disabled. Idem with
> de&&mand() vs assert().
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Merging a layout document with a database record

[Marcel Laverdet]

*hijack* xml-literals is plates but without the need to use strings
everywhere:

https://github.com/laverdet/js-xml-literal

On Sun, Mar 4, 2012 at 5:33 PM, Tito Ciuro  wrote:

> Hi Jann,
>
> Having read both options, I would say that plates matches our workflow
> better. Based on the way we work, plates is unobtrusive and easily lets
> each one of us work without having to change anything. If at some point we
> see that it's not working for us, we'll certainly look at vacuum. :-)
>
> Thanks for the feedback!
>
> -- Tito
>
> On Mar 4, 2012, at 3:00 PM, Jann Horn wrote:
>
> > Am Sonntag, den 04.03.2012, 03:49 -0800 schrieb fent:
> >> Nice. More templating engines should offer streaming.
> >
> > thanks :)
> >
> >
> >> But he did mention he's looking for a solution for both programmers and
> >> designers. With plates there's no special syntax, it's just plain html.
> >
> > But that also means it's restricted to use in HTML files.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] [meta] GPG?

[Marcel Laverdet]

SPF takes care of my worries about fake emails.

On Wed, Mar 7, 2012 at 4:30 AM, Richard Marr  wrote:

> > Fake emails aren't that hard, I think...
>
> Misunderstanding, let me rephrase:
>
> (likely damage) * (probability of it happening) > (effort required)
>
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] garbage collection, patterns: classical/prototypal inheritance and ValueObject

[Marcel Laverdet]

If you can write it in JS, v8 can garbage collect it.

On Sat, Mar 10, 2012 at 2:46 PM, Phoscur  wrote:

> Short Question: Do V8 and Jägermonkey garbage collect prototype chains
> at some point?
>
> Let code speak: https://gist.github.com/e83c353f7f16e14e4333
>
> Actually, while writing this, I found the solution (line 69/70), but I
> would like to leave it without that, as forgetting it may produce a
> memory leak everytime.
>
> Also: How can I improve this pattern? Is it wrong to mix classical and
> prototypal inheritance like this?
>
> I realize that this is one of the JavaScript features, static
> programming languages are only capable of with clumsy reflection. And it
> all comes from this magical Object.create, which uses I'm still exploring.
>
> If you think this is OT for nodejs, show me a better mailinglist to post
> this please.
>
> Best regards,
> Ph
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: How to use AntiSamy-java from a node.js application to sanitize HTML

[Marcel Laverdet]

Sanitization is not difficult. Just escape 5 or so HTML control characters.

On Wed, Mar 28, 2012 at 1:06 PM, dmh2000  wrote:

> because sanitization is pretty difficult and Anti-Samy has a strong
> organization backing it up. that said, I'm sure the existing npm modules
> are good.
>
> http://www.25hoursaday.com/weblog/2008/08/31/DevelopersUsingLibrariesIsNotASignOfWeakness.aspx
>
>
> On Friday, March 2, 2012 3:30:39 PM UTC-8, mscdex wrote:
>>
>> On Mar 2, 5:45 pm, dmh2000  wrote:
>> > i posted a gist on github with an example, using Joe Ferners node-java
>> > to interface to the AntiSamy java library for HTML sanitizationhttps://
>> gist.**github.com/1961957 
>>
>> Why not use something with less overhead, like one of the sanitization
>> modules already on npm?
>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Node in 1 year?

[Marcel Laverdet]

In a year v8 will implement yield in the form of generators and finally we
will have a robust tool that can expressively mitigate the nested callback
problem.

I'm sorry.

On Mon, Apr 2, 2012 at 5:53 PM, TipTop  wrote:

> So I would like to know where node thinks it will be in 1 year?
>
> What are things that are been looked at for improvement with node as a
> whole?
>
> At some point nodes going to run into a wall, and that wall is javascript.
> I feel that js is nodes achilles heel. I LOVE js and live by it but its has
> flaws, maths and stuff like that.
>
> Whats the plan?
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: Modest proposal to make async optional in Node.js

[Marcel Laverdet]

I don't get it if people want sync stuff why not just use one of the many
sync modules out there. This argument is like talking about putting redis
in core what's going on?

On Sat, Apr 7, 2012 at 3:46 PM, Mikeal Rogers wrote:

>
> On Apr 7, 2012, at April 7, 20121:38 PM, Oleg Podsechin wrote:
>
> > I'm not proposing a fork of Node, but rather a place where developing
> for Node using a synchronous style
>
> that's called a fork :)
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: How to avoid callback hell?

[Marcel Laverdet]

Yeah this is like completely wrong. You just made all this up, man.

Fibers doesn't use Isolates anymore than Node does. Fibers also work on
Node 0.4.x (and probably lower), long before Isolates were even introduced
into v8.

node-fibers doesn't "implement threading" it uses libcoro, the actual
method under the hood is either setjmp/longjmp or ucontext depending on
your platform. These are primitives used as pieces of threading in larger
systems so they are vaguely similar, but node-fibers doesn't invoke any
scheduler, nor does it need locking. Performance is fine.

On Mon, Apr 9, 2012 at 4:51 PM, Joe Ferner  wrote:

> Many streamline like APIs use node-fibers (https://github.com/laverdet/
> node-fibers) under the covers and fibers requires isolates which is
> now deprecated and is going to be removed if it hasn't already. I also
> think that the way it works under the covers also incurs performance
> impacts because it ends up implementing threading which is slow. If
> you like non-callback APIs I just wouldn't use node if I were you.
>
> I like using the async library when things get complicated.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: How to avoid callback hell?

[Marcel Laverdet]

func()[1] not being allowed in PHP is just a silly deficiency in the
language grammar and runtime. I "fixed" it in 2009 with a rewrite rule
(right before APC in the compile chain). func()[1] -> _helper(func(), 1). I
have a habit of not accepting languages the way they're given to me I guess.

Anyway I don't think that's a very good comparison. Or maybe it is because
they're both easily fixable problems.

On Tue, Apr 10, 2012 at 1:14 PM, Axel Kittenberger  wrote:

> On Tue, Apr 10, 2012 at 3:37 PM, Yi Tan  wrote:
> > you really should spend a few hours learning coffee script if the js
> > callback syntax make you uncomfortable
>
> Unless coffee script fixes its "implicit local variable is global if
> the names match and just dont take care to not accidently name it
> equally" I will not touch it with a long stick.
>
> Anyway, I find this node.js and callback arguments popping up again
> and again very similar to what happens when asking the PHP guys and
> gals why func()[1] is not a valid language construct? They get all
> miffed usual arguments follow, and it happens all the time again. I
> suppose simply because deeply within they know there is some
> fundamental problem, but convince themselves with far fetched
> arguments like "just get a larger screen" etc. at least as much as the
> repeated questions. Only long after the lifecycle of software solution
> people come, well yes that sucked didn't it? We kinda knew it all the
> way, but we just decided to ignore it.
>
> Maybe you have other good examples?
> Ask GNOME 3 why the panel is no longer customizeable.
> Ask TCL what the they where thinking when they handled every integer
> variable as string.
> Ask Java why multiple inheritence was that bad after all, and all the
> workarounds they later needed for it. You got an Inputstream object
> and Outputstream object, but how to get an InputOutputStream?
> Ask Javascript, about 'this'.
> Ask terminal guys, about why terminal emulations are that complicated
> and never compitabitle to anything else.
> Ask Windows why \r\n, ask why they never ever managed to abolish drive
> letters.
> Ask Apple why \n\r
> Ask Linux why inotify and fanotify while both being non-satisfactory
> for any usecase but the single one they were designed for.
> etc.
>
> So now that I annoyed every tech group there is, I better get logged
> of for a while :-)))
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: How to avoid callback hell?

[Marcel Laverdet]

Joe your stubbornness speaks volumes. If you'd have quit everything in life
after spending 10 minutes and messing up once you wouldn't get anywhere.
There's an ever-growing number of supporters of this kind of
technology (435 followers on github for fibers, 222 for streamline) and to
not even explore it because of baseless assumptions is silly. It's not my
problem if you don't want to use fibers or streamline, I don't care.. but
it becomes my problem when you literally make up lies about this software.
It's good and robust software, I promise. There's a one time cost to learn
some simple rules about how the software works and then you can look
forward to *significant* reductions in lines of code written.

On Tue, Apr 10, 2012 at 3:01 PM, 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  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  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 nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: How to avoid callback hell?

[Marcel Laverdet]

> PS: I just recently heard about node's past ability to froze stack with
promise.wait(). It's sad that this ability was removed just because some
guys used it wrong. It's useful and needed feature for right hands.

While I personally wasn't part of the community when that went down I did a
lot of research into that era. Node did have a wait() method, but it was
naively implemented. No continuations were used; everything was on the same
stack. The result was that you could only resolve the last promise that had
been yielded. However the straw that broke the camel's back was that Node's
HTTP parser was not reentrant; if you froze the stack while in a callback
initiated from the HTTP parser the fun would stop. Fibers solves the first
problem completely, and leaves the second problem as an exercise for the
user (though does make it much harder if not impossible to mess up core
modules).

On Sun, Apr 15, 2012 at 5:53 AM, Eldar  wrote:

> 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 the following line:
>
>mkdirp('path/to/something')
>
> What does it mean? It's sync? It uses faux blocking? If it's so, why it
> doesn't allow me to run it in parallel?
>
> I guess for the reasons above Tim Caswell wrote:
>
>>  Node “promises” had a method called “wait” that would just suspend the
>> current stack and return the value after the promise was resolved. This was
>> dangerous because libraries were using this technique and it meant that
>> *any* function call could potentially cause your code to get suspended and
>> have things change out from under you.
>
> Please correct me if I get it wrong.
>
> System programming is about solving small concrete tasks with non-changing
> requirements and known in advance data flow. May be it's about something
> else, but practice shows that it's always possible to organize system code
> so that it wouldn't be a hell while sticking with only callbacks, event
> emitters and pipes. I personally agree with the following and came to the
> same value:
>
>> Also, despite being the author of half a dozen control flow libraries, I
>> never use any of them anymore.  I don't like the extra dependency on my
>> library or app, and most importantly, I don't like all the inserted frames
>> in my stack traces.
>>
>
> Everything above was about system programming. There are other application
> domains. Saying business apps. Lets consider the following:
>
>   calculate_taxes(item)
>
> It doesn't have IO? It has and blocks? It has but doesn't block? The
> answer is - who cares? To day it does IO, yesterday it didn't, tomorrow it
> will become sync again. The only right way to program in such conditions is
> to hide IO completely.  Consider the case  when all you code consist's just
> from functions like calculate_taxes. Is it possible to stick with pure js?
> No!
>
> So "How to avoid callback hell?" The answer is - you should learn to
> program. Sometimes it's better to refactor your code while sticking with
> pure js, sometimes you should pull extra dependency like fibers. There is
> no definite answer and everyone can make a mistake.
>
> PS: I just recently heard about node's past ability to froze stack with
> promise.wait(). It's sad that this ability was removed just because some
> guys used it wrong. It's useful and needed feature for right hands.
>
>
> On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote:
>>
>> I posted a follow-up on my blog: http://bjouhier.wordpress.com/**
>> 2012/04/14/node-js-awesome-**runtime-and-new-age-**javascript-gospel/
>>
>> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote:
>>>
>>> I'm trying to write a simple app that preforms a db query when a user
>>> connects to a tcp port.
>>>
>>> I can get the query working if I do everything as callbacks:
>>>
>>>  db.open(... fn() {
>>>  db.collection( fn() {
>>>   db.query(.. fn() {
>>>   });
>>>   });
>>>   });
>>>
>>> But as you can see this creates callback hell.
>>>
>>> What I would like to do is have a class, but being as everything is
>>> async it makes it incredibly difficult to ensure all your variables are
>>> set.
>>>
>>> var client;
>>> db.connect(connect, fn(){
>>>   client = connect;
>>> });
>>> client.close();
>>>
>>> Will cause an error because client hasn't been set yet.  Another thing I
>>> thought of doing was chaining it all together:
>>>
>>> db.connect(connect, fn(){
>>>  ...
>>> process.nextTick(fn(){ doNext(); });
>>> });
>>>
>>> this gets very messy and hard to manage, how can I deal with callback
>>> hell?
>>>
>>>
>>>
> On Saturday, April 14, 2012 8:30:33 P

Re: [nodejs] Re: How to avoid callback hell?

[Marcel Laverdet]

idk man my advice has always been to first learn callbacks and what's going
on behind the scenes, and then to give something like fibers a try if you
want. It's more like OP said that he knew how to swim but was having
problems crossing the English Channel. In this case it doesn't matter
whether you swim, boat, or fly.. he just wanted to get across. I try to
limit my participation in these threads to mentioning non-obvious but
significant advantages of fibers, and defending downright lies; "la la la
la fibers" isn't my attitude. My feeling is that it's common for the
pro-pure crowd to be like "those advantages suck".

There are advantages that fibers get you and there are advantages callbacks
get you. I prefer a tiny bit of magic in order to reduce the amount of code
I have to write, and to get back native loops (for, while, do while,
continue, break) and native error handling (try, catch, finally). But maybe
the magic is too much for you and you prefer callbacks or pure-JS solutions.

Disclaimer: I am the author of node-fibers

On Tue, Apr 17, 2012 at 1:51 AM, Dan North  wrote:

> As a relatively recent adopter of node.js and even JavaScript I find the
> tendency to offer streamline etc. to newcomers a bit like offering a boat
> to someone who has just joined a swimming club and is learning to swim.
>
> - "I'm finding swimming tricky"
> - "Use a boat!"
> - "I think I want to understand swimming"
> - "Use a kayak! It's quicker. It's like it swims for you!"
> - "Nearly everyone else here is swimming. It can't be that hard. I just
> need help with wrapping my head around it."
> - "Try these water-wings called async while you get used to the water."
> - "Oh thanks, that looks useful."
> - "Use a kayak!"
> - "Look, I'm not afraid of getting wet or anything and I can doggy-paddle
> but it's exhausting. I want to learn good swimming technique. Can you point
> me to some useful resources?"
> - "La la la use a boat!"
> - *sigh* (leaves)
>
>
> So, since I'm also likely to end up coaching this stuff because that's
> what I do, and I'm a fan of good resources, I'm genuinely interested in the
> following:
>
> Can anyone recommend a good resource for an experienced programmer who is
> new to async, callback- and event-based, single event loop programming in
> JavaScript and node.js? And no I don't want a boat or anything else that
> masks the "async experience". Honestly, I'll be ok.
>
> Thanks,
> Dan
>
> -Original Message-
> From: Jorge 
> Sender: nodejs@googlegroups.com
> Date: Mon, 16 Apr 2012 20:39:15
> To: 
> Reply-To: nodejs@googlegroups.com
> Subject: Re: [nodejs] Re: How to avoid callback hell?
>
> On Apr 16, 2012, at 3:08 PM, Nuno Job wrote:
>
> > 
> >
> > Nuno
>
>
> Gratuitous, and unnecessarily rude: -1024
> --
> Jorge.
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Odd evalution of instanceof regexp in sandboxed module

[Marcel Laverdet]

The new context gets its own RegExp and set of built-ins. You'll run into
the same issue with [] and Array, {} and Object, and function(){} and
Function.

On Mon, Apr 30, 2012 at 1:28 PM, Eric  wrote:

> Hi guys,
>
> I have a code that check if a certain object is a regexp by evaluating the
> expression " regexp_literal instanceof RegExp". When I evaluate the code in
> a node REPL it returns true. But when I evaluate it using a
> sandboxed-module (I use it for DI in my unit tests) the same expression
> evaluates to false.
>
> Tracking down this odd behavior I wen't writing this
> "proof-of-concept"  code:
>
> --[ https://gist.github.com/2560249 ]--
> var reg = /^[a-z]$/;
>
> console.log('case 01: typeof /^[a-z]$/ returns %s', typeof reg);
> console.log('case 02: /^[a-z]$/ instanceof RegExp returns %s', reg
> instanceof RegExp);
> console.log('case 03: /^[a-z]$/.constructor.name === "RegExp" returns
> %s', reg.constructor.name === 'RegExp');
>
> var util = require('util'),
> vm = require('vm'),
> sandbox = { u: reg };
>
> vm.runInNewContext('out1 = /^[a-z]$/ instanceof RegExp; out2 = u
> instanceof RegExp; u_name = u.constructor.name', sandbox);
> console.log(util.inspect(sandbox));
>
> When I run this code I got the following output:
>
>   hobbes:weird ericchaves$ node app.js
>   case 01: typeof /^[a-z]$/ returns object
>   case 02: /^[a-z]$/ instanceof RegExp returns true
>   case 03: /^[a-z]$/.constructor.name === "RegExp" returns true
>   { u: /^[a-z]$/, u_name: 'RegExp', out1: true, out2: false }
>
> Why is that the out2 is false? isn't the variable U inside the sandbox a
> regexp? Couls someone help me out understanding this odd behavior?
>
> Cheers,
>
> Eric
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Odd evalution of instanceof regexp in sandboxed module

[Marcel Laverdet]

The new context has its own copy of Object, Array, Function, RegExp, and
all the other native objects. There's nothing special about those built-in
objects, other than being built-in.

> require('vm').runInNewContext('Array == MyArray', {MyArray: Array})
false

Consider what happens when you change your prototype.

> Array.prototype.hello = 1;
1
> [].hello
1
> require('vm').runInNewContext('[].hello')
undefined

On Mon, Apr 30, 2012 at 6:56 PM, Eric  wrote:

> Hi Guys,
>
> Thanks for the help. I'll certainly look into those methods. I'm still
> confused however, so forgive me for asking again. If I got yours
> explanation right the new context has his own copy of the source objects,
> but they are Javascript RegExp isn't? why instanceof fails?
>
> Thanks again,
>
> Eric
>
> On Monday, April 30, 2012 6:22:04 PM UTC-3, Ben Noordhuis wrote:
>
>> On Mon, Apr 30, 2012 at 23:14, Marcel Laverdet wrote:
>> > The new context gets its own RegExp and set of built-ins. You'll run
>> into
>> > the same issue with [] and Array, {} and Object, and function(){} and
>> > Function.
>>
>> What Marcel said. Check out util.isArray(), util.isDate() and
>> util.isRegExp(), they work across contexts.
>>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[nodejs] Is it legit to distribute binaries via npm?

[Marcel Laverdet]

Title says it all.

It seems that modules with a compile stage can sometimes be difficult for
users to get installed. Ubuntu users may not have their node headers
installed, Windows users may not have any compiler at all, Linux users may
have broken build environments, there's just lots of issues that come up
and often require manual intervention.

@japj right now is doing some awesome work getting fibers working on
Windows (as far as I can tell it's pretty much done) and it's got me
thinking about distribution for Windows users. It would be simple enough to
build a version of each tag for Windows 32/64 & Linux 32/64/arm & OS X
32/64. Of course source would also be distributed so you could build it on
your own if you're feeling adventurous or if you're on a different platform.

But is someone going to beat me up if I stick a bunch of compiled binaries
into npm?

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: Is it legit to distribute binaries via npm?

[Marcel Laverdet]

Why do that? Then you're just adding another point of failure.

On Sat, May 5, 2012 at 4:41 AM, Morteza Milani wrote:

> Create tarballs for each platform that contains all binaries you need.
> serve them somewhere.
>
> Create a downloader script that downloads tarballs based on users'
> platform.
>
> Then in your package.json:
>
> "scripts": {
> "preinstall": "./bin/downloader || true; node-gyp rebuild"
> }
>
> This is what I do here: https://github.com/milani/appjs/tree/master/bin
>
> On Saturday, May 5, 2012 3:28:39 AM UTC+4:30, Marcel wrote:
>>
>> Title says it all.
>>
>> It seems that modules with a compile stage can sometimes be difficult for
>> users to get installed. Ubuntu users may not have their node headers
>> installed, Windows users may not have any compiler at all, Linux users may
>> have broken build environments, there's just lots of issues that come up
>> and often require manual intervention.
>>
>> @japj right now is doing some awesome work getting fibers working on
>> Windows (as far as I can tell it's pretty much done) and it's got me
>> thinking about distribution for Windows users. It would be simple enough to
>> build a version of each tag for Windows 32/64 & Linux 32/64/arm & OS X
>> 32/64. Of course source would also be distributed so you could build it on
>> your own if you're feeling adventurous or if you're on a different platform.
>>
>> But is someone going to beat me up if I stick a bunch of compiled
>> binaries into npm?
>>
>  --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Re: Is it legit to distribute binaries via npm?

[Marcel Laverdet]

For several hundred meg libraries the answer is much less obvious.. But
even with a sophisticated or integrated build system, you still can't make
assumptions about their environment? I think Node developers on Windows
without a compiler even installed are quite common. Does node-gyp solve
that?

On Sun, May 6, 2012 at 2:59 AM, Isaac Schlueter  wrote:

> The correct approach is to set up your module to compile using
> node-gyp, such that it can be compiled on windows or on Unix.
>
> Relying on a preinstall script to fetch stuff from a different site is
> weird.  In many ways, that's even worse than relying on install-time
> compilation, because it's yet another service to trust and depend on.
> What's worse, I'm guessing that the bin/downloader thing assumes bash
> or sh or something.
>
> Bundling multiple pre-compiled binaries is also awful.
>
> Use a binding.gyp file.  Use node-gyp.  This is what we're going to be
> optimizing for in the future.
>
> On Sat, May 5, 2012 at 10:33 PM, Morteza Milani 
> wrote:
> >> The trouble is it's not just multiple platforms, but multiple node
> >> versions that you may want to support. I'm assuming your binary is a
> node
> >> extension. Is that true?
> >
> > No its not node extension.
> >
> >>  You could distribute your module without the binary and tell people to
> >> grab the binary themselves in whatever way they feel is best.
> >
> > Do you feel ok if there was no npm to install modules and you had to
> install
> > them manually yourself? Of Course not! its just to ease the process. So
> my
> > downloader is! This is what node-gyp does even.
> >
> > I don't think its another point of failure. Its even a positive point:
> >
> > 1) Users don't need to download a huge node module that contains
> unnecessary
> > files (those for other platforms).
> > 2) They don't need to choose among packages in a download page and put
> it in
> > the proper place in directory 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 Google
> > Groups "nodejs" group.
> > To post to this group, send email to nodejs@googlegroups.com
> > To unsubscribe from this group, send email to
> > nodejs+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] BeagleBone with node.js - getting started.

[Marcel Laverdet]

libcoro runs fine on ARM, but you do need to use the pthread_cond_wait
version by passing -DCORO_PTHREAD. There is a check for this in the
Makefile (and new gyp file) but there hasn't been strong testing there.

On Wed, May 9, 2012 at 12:57 PM, Jorge  wrote:

> On May 9, 2012, at 5:35 PM, Paul Tanner wrote:
>
> > Thx Jorge
> >
> > Evidently I was wrong to go ahead and install npm in the usual way.
>  There must be a separate version or switch option for installation on ARM.
> >
> > More searching needed.  There are several working node modules (eg http)
> in the distribution.  The question is how were they installed?
> >
> > Paul
>
> Hi Paul,
>
> I think libcoro can't run on an ARM, but you should better ask Marcel
> Laverdet (https://github.com/laverdet/node-fibers), or perhaps Marc
> Lehmann (http://software.schmorp.de/pkg/libcoro.html)
>
> > cc  -Wall -Wno-deprecated-declarations -I/usr/include
> -I/usr/include/node -g -O3 -minline-all-stringops -m32 -DCORO_UCONTEXT
> -fPIC -c -o libcoro.o libcoro/coro.c
>
>
> The built-in modules come prebuilt with node so there's no need to "make"
> them.
>
> Could you try to install threads_a_gogo <
> https://github.com/xk/node-threads-a-gogo/> and tell me how it goes ?
>
> npm install threads_a_gogo
>
> And what this gives:
>
> node ./node_modules/threads_a_gogo/test/test01_loop_as_fast_as_possible.js
> 1
>
> ?
> --
> Jorge.
> github.com/xk/
> @jorgechamorro
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[nodejs] Fibers: now with Windows support, binary distribution, and gyp

[Marcel Laverdet]

Hey all just a quick note about some news on node-fibers. Thanks to the
work of @japj, node-fibers is now runnable under Windows. Now you can use
fibers on pretty much any platform.

Semi-related: node-fibers now includes a binary for Windows, OS X, and
Linux in both 32 and 64-bit x86 architectures; this simplifies the install
process greatly. For other platforms node-gyp will be invoked at install
time to build a version of fibers just for you.

Check it out for yourself:
npm install fibers
npm test fibers

More information at:
https://github.com/laverdet/node-fibers

Please report any bugs to the github project, thanks!

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] BeagleBone with node.js - getting started.

[Marcel Laverdet]

gcc version shouldn't matter. The pthread version of libcoro will run on
anything with POSIX-pthreads, it's a very very robust implementation.

That's not to say that node-fibers will run on everything.. the build
process will need to accomodate that. I got access to a beaglebone and
tried to get the latest version of node running on it but didn't get very
far before moving on to other things.

On Wed, May 9, 2012 at 2:29 PM, Jorge  wrote:

> @Marcel Cool! @Paul what does `cc -v` give you ?
>
>
> On May 9, 2012, at 9:18 PM, Marcel Laverdet wrote:
>
> > libcoro runs fine on ARM, but you do need to use the pthread_cond_wait
> version by passing -DCORO_PTHREAD. There is a check for this in the
> Makefile (and new gyp file) but there hasn't been strong testing there.
> >
> > On Wed, May 9, 2012 at 12:57 PM, Jorge  wrote:
> > On May 9, 2012, at 5:35 PM, Paul Tanner wrote:
> >
> > > Thx Jorge
> > >
> > > Evidently I was wrong to go ahead and install npm in the usual way.
>  There must be a separate version or switch option for installation on ARM.
> > >
> > > More searching needed.  There are several working node modules (eg
> http) in the distribution.  The question is how were they installed?
> > >
> > > Paul
> >
> > Hi Paul,
> >
> > I think libcoro can't run on an ARM, but you should better ask Marcel
> Laverdet (https://github.com/laverdet/node-fibers), or perhaps Marc
> Lehmann (http://software.schmorp.de/pkg/libcoro.html)
> >
> > > cc  -Wall -Wno-deprecated-declarations -I/usr/include
> -I/usr/include/node -g -O3 -minline-all-stringops -m32 -DCORO_UCONTEXT
> -fPIC -c -o libcoro.o libcoro/coro.c
> >
> >
> > The built-in modules come prebuilt with node so there's no need to
> "make" them.
> >
> > Could you try to install threads_a_gogo <
> https://github.com/xk/node-threads-a-gogo/> and tell me how it goes ?
> >
> > npm install threads_a_gogo
> >
> > And what this gives:
> >
> > node
> ./node_modules/threads_a_gogo/test/test01_loop_as_fast_as_possible.js 1
> >
> > ?
> > --
> > Jorge.
> > github.com/xk/
> > @jorgechamorro
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] BeagleBone with node.js - getting started.

[Marcel Laverdet]

Oh yeah, that's true. I remember when we got this working on a beaglebone
we just left out -m32 altogether and did -march=arm.

As for my beaglebone I'm crazy and installed Gentoo on it, so this is my cc
-v output ;)

bone ~ # cc -v
Using built-in specs.
COLLECT_GCC=/usr/armv7a-unknown-linux-gnueabi/gcc-bin/4.5.3/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7a-unknown-linux-gnueabi/4.5.3/lto-wrapper
Target: armv7a-unknown-linux-gnueabi
Configured with:
/var/tmp/portage/sys-devel/gcc-4.5.3-r2/work/gcc-4.5.3/configure
--prefix=/usr --bindir=/usr/armv7a-unknown-linux-gnueabi/gcc-bin/4.5.3
--includedir=/usr/lib/gcc/armv7a-unknown-linux-gnueabi/4.5.3/include
--datadir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3
--mandir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3/man
--infodir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3/info
--with-gxx-include-dir=/usr/lib/gcc/armv7a-unknown-linux-gnueabi/4.5.3/include/g++-v4
--host=armv7a-unknown-linux-gnueabi --build=armv7a-unknown-linux-gnueabi
--disable-altivec --disable-fixed-point --without-ppl --without-cloog
--disable-lto --enable-nls --without-included-gettext --with-system-zlib
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp
--with-python-dir=/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3/python
--enable-checking=release --disable-libgcj --with-arch=armv7-a
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=
http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.3-r2 p1.1, pie-0.4.7'
Thread model: posix
gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7)

On Wed, May 9, 2012 at 3:26 PM, Jorge  wrote:

> On May 9, 2012, at 9:45 PM, Marcel Laverdet wrote:
>
> > gcc version shouldn't matter. The pthread version of libcoro will run on
> anything with POSIX-pthreads, it's a very very robust implementation.
> >
> > That's not to say that node-fibers will run on everything.. the build
> process will need to accomodate that. I got access to a beaglebone and
> tried to get the latest version of node running on it but didn't get very
> far before moving on to other things.
>
> but isn't it complaining about the -m32 and the -minline-all-stringops GCC
> (i386) options ?
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Re: [nodejs] Object as hash with 7 million entries slows V8

[Marcel Laverdet]

There is an issue in v8 where idle tick GC does not pick up where the old
GC left off and leads to lots of time wasted. See v8 issue #1458. This is
fixed in bleeding_edge, but hasn't landed in node yet, not even 0.7.x. Try
Jeremy's suggestion or you could also try using bleeding_edge v8 on node
0.7.x. I imagine both would lead to improvements.

On Fri, May 11, 2012 at 3:43 AM, Jérémy Lal  wrote:

> Idle -> GC -> visiting objects (?)
>
> Hence my suggestion : control gc() calls yourself.
>
> On 11/05/2012 10:20, Joran Greef wrote:
> > The thing is the JS is doing nothing, the huge hash is just sitting
> there.
> >
> > On Friday, May 11, 2012 9:57:47 AM UTC+2, kapouer wrote:
> >
> > Isn't that gc doing its work ?
> > As a workaround, you can turn it off and run it manually
> > node --nouse_idle_notification --expose_gc
> > > global.gc();
> >
> > Regards,
> > J�r�my.
> >
> > On 11/05/2012 09:51, Joran Greef wrote:
> > > I have posted this in v8-users but perhaps someone else here will
> also be familiar with this:
> > >
> > > I am using V8 as part of Node and have written a Javascript
> implementation of Bitcask, using a Javascript object as a hash to keep file
> offsets in memory.
> > >
> > > This object has 7 million entries and I'm noticing that while the
> JS code is resting, doing nothing, V8 is hitting 100% CPU every few seconds
> and doing this continually.
> > >
> > > Attached is the full result of running V8 with --prof.
> > >
> > > And of particular interest:
> > >
> > > [C++]:
> > >ticks  total  nonlib   name
> > >   73615   43.1%   43.1%
>  v8::internal::StaticMarkingVisitor::VisitUnmarkedObjects
> > >   68436   40.1%   40.1%  _accept$NOCANCEL
> > >47962.8%2.8%
>  v8::internal::FlexibleBodyVisitor v8::internal::JSObject::BodyDescriptor, void>::VisitSpecialized<40>
> > >
> > > Should I be using many smaller hashes to keep this overhead down?
> i.e. some sort of sparse hash implementation? Or using key mod 1000 to
> determine the hash it should be in?
> > >
> > > Does V8 have limits on hash table sizes?
> > >
> > > Thanks.
> > >
> > > --
> > > Job Board: http://jobs.nodejs.org/
> > > Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-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 nodejs@googlegroups.com>
> > > To unsubscribe from this group, send email to
> > > nodejs+unsubscr...@googlegroups.com  nodejs%2bunsubscr...@googlegroups.com>
> > > For more options, visit this group at
> > > http://groups.google.com/group/nodejs?hl=en?hl=en <
> http://groups.google.com/group/nodejs?hl=en?hl=en>
> >
>
> --
> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[nodejs] NodeJS PPTP VPN server

[Marcel Laverdet]

I wrote an experimental PPTP VPN server in Node. Why? We may never know.
Anyway this was part of a larger personal project and I ultimately decided
to swap this component out for a solution involving routing tables and
tun/tap instead. Figured there was a small chance someone would get some
use from it so here it is.

https://github.com/laverdet/node-pptp

Enjoy.

-- 
-- 
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+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.