00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:07:00  * daviddiasquit (Remote host closed the connection)
00:07:41  * calvinfojoined
00:09:07  * calvinfo1joined
00:09:07  * calvinfoquit (Read error: Connection reset by peer)
00:15:56  * mikealjoined
00:16:01  * mikealquit (Client Quit)
00:19:01  * calvinfo1quit (Quit: Leaving.)
00:23:02  * mikealjoined
00:33:22  * mikealquit (Quit: Leaving.)
00:47:51  * zz_karupanerurachanged nick to karupanerura
00:49:37  <felicity>hm - i need to fork/exec a process with a uv_tcp_t connected to stdin/out/err - is there any way to do that? i don't see a dup function or any way to get the fd out of the uv_tcp_t
00:50:26  * calvinfojoined
00:54:53  * thlorenzquit (Remote host closed the connection)
00:59:41  <felicity>ah i see, uv_spawn can do that with a uv_stdio_container_t
01:05:24  <txdv>alternatively you can pass the through a pipe to the created process
01:05:27  <txdv>and read directly from the fd
01:07:34  * timoxleyjoined
01:11:00  * timoxleyquit (Client Quit)
01:16:12  * st_lukejoined
01:28:11  * st_lukequit (Remote host closed the connection)
01:28:57  * calvinfoquit (Quit: Leaving.)
01:30:56  * calvinfojoined
01:34:44  * st_lukejoined
01:51:23  * hzquit
01:59:28  * thlorenzjoined
02:00:10  * calvinfoquit (Quit: Leaving.)
02:03:27  * thlorenzquit (Remote host closed the connection)
02:22:22  * LeftWing__joined
02:24:02  * calvinfojoined
02:28:22  * kuplatup1ujoined
02:32:25  * kenperkins_joined
02:33:58  * LeftWingquit (*.net *.split)
02:33:59  * kenperkinsquit (*.net *.split)
02:33:59  * kuplatupsuquit (*.net *.split)
02:47:19  <M28>any way to make uv_close let a tcp connection finish sending its data before closing it? or do I have to track that?
02:54:28  * thlorenzjoined
02:54:57  * calvinfoquit (Quit: Leaving.)
03:00:43  * inolenjoined
03:04:45  * thlorenzquit (Remote host closed the connection)
03:05:44  * calvinfojoined
03:10:12  * thlorenzjoined
03:15:38  <MI6>joyent/node: isaacs v0.10 * 7f82fae : npm: Upgrade to v1.3.22 - http://git.io/kfFawA
03:21:45  * inolenquit (Quit: Leaving.)
03:28:05  * st_lukequit (Remote host closed the connection)
03:31:15  <MI6>nodejs-v0.10-windows: #400 UNSTABLE windows-ia32 (11/606) windows-x64 (11/606) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/400/
03:43:15  * brsonjoined
03:48:17  * calvinfoquit (Quit: Leaving.)
03:52:51  * kazuponjoined
04:02:15  * c4miloquit (Remote host closed the connection)
04:23:40  * abraxasjoined
04:28:07  * abraxasquit (Ping timeout: 246 seconds)
04:57:34  * inolenjoined
05:07:53  * brsonquit (Quit: leaving)
05:10:00  * calvinfojoined
05:11:33  * LeftWing__changed nick to LeftWing
05:24:18  * calvinfoquit (Quit: Leaving.)
05:46:09  * thlorenzquit (Remote host closed the connection)
06:06:34  * inolenquit (Quit: Leaving.)
06:14:55  * inolenjoined
06:16:10  * inolenquit (Client Quit)
06:30:13  * inolenjoined
06:41:09  <MI6>nodejs-v0.10-windows: #401 UNSTABLE windows-ia32 (11/606) windows-x64 (11/606) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/401/
06:47:35  * inolenquit (Quit: Leaving.)
07:25:44  * felixgejoined
07:30:39  * felixgequit (Ping timeout: 272 seconds)
07:30:43  * st_lukejoined
07:50:00  * bajtosjoined
09:05:21  <indutny>heya
09:05:23  <indutny>how are you?
09:13:28  * mikealjoined
09:18:13  * calvinfojoined
09:26:43  * felixgejoined
09:27:24  * indexzerojoined
09:33:26  <felicity>is UV_CREATE_PIPE in uv_spawn the only way to create an anonymous pipe? i want to just fork, not exec, so i can't use uv_spawn
09:35:17  * m76joined
09:37:24  * hzjoined
09:45:34  * rendarjoined
09:59:02  * calvinfoquit (Quit: Leaving.)
09:59:37  <felicity>oh i see, the uv_file in uv_pipe_init is just an fd
10:28:16  <txdv>M28: invoke uv_shutdown first and in its callback uv_close
10:35:35  <indutny>felicity: I don't think that fork() really works weel in libuv
10:35:40  <indutny>well*
10:36:48  <felicity>indutny: i fork() as soon as the program starts and hand off fds via pipes to the child process, which then does uv_spawn
10:37:02  <felicity>to avoid having to fork the main program while it's running
10:37:10  <indutny>it is ok if you're forking before uv_default_loop()/uv_loop_new() call
10:37:22  <indutny>anyway
10:37:31  <indutny>I think you can do
10:37:34  <indutny>uv_pipe_open(..., fd)
10:37:40  <indutny>and pass it to uv_spawn
10:38:32  <indutny>or
10:38:36  <indutny>use UV_INHERIT_FD
10:38:42  <indutny>and pass fd to the option
10:42:08  * felixgequit (Quit: felixge)
10:50:46  * kazuponquit (Remote host closed the connection)
10:54:24  * felixgejoined
10:56:21  * felixgequit (Client Quit)
11:04:18  * skypjackjoined
11:31:40  * bajtosquit (Quit: bajtos)
11:32:33  <mmalecki>sup indutny
11:32:38  <indutny>all good
11:32:45  <indutny>trying to make use of uv_try_write in node
11:33:03  <mmalecki>oh, nice. was the recently added?
11:33:32  <indutny>yep
11:36:42  <txdv>so
11:36:48  <txdv>uv_try_write and if that doesnt work queue the work?
11:36:54  <txdv>or how are you going to use it?
11:37:06  <mmalecki>whoops. airport security found something in my baggage
11:37:06  <mmalecki>brb
11:37:31  <indutny>yep
11:37:34  <indutny>txdv: indeed
11:38:06  <txdv>and you think that will be faster?
11:38:11  <indutny>surely it'll be
11:38:13  <indutny>we already use this
11:38:18  <indutny>in node
11:38:24  <indutny>but we're allocating even if it was immediate
11:38:33  <indutny>with uv_try_write() we can avoid allocations
11:38:37  <txdv>how much speed improvement do you project on low volume streams? something like irc
11:38:53  <indutny>it's not for low volume
11:40:18  <txdv>WHAAAAAT
11:40:34  <txdv>isnt try write in the unstable branch?
11:40:44  <indutny>it is
11:40:47  <indutny>well
11:40:49  <indutny>yep
11:41:52  <txdv>so when will that hit node.js
11:42:08  <mmalecki>fuckme.jpg, or how I should clean my smoking equipment before flying with it
11:42:26  <mmalecki>indutny: let me know when you have a patch, we'll give it a try at vigour/spacedock
11:42:50  <txdv>what smoking equipment
11:43:09  <mmalecki>txdv: grinder, in particular
11:43:42  <mmalecki>their dog sniffed something in my luggage
11:44:06  <mmalecki>it was my grinder, which turned out to contain silly amount of weed
11:44:10  <mmalecki>brb boarding
11:44:17  <txdv>yeah
11:44:24  <txdv>that is what ginrders contain usually
11:45:46  <indutny>oh gos :)
11:45:46  <indutny>gosh
11:45:46  <indutny>mmalecki: you better be careful
11:45:52  * janjongboomjoined
11:50:05  <txdv>ja
11:52:31  <txdv>mmalecki: do you have a toshiba or a bosh?
11:52:35  <txdv>bosch
11:53:56  <txdv>indutny: when is the next stable comming?
11:54:03  <txdv>will that stable contain ipv6 for tcp?
11:54:04  <indutny>in a month or two
11:54:09  <indutny>txdv: idk yet
11:54:25  <txdv>i have been bitching about that for a year
11:55:21  <indutny>haha
11:55:25  <indutny>not too much
11:55:44  <indutny>https://github.com/joyent/node/pull/5087
11:55:48  <indutny>almost a year too
11:56:19  <txdv>https://github.com/joyent/libuv/issues/635
11:56:46  <indutny>oh nice :)
11:56:53  <indutny>right
11:56:55  <indutny>I forgot about it
11:57:00  <indutny>well, I think it'll land
11:57:09  <indutny>not sure if it'll be enabled by default in node for now
11:57:12  <indutny>but perhaps yes
11:57:21  <indutny>that's something that we need to discuss
11:57:35  <txdv>the api has changed
11:57:39  <txdv>no more bind/bind6
11:57:41  <indutny>yep
11:57:45  <indutny>that's a not a big deal
11:57:58  <indutny>the big deal is a dns resolution in node
11:58:03  <indutny>it puts A before AAAA
11:58:05  <indutny>always
11:58:17  <txdv>i hate dns
11:58:42  <txdv>never thought about it as a service you have to implement on top of ip
11:58:52  <txdv>until i wrote that wrapper for libuv
11:59:36  <txdv>funny, i predicted the bind/bind6 -> bind change in my discussion
11:59:39  <txdv>em monologue
11:59:44  <txdv>cause nobody wanted to talk ipv6 with me
12:02:01  <indutny>:)
12:02:07  <indutny>haha
12:44:42  * daviddiasjoined
13:38:13  * skypjackquit (Quit: Sto andando via)
13:38:40  * skypjackjoined
13:48:23  * thlorenzjoined
13:54:42  * c4milojoined
14:05:23  * indexzeroquit (Quit: indexzero)
14:27:35  * pachetjoined
14:36:30  * karupanerurachanged nick to zz_karupanerura
14:42:02  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:48:00  * daviddiasquit (Read error: Connection reset by peer)
14:48:39  * daviddiasjoined
14:56:03  * hzquit (Ping timeout: 260 seconds)
14:58:26  * daviddiasquit (Ping timeout: 264 seconds)
14:59:37  * daviddiasjoined
15:01:51  * daviddia_joined
15:03:59  * hzjoined
15:05:38  * daviddiasquit (Ping timeout: 264 seconds)
15:13:23  <M28>txdv: thanks!
15:24:32  * c4miloquit (Remote host closed the connection)
15:28:30  * kazuponjoined
15:36:55  * bradleymeckjoined
15:37:11  * bradleymeckquit (Client Quit)
15:46:35  * hzquit
16:09:23  * skypjackquit (Quit: Sto andando via)
16:20:46  * rendarquit (Quit: Leaving)
16:25:23  * inolenjoined
16:35:36  * dap_joined
16:42:47  * inolenquit (Quit: Leaving.)
16:46:23  * c4milojoined
16:50:50  * c4miloquit (Ping timeout: 245 seconds)
17:04:46  <indutny>рунф
17:04:47  <indutny>heya
17:04:49  <indutny>no call?
17:05:22  * AvianFlujoined
17:07:28  <indutny>isaacs: ?
17:07:30  <indutny>tjfontaine: ?
17:07:37  <indutny>trevnorris: ?
17:17:39  <MI6>joyent/node: Benjamin Waters master * 8c4b2c3 : doc: Missing word 'are' in documentation - http://git.io/3rmryw
17:21:00  <isaacs>indutny: oh, right.
17:21:09  <indutny>is it a holiday in US?
17:21:11  <isaacs>indutny: are you guys calling? or no call today, i guess, because holiday?
17:21:11  <indutny>I mean
17:21:17  <indutny>still
17:21:23  <isaacs>indutny: not really, but when xmas is in the middle of the week, lots of people just take the whole week off
17:21:23  <indutny>ah, I see :)
17:21:23  <indutny>its ok then
17:21:51  <isaacs>it's "boxing day" today, but that's not a real holiday in the US, just in other anglophone countries
17:22:26  <indutny>:)
17:22:28  <indutny>ok
17:22:31  <indutny>brb
17:22:33  <indutny>dinner time
17:33:16  * bajtosjoined
17:41:43  * daviddia_quit (Remote host closed the connection)
17:42:15  * daviddiasjoined
17:44:56  * daviddia_joined
17:46:38  * daviddiasquit (Ping timeout: 246 seconds)
18:06:03  * mikealquit (Quit: Leaving.)
18:15:49  * M28quit (Read error: Connection reset by peer)
18:23:07  * thlorenzquit (Remote host closed the connection)
18:25:37  * bajtosquit (Quit: bajtos)
18:26:56  * rendarjoined
18:31:08  * paulfryzeljoined
18:34:28  * c4milojoined
18:35:21  * paulfryzelquit (Remote host closed the connection)
18:35:59  * paulfryzeljoined
18:39:43  * c4miloquit (Ping timeout: 272 seconds)
18:44:33  * dap_quit (Quit: Leaving.)
18:48:29  * hzjoined
18:59:18  * dcrostajoined
19:00:08  <dcrosta>what is the best/appropriate way to know when a client has closed a tcp connection to a libuv server process? i've attached a close_cb to the uv_tcp_t handle, but it seems never to get called.
19:12:45  <felicity>using 0.11.16 on OS X, i have a crash when calling uv_tcp_init: http://privatepaste.com/a360374822 - any suggestions?
19:16:22  <felicity>(oh - i guess maybe libuv dislikes the pointer to its handles changing...)
19:19:28  * thlorenzjoined
19:21:32  * hz_joined
19:21:52  * hzquit (Disconnected by services)
19:21:52  * hz_changed nick to hz
19:30:04  * kazuponquit (Remote host closed the connection)
19:30:04  * brsonjoined
19:30:15  * dap_joined
19:30:18  * dap_quit (Client Quit)
19:30:53  * dap_joined
19:36:45  * calvinfojoined
19:46:20  <txdv>dcrosta: if the read callback returns < 0
19:46:36  <txdv>you should pretty much uv_close it
19:46:39  <dcrosta>txdv thanks -- yeah, just finally managed to find https://groups.google.com/forum/#!searchin/libuv/socket$20close/libuv/IG7tTbf6Zmg/tFJsshNlEEcJ which pointed me in that direction
19:47:00  <txdv>otherwise if you are done doing your buisness and you call uv_shutdown and then uv_close in the callback
19:47:08  <dcrosta>it wasn't obvious from http://nikhilm.github.io/uvbook/networking.html#tcp that that's how you could tell if it was closed
19:47:26  <txdv>THat documentation is not complete
19:47:41  <txdv>I had to lookup in my wrapper code
19:48:16  <txdv>felicity: what version are you using?
19:49:01  * stagasjoined
19:49:09  <txdv>that variable uv is probably not allocated
19:49:27  * daviddia_quit (Remote host closed the connection)
19:50:01  <dcrosta>txdv yeah, i've already learned a lot more from reading uv.h than from the tutorial (though i wouldn't have been able to get started without the tutorial). documentation is hard
19:50:08  <felicity>txdv: i found the problem: on the second iteration, realloc of course moves the array to a different memory area and the old handle address becomes in valid.
19:50:15  <felicity>silly bug ;)
19:50:53  <txdv>you cant reallocate the the variable 'uv:uv_tcp_t' because internally libuv saves it
19:51:25  <txdv>this is an issue people have in GC languages like I did in my wrapper and you had to lock that memory down
19:52:06  <txdv>but in C this should not be an issue because malloc memory doesn't get moved
19:52:22  <txdv>unless you realloc it of course, but I don't see a reason why anyone should do that
19:52:44  <txdv>dcrosta: what are you doing with libuv?
19:52:49  <txdv>any special port or just playing around?
19:53:03  <felicity>well, without traversing the list i don't know how many to allocate to begin with. (easy enough to walk it twice though, or just allocate pointers instead of objects)
19:53:57  <dcrosta>txdv at this point mostly just playing around; possibly in the future, a port of a python app to pure-C based on libuv (an RTB app for online advertising)
19:55:02  <txdv>you know there is a python binding for libuv
19:55:11  <txdv>you could use that if you want real time properties of libuv
19:55:51  <txdv>unless you need the speed of c
19:57:50  <dcrosta>we need the speed of C (or at least, we'd like it). we've got a pretty well-optimized stack on the connection handling and http decoding side of the world; it's the app logic itself that needs rewriting. refcounting kills you in high-volume and low-latency worlds
19:58:32  <txdv>you mean pythons refcounting?
19:59:38  * dsantiagoquit (Ping timeout: 264 seconds)
20:02:03  * brsonquit (Ping timeout: 272 seconds)
20:02:06  <txdv>yeah
20:02:17  <txdv>if you want to have low latency you better write in C and manage that memory yourself
20:03:27  * dsantiagojoined
20:04:20  <dcrosta>that's the idea
20:04:54  <dcrosta>truthfully, i've also just been longing to write C for a while. been doing pretty much python only for about 4 years now, need some variety
20:05:18  <txdv>after 4 years of python a shotgun would be variety enough for me
20:09:47  <txdv>have you written c before dcrosta ?
20:14:42  <dcrosta>txdv i'm a bit rusty, but it's coming back to me
20:20:47  * dsantiagoquit (Quit: Computer has gone to sleep.)
20:22:49  * c4milojoined
20:22:59  * calvinfoquit (Quit: Leaving.)
20:23:53  * calvinfojoined
20:26:06  * daviddiasjoined
20:27:39  * c4miloquit (Ping timeout: 272 seconds)
20:28:13  * calvinfoquit (Ping timeout: 252 seconds)
20:30:48  * kazuponjoined
20:30:49  * daviddiasquit (Ping timeout: 272 seconds)
20:34:08  * calvinfojoined
20:35:23  * kazuponquit (Ping timeout: 260 seconds)
21:02:30  * calvinfoquit (Quit: Leaving.)
21:04:30  * kellabytequit (Ping timeout: 245 seconds)
21:04:48  <dcrosta>does uv_write attempt to free the memory in the uv_buf_t's it is passed? I assume not, right?
21:08:34  * kellabytejoined
21:08:52  * kellabytequit (Changing host)
21:08:52  * kellabytejoined
21:08:52  * kellabytequit (Changing host)
21:08:52  * kellabytejoined
21:11:11  <txdv>dcrosta: no
21:11:29  <dcrosta>txdv thanks, i thought not. time to break out valgrind, then...
21:11:55  <txdv>that would be bad becvause various runtimes have their own heaps and allocation/free functions
21:13:30  <dcrosta>txdv yeah, i thought so. but better to ask, i figured
21:13:37  <dcrosta>i think i found the problem, was double free()ing
21:13:41  <txdv>note that uv_buf_init does allocate the returned uv_buf_t on the stack
21:13:50  <txdv>that means it goes away once the method is done
21:13:53  * st_lukequit (Remote host closed the connection)
21:14:27  <txdv>you need to allocate uv_buf_t with malloc specifically and free it on write or something
21:17:46  <dcrosta>uv_buf_init copies the "base" pointer (not the value at that addr) right?
21:18:13  <txdv>yeah
21:18:15  <dcrosta>ah, yes: "The user is responsible for freeing base after the uv_buf_t is done."
21:18:21  <txdv>uv-common.c:70
21:19:11  <txdv>if you do uv_buf_t buf = uv_buf_init("ASD", 3) it will be allocated on the stack
21:19:24  <dcrosta>right
21:19:26  <dcrosta>==7967== LEAK SUMMARY:
21:19:26  <dcrosta>==7967== definitely lost: 0 bytes in 0 blocks
21:19:26  <dcrosta>==7967== indirectly lost: 0 bytes in 0 blocks
21:19:26  <dcrosta>==7967== possibly lost: 0 bytes in 0 blocks
21:19:26  <LOUDBOT>WHAT SAY YOU TO THAT, FOUL SOUL?
21:19:26  <dcrosta>:D
21:19:34  <dcrosta>sorry LOUDBOT
21:19:34  * indexzerojoined
21:19:52  <txdv>CAPSLOCK BOT REPORTING
21:19:52  <LOUDBOT>LOL WUT ARE YOU DOING WAY OUT THERE
21:30:52  * kazuponjoined
21:47:57  * brsonjoined
21:55:36  * paulfryz_joined
21:58:06  * paulfryz_quit (Client Quit)
21:59:09  * paulfryzelquit (Ping timeout: 252 seconds)
22:04:33  * kazuponquit (Ping timeout: 272 seconds)
22:08:16  * indexzeroquit (Ping timeout: 240 seconds)
22:11:01  * c4milojoined
22:13:44  * c4milo_joined
22:13:47  * c4miloquit (Read error: Connection reset by peer)
22:15:00  * c4milojoined
22:15:12  * c4milo_quit (Read error: Connection reset by peer)
22:20:40  * M28joined
22:31:47  * rendarquit
22:58:39  * brsonquit (Ping timeout: 240 seconds)
23:00:56  * kazuponjoined
23:02:49  * hzquit
23:04:13  <thlorenz>is there a reason the req_cleanup (https://github.com/thlorenz/libuv-dox/blob/master/methods.md#uv_fs_req_cleanup) exists for uv_fs_t but not the other req types?
23:05:10  <thlorenz>some other reqs also have extra fields that need cleaning up
23:09:01  * daviddiasjoined
23:09:06  <felicity>when my write callback runs, my buffer is in req->bufsml, which is a private field, not in req->bufs. so... how do i free it?
23:10:30  <felicity>(example: http://privatepaste.com/febc45e111)
23:13:32  * daviddiasquit (Ping timeout: 246 seconds)
23:13:44  * inolenjoined
23:15:27  <txdv>I don't know about uv_req_cleanup
23:16:05  <thlorenz>yeah, I was just wondering since for fs_t I don't have to worry that I may forget to free something
23:16:32  <thlorenz>for the other reqs I'm not always sure if something may stay behind
23:16:51  <txdv>according to the tests after every uv_fs_* operation(in the callback) you have to call uv_fs_req_cleanup
23:17:29  <txdv>look at test/test-fs.c -> in every callback is a uv_fs_req_cleanup
23:19:04  <thlorenz>yeah, the fs_t is easy since that method exists, I was talking about the other request types
23:19:25  <txdv>what other types?
23:19:29  <thlorenz>since such a method doesn't exist for them, I'm mostly guessing what I have to do to properly clean those up
23:19:42  <txdv>what other types?
23:19:52  <thlorenz>like get_addrinfo_t for instance
23:20:05  <thlorenz>has a bunch of private fields
23:20:26  <thlorenz>one being char *service - so I have to keep in mind to free those
23:20:28  <txdv>there is no such struct
23:20:44  <thlorenz>sry uv_addrinfo_t
23:20:49  <thlorenz>https://github.com/thlorenz/libuv-dox/blob/master/types.md#uv_getaddrinfo_t--uv_req_t
23:21:03  <thlorenz>actually uv_getaddrinfo_t
23:22:13  <txdv>uv_freeaddrinfo
23:22:36  <txdv>yeah you have to cleanup that too
23:23:04  <felicity>okay, i see that in src/unix/stream.c:677, uv__write_req_finish explicitly sets req->bufs = NULL. so is this deliberate? i need to keep my own list of buffers to free?
23:23:07  <thlorenz>ok bad example, what about uv_write_t though?
23:23:46  <txdv>no cleanup for that
23:23:49  <thlorenz>unless for those types I can assume that no specific cleaning up is needed
23:23:50  <thlorenz>:)
23:24:01  <thlorenz>ah, so if no cleanup method exists I'm good?
23:24:11  <thlorenz>i.e. no manual freeing necessary?
23:24:20  <txdv>da
23:24:35  <thlorenz>unless of course I added something to void *data
23:24:52  <thlorenz>assuming da was russian for yes?
23:24:58  <txdv>ja
23:25:07  <thlorenz>danke, spasibo, thanks
23:25:18  <thlorenz>that makes sense then
23:25:44  <txdv>uv_write takes only a uv_buf_t which is a pointer to the buffer and the lenght of it
23:25:48  <txdv>there is nothing to cleanup
23:26:43  <thlorenz>cool, so in the future if no cleanup_req method exists for a req type, I'm not gonna worry about leaking
23:26:55  <txdv>the async api (tcp, udp) is usually clean free
23:27:12  <txdv>the problem is with the sync api which is handled by an internal thread poo.l
23:27:40  <txdv>always best to lookup in once of the tests, they are showcases if there are any free functions for specific calls
23:27:46  <txdv>one of the tests*
23:27:58  <thlorenz>yeah, that's what I have been doing
23:28:24  <thlorenz>working on getting some examples pulled out from those to make finding these things easier
23:28:25  <txdv>felicity: I don't know why it sets it to NULL there
23:29:24  <txdv>it might have something to do with passing handles through the buffer
23:29:26  <felicity>txdv: i have an idea: because if you pass more than 4 buffers, it malloc()s space for it, which it then has to free.
23:29:36  <txdv>o
23:29:52  <felicity>so, in the 1-buffer case it would be possible to not NULL it, but with 5 buffers, it has to free the space before the callback...
23:30:00  <felicity>(as there is of course, no uv_write_cleanup ;)
23:30:33  <txdv>create an issue for that
23:30:47  <txdv>indutny should know, or bnoordhuis
23:30:47  <felicity>okay
23:31:10  <txdv>this is a question that is located too deep in the lib
23:31:27  <txdv>i have to investigate that myself but I fell to weak to do it today
23:31:52  <felicity>for now i just made a struct to hold my callback data and the buffer, it would be nice if that wasn't necessary though. (i'll make an issue)
23:32:49  * pachetquit (Quit: leaving)
23:34:07  * kazuponquit (Ping timeout: 252 seconds)
23:34:10  <txdv>I don't know what bufsml is for
23:34:21  <txdv>but that is in the internal code of libuv
23:34:42  <txdv>(it should work without us looking at it)
23:34:59  <txdv>but I wonder as well why it frees bufs
23:35:23  * inolenquit (Quit: Leaving.)
23:40:19  <txdv>even the comment says that this part of code should be revisisted
23:40:55  * calvinfojoined
23:44:50  * txdvquit (Read error: Connection reset by peer)
23:44:59  * txdvjoined
23:45:05  <felicity>i created https://github.com/joyent/libuv/issues/1059
23:47:32  * calvinfoquit (Quit: Leaving.)
23:47:56  <txdv>has been set to null
23:58:15  * inolenjoined