o do "make distclean" and "make" which starts
from the beginning again.
This problem also happens when "make" is completed successfully, then I
edited one of the files and when I run "make", it gives similar error as
above instead of recompiling what I chang
whatever to close the connection.
This would make those two things above a lot easier for the user,
isn't it? (of course this means libuv must handle the allocation)
Felix Halim
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Po
yway, my concern is the memory usage.
If we have a big response, it is better to use (1) to save memory as
you cannot do that using (2).
Felix Halim
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message
uv_printf("a very long string ... ") will
return false that suggest the user to pause writing and resume on a
callback somewhere.
IMHO, the availability of string buffer utility in libuv will improve
it's usability by A LOT.
Felix Halim
--
Job Board: http://jobs.nodejs.org/
y use one buffer for the
on_alloc().
If it interleaves, then it can step toe one another.
Felix Halim
--
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
G
_t buf) {
// use the "buf", but no need to free(buf.base)
}
Felix Halim
On Tue, Jul 24, 2012 at 10:35 AM, Felix Halim wrote:
> In the uv_read_start() documentation, it says that the on_alloc and
> on_read can be called many times.
> However, it doesn't specify the order.
> I
e web form I used is a simple html:
http://127.0.0.1:8000/blabla";>
Run it on a browser and click the button.
Felix Halim
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You receive
resources.
One other concern is that if the Content-Length of the POST request is
bigger than the actual length of the body,
then the server will keep on waiting the last bytes.
Is there a timeout mechanism in libuv to force close the connection
during parsing?
Felix Halim
On Thu, Jul 26, 2012 at
d twice).
However, it will save our time in deciphering the guts of libuv code
if there is a comment (in the code) right next after the assert(),
explaining what kind of error each assert() is trying to catch.
That would be very helpful for programmers.
Thanks,
Felix Halim
On Thu, Jul 26, 2012 a
I was expecting to see this chat room to keep running indefinitely:
http://chat.nodejs.org/
What happened to it?
Felix Halim
--
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
&write_req, (uv_stream_t*)&handle, &resbuf, 1, 0);
uv_close((uv_handle_t*)req->handle, on_close);
Is it guaranteed that the close will happen after all writes are finished?
I couldn't find any info regarding this in the uv.h
Felix Halim
--
Job Board: http://jobs.nodejs.org/
Po
On Fri, Jul 27, 2012 at 1:54 PM, Mihamina Rakotomandimby
wrote:
> On 07/27/2012 08:47 AM, Felix Halim wrote:
>>
>> I was expecting to see this chat room to keep running indefinitely:
>> http://chat.nodejs.org/
>
>
> Despite Node is a wonderfull tool, I think we
On Fri, Jul 27, 2012 at 8:00 PM, Ben Noordhuis wrote:
> On Fri, Jul 27, 2012 at 9:38 AM, Felix Halim wrote:
>> Is it mandatory to call uv_close in the callback of uv_write?
>>
>> Or we can just write it like this (3 uv_writes, followed by one uv_close):
>>
>>
On Fri, Jul 27, 2012 at 8:00 PM, Ben Noordhuis wrote:
> On Fri, Jul 27, 2012 at 9:38 AM, Felix Halim wrote:
>> Is it mandatory to call uv_close in the callback of uv_write?
>>
>> Or we can just write it like this (3 uv_writes, followed by one uv_close):
>>
>>
When we call:
uv_run(uv_loop);
The lines after that will never get called, unless we exit from uv_loop.
What is the function to call for that?
Felix Halim
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You
you guys open up the Wiki section on the uv github so we can get
>> some tuts rolling?
>
> Done.
So if I have libuv questions, should I post it in this mailing list?
or the wiki? or the Issues section?
Felix Halim
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://git
thread (and you are left with even fewer
available thread pool), right?
How does uv_timer implemented? (Does it uses a thread and block like sleep()?)
@Nikhil: why do you use sleep() in your fibonacci example?
https://github.com/nikhilm/uvbook/blob/master/code/queue-work/main.c
Felix Halim
On Tue, Aug 7, 2012 at 1:28 AM, Felix Halim wrote:
> I am using (the updated) Ryan Dahl's simple webserver:
>
> https://gist.github.com/1249783
>
> I modify the webserver.c so that instead of responding with a simple
> "hello world", it send a large response
SIGPIPE but node won't
crash anymore"
So, how does node.js handle that SIGPIPE?
Felix Halim
--
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
On Tue, Aug 7, 2012 at 8:42 PM, Ben Noordhuis wrote:
> On Tue, Aug 7, 2012 at 6:05 AM, Felix Halim wrote:
>> On Tue, Aug 7, 2012 at 3:47 AM, Ben Noordhuis wrote:
>>> No, libuv (and node.js) handles that fine. Chances are high that the
>>> bug is in your appli
tion above doesn't have an example
on how to use addons + libuv to do a non-blocking addons.
Can anyone give a simple example of non-blocking addons?
Thanks,
Felix Halim
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting
nce I get to define the
API for the communications.
Here is my generic http-server in C++11 that wraps libuv (it supports async
requests see the test_server.cc
<https://github.com/felix-halim/http-server/blob/master/test_server.cc>):
https://github.com/felix-halim/http-server
It has been
22 matches
Mail list logo
