00:00:12  <bnoordhuis>ryah: sure
00:00:19  <ryah>maybe one of you can summarize the situation and the possible solutions
00:00:24  <ryah>then i will reply tonight
00:00:27  <bnoordhuis>i'll do the kick-off
00:00:31  <ryah>thanks
00:01:27  <rmustacc>Feel free to include or not include me as you guys wish. I'm just a guy who shouts my mouth.
00:01:33  <igorzi>cool, thanks bnoordhuis
00:01:43  <dmkbot1>joyent/node: isaacs: node -v in bash PROMPT_COMMAND causes assertion error - https://github.com/joyent/node/issues/1720
00:01:44  <dmkbot1>joyent/node: ry: SSL hanging due undrained error queue? - https://github.com/joyent/node/issues/1719
00:01:55  <ryah>yes please include [email protected]
00:02:08  <bnoordhuis>rmustacc: will do
00:06:43  <dmkbot1>joyent/node: isaacs: node -v in bash PROMPT_COMMAND causes assertion error - https://github.com/joyent/node/issues/1720
00:06:44  <dmkbot1>joyent/node: isaacs: node -v in bash PROMPT_COMMAND causes assertion error - https://github.com/joyent/node/issues/1720
00:11:43  <dmkbot1>joyent/node: isaacs: node -v in bash PROMPT_COMMAND causes assertion error - https://github.com/joyent/node/issues/1720
00:13:17  <piscisaureus>igorziL https://gist.github.com/40c7e07487731f91389a
00:13:23  <piscisaureus>igorzi: https://gist.github.com/40c7e07487731f91389a
00:14:24  <bnoordhuis>ryah: 0.4.12 on linux: python tools/test.py --mode=debug,release [09:25|% 100|+ 480|- 0]: Done
00:14:47  * brsonquit (Ping timeout: 258 seconds)
00:15:37  <ryah>bnoordhuis: very good
00:16:43  <dmkbot1>joyent/node: kingkaeru: net_uv.js throws assertion error - https://github.com/joyent/node/issues/1697
00:18:29  <igorzi>piscisaureus: that repros it?
00:18:36  <piscisaureus>igorzi: yes
00:18:46  <piscisaureus>I really gtg to bed now
00:18:48  <piscisaureus>sorry
00:18:52  <piscisaureus>I wil think about a solution
00:18:52  <ryah>piscisaureus: night
00:18:56  <igorzi>piscisaureus: night
00:19:00  <piscisaureus>thnx all
00:20:38  <ryah>bnoordhuis: try this
00:20:39  <ryah>bash-3.2$ . <(node -e 'console.log("echo foo")')
00:20:54  <bnoordhuis>tried it, still wfm
00:21:00  <ryah>in bash?
00:21:43  <bnoordhuis>yes
00:21:47  <bnoordhuis>isaacs: you around?
00:22:02  <isaacs>sort of
00:22:08  <bnoordhuis>can you try this? https://github.com/bnoordhuis/libuv/commit/ef58627
00:22:18  <isaacs>bnoordhuis: i'm about to leave for class
00:22:27  <isaacs>i can try this evening
00:22:32  <isaacs>like, 10 or so
00:22:41  <bnoordhuis>i'll probably be in bed by then
00:22:50  <bnoordhuis>i should hope so
00:23:33  <ryah>bnoordhuis: testing
00:24:08  <ryah>bnoordhuis: yes that fixes it
00:24:11  <ryah>bnoordhuis: how can we test?
00:24:26  <bnoordhuis>ryah: simulate a failed write
00:24:32  <bnoordhuis>maybe i can nick pietern's test
00:24:50  <ryah>bnoordhuis: which sort of error?
00:25:20  <bnoordhuis>ryah: ECONNRESET, for example
00:25:42  <ryah>hm
00:25:47  <bnoordhuis>i think pietern's test creates two write requests where the first one passes and the second fails
00:25:59  <bnoordhuis>https://gist.github.com/1220786
00:26:32  <ryah>bnoordhuis: that one demos it?
00:26:55  <bnoordhuis>well, maybe not
00:27:06  <bnoordhuis>i'll see if i can come up with something
00:32:15  <CIA-53>node: Ryan Dahl v0.4 * r771ba34 / (4 files in 3 dirs): Bump version to v0.4.12 - http://git.io/OCp5nw
00:32:15  <CIA-53>node: Ryan Dahl v0.4 * rcfe0f42 / src/node_version.h : Now working on v0.4.13 - http://git.io/i8RPAg
00:36:08  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:39:38  * isaacsquit (Quit: isaacs)
00:39:39  <ryah>one done, one to go
00:44:04  <igorzi>bnoordhuis: also i think we need to have status in uv_fs_event_cb (if it fails)
00:44:29  <bnoordhuis>igorzi: how can it fail?
00:44:50  <bnoordhuis>ryah: fwiw, 0.4.12 on sunos: [09:48|% 100|+ 474|- 6]: Done
00:45:31  <igorzi>i don't have a failing use case.. but on windows the overlapped ReadDirectoryChangesW could come back with an error
00:46:55  <igorzi>bnoordhuis: maybe we can set events to -1 in that case?
00:46:57  <ryah>what does failure mean?
00:47:59  <bnoordhuis>igorzi: is there anything the caller can do when an error happens?
00:48:24  <bnoordhuis>if not, we might as well silently swallow it
00:48:36  <bnoordhuis>s/caller/callee/
00:48:40  <igorzi>should we continue watching the fs?
00:49:18  <bnoordhuis>what kind of errors can ReadDirectoryChangesW return?
00:49:45  <igorzi>i don't know. let me find out.
00:49:47  <CIA-53>node: Ryan Dahl v0.4 * rb31d5ac / Makefile : Update website address in Makefile - http://git.io/6YK3Fg
00:51:43  <dmkbot1>joyent/node: davglass: HTTP parser fails if server returns no headers - https://github.com/joyent/node/issues/1711
00:51:47  <igorzi>bnoordhuis: well, it will fail if the buffer gets overflowed.. but in that case we could just swallow it and continue listening
00:52:13  <bnoordhuis>igorzi: agreed
00:53:23  <rmustacc>It's probably important to notify the user in that event.
00:56:17  * ericktquit (Quit: erickt)
00:56:18  <igorzi>rmustacc: hmm, yeah, i think you're right..
00:57:28  <rmustacc>We're actually going to want the API to include some kind of error event, for example, the directory you're watching might get removed via rmdir or the file rm.
00:59:02  <bnoordhuis>can you reliably detect that?
00:59:45  * bnoordhuisside-tracks
01:02:11  <rmustacc>bnoordhuis: I'd have to check my notes. But usually yes.
01:02:54  <rmustacc>I'm going to have to head out for now.
01:03:09  <rmustacc>Catch up with you folks later.
01:03:10  * rmustaccpart
01:04:58  * felixgejoined
01:36:20  * felixgequit (Ping timeout: 252 seconds)
01:43:54  * brsonjoined
01:46:43  <dmkbot1>joyent/node: davglass: HTTP parser fails if server returns no headers - https://github.com/joyent/node/issues/1711
01:58:45  <pquerna>fuck openssl.
01:58:54  <pquerna>i guess it is best to do that error loop shit
02:22:52  * ericktjoined
02:23:07  * ericktquit (Client Quit)
02:23:59  * ericktjoined
02:46:21  * brsonquit (Ping timeout: 260 seconds)
02:46:52  <bnoordhuis>ryah: https://github.com/bnoordhuis/libuv/compare/issue1720 <- review?
02:51:43  <dmkbot1>joyent/node: ry: SSL hanging due undrained error queue? - https://github.com/joyent/node/issues/1719
02:56:43  <dmkbot1>joyent/node: ry: SSL hanging due undrained error queue? - https://github.com/joyent/node/issues/1719
03:11:12  <ryah>bnoordhuis: 1sec
03:11:43  <dmkbot1>joyent/node: hildjj: Results of stat() incorrect, don't match statSync - https://github.com/joyent/node/issues/1401
03:16:43  <dmkbot1>joyent/node: ry: SSL hanging due undrained error queue? - https://github.com/joyent/node/issues/1719
03:16:44  <dmkbot1>joyent/node: ry: SSL hanging due undrained error queue? - https://github.com/joyent/node/issues/1719
03:21:04  <ryah>bnoordhuis:
03:21:05  <ryah>[% 0|+ 13|- 0]: tcp_write_error
03:21:05  <ryah>`tcp_write_error` failed: exit code 6
03:21:05  <ryah>Output from process `tcp_write_error`:
03:21:06  <ryah>Assertion failed in test/test-tcp-write-error.c on line 81: req->handle->write_queue_size > 0
03:22:19  <bnoordhuis>hmm, that 1M write succeeded in one go?
03:22:48  <ryah>*shrug*
03:23:09  <ryah>can i increase that buffer?
03:23:38  <bnoordhuis>sure
03:24:15  <ryah>even if i make it 100mb i get that
03:24:16  <ryah>sometimes
03:26:12  <bnoordhuis>hmm, odd
03:26:58  <bnoordhuis>i'm going to ponder this
03:27:06  <bnoordhuis>but first i'm going to sleep for a couple of hours
03:27:12  <ryah>ok
03:27:16  <ryah>im debugging
03:27:17  <ryah>night
03:27:21  <bnoordhuis>night, ryah
03:31:49  * bnoordhuisquit (Ping timeout: 240 seconds)
04:23:13  * felixgejoined
04:23:13  * felixgequit (Changing host)
04:23:13  * felixgejoined
04:28:55  * felixgequit (Quit: http://www.debuggable.com/)
04:41:43  <dmkbot1>joyent/node: ry: SSL hanging due undrained error queue? - https://github.com/joyent/node/issues/1719
05:51:19  * isaacsjoined
05:55:36  * ericktquit (Quit: erickt)
06:25:43  * mralephjoined
06:36:43  <dmkbot1>joyent/node: plexel: https requestCert unusable with Firefox and Chrome - https://github.com/joyent/node/issues/1516
06:45:55  * isaacsquit (Quit: isaacs)
07:01:43  <dmkbot1>joyent/node: plexel: https requestCert unusable with Firefox and Chrome - https://github.com/joyent/node/issues/1516
07:20:11  * mralephquit (Quit: Leaving.)
07:24:09  * mralephjoined
07:31:35  <pquerna>thread local error queues. fucking stupid shit. sigh.
07:31:43  <dmkbot1>joyent/node: jampy: "Exec format error" when cross-compiling for ARM (workaround provided) - https://github.com/joyent/node/issues/1541
07:41:43  <dmkbot1>joyent/node: jampy: "Exec format error" when cross-compiling for ARM (workaround provided) - https://github.com/joyent/node/issues/1541
07:46:43  <dmkbot1>joyent/node: seebees: Tests for Sockets - https://github.com/joyent/node/issues/1699
07:46:52  * pieternjoined
07:53:17  * piscisaureusjoined
07:58:46  * mralephquit (Quit: Leaving.)
08:33:11  * mralephjoined
08:33:12  * mralephquit (Client Quit)
09:16:43  <dmkbot1>joyent/libuv: erickt: Fix a couple warnings, added some asserts, and compiling with gcc-4.5 and mingw-w64 - https://github.com/joyent/libuv/issues/186
09:46:43  <dmkbot1>joyent/node: jbergstroem: running test GH-814 sometimes leaves trailing processes - https://github.com/joyent/node/issues/914
09:51:25  * piscisaureus_joined
09:51:31  * piscisaureus_quit (Client Quit)
09:52:35  * piscisaureus_joined
09:53:57  <pietern>piscisaureus: morning
09:54:13  <piscisaureus_>pietern: morning
09:54:50  <pietern>just to check, you observed the same write callback reordering issue on win?
09:54:58  <piscisaureus_>pietern: I
09:55:38  <piscisaureus_>pietern: (sorry gt get used to this keyboard)
09:55:38  <piscisaureus_>I have observed a write callback reordering issue, but the cause is very different
09:56:01  <piscisaureus_>Bug 1697 was originally reported by a windows user
09:56:23  <pietern>right
09:56:23  <pietern>ok
09:57:38  <piscisaureus_>pietern: what is your opinion on this? Should libuv make the guarantee that write callbacks are ordered?
09:57:57  <pietern>piscisaureus_: I think so,
09:58:34  <pietern>the canonical example is of course the short write and the callback that gets called with the error immediately, bypassing already done callbacks
09:58:51  <pietern>not because it may be convenient memory-cleanup-wise
09:59:16  <pietern>but more because you'd expect a failure callback not to be followed by a succesful one
09:59:38  <pietern>I think you should be able to call uv_close on a write callback for a failed write
09:59:54  <piscisaureus_>I think you can always do that
09:59:56  <pietern>and know that that was the last succesful invocation
10:00:15  <piscisaureus_>I can't really think of any cases where that might make a difference
10:00:31  <piscisaureus_>I am just afraid that people get bitten by this
10:00:35  <pietern>let's say you keep your own write queue
10:00:48  <pietern>to control buffer size bounds
10:01:02  <pietern>and want to create a new write request for every request that is done
10:01:20  <pietern>naively you would call uv_write for every successful write callback
10:01:28  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
10:01:54  <piscisaureus_>true
10:02:03  <pietern>but you need to keep at least a flag or some kind of indicator that writing is no longer possible when a single write callback with status=-1 is interleaved
10:02:35  <pietern>and if the ordering guarantees that callbacks are called with status=0, then status=-1 on error, but never switch back to status=0
10:03:07  <pietern>another reason for doing this is that it follows the ordering of data on the stream
10:03:14  <pietern>which is the most important one i think
10:03:41  <piscisaureus_>hmm
10:03:51  <piscisaureus_>I am afraid this is going to escalate
10:04:03  <pietern>piscisaureus_: what would be the reason to not give this guarantee?
10:04:07  <piscisaureus_>Next thing, people want us to make guarantees that timers are called in order
10:04:11  <piscisaureus_>:-p
10:04:15  <pietern>hehehe
10:04:18  <pietern>right
10:04:25  <piscisaureus_>pietern: performance could be an issue
10:05:00  <piscisaureus_>piscisaureus_: we have this nice shortcut that bypasses the completion port whenever possible
10:05:59  <pietern>piscisaureus_: but should the cb for a failed write be called before callbacks for successful writes that happened before?
10:06:09  <pietern>because they are executed eventually, right?
10:06:37  <pietern>we do have the guarantee that if a write fails, it will not succeed in the future
10:06:47  <piscisaureus_>yes
10:06:54  <pietern>EINTR and EAGAIN are caught, but all others mean definitive failure
10:07:31  <pietern>piscisaureus_: (this needs to be done on the unix code as well I believe)
10:07:39  <piscisaureus_>pietern: I presume that writes cannot succees if a previous write has failed - but this is really up to the OS
10:07:50  * piscisaureus_changed nick to piscisaureus
10:08:03  <pietern>piscisaureus_: when you bypass the completion port, you can feed an uv_idle event to call the cb from a fresh stack, right?
10:08:19  <piscisaureus>pietern: yes, that's what we do already
10:08:19  <pietern>(not sure how you do that in win now, unix feeds a write event)
10:08:34  <pietern>piscisaureus: ok
10:08:39  <pietern>piscisaureus: just to get in the mindset :)
10:09:17  <pietern>piscisaureus: I'll read up on the posix spec about failing writes
10:09:28  <pietern>I think it does guarantee failure after 1 failure
10:09:35  <piscisaureus>pietern: on windows we keep a queue of events that we know have completed - we only poll the OS for new events if that queue is empty
10:09:35  <piscisaureus>Short-circuiting means that if you know a write has completed immediately, you insert it straight into that queue
10:10:26  <piscisaureus>pietern: and polling does imply the OS event queue is completely empty after that
10:11:06  <piscisaureus>pietern: so that means that if we have a short-circuited write, we need to ensure that both the libuv queue and the OS queue are fully drained before making the callback
10:11:20  <piscisaureus>pietern: that sounds very unfortunate
10:14:36  <piscisaureus>pietern: I can think of another option but that's also sacrificing convenience for performance.
10:14:43  <pietern>piscisaureus: but before it can short-circuit, you already know they are empty, because otherwise you wouldn't bypass the completion port, right?
10:15:10  <piscisaureus>pietern: it's not us who decides to bypass the completion port - it's windows.
10:15:56  <pietern>and windows can call callbacks on completion ports in arbitrary order?
10:16:15  <piscisaureus>pietern: windows does that when the kernel socket buffer has room for the write immediately. If there's room that means that previous writes must have completed, but it does not guarantee that libuv has made the callback for that write already.
10:16:38  <piscisaureus>pietern: no, windows does not make callbacks in arbitrary order.
10:17:02  <pietern>piscisaureus: ok, so if windows bypasses, libuv already knows the previous writes have completed?
10:17:21  <piscisaureus>pietern: windows knows that - libuv doesn't
10:17:49  <piscisaureus>pietern: we can assume that those writes have completed, sure
10:18:03  <pietern>piscisaureus: so let's say the socket gets disconnected half way through,
10:18:17  <pietern>then the write call immediately returns something like "omg I can't write"
10:18:24  <piscisaureus>yes
10:18:29  <pietern>while libuv is not yet aware of the writes that have completed?
10:18:33  <piscisaureus>yes
10:18:35  <pietern>omg
10:19:02  <pietern>that's inconvenient
10:19:36  <pietern>libuv keeps a list of pending writes, right?
10:19:51  <pietern>so when this conditions happens with num_in_flight == 0, the callback can be invoked
10:20:17  <pietern>but with num_in_flight > 0 it should append the callback in some kind of queue until num_in_flight reaches 0
10:20:28  <piscisaureus>pietern: it doesn't keep a list, it keeps a number of in-flight writes though
10:20:31  <piscisaureus>pietern: https://github.com/joyent/libuv/blob/master/src/win/tcp.c#L657-673
10:21:32  <piscisaureus>pietern: the core reactor: https://github.com/joyent/libuv/blob/master/src/win/core.c#L178-206
10:23:08  <pietern>piscisaureus: so this doesn't yet defer failed writes to a fresh stack
10:23:29  <piscisaureus>pietern: it returns -1 on some failed writes, yes
10:23:39  <piscisaureus>pietern: it does not make the callback in that case
10:24:07  <pietern>piscisaureus: reading some more code to get the gist of things
10:24:33  <piscisaureus>heh, good luck :-)
10:31:37  <piscisaureus>pietern: what are you doing in daily life btw. Working on redis all day?
10:31:45  <pietern>piscisaureus: pretty much :)
10:32:04  <pietern>piscisaureus: and getting my CS degree in the mean-time ;)
10:32:11  <piscisaureus>heh
10:32:28  <piscisaureus>someone else who's trying to get a degree :-)
10:32:36  <pietern>piscisaureus: not CS right?
10:32:57  <piscisaureus>no, Technische Bestuurskunde in plat hollands
10:33:26  <pietern>which university?
10:33:36  <piscisaureus>Systems sngineering, policy analysis and management in fancypants mode
10:33:37  <piscisaureus>TU Delft
10:35:59  <pietern>that's a lot of business processes stuff right?
10:36:13  <piscisaureus>yes - too much
10:36:16  <pietern>industrial engineering, modeling logistics, etc
10:36:26  <piscisaureus>yes
10:36:31  <piscisaureus>oh that stuff is nice
10:37:58  <piscisaureus>I interpreted "business processes stuff" as the bullshit the it section does here
10:38:23  <piscisaureus>but building simulations is very interesting
10:38:37  <pietern>well, I've seen a fair amount of bullshit in Gr as well
10:38:59  <pietern>it's really amazing how some of these business guys do databases
10:39:22  <pietern>there should be overlap with CS, but the mindset is nearly 100% different
10:39:31  <pietern>hopefully it's better in delft :)
10:39:41  <piscisaureus>indeed. Or how they think of "services"
10:39:50  <pietern>right, WDSL, SOAP, BPEL
10:40:21  <pietern>all the stuff the "enterprise" evangelized 10-15 years ago
10:41:15  <piscisaureus>The problem is that IT is only an abstract notion to these guys. Nobody has any idea what it means to actually implement the designs they make.
10:41:52  <pietern>right, next to the conceptual idea there appears to be little notion on the operational and maintenance effects
10:42:03  <pietern>let alone dev costs
10:42:49  <piscisaureus>I don't want to get all excited about this now :-) I have decided to just ignore that and do other stuff.
10:43:01  <pietern>haha
10:43:16  <pietern>you sound more like a CS guy indeed :)
10:43:29  <piscisaureus>Hmm. Don't get me started :-)
10:43:48  <piscisaureus>afk for a while
10:44:00  <pietern>piscisaureus: btw, windows does not guarantee that a iocp bypass means that the previous writes requiring iocp were already triggered back in uv?
10:44:07  <pietern>piscisaureus: later!
10:44:38  <piscisaureus>pietern: sorry, I have to talk to my boss now :-)
10:44:46  <pietern>np, later
10:53:17  <piscisaureus>pietern: re btw, windows does not guarantee that a iocp bypass means that the previous writes requiring iocp were already triggered back in uv?
10:53:17  <piscisaureus>It doesn't
11:11:43  <dmkbot1>joyent/libuv: erickt: Fix a couple warnings, added some asserts, and compiling with gcc-4.5 and mingw-w64 - https://github.com/joyent/libuv/issues/186
11:18:43  <piscisaureus>pietern: I can think of trick that probably works to avoid write cb reordering. It hurts perf only when reordeing is a risk - but I am kinda afraid to apply it, because if people have code that triggers it a lot, they will get worse perf without knowing why it happens.
11:20:21  <pietern>piscisaureus: I might have an idea as well...
11:20:29  <piscisaureus>oh, nice :-)
11:20:30  <pietern>one that shouldn't hurt perf
11:20:42  <piscisaureus>shoot
11:21:02  <pietern>this also tackles the issue that failed writes cbs get a fresh stack
11:21:10  <pietern>instead of returning -1 from the write call
11:21:16  <pietern>what about… *drumroll*
11:21:34  <pietern>making a linked list out of all write requests
11:21:39  <pietern>adding onto the tail from uv_write
11:22:02  <piscisaureus>I am going to think about this during lunch :-)
11:22:02  <pietern>when the iocp fires, it is marked as done, and calls its cb IFF it is the head of the list
11:22:33  <piscisaureus>yeah actually I considered that but then I thought about beren op de weg
11:22:41  <piscisaureus>let me consider that again
11:22:47  <pietern>when the iocp is bypassed, the uv_process_tcp_write is called by the loop as well, and also called IFF head of list
11:23:02  <pietern>when one is head of the list, it can trigger every cb while(done)
11:23:26  <pietern>can't think of any beren op de weg, but it's still a fresh idea
11:23:29  <pietern>letting it sink as well
11:23:34  <pietern>and going to work on smth else
11:23:38  <pietern>have a good lunch :)
11:23:48  * pieternchanged nick to pietern_afk
11:46:43  <dmkbot1>joyent/node: telemachus: Two test failures for v0.4.12 on OSX Lion - https://github.com/joyent/node/issues/1721
12:06:29  <piscisaureus>pietern_afk: this probably does it as well: https://gist.github.com/3f5b4b1c654ebb21ce55
12:06:37  <piscisaureus>with perf hazard
12:07:20  <pietern_afk>piscisaureus: yep
12:07:49  <pietern_afk>going through the cp when there are pending write reqs
12:08:02  <pietern_afk>can be bypassed with a linked list, but adds some complexity
12:51:43  <dmkbot1>joyent/node: BillBarnhill: Fix memory allocation in uv__fs_after - https://github.com/joyent/node/issues/1686
13:48:07  <piscisaureus>bnoordhuis: here?
13:56:58  * dmkbotjoined
13:59:56  * dmkbot1quit (Ping timeout: 252 seconds)
14:01:47  * ericktjoined
14:11:55  <dmkbot>joyent/node: hildjj: Results of stat() incorrect, don't match statSync - https://github.com/joyent/node/issues/1401
14:25:52  <pietern_afk>piscisaureus: https://gist.github.com/93bffdb246545f272a8f
14:25:59  <pietern_afk>couldn't help implementing it ;)
14:26:07  <pietern_afk>but don't have a windows env ready
14:26:19  <pietern_afk>(can't get gyp to run under cygwin, some error with python)
14:26:26  <pietern_afk>so not sure if it works
14:29:28  <piscisaureus>pietern: don't use cygwin - use mingw or msvc
14:29:55  <pietern_afk>piscisaureus: how can I get gyp to run there?
14:30:35  <piscisaureus>pietern_afk: with mingw just use the static makefile
14:31:33  <piscisaureus>pietern_afk: for msvc you have to checkout gyp to the build/gyp directory. Make sure you have python. Then run `vcbuild.bat nobuild`
14:32:08  <pietern_afk>piscisaureus: any win python is ok? tried cygwin but that failed miserably
14:32:37  <piscisaureus>pietern_afk: we all hate cygwin, we're moving away from it and I don't feel like figuring it out now :-)
14:32:52  <piscisaureus>I would advice to install python 2.x
14:35:15  <pietern_afk>piscisaureus: anyway, that gist should force write callback ordering without perf penalty
14:45:25  <piscisaureus>pietern: can you publish that patch as a proper git patch?
14:45:36  <piscisaureus>pietern_afk: I have trouble applying it.
14:45:44  <pietern_afk>piscisaureus: sure
14:45:56  <piscisaureus>pietern_afk: you could also just push it to your private repo
14:46:55  <dmkbot>joyent/node: mikeal: streams2 - https://github.com/joyent/node/issues/1681
14:47:39  <pietern_afk>piscisaureus: https://github.com/pietern/libuv/tree/win-write-order
14:47:43  <pietern_afk>never compiled it
14:47:58  <pietern_afk>trying to get that to work now..
14:48:41  <pietern_afk>piscisaureus: btw how do you debug tests that abort()?
14:48:47  <pietern_afk>msvc just bails here
14:49:13  <piscisaureus>pietern_afk: yes that's very annoying
14:49:50  <piscisaureus>pietern_afk: Usually I just insert a breakpoint or put something like *((char*) NULL) = 0 there
14:58:40  <pietern_afk>piscisaureus: this apparently isn't the holy grail
14:58:42  <pietern_afk>lots of errors
14:58:45  <piscisaureus>pietern_afk: do all requests need to have this next_req field
14:58:59  <piscisaureus>pietern_afk: yes - but I can get it to compile :-)
14:59:14  <pietern_afk>piscisaureus: with some edits here and there probably
14:59:26  <pietern_afk>there were some copy/paste errors
14:59:50  <pietern_afk>piscisaureus: I made an error
15:00:03  <pietern_afk>this list of writes should be parallel to the existing one
15:00:10  <pietern_afk>so next_req cannot be reused
15:00:16  <pietern_afk>stay tuned, patching this stuff ;)
15:00:32  <piscisaureus>pietern_afk: ok
15:00:40  <piscisaureus>pietern_afk: I already caught that one :-)
15:01:23  <piscisaureus>pietern: it is not bad to have this queue btw - we're going to need something like it anyway to suppport writev with >1 buffer on pipes and file streams
15:01:56  <pietern_afk>because win doesn't do posix writev?
15:02:09  <piscisaureus>pietern_afk: it does only for sockets
15:02:28  <piscisaureus>and it can do something like that for files but it's not usable
15:03:04  <piscisaureus>pietern_afk: right now we just die if the user tries to write multiple buffers at once to a pipe
15:03:14  <piscisaureus>and file streams are not yet implemented
15:04:09  <pietern_afk>piscisaureus: you can fire off as many writes to be completed later as you want?
15:04:21  <piscisaureus>pietern_afk: yes
15:04:22  <pietern_afk>or does it bail after N pending completion requests
15:04:27  <pietern_afk>that's cool
15:05:19  <piscisaureus>pietern_afk: it bails only if you fill exceed the limit for unpaged kernel memory
15:05:49  <piscisaureus>that's very unlikely but it could happen if you queue like 100000 writes or something
15:08:42  <piscisaureus>pietern: why do you start the iteration at loop->pending_reqs_tail in uv_process_tcp_write?
15:09:46  <pietern_afk>piscisaureus: copy/paste typo
15:09:50  <pietern_afk>I have a new patch
15:09:51  <pietern_afk>one sec
15:09:57  <pietern_afk>testing if it compiles without warnings ;)
15:09:57  <piscisaureus>pietern_afk: ok
15:11:52  <pietern_afk>piscisaureus: argh msvc recompiles everything
15:12:24  <pietern_afk>piscisaureus: pushed a new commit
15:12:26  <pietern_afk>that should work
15:12:50  * bnoordhuisjoined
15:14:18  <pietern_afk>piscisaureus: tests pass.. so that's good
15:14:32  <pietern_afk>there are a couple of fs_* tests that fail, that's expected?
15:15:09  <piscisaureus>yes, that's unrelated
15:15:16  <piscisaureus>they're pending getting fixed
15:16:11  <piscisaureus>Now we have to see whether it fixes https://gist.github.com/40c7e07487731f91389a on node :-)
15:16:49  <piscisaureus>And we have to discuss whether we want write cb ordering still... but since this can be done without perf regression I think it's likely to get in
15:18:02  <pietern_afk> sweet!
15:18:28  <pietern_afk>if it doesn't fix that one, it's immediately clear that it isn't the write ordering
15:18:47  <piscisaureus>heh :-)
15:18:50  <piscisaureus>it's not
15:19:01  <piscisaureus>if it doesn't fix the test then your patch is broken
15:19:06  <piscisaureus>:-p
15:19:09  <pietern_afk>argh!
15:19:11  <pietern_afk>hehe
15:21:55  <dmkbot>joyent/node: mikeal: streams2 - https://github.com/joyent/node/issues/1681
15:30:31  <piscisaureus>pietern_afk: something is wrong with that patch
15:30:37  <pietern_afk>piscisaureus: ok
15:31:02  <pietern_afk>piscisaureus: what's going on?
15:31:03  <piscisaureus>pietern_afk: if I run the benchmarks the tcp_pump1 throughput drops from 1.5 to 0.5 gbit/s
15:31:16  <pietern_afk>ok, checking it out
15:33:53  <pietern_afk>piscisaureus: looks like the only way that can happen is the delay between do_write() and write_cb()
15:34:49  <pietern_afk>piscisaureus: those writes complete before doing a new write
15:34:59  <pietern_afk>so it shouldn't be a contention thing
15:35:14  <piscisaureus>pietern_afk: that indeed seems unlikely
15:35:23  <piscisaureus>pietern_afk: but are you seeing it as well or not?
15:35:25  <pietern_afk>does this code checkout include your previous patch that added the write to iocp?
15:35:56  <piscisaureus>just try "vcbuild release bench" on both your patch branch and origin/master
15:36:13  <piscisaureus>pietern_afk: obviously I backed that out :-)
15:36:35  <pietern_afk>ok thanks for the tip
15:36:45  <pietern_afk>I have a VM with win7 running
15:36:55  <dmkbot>joyent/node: hildjj: Results of stat() incorrect, don't match statSync - https://github.com/joyent/node/issues/1401
15:37:05  <piscisaureus>I have a macbook with win7 running
15:37:13  <piscisaureus>what's worse?
15:37:31  <pietern_afk>;)
15:41:24  <pietern_afk>piscisaureus: pump1 with patch = 0.5gbit
15:41:29  <pietern_afk>checking the original now
15:41:34  <piscisaureus>pietern_afk: hmm. the throughput seems highly variable
15:41:55  <dmkbot>joyent/node: hildjj: Results of stat() incorrect, don't match statSync - https://github.com/joyent/node/issues/1401
15:42:47  <pietern_afk>piscisaureus: indeed, couple more runs with the patch shows variation between 0.2gbit and 2.1gbit
15:43:15  <piscisaureus>pietern_afk: pls compare with origin/master
15:43:22  <pietern_afk>piscisaureus: will do
15:43:26  <piscisaureus>I am also seeing huge variance
15:43:49  <pietern_afk>piscisaureus: any way to have msvc not rebuild *everything* for every build?
15:44:07  <piscisaureus>pietern_afk: hmm. it doesn't do that for me ...
15:44:11  <piscisaureus>I don't know
15:44:23  <pietern_afk>ok
15:44:33  <pietern_afk>maybe because I'm using the repo over a network share
15:45:24  <pietern_afk>piscisaureus: same variation
15:45:30  * ericktquit (Quit: erickt)
15:45:32  <pietern_afk>~0.1 through ~2.0
15:45:35  <piscisaureus>okay
15:46:55  <dmkbot>joyent/node: hildjj: Results of stat() incorrect, don't match statSync - https://github.com/joyent/node/issues/1401
15:47:17  <piscisaureus>pietern_afk: I'm kind of gone
15:47:25  <pietern_afk>piscisaureus: have a good weekend
15:47:33  <piscisaureus>pietern_afk: I think the variance is due to the silly receive window backoff timer.
15:47:51  <piscisaureus>we've had issues with that before
15:49:15  <pietern_afk>piscisaureus: I hope the patch is OK, and if it is the write ordering can hopefully make it
15:49:31  <pietern_afk>can hack around it in user space, but rather have it as I'd expect in the core ;)
15:51:39  * jonaslundquit (Ping timeout: 258 seconds)
15:52:02  * brsonjoined
15:57:33  <CIA-53>node: Ben Noordhuis v0.4 * red44098 / deps/libev/wscript :
15:57:34  <CIA-53>node: build: fix SYS_clock_gettime feature check
15:57:34  <CIA-53>node: execute=True makes it fail while cross-compiling.
15:57:34  <CIA-53>node: Fixes #1541. - http://git.io/hzfpIw
15:59:52  <piscisaureus>bnoordhuis: so we're going together to GOTO?
15:59:56  <piscisaureus>+1
16:00:22  <bnoordhuis>piscisaureus: seems like it
16:00:32  <bnoordhuis>we're not sharing a hotel room though >:(
16:01:55  <dmkbot>joyent/libuv: erickt: Fix a couple warnings, added some asserts, and compiling with gcc-4.5 and mingw-w64 - https://github.com/joyent/libuv/issues/186
16:05:53  * isaacsjoined
16:06:55  <dmkbot>joyent/node: jbergstroem: running test GH-814 sometimes leaves trailing processes - https://github.com/joyent/node/issues/914
16:06:56  <dmkbot>joyent/node: hildjj: Results of stat() incorrect, don't match statSync - https://github.com/joyent/node/issues/1401
16:09:22  <piscisaureus>bnoordhuis I am kind on pietern's side now - I think for convenience we should guarantee write callback ordering
16:09:35  <piscisaureus>We can prolly without performance impact
16:09:51  <piscisaureus>ryah: ^ same
16:10:10  <ryah>yes, why not?
16:11:37  <piscisaureus>okay
16:11:54  <piscisaureus>it's just a diversion from our current path which is that we don't guarantee callback ordering
16:11:59  <piscisaureus>I agree
16:12:07  <indutny>ryah: sorry, no commits and pull requests. I'm super tired and was super busy all day :)
16:12:16  <bnoordhuis>piscisaureus: that's what i was proposing, right? :)
16:12:28  <piscisaureus>it also complicates uv-win a bit, but we will fix node bug 1697 with it
16:13:29  <pietern_afk>bnoordhuis: hola
16:13:45  <bnoordhuis>pietern_afk: hela
16:13:54  <pietern_afk>bnoordhuis: the assert error in uv__drain is caused by the write queue being empty, but the write_queue_size != 0
16:14:07  <bnoordhuis>yes, i've been working on that
16:14:07  <pietern_afk>because of the partial write
16:14:14  <bnoordhuis>https://github.com/bnoordhuis/libuv/compare/issue1720
16:14:25  <bnoordhuis>it's not fully functional yet though
16:15:55  <pietern_afk>bnoordhuis: cool
16:16:03  <ryah>indutny: np
16:16:11  <pietern_afk>that makes the entire thing re-entrant
16:16:21  <pietern_afk>you can keep calling uv_write against a disconnected socket
16:16:35  <pietern_afk>and it won't break
16:16:41  <pietern_afk>just call the cb with status=-1
16:17:29  <bnoordhuis>that reminds me... ryah, did you figure out why that test was failing?
16:22:59  <pietern_afk>have a good weekend guys, pleasure working with you on this
16:23:07  <pietern_afk>going to the vrijdagmiddagborrel
16:23:19  <pietern_afk>later!
16:23:23  * pietern_afkquit (Quit: pietern_afk)
16:24:57  <bnoordhuis>ah, the vrijmibo... the one thing i miss working from home
16:25:16  <bnoordhuis>no matter, i'll just create my own vrijmibo
16:25:44  * bnoordhuisopens another can
16:27:46  <piscisaureus>yes I am also at the vrijmibo
16:30:47  <ryah>bnoordhuis: no
16:31:05  <ryah>bnoordhuis: it seems that when one write fails - it decrements the queue_size
16:31:18  <ryah>bnoordhuis: so after the uv_write call it looks like nothing is queued
16:32:05  <bnoordhuis>okay, back to the drawing board
16:36:55  <dmkbot>joyent/node: isaacs: node -v in bash PROMPT_COMMAND causes assertion error - https://github.com/joyent/node/issues/1720
16:38:58  <bnoordhuis>piscisaureus: i've got just the thing for you -> http://www.hanselman.com/blog/WebMatrixAndNodejsTheEasiestWayToGetStartedWithNodeOnWindows.aspx
16:44:47  <bnoordhuis>so that tcp-write-error test passes on both linux and sunos
16:45:17  <bnoordhuis>coincidentally, we should probably SIG_IGN SIGPIPE while running tests
16:46:08  <bnoordhuis>ryah: is there a mac i can log into?
16:51:27  <ryah>bnoordhuis: you can log into mine
16:51:35  <ryah>oh hm -
16:51:42  <ryah>i guess im behind a nat
16:52:23  <ryah>one sec, i'll set up a tunnel
17:15:48  * piscisaureusquit (Ping timeout: 260 seconds)
17:20:23  * ericktjoined
17:21:25  <ryah>meh. i can't figure it out
17:21:39  <CIA-53>node: Ben Noordhuis master * r0ad28fd / src/node_crypto.cc :
17:21:39  <CIA-53>node: crypto: fix error message buffer overrun
17:21:39  <CIA-53>node: ERR_error_string() expects a buffer of at least 256 bytes, the input buffer
17:21:39  <CIA-53>node: was not even half that size. Use ERR_error_string_n() instead. - http://git.io/V_GTiQ
17:22:04  <bnoordhuis>ryah: ssh -R to some machine i can log into as well?
17:22:28  <bnoordhuis>nodejs.org or i can set up an account for you on my joyent machine
17:23:26  <ryah>oops. i didn't have sshd turned on :)
17:24:17  <ryah>bnoordhuis: yeah i did this:
17:24:26  <ryah>ssh -R 10000:localhost:22 [email protected]
17:24:43  <bnoordhuis>hah okay
17:25:08  <ryah>you have a user [email protected] here
17:25:17  <bnoordhuis>cool, let me try it
17:25:20  <igorzi>piscisaureus: so, what's going on with the reordering bug?
17:26:06  <ryah>i should have just spent the last 30 minutes debugging it instead of trying to give you ssh access -_-
17:27:47  <igorzi>ryah: bnoordhuis: piscisaureus: can we move the call 30 min later today?
17:27:56  <bnoordhuis>igorzi: sure
17:28:06  <igorzi>(i have a meeting)
17:33:24  <igorzi>bnoordhuis: ryah: any new ideas for uv_fs_event api?
17:34:48  <bnoordhuis>ryah: not having much luck with the tunnel so far
17:35:21  <bnoordhuis>no netcat or nmap installed but a python one-liner seems to suggest that there's not an actual connection on localhost:10000
17:35:32  <bnoordhuis>ssh *is* listening on that address though
17:35:42  <ryah>igorzi: replying to the email now
17:35:57  <bnoordhuis>igorzi: i don't really like the idea of platform-dependent functions
17:35:57  <ryah>bnoordhuis: sorry - i can't get it going
17:36:03  <ryah>isaacs: do you have a mac with an ip?
17:36:11  <isaacs>ryah: a public ip?
17:36:13  <ryah>yes
17:36:15  <isaacs>no
17:36:17  <ryah>that he can ssh into
17:36:23  <ryah>hm..
17:36:34  <isaacs>i could set up a tunnel through another server, though
17:36:49  <ryah>isaacs: if you can.. somehow im not having much luck
17:36:53  <isaacs>ssh from the mac to the public server, map 22 here to 2222 there
17:36:56  <isaacs>k, just a sec..
17:37:31  <bnoordhuis>isaacs: don't hurry, dinner's ready here
17:37:37  <bnoordhuis>back in 45 minutes
17:40:20  * Bert19474378joined
17:40:28  <Bert19474378>hey
17:41:01  <Bert19474378>i am not being difficult so much...
17:41:26  <Bert19474378>I can't be on the call at 8pm or 9pm
17:42:21  <Bert19474378>so that's neither the old nor the new one
17:53:34  <isaacs>bnoordhuis: send me your public key. i got it working
18:12:01  <ryah>hey guys - sorry
18:12:04  <ryah>let's skype
18:12:56  <ryah>bnoordhuis: yt?
18:13:09  <ryah>igorzi: yt?
18:25:51  <Bert19474378>I can Skype now
18:26:06  <Bert19474378>for the next 15 minutes
18:31:17  <ryah>igorzi: http://drupal.org/project/token
18:31:23  <ryah>oops that wasnt for igore
18:31:26  <ryah>isaacs: http://drupal.org/project/token
18:33:02  <ryah>isaacs: user pages http://drupal.org/user/16496
18:33:33  <ryah>sorry guys - our scrum for today didn't happen
18:34:20  <isaacs>that's pretty rad
18:35:40  <igorzi>ryah: no call today?
18:36:16  <Bert19474378>bnoordhuis: did you do any prefork benchmarks yet?
18:36:38  * Bert19474378changed nick to Bert___
18:37:30  <igorzi>Bert___: ryah: i was thinking that maybe we could do another benchmark on windows that does multithreaded libuv server (with a single iocp)? that'll kind of give us best-case scenario, which would be a good datapoint.
18:38:09  <Bert___>yes. +1
18:38:39  * mralephjoined
18:38:45  <igorzi>Bert___: ok, i'll do that.
18:38:47  <Bert___>maybe just build it on top of raw iocp?
18:39:27  <Bert___>igorzi: wow. where does all your time coke from?
18:39:48  <Bert___>coke -> come
18:40:01  <Bert___>but yeah +1
18:40:40  <igorzi>Bert___: heh.. i don't get out much these days... with 10-month old baby :)
18:41:16  <Bert___>heh
18:41:37  <Bert___>I should have a baby too then :-)
18:41:55  <dmkbot>joyent/node: jbergstroem: running test GH-814 sometimes leaves trailing processes - https://github.com/joyent/node/issues/914
18:51:50  * Bert___quit (Ping timeout: 252 seconds)
18:56:40  * piscisaureusjoined
18:58:43  <ryah>igorzi++
18:59:04  <bnoordhuis>sorry i'm late, old house plumbing emergency
18:59:31  <bnoordhuis>did you guys have the call yet?
19:00:01  <ryah>bnoordhuis: just isaacs and me. it's okay- let's just skip it for today
19:00:17  <bnoordhuis>okay, cool
19:00:20  <isaacs>bnoordhuis: i've got that ssh tunnel set up
19:00:30  <isaacs>bnoordhuis: wanna send me your pubkey?
19:00:44  <bnoordhuis>isaacs: pm'd
19:01:26  <isaacs>kewl, just a sec...
19:03:38  <bnoordhuis>piscisaureus: no, no benchmarks yet
19:11:24  * piscisaureusquit (Ping timeout: 260 seconds)
19:34:33  * brsonquit (Quit: leaving)
19:35:13  <bnoordhuis>ryah: that test always seems to pass on isaacs's machine...
20:08:59  <ryah>bnoordhuis: okay...
20:09:08  <ryah>bnoordhuis: i will investigate on my end
20:09:12  <bnoordhuis>cool
20:09:12  <ryah>i need to get some food fist
20:09:43  <ryah>bnoordhuis: can you take a long hard look at https://github.com/joyent/node/commit/1d37ad0
20:09:52  <bnoordhuis>sure
20:10:02  <ryah>bnoordhuis: im worried it might affect perf
20:10:20  <ryah>effect
20:10:20  <bnoordhuis>that reminds me, we need https benchmarks
20:10:26  <bnoordhuis>affect :)
20:13:43  <isaacs>ryah: "effect perf" ==> "cause there to be perf", affect perf --> "have some effect on perf"
20:13:49  <isaacs>english is stupid
20:23:29  <DrPizza>affect
20:23:31  <DrPizza>oh
20:25:39  <isaacs>the reason behind that, btw, is that one comes from "ex ficire", "to bring out from", and affect from "ad ficire" , "to do to/at"
20:26:38  <isaacs>effect as a noun, then, has the sense of "that which is brought out". affect as a noun means "a state or pretense", which is a completely different thing.
20:26:56  * isaacsso happy i learned this language before i could remember, it's probably really painful.
20:38:53  <bnoordhuis>not to disparage your fine language
20:39:11  <bnoordhuis>but english is rather simple compared to germanic or slavic languages
20:40:07  <bnoordhuis>an easy and fairly regular grammar, no naamvallen
20:41:05  <DrPizza>english's #1 problem is spelling and pronunciation
20:41:33  <DrPizza>and the total lack of rules or regularity
20:41:55  <dmkbot>joyent/node: seebees: Tests for Sockets - https://github.com/joyent/node/issues/1699
20:47:47  <ryah>an english spelling reform would be nice
20:54:29  <isaacs>ryah: you'll have better luck reforming javascript
20:54:59  <isaacs>DrPizza: the regularity only makes sense when you realize that our spelling captures etymology, rather than pronounciation
20:55:25  <isaacs>which is why you really need to learn (at least) a little latin, greek, german, and french to be able to spell english words properly
20:56:31  * piscisaureusjoined
21:06:55  <dmkbot>joyent/libuv: piscisaureus: uv_strerror woes - https://github.com/joyent/libuv/issues/187
21:12:44  <bnoordhuis>why does this only work when stdin is a pipe? >:(
21:12:45  <bnoordhuis>var conn = tls.connect(port, host, function() {
21:12:45  <bnoordhuis> conn.pipe(process.stdout);
21:12:45  <bnoordhuis> process.stdin.pipe(conn);
21:12:45  <bnoordhuis>});
21:13:04  <bnoordhuis>both with libuv and legacy btw
21:13:48  <piscisaureus>bnoordhuis: are you actually using node?
21:13:54  <bnoordhuis>piscisaureus: for a change
21:14:02  <piscisaureus>hahahahahaha
21:14:15  <piscisaureus>didn't they tell you when you got hire...
21:14:17  <piscisaureus>d
21:14:31  <bnoordhuis>but yeah, i'm going back to php
21:14:31  <piscisaureus>node sucks monkey balls
21:14:35  <bnoordhuis>to phode!
21:14:46  <piscisaureus>fuck yeah!
21:15:01  <piscisaureus>bnoordhuis: but did you get the hashmap working already?
21:15:22  <bnoordhuis>piscisaureus: i promised myself i would but i haven't gotten around to it
21:15:31  <piscisaureus>bnoordhuis: I haven't done anything since and this weekend it's not gonna happen either...
21:15:42  <piscisaureus>so you have two days ...
21:15:49  <bnoordhuis>maybe sunday, tomorrow is family day
21:16:17  <piscisaureus>ah
21:16:22  <piscisaureus>family issues
21:16:26  <bnoordhuis>those too
21:17:39  <piscisaureus>I totally don't feel like coding any more
21:18:29  <piscisaureus>I even didn't do so much node coding
21:18:52  <bnoordhuis>how come?
21:19:01  <piscisaureus>busy with other stuff
21:19:39  <bnoordhuis>btw, tls handshakes are really fscking expensive - 6 round trips just to set up the connection!
21:19:39  <piscisaureus>preparing the presentation for monday, literature research for my thesis :-(
21:19:45  <bnoordhuis>oh right, monday
21:20:02  <piscisaureus>you gonna come still?
21:20:04  <bnoordhuis>sure
21:20:17  <bnoordhuis>it's not a party if ben didn't crash it
21:20:44  <bnoordhuis>when / how late is it?
21:21:00  <ryah>isaacs: whats the commands for setting up an ssh tunnel?
21:21:05  <ryah>i need bnoordhuis's help
21:21:08  <piscisaureus>bnoordhuis: http://kingsofcode.com/agenda
21:21:36  <bnoordhuis>ryah: i'm here for you *pats shoulder*
21:21:37  <isaacs>ryah: ssh izs.me -R 8022:localhost:22
21:21:50  <isaacs>ryah: then he ssh's into izs.me, and then on izs.me ,does `ssh localhost -p 8022`
21:22:07  <isaacs>ryah: but use your own server, of course :)
21:22:15  <isaacs>and set up a user for ben, and add his keys in places.
21:23:00  <piscisaureus>you really need a mac that badly?
21:23:08  <bnoordhuis>piscisaureus: so i should be there around 15.00 hours?
21:23:19  <bnoordhuis>piscisaureus: only to test on!
21:23:58  <piscisaureus>bnoordhuis: that's when I start. The rest is probably boring, so, yeah
21:25:06  <ryah>bnoordhuis: ssh [email protected] -p 8022
21:25:21  <ryah>bnoordhuis: does that work?
21:25:39  <bnoordhuis>ryah: asks me for a password
21:25:57  <bnoordhuis>you're going to ask me for my pubkey again now, aren't you?
21:27:46  <bnoordhuis>piscisaureus: dinner afterwards?
21:28:04  <piscisaureus>bnoordhuis: sure
21:28:21  <ryah>bnoordhuis: passwd nodenode
21:29:04  <bnoordhuis>ryah: doesn't work
21:29:08  <ryah>bnoordhuis: try again
21:29:30  <bnoordhuis>ryah: still doesn't work
21:29:47  <ryah>bnoordhuis: try ssh nodejs.org -p 8022
21:30:10  <bnoordhuis>hurray
21:30:15  * bnoordhuisquickly changes the password
21:30:24  <ryah>bnoordhuis: libuv is in that dir
21:32:30  <bnoordhuis>and indeed it fails
21:35:55  <bnoordhuis>stole your swap file
21:36:16  <piscisaureus>bnoordhuis: igorzi: ryah: so we do want to guarantee write callback ordering in libuv?
21:36:28  <bnoordhuis>yes
21:39:27  <ryah>piscisaureus: i didnt know we ever didn't guarantee it
21:40:48  <piscisaureus>Okay, them I want to land pietern's patch - but he's got to sign the cla first ...
21:43:43  <ryah>bnoordhuis: are you able to see what's happening?
21:44:13  <bnoordhuis>ryah: not yet, it only happens sometimes
21:44:24  <CIA-53>libuv: Pieter Noordhuis writeorder * rf0044c0 / (6 files in 3 dirs): win: guarantee write callback ordering - http://git.io/F-8T9Q
21:47:22  <bnoordhuis>gdb, `print errno` -> $2 = <unknown type>
21:47:27  <bnoordhuis>os x >:(
21:51:55  <dmkbot>joyent/libuv: piscisaureus: write callback order (windows) - https://github.com/joyent/libuv/issues/188
21:51:55  <dmkbot>joyent/libuv: piscisaureus: write callback order (windows) - https://github.com/joyent/libuv/issues/188
21:52:14  <piscisaureus>dmkbot is quite chattly lately
21:52:42  <igorzi>piscisaureus: did you try benchmarking it? doesn't seem that it should cause any issues.. also, does it fix your node repro?
21:53:25  <piscisaureus>igorzi: didn't seem to matter much, only the tcp-pump1 bench was showing weird figures
21:53:53  <piscisaureus>variations between literally 100mbit and 1.5 gbit
21:53:54  <ryah>bnoordhuis: i grep /usr/include/sys/errno.h to find errnos
21:54:05  <piscisaureus>but this patch made no difference
21:54:08  <ryah>bnoordhuis: also "print (int)errno"
21:54:16  <bnoordhuis>behold:
21:54:17  <bnoordhuis>(gdb) r
21:54:17  <bnoordhuis>`/Users/bnoordhuis/libuv/test/run-tests' has changed; re-reading symbols.
21:54:17  <bnoordhuis>Starting program: /Users/bnoordhuis/libuv/test/run-tests tcp_write_error tcp_write_error
21:54:17  <bnoordhuis>Segmentation fault
21:54:39  <ryah>?
21:54:48  <bnoordhuis>i somehow managed to make gdb crash
21:54:54  <ryah>oh
21:55:53  <bnoordhuis>ryah: btw, pro tip: `p (char*)strerror(errorno)`
22:05:52  <CIA-53>node: Bert Belder master * r8b754a9 / test/simple/test-regress-GH-1697.js : Add regression test for issue 1697 - http://git.io/1b1jHg
22:26:11  <ryah>bnoordhuis: that bug is the last thing for v0.5.7
22:26:20  <ryah>bnoordhuis: isaacs reports npm is running fine otherwise
22:27:04  <bnoordhuis>so it's all down to poor ben again
22:27:08  <ryah>:)
22:27:10  * bnoordhuiscracks open another red bull
22:27:18  <ryah>bnoordhuis: or leave it for me, but im so sleepy today
22:27:24  <ryah>sending emails to random people
22:27:24  <ryah>etc
22:27:30  <bnoordhuis>no, i'll fix it
22:27:30  <piscisaureus>heh
22:27:41  <piscisaureus>ryah: there was nothing shocking in there right?
22:27:42  <bnoordhuis>it's a bug in the test, not in the patch
22:28:27  <ryah>bnoordhuis: i dont know- i think until the callback fires the write_queue_size should be nonzero
22:28:49  <piscisaureus>not on windows no
22:28:54  <piscisaureus>ryah: I don't agree
22:29:02  <ryah>why
22:29:29  <piscisaureus>the write queue size is just a best effort estimate of how much is really in the kernel buffer
22:30:07  <piscisaureus>ryah: hmm
22:30:35  <piscisaureus>ryah: I think we added that so that if write_queue_size == 0 it advisable to write more
22:31:19  <piscisaureus>ryah: if a write completes synchronously then there's no need to count towards the queue size
22:32:25  <ryah>piscisaureus: yes, agreed
22:32:59  <bnoordhuis>btw, we need to handle SIGPIPE in the tests
22:33:01  <ryah>what if it fails synchronously?
22:33:01  <bnoordhuis>Program terminated with signal SIGPIPE, Broken pipe.
22:33:05  <ryah>bnyeah
22:33:09  <ryah>bnoordhuis: yeah
22:35:36  * rmustaccjoined
22:36:51  <CIA-53>libuv: Ryan Dahl master * rf00a5e6 / test/runner-unix.c : ignore SIGPIPE in tests - http://git.io/ohrBaQ
22:37:59  <bnoordhuis>bah, bested!
22:38:15  * brsonjoined
22:44:26  <piscisaureus>It would be really nice if we could get pietern's patch in 0.5.7 too
22:44:47  <piscisaureus>it seems that it makes socketio unusable on windows which makes me very sad
22:46:44  <ryah>piscisaureus: we need to wait for his approval to include it in the project
22:47:22  <piscisaureus>i know
22:47:39  <CIA-53>libuv: Igor Zinkovsky file_watcher * r19132b2 / (9 files in 5 dirs): windows: file watcher (+5 more commits...) - http://git.io/N4bY7Q
22:48:10  <igorzi>bnoordhuis: ^------ windows file watcher
22:48:14  <ryah>oh shit
22:48:22  <ryah>nice igor :)
22:48:28  <piscisaureus>wow
22:49:10  <igorzi>ahh come on, ReadDirectoryChangesW almost does everything for me :)
22:50:18  <piscisaureus>can you also watch individual files with this
22:50:20  <piscisaureus>?
22:50:28  <igorzi>piscisaureus: yep
22:50:33  <piscisaureus>oh nice
22:50:50  <igorzi>now, we just need to agree on the api :)
22:50:57  <piscisaureus>hehe
22:50:59  <piscisaureus>yes I know
22:51:10  <piscisaureus>+ case FILE_ACTION_ADDED:
22:51:10  <piscisaureus>+ case FILE_ACTION_REMOVED:
22:51:10  <piscisaureus>+ case FILE_ACTION_RENAMED_NEW_NAME:
22:51:22  <piscisaureus>^-- igorzi: why is OLD_NAME not included?
22:52:02  <igorzi>piscisaureus: OLD_NAME+NEW_NAME come as a pair of events.. should we fire both?
22:52:20  <rmustacc>igorzi: You probably should, because you can always hit a case where you're only going to get one of them.
22:52:21  <igorzi>piscisaureus: yeah, we should :)
22:52:52  <piscisaureus>also, people can't distinguish this from delete+create
22:53:06  <piscisaureus>so you want to have an event for the "deleted filename" and one for the added filename
22:54:38  <ryah>[email protected]:~/projects/libuv% ./test/run-tests --list | wc -l 64
22:54:46  <ryah>er
22:54:47  <ryah>[email protected]:~/projects/libuv% ./test/run-tests --list | wc -l 64
22:54:47  <ryah>[email protected]:~/projects/libuv%
22:54:49  <ryah>meh
22:54:57  <ryah>64 tests, is what i mean to say
22:55:02  <ryah>libuv is looking good these days
22:57:11  <piscisaureus>there are so many loose ends still
22:57:15  <ryah>true
22:57:40  <ryah>but i think libuv is now the best high-performance x-platform library
22:57:56  <ryah>*networking library
22:58:05  <piscisaureus>well... maybe
22:58:10  <piscisaureus>depends on the metrics you choose
22:58:25  <piscisaureus>but it has a good chance :-)
22:58:35  <ryah>i would use it
22:58:45  <ryah>does that count as a metric?
22:58:46  <piscisaureus>me too
22:58:55  * brsonquit (Quit: leaving)
22:59:14  <piscisaureus>although I would not use vt100 emulation
22:59:17  <piscisaureus>:-p
22:59:19  <igorzi>was someone trying to use it for redis?
22:59:32  <piscisaureus>igorzi: someone, yes
22:59:44  <piscisaureus>just as an experiment, they're not going to use it for real
22:59:49  <igorzi>and, do you know how it went?
23:01:02  <bnoordhuis>ryah: seems i fixed it
23:01:19  <bnoordhuis>apparently os x is able to write out 1M in one go, on localhost anyway
23:01:47  <ryah>bnoordhuis: you sure? when i looked into i was getting errors like ECONNREFUSED ...
23:01:58  <bnoordhuis>i updated the test to not shutdown the server until the first packet is received from the client
23:02:13  <ryah>well whatever. let's get this release out
23:02:43  <piscisaureus>igorzi: he liked it, but their own event loop was a little more efficient I believe
23:03:10  <piscisaureus>igorzi: that's pietern, he hangs out here, saw him this morning
23:03:33  <piscisaureus>igorzi: we're waiting for him to sign the CLA :-(
23:03:38  <bnoordhuis>also a noordhuis <3
23:03:45  <igorzi>piscisaureus: ok thanks. good to know :)
23:03:51  <igorzi>not related?
23:04:06  <CIA-53>libuv: Ryan Dahl master * rd0a46a5 / src/unix/internal.h : HAVE_FUTIMES on osx - http://git.io/Bt31Mg
23:04:54  <piscisaureus>igorzi: are you now starting on redis?
23:05:11  <piscisaureus>s/you/your company/
23:05:22  <CIA-53>libuv: Igor Zinkovsky file_watcher * re49246a / src/win/fs-event.c : windows: fire UV_RENAME for FILE_ACTION_RENAMED_OLD_NAME - http://git.io/17onQQ
23:06:19  <igorzi>piscisaureus: just looking at it for now.. it seems that there's a fork that works on windows. do you know if it's any good?
23:06:46  <igorzi>https://github.com/dmajkic/redis
23:12:42  * mralephquit (Quit: Leaving.)
23:14:49  <bnoordhuis>ryah: can you apply the three patches in ~/libuv/ ? easier than trying to get them out
23:15:50  <ryah>bnoordhuis: shure
23:16:09  <ryah>so tired im even misspelling simple words now
23:16:16  <bnoordhuis>coffee time!
23:18:17  <CIA-53>libuv: Ben Noordhuis master * r4487531 / (test/test-list.h test/test-tcp-write-error.c): test: check that write_queue_size updates after write error - http://git.io/gSA8TQ
23:18:17  <CIA-53>libuv: Ben Noordhuis master * r3c0684e / src/unix/stream.c : unix: pass error to write callback in stream cleanup - http://git.io/61FwLQ
23:18:20  <CIA-53>libuv: Ben Noordhuis master * r75a088e / src/unix/stream.c : unix: remove failed write requests from stream->write_queue_size - http://git.io/pS-EdQ
23:18:43  <piscisaureus>igorzi: I don't know ...
23:23:39  <CIA-53>node: Ryan Dahl master * rd750927 / (5 files in 2 dirs): Upgrade libuv to 75a088e - http://git.io/slaX4w
23:32:53  <ryah>please don't land anything in node/master right now
23:34:15  <ryah>http://nodejs.org/dist/v0.5.7/node-v0.5.7-rc1.tar.gz
23:34:20  <ryah>please test
23:39:50  * bnoordhuisdownloads
23:47:50  <igorzi>piscisaureus: i noticed that your prefork server listens with backlog=10.. did you try increasing that?
23:48:02  <piscisaureus>igorzi: oh hmm
23:48:10  <piscisaureus>igorzi: that's not good
23:48:46  <piscisaureus>I put that in there because I suspected that it was causes by a too big backlog
23:49:55  <piscisaureus>igorzi: sounds like this could make a big difference. will check.
23:50:05  <igorzi>piscisaureus: k
23:55:20  <ryah>[15:43|% 100|+ 530|- 42]: Done <-- sunos make test-all
23:55:24  <ryah>*sigh*
23:57:30  <piscisaureus>didn't we fix simple/test-tls-peer-certificate on windows?