Yeah, at least one or require('require') won't work :-P
On 12/07/2012, at 17:28, tjholowaychuk wrote:
> Let's face it, some globals are convenient :p otherwise hell,
> require('array'), require('object'), require('array-map')... the list
> goes on
>
> On Jul 11, 8:40 am, Joran Greef wrote:
>> I
On 28/06/2012, at 16:50, Jorge wrote:
> On 28/06/2012, at 12:13, Ben Noordhuis wrote:
>> On Thu, Jun 28, 2012 at 10:40 AM, Jorge wrote:
>>>
>>>
>>> https://github.com/xk/node-threads-a-gogo/blob/master/src/threads_a_gogo.cc#L202
>>> https://gith
On 28/06/2012, at 12:13, Ben Noordhuis wrote:
> On Thu, Jun 28, 2012 at 10:40 AM, Jorge wrote:
>>
>>
>> https://github.com/xk/node-threads-a-gogo/blob/master/src/threads_a_gogo.cc#L202
>> https://github.com/xk/node-threads-a-gogo/blob/master/src/threads_a_gogo.cc#L2
should just be the default behaviour of libuv.
>>
>> Agreed. Though I still would like to know if that's the actual pattern
>> that Jorge uses. :-)
>
> I think you can see the relevant code at
> https://github.com/xk/node-threads-a-gogo/blob/master/src/threads_a_gogo
On 25/06/2012, at 19:50, Jorge wrote:
> On 25/06/2012, at 19:11, Fedor Indutny wrote
>> On Tue, Jun 26, 2012 at 12:04 AM, Jorge wrote:
>>>
>>> What does replace
>>>
>>> ev_async_start(EV_DEFAULT_UC_ &thread->async_watcher);
>&g
On 25/06/2012, at 19:11, Fedor Indutny wrote
> On Tue, Jun 26, 2012 at 12:04 AM, Jorge wrote:
>> On 25/06/2012, at 18:28, Fedor Indutny wrote:
>>>
>>> You should try using:
>>>
>>> uv_async_init(uv_default_loop(), &async_watcher,
On 25/06/2012, at 18:31, Isaac Schlueter wrote:
>
> On Mon, Jun 25, 2012 at 9:25 AM, Jorge wrote:
>> One more thing:
>>
>> I've been reading the "API changes between v0.6 and v0.8" and "How to
>> migrate from eio_custom to uv_queue_work"
ev_async_start(EV_DEFAULT_UC_ &thread->async_watcher);
and
ev_async_stop(EV_DEFAULT_UC_ &thread->async_watcher);
?
Cheers,
--
Jorge.
(*)(ev_async*, int)’ to ‘void (*)(ev_loop*, ev_async*, int)’
../src/threads_a_gogo.cc:747: error: cannot convert ‘ev_async*’ to ‘ev_loop*’
for argument ‘1’ to ‘void ev_async_start(ev_loop*, ev_async*)’
Thanks,
--
Jorge.
On 25/06/2012, at 18:10, Jorge wrote:
> Yes that works, thank you very much Isa
Yes that works, thank you very much Isaac.
--
Jorge.
On 25/06/2012, at 17:58, Isaac Schlueter wrote:
> Aha, the issue is that ~ is not being expanded in the shebang step.
> If you do this, it will work:
>
> ./configure --prefix=$HOME/JAVASCRIPT/binarios
>
> We can
);
^
Error: ENOENT, no such file or directory
'~/JAVASCRIPT/binarios/lib/node_modules/npm/bin/npm-cli.js'
at Object.fs.openSync (fs.js:338:18)
at Object.fs.readFileSync (fs.js:182:15)
at shebang (/Users/jorge/JAVASCRIPT/node-v0.8.0/tools/installer.js:53:20)
On Jun 10, 2012, at 9:39 AM, Isaac Schlueter wrote:
>
> On Sun, Jun 10, 2012 at 12:20 AM, Jorge wrote:
>> On Jun 8, 2012, at 8:06 PM, AJ ONeal wrote:
>>
>>> I would like to propose that an additional parameter, `context` be added to
>>> core node modules tha
h more than "this" :-P
--
Jorge.
+1k ^ 256
On Jun 2, 2012, at 11:29 AM, Bruno Jouhier wrote:
> Trying to be constructive (and apologies for the flame on applications).
> Would the following be a reasonable way forwards:
>
> * deprecate nextTick. It is confusing and changing it may create difficulties
> and add to the confusio
On Jun 1, 2012, at 11:54 PM, Marco Rogers wrote:
>
>
> There's currently no good way to assign a handler to the end of the current
> RTC.
>
> Agreed. We should add one and call it something besides nextTick :)
+1k ^128
--
Jorge.
On Jun 1, 2012, at 6:29 PM, Jorge wrote:
> On May 30, 2012, at 12:57 AM, Tim Caswell wrote
>>> On Tue, May 29, 2012 at 5:22 PM, Jorge wrote:
>>>
>>> FYI: setImmediate === nextTick and identical to a setTimeout(f,0) without
>>> the clamping.
>>
>
On May 30, 2012, at 12:57 AM, Tim Caswell wrote
>> On Tue, May 29, 2012 at 5:22 PM, Jorge wrote:
>>
>> FYI: setImmediate === nextTick and identical to a setTimeout(f,0) without
>> the clamping.
>
> so I guess in a way setImmediate(fn) could be described fa
it.
But there's no need to touch (such an essential piece of) node's public API
(and fuck all its users and their programs) to fix node's internal bugs.
--
Jorge.
On May 31, 2012, at 10:50 AM, James Howe wrote:
> The git issue now has good examples of why something higher-pr
FYI: setImmediate === nextTick and identical to a setTimeout(f,0) without the
clamping.
--
Jorge.
On May 29, 2012, at 10:45 PM, Isaac Schlueter wrote:
> Computationally expensive stuff should be done in a child process, or
> a uv_work_t thread in an addon. nextTick is a bad fit fo
On May 27, 2012, at 8:38 PM, Marco Rogers wrote:
> Early post cause I'm on my phone. In short, I think the new behavior should
> definitely have trampoline behavior to prevent starvation.
What do trampolines have to do with starvation?
--
Jorge.
On May 27, 2012, at 10:49 PM, Mikeal Rogers wrote:
>
> On May 27, 2012, at May 27, 20121:41 PM, Isaac Schlueter wrote:
>
>> Jorge,
>>
>> They're not "rare cases". Virtually every use of nextTick is
>> specifically designed to allow the attac
n, May 27, 2012 at 10:51 AM, Isaac Schlueter wrote:
> Another option, which may prevent recursive starvation, would be to
> process all the nextTicks at the end of the current tick, but any
> additional nextTicks added in that pass would wait a bit.
>
> On Sun, May 27, 2012 a
n no code breaks and we eventually get the right behavior with the right
> name.
This needs a different method name, if not, the sky is going to fall on our
heads.
And the proper name IMO would be *this*Tick not *next*Tick :-P
And perhaps it should be internal, not part of the public API: _thisTick(). But
that depends: exactly *where* have you seen the problem you mention, @izs?
--
Jorge.
e-case
> where it's known to break, we can try it early in v0.9.
It would mean there's one more thing that can go wrong: the way it's now it's ~
impossible to block the event loop (*), the way you're proposing you could.
(*)except with long running callbacks such as fibonaccis
--
Jorge.
I simply replace deps/v8 without applying any patches and it works fine...
On May 10, 2012, at 2:35 AM, mscdex wrote:
> I am curious about getting a more recent version of v8 running in
> either node 0.7.x or 0.6.x.
>
> I tried swapping out v8 in 0.7.8 and 0.6.17 with a copy of v8 3.10.8.4
> (ch
Begin forwarded message:
> From: Jorge Chamorro Bieling
> Date: March 14, 2012 12:08:48 AM GMT+01:00
> To: Isaac Schlueter
> Subject: Re: Now a simple control-S in the terminal can grind to a halt any
> node.js server.
> On Mar 13, 2012, at 11:56 PM, Isaac Schlueter wrote:
26 matches
Mail list logo
