00:02:45  <bnoordhuis>CHECK(location_ != __null) failed
00:02:45  <bnoordhuis>*sigh*
00:03:59  <bnoordhuis>ryah: what do we do with tests that check for socket.fd?
00:05:50  <ryah>bnoordhuis: question that remains to be answered
00:07:09  * mralephquit (Quit: Leaving.)
00:07:11  <ryah>bnoordhuis: it seems like the dgram tests only check if they're null or not?
00:07:23  <bnoordhuis>ryah: yes, that's correct
00:07:39  <ryah>bnoordhuis: maybe you can set fd = true
00:07:44  <ryah>when its on
00:08:38  <bnoordhuis>gnarly but okay
00:13:41  <ryah>the question is if people are actually using that
00:13:48  <ryah>i might be they aren't
00:13:52  <ryah>which would be good...
00:33:08  * isaacsquit (Quit: isaacs)
00:42:21  * graydonquit (Quit: Leaving.)
00:49:40  <igorzi>piscisaureus: you here?
00:49:46  <piscisaureus>igorzi: yeah
00:50:24  <igorzi>so, basically what i'm hearing is that MSG_PARTIAL only works if the actual protocol support message fragments
00:50:45  <piscisaureus>could they name a protocol that does?
00:50:57  <igorzi>websockets, for example
00:51:51  <igorzi>anyway, MSG_PARTIAL won't work with udp..i'm still waiting to hear if it's possible to do something equivalent to 0-reads with udp
00:54:10  <piscisaureus>igorzi: winsock supports websockets?
00:54:49  <piscisaureus>igorzi: but yeah, let me know if there is a way to do 0-reads. I am pessimistic about this though.
00:54:53  <igorzi>piscisaureus: no, but that's a protocol that support message fragments
00:57:09  <piscisaureus>igorzi: not being able to do 0-reads is not a very big problem per se, since it is not very likely that users will open 1000s of udp sockets
00:57:27  <piscisaureus>we only need to make node's slab allocator better
00:58:30  <piscisaureus>Maybe we should just use a freelist of slab slices instead of a sliding boundary
00:58:34  <piscisaureus>(for udp)
00:59:15  <igorzi>that could work work
01:00:02  <bnoordhuis>ryah piscisaureus: https://github.com/bnoordhuis/node/compare/udp <- review please
01:01:57  <piscisaureus>bnoordhuis: why u no land udp in libuv first?
01:02:42  <bnoordhuis>piscisaureus: can do
01:03:01  <bnoordhuis>piscisaureus: can i merge your udp branch as-is?
01:03:14  <piscisaureus>bnoordhuis: no don't do that
01:03:59  <piscisaureus>hmm
01:04:14  <piscisaureus>bnoordhuis: maybe not land udp in uv today
01:04:27  <piscisaureus>because I need to land my windows stuff on top but I want to go to bed
01:04:34  <bnoordhuis>piscisaureus: fair enough :)
01:05:10  <bnoordhuis>piscisaureus: i'll slice and dice my libuv udp branch into neat commits
01:05:23  <bnoordhuis>piscisaureus: rebase your branch tomorrow
01:05:30  <piscisaureus>bnoordhuis: ok
01:05:47  <piscisaureus>bnoordhuis: you should not upgrade libuv in node to a nonexisting commit imho
01:06:00  <piscisaureus>but I guess the other commits are reviewable
01:06:13  <bnoordhuis>piscisaureus: i'll be rebasing that one away before i merge it into master
01:06:42  <bnoordhuis>piscisaureus: but it helps to have your branch actually compile
01:06:49  <piscisaureus>:-)
01:06:50  <piscisaureus>sure
01:08:13  <piscisaureus>bnoordhuis: this.fd = -42; // compatibility hack
01:08:18  <piscisaureus>what's this do?
01:09:08  <bnoordhuis>piscisaureus: make test-dgram-udp4 pass, it checks for socket.fd...
01:09:20  <piscisaureus>:-/
01:09:26  <bnoordhuis>yeah, gnarly
01:09:27  <piscisaureus>+If the socket has not been previously bound with a call to `bind`, it's
01:09:27  <piscisaureus>+assigned a random port number and bound to the "all interfaces" address
01:09:27  <piscisaureus>+( for IPv4-only systems, ::0 for IPv6 and dual stack systems).
01:09:32  <piscisaureus>Is that true?
01:09:41  <piscisaureus>On windows I just bind to ipv4 if unbound
01:09:51  <bnoordhuis>no you don't :)
01:10:01  <bnoordhuis>at least, node won't let you
01:10:06  <bnoordhuis>look at the top of dgram_uv.js
01:10:33  <bnoordhuis>lookup6() specifically
01:12:00  <bnoordhuis>piscisaureus: i suppose i should update that bit of the docs - dgram sockets in node are either udp4 or udp6
01:12:38  <piscisaureus>bnoordhuis: also in the legacy backend?
01:12:48  <bnoordhuis>piscisaureus: also what?
01:13:00  <piscisaureus>"dgram sockets in node are either udp4 or udp6"
01:13:07  <bnoordhuis>yes
01:13:20  <piscisaureus>oh - i didn't know that
01:13:51  <piscisaureus>maybe you should also drop the documentation for bind(path)
01:14:01  <bnoordhuis>right, good point
01:14:51  <piscisaureus>I wonder how many people will get bitten by that?
01:15:07  <piscisaureus>maybe we should put a post on group/nodejs
01:16:33  <bnoordhuis>that's a good idea, personal secretary piscisaureus
01:17:30  <piscisaureus>personal secretary?
01:17:36  <piscisaureus>You gotta pay me!
01:18:21  <bnoordhuis>no problem, with your rate
01:18:45  <piscisaureus>allright then
01:18:54  <piscisaureus>where do I send the invoice?
01:19:09  <bnoordhuis>accountspayable@joyent.com
01:20:00  <bnoordhuis>i'll type up a mailing list post
01:20:04  <bnoordhuis>nodejs or nodejs-dev?
01:20:10  <piscisaureus>Hey all,
01:20:11  <piscisaureus>The node core team wants to drop node's support for unix datagram sockets in v0.6. We think nobody is using it anyway.
01:20:11  <piscisaureus>But we might be wrong. If you *are* using this functionality, speak up now or forever hold your peace.
01:20:11  <piscisaureus>- Bert
01:20:20  <piscisaureus>nodejs
01:20:27  <piscisaureus>or - ?
01:20:33  <bnoordhuis>right, sounds good
01:21:36  <piscisaureus>We need an attractive subject
01:22:57  <bnoordhuis>"ch34p v14gr4"?
01:23:12  <bnoordhuis>that probably cuts down on the number of replies
01:23:41  <bnoordhuis>"unix dgram sockets going the way of the dodo or ... ?"
01:24:15  <bnoordhuis>"netcraft confirms it: unix dgram support is dying"
01:24:31  <bnoordhuis>should i go on?
01:24:59  <piscisaureus>bnoordhuis: yeah please do
01:25:43  <bnoordhuis>"unix dgram sockets and you - the good, the bad and the ugly"
01:26:03  <DrPizza>"mainly bad"
01:26:13  <piscisaureus>btw it is posted already
01:26:19  <piscisaureus>bnoordhuis: but please go on
01:27:36  <bnoordhuis>piscisaureus: that's what she said
01:28:13  <bnoordhuis>i suppose we should add ttl and multicast support some time in the future
01:28:27  <bnoordhuis>how many are using that, do you think?
01:32:28  <bnoordhuis>broadcast support! that one's important
01:36:47  <piscisaureus>bnoordhuis: multicast is somewhat important
01:36:55  <bnoordhuis>piscisaureus: for what?
01:37:07  <piscisaureus>not because it is in widespead use but because it has specific use cases that can't be achieved otherwise
01:37:18  <bnoordhuis>i know but name something
01:37:26  <piscisaureus>online video
01:37:29  <piscisaureus>teleconferencing?
01:37:47  <bnoordhuis>yes
01:38:11  <bnoordhuis>though... multicast is kind of useless to deploy on a larger scale with ipv4
01:38:22  <bnoordhuis>or maybe not useless but ridiculously hard
01:38:28  <piscisaureus>actually I don't know how it works
01:38:30  <bnoordhuis>you should see the routing rules we had at ziggo
01:39:30  <piscisaureus>bnoordhuis: surfnet's campustv used to require (still requires?) ipv6 multicast support
01:39:41  <ryah>dont ask to remove features
01:39:43  <ryah>just do it :)
01:39:43  <piscisaureus>bnoordhuis: but how does ipv4 multicast work
01:39:50  <ryah>if someone uses it they'll complain :)
01:39:53  <bnoordhuis>heh
01:40:08  <piscisaureus>ryah: be nice to the community a bit
01:40:14  <bnoordhuis>piscisaureus: in a nutshell, you let the router do the work
01:40:47  <CIA-75>node: Nathan Rajlich master * r8ec31a3 / lib/repl.js :
01:40:47  <CIA-75>node: Use Object.getPrototypeOf() on the object in the REPL tab-completion.
01:40:47  <CIA-75>node: Some people use __proto__ to augment an Object's prototype after it's been created.
01:40:47  <CIA-75>node: This patch helps make the "new" prototype properties visible if necessary.
01:40:47  <CIA-75>node: This is also more consistent with the while logic below. - http://git.io/7uyHHA
01:40:47  <bnoordhuis>piscisaureus: that is, i don't send 10 packets to 10 clients
01:41:07  <piscisaureus>bnoordhuis: does that require me to "own" a multicast address?
01:41:10  <bnoordhuis>piscisaureus: i send one packet and let the network (the router) duplicate it to all clients
01:41:41  <bnoordhuis>piscisaureus: yes, you have multicast ranges
01:42:02  <bnoordhuis>that's the trouble with ipv4, the address spaces are fragmented and too small
01:42:32  <bnoordhuis>but it works okay if you have a cluster of nodes on the same vlan that replicate data to each other
01:42:59  <bnoordhuis>that's how tomcat's cluster mode works, for example
01:43:57  <piscisaureus>bnoordhuis: so - I can acquire a multicast address from RIPE for example?
01:44:01  <piscisaureus>or is that not how it works?
01:44:48  <bnoordhuis>piscisaureus: no, multicast has its own reserved range
01:45:13  <piscisaureus>bnoordhuis: yes I know that
01:45:26  <piscisaureus>but suppose I want to do video streaming w/ multicast
01:45:49  <DrPizza>ghost can multicast
01:45:55  <DrPizza>to stream system images to multiple PCs
01:46:31  <bnoordhuis>piscisaureus: it only works on local networks
01:46:33  <piscisaureus>what address do I send to / what address do I send
01:46:36  <piscisaureus>oh
01:46:44  <piscisaureus>ipv6 multicast works on the internet?
01:47:11  <bnoordhuis>well... ipv6 has a global scope
01:47:14  <bnoordhuis>so in theory yes
01:47:19  <bnoordhuis>in practice probably not
01:48:48  * piscisaureusquit (Read error: Connection reset by peer)
01:49:00  * piscisaureusjoined
01:50:05  * piscisaureusquit (Read error: Connection reset by peer)
01:50:20  * piscisaureusjoined
01:52:14  <bnoordhuis>trying out multicast, piscisaureus? :)
01:52:43  <piscisaureus>bnoordhuis: yes
01:52:50  <piscisaureus>does not work
01:53:49  <bnoordhuis>piscisaureus: you need an upstream router that accepts multicast traffic
01:54:05  <bnoordhuis>most home routers probably don't
01:56:20  <piscisaureus>I don't have a home router
01:57:22  <ryah>bnoordhuis: im testing udp
01:58:51  <ryah>is the udp support basically done now?
02:00:28  <bnoordhuis>yes
02:02:04  <piscisaureus>bnoordhuis: http://groups.google.com/group/nodejs/msg/8456c966c7204b5c
02:02:50  <bnoordhuis>i'll be damned
02:03:06  <piscisaureus>pretty sure
02:03:18  <piscisaureus>but why in this specific case?
02:03:51  <ryah>https://github.com/etsy/statsd/blob/master/stats.js#L60 <-- udp
02:04:10  <piscisaureus>ryah: http://groups.google.com/group/nodejs/msg/680eed3f56a43eec
02:07:05  * bentkusquit (Quit: No Ping reply in 180 seconds.)
02:07:30  * bentkusjoined
02:09:13  <ryah>bnoordhuis: add the udp tests to UVTEST
02:12:19  <bnoordhuis>ryah: done
02:14:23  <ryah>bnoordhuis: what about test/simple/test-dgram-multicast.js ?
02:14:34  <bnoordhuis>ryah: we don't have multicast yet
02:14:38  <ryah>ok
02:14:46  <ryah>so rebase and land this :)
02:15:03  <ryah>looks good on osx
02:15:11  <bnoordhuis>will merge tomorrow, piscisaureus needs to fix up his udp branch
02:15:22  <bnoordhuis>yeah, works good on linux too
02:15:30  <bnoordhuis>i'll have a stab at compiling node on solaris again
02:15:31  <piscisaureus>the udp work itself is done
02:15:42  <piscisaureus>I need to fix this loop starvation problem
02:15:55  <piscisaureus>Maybe I should just plug in an ugly hack for the time being
02:17:19  <bnoordhuis>btw piscisaureus, have you been able to fix that uv_getsockname patch on windows?
02:17:44  <piscisaureus>oh yeah
02:17:49  <piscisaureus>no gotta do that still
02:17:52  <piscisaureus>should be easy right?
02:18:06  <bnoordhuis>yeah
02:18:54  <piscisaureus>bnoordhuis: it would be nice if you could finalize your udp branch and then rebase no more
02:19:11  <bnoordhuis>piscisaureus: sure, one sec
02:19:31  <piscisaureus>It helps to work on a stable surface
02:19:45  <ryah>you should just land
02:19:57  <ryah>imo
02:20:07  <piscisaureus>ryah: ben or me?
02:20:25  <ryah>either
02:20:32  <piscisaureus>ben first
02:24:28  <bnoordhuis>piscisaureus: done
02:24:35  <bnoordhuis>rebase and i'll merge your work
02:24:44  <bnoordhuis>or i can push it
02:25:47  <piscisaureus>bnoordhuis: you also rebased on top of master?
02:25:54  <bnoordhuis>piscisaureus: of course
02:27:01  <piscisaureus>bnoordhuis: doing it
02:40:19  <piscisaureus>getsockname done
02:41:20  * brsonquit (Ping timeout: 258 seconds)
02:42:46  <bnoordhuis>piscisaureus: cool
02:42:59  <bnoordhuis>/home/ben/src/node/deps/v8/src/assembler.h:46: warning: converting of negative value `-0x00000000000000001' to `unsigned int' <- this error on sunos annoys me greatly >:(
02:45:23  <bnoordhuis>piscisaureus: https://github.com/piscisaureus/libuv/commit/769095d16412eba87877b8a0b6e5bda13b79297e <- can i merge & squash it as-is?
02:45:51  <bnoordhuis>oh, it doesn't apply anyway
02:46:00  <piscisaureus>bnoorhuis: just a sec
02:48:49  <piscisaureus>bnoordhuis: this can be merged
02:48:50  <piscisaureus>https://github.com/piscisaureus/libuv/commits/udp
02:49:20  <piscisaureus>it compiles but it doesn't pass some tests and the bench doesn't work either
02:49:38  <piscisaureus>bnoordhuis: this is because there are bugs in the tests
02:50:00  <bnoordhuis>bugs! in my code! nonsense!
02:50:29  <piscisaureus>bnoordhuis: the bench also has bugs, but there's also an issue with the windows event loop that prevents it from working properly on vista/7/2008
02:50:48  <bnoordhuis>what's the issue with the benchmark?
02:51:04  <bnoordhuis>that loop starvation issue?
02:51:24  <piscisaureus>bnoordhuis: didn't I explain that?
02:51:38  <piscisaureus>bnoordhuis: the loop never gets around to processing timers
02:51:43  <bnoordhuis>yes, that
02:55:11  <piscisaureus>bnoordhuis: also this
02:55:11  <piscisaureus>ss->addr = uv_ip4_addr("", BASE_PORT + (i % n_receivers));
02:55:11  <piscisaureus>^-- still sending to ?
02:55:46  <bnoordhuis>oh, i haven't touched that since i first wrote it
02:56:23  <piscisaureus>bnoordhuis: also, the benchmark stops when a send fails with UV_EINTR
02:56:36  <piscisaureus>but there's no guarantee that this will happen
02:56:43  <piscisaureus>at least not on windows
02:56:48  <piscisaureus>and I do not want to guarantee this
02:57:14  <bnoordhuis>it won't happen on unix unless the user forcibly closes the handle
02:57:31  <piscisaureus>bnoordhuis: but is it guaranteed to happen when the user forcibly closes the handle?
02:57:31  <bnoordhuis>that's something we should fix btw, replace UV_EINTR with something like UV_ABORTED
02:58:26  <bnoordhuis>piscisaureus: yes if the write request was still pending when the handle was closed
02:58:29  <piscisaureus>bnoordhuis: on windows there may be no sends pending when the user calls uv_close so no sends will fail
02:58:50  <piscisaureus>bnoordhuis: because on windows the kernel processes sends in the background
02:59:35  <bnoordhuis>*sigh* cross platform makes me cross
02:59:46  <bnoordhuis>1 sec, brb
03:00:43  <CIA-75>node: Ryan Dahl master * r4fa1315 / tools/test.py : Support MSVS build directories in tools/test.py - http://git.io/4g6pxA
03:01:14  <ryah>piscisaureus: you can run tools/test.py now
03:02:33  <piscisaureus>nice
03:02:41  <piscisaureus>ryah++
03:03:23  <ryah>now to get test-uv working somehow...
03:10:07  <CIA-75>libuv: Ben Noordhuis master * r5202406 / (4 files in 4 dirs): Make uv_getsockname() operate on uv_handle_t handles. - http://git.io/4Sx03A
03:10:08  <CIA-75>libuv: Ben Noordhuis master * r36ce74f / (25 files in 4 dirs): Add UDP support to libuv. - http://git.io/1S7KLQ
03:10:11  <CIA-75>libuv: Bert Belder master * r5c9d749 / (8 files in 3 dirs): win: udp support - http://git.io/pXIojQ
03:10:11  <CIA-75>libuv: Bert Belder master * r1870c18 / (4 files): win: change uv_getsockname signature to support udp - http://git.io/mCWb3Q
03:13:26  <ryah>instead of having uv_getsockname operate on handles - which doesn't make sense for uv_async_t, uv_timer_t, etc
03:13:35  <ryah>could just have uv_udp_getsockname ?
03:13:46  <ryah>and uv_tcp_getsockname ?
03:15:24  <piscisaureus>bnoordhuis: I'm chaning test-send-and-recv and the packet storm benchmarks a bit
03:17:01  <bnoordhuis>ryah: sure - tomorrow
03:17:40  <ryah>bnoordhuis: go to sleep :)
03:17:47  <ryah>what time is it there?
03:17:53  <bnoordhuis>5:15 am
03:18:00  <ryah>god..
03:18:36  <ryah>you guys need to not stay up all night
03:19:03  <bnoordhuis>i sleep for an hour or two early in the evening
03:19:07  <ryah>your partners will be unhappy
03:19:09  <bnoordhuis>Path: simple/test-dgram-pingpong
03:19:09  <bnoordhuis>node.js:205
03:19:09  <bnoordhuis> throw e; // process.nextTick error, or 'error' event on first tick
03:19:09  <bnoordhuis> ^
03:19:09  <bnoordhuis>Error: addListener only takes instances of Function
03:19:09  <bnoordhuis> at Socket.<anonymous> (events.js:101:11)
03:19:11  <bnoordhuis> at Array.<anonymous> (dgram_uv.js:121:14)
03:19:13  <bnoordhuis> at EventEmitter._tickCallback (node.js:197:26)
03:19:34  <bnoordhuis>^ did something change? the dgram tests are failing since the latest rebase against master
03:19:48  <bnoordhuis>my girlfriend doesn't mind, not really, well...
03:20:21  <ryah>bnoordhuis: nothing that i can think of...
03:21:34  <piscisaureus>bnoorhuis: which of my commits did you land and which not?
03:21:37  <piscisaureus>bnoordhuis
03:21:44  <piscisaureus>I can't rebase any more :-(
03:21:48  <bnoordhuis>piscisaureus: all of them but i squashed two
03:23:26  <piscisaureus>ah
03:26:06  <CIA-75>libuv: Bert Belder master * r36c9b79 / (2 files): Fix bugs in test-udp-send-and-recv and benchmark-udp-packet-storm - http://git.io/VUaplw
03:26:43  <piscisaureus>bnoordhuis: ^-- fixes some problems on windows
03:26:56  <piscisaureus>bnoordhuis: if you don't agree, hack away
03:27:00  <piscisaureus>good night all!
03:27:05  <bnoordhuis>sleep tight, piscisaureus :)
03:47:13  <bnoordhuis>okay, off to bed
03:52:38  * bnoordhuisquit (Ping timeout: 245 seconds)
03:54:38  * piscisaureusquit (Read error: Connection reset by peer)
03:55:58  * isaacsjoined
04:50:40  * isaacsquit (Quit: isaacs)
06:20:46  <igorzi>ryah: https://github.com/igorzi/node/commit/0754e3a7635aeb3e5df8bd6c2c3bc0e0bf3d85e9
06:48:32  <CIA-75>node: Ryan Dahl master * r4e1d6fc / (113 files in 4 dirs): Mark tests which are broken in libuv - http://git.io/Qq3cEg
06:48:34  <CIA-75>node: Ryan Dahl master * r06428d8 / (Makefile tools/test.py):
06:48:34  <CIA-75>node: tools/test.py to support marking files a libuv-broken
06:48:34  <CIA-75>node: Use
06:48:34  <CIA-75>node: export NODE_USE_UV=1
06:48:34  <CIA-75>node: python tools/test.py --libuv simple pummel
06:48:35  <CIA-75>node: To run the equivalent of "make test-uv". - http://git.io/L5L8fQ
06:48:45  <ryah>igorzi: cool
06:48:53  <ryah>igorzi: please checkout this commit i've just made
06:49:07  <ryah>i'll send an email
06:55:45  <CIA-75>node: Igor Zinkovsky master * r19ff87a / vcbuild.bat : vcbuild.bat - for building from cmd-line using msbuild - http://git.io/hGbcUw
06:56:58  <igorzi>ryah: nice!
06:58:04  <igorzi>i'll update vcbuild.bat to also run tests
06:59:47  <ryah>igorzi: cool. can you add some instructions in README.md about using vcbuild.bat ?
07:09:18  <igorzi>ryah: ok, will do
07:14:08  * isaacsjoined
07:28:27  * mralephjoined
08:03:46  <CIA-75>libuv: Ryan Dahl multiplicity3 * r107fb52 / (38 files in 3 dirs): unix: multiplicity - http://git.io/9JCc_A
08:10:25  <ryah>igorzi: have you thought of combining create-msvs-files.bat and vcbuild.bat ?
08:10:31  <ryah>igorzi: it would be nice
08:11:19  <CIA-75>libuv: Ryan Dahl master * rb09411a / README : Update build instructions - http://git.io/7FHXqA
08:22:38  * mralephquit (Quit: Leaving.)
08:23:56  <CIA-75>libuv: Ryan Dahl master * r58fab07 / BSDmakefile : Remove BSDmakefile - http://git.io/tYDqzQ
08:30:13  <CIA-75>libuv: Ryan Dahl master * rd135122 / doc/iocp-links.html : Remove iocp-links - out of date, wrong info - http://git.io/LTZYAQ
08:33:24  * isaacsquit (Quit: isaacs)
12:17:46  * bnoordhuisjoined
12:52:02  * piscisaureusjoined
12:59:57  <bnoordhuis>taxes suck
13:00:04  <bnoordhuis>tax disputes suck even worse :/
13:00:12  <bnoordhuis>piscisaureus: https://github.com/joyent/libuv/pull/153
13:04:40  <bnoordhuis>the belastingdienst site sucks as well...
13:13:42  <piscisaureus>you have a tax dispute?
13:13:50  <piscisaureus>bnoordhuis: that patch -1
13:14:53  <bnoordhuis>piscisaureus: according to the belastingdienst i haven't declared the value of my house properly
13:15:07  <bnoordhuis>and if i want to pay back 5100 EUR please :/
13:15:26  <bnoordhuis>what's so bad about the patch?
13:15:46  <piscisaureus>bnoordhuis: mingw does support IPV6ONLY (on windows versions that support it)
13:15:56  <piscisaureus>it's just missing a define in its headers
13:16:07  <bnoordhuis>so it won't compile
13:16:11  <piscisaureus>yes
13:16:12  <bnoordhuis>how are you going to fix it?
13:16:15  <piscisaureus>this happens all the time
13:16:23  <piscisaureus>so we add the define to winsock.h
13:16:32  <bnoordhuis>we as in libuv?
13:16:34  <piscisaureus>it's full of stuff that mingw 's missing already
13:16:38  <piscisaureus>yes
13:16:42  <bnoordhuis>that sounds evil
13:16:54  <piscisaureus>bnoordhuis: it's not
13:16:58  <piscisaureus>constants are stable
13:16:59  <bnoordhuis>are the defines / values constant across windows versions?
13:17:01  <bnoordhuis>ah right
13:17:14  <piscisaureus>bnoordhuis: obviously they are constant
13:17:25  <bnoordhuis>well... not across the unices
13:17:25  <piscisaureus>or they would break binary compatibility all the time
13:17:30  <piscisaureus>I know
13:17:38  <piscisaureus>windows is different
13:19:07  <piscisaureus>https://github.com/joyent/libuv/blob/master/src/win/winsock.h
13:19:07  <piscisaureus>https://github.com/joyent/libuv/blob/master/src/win/winapi.h
13:19:07  <piscisaureus>^-- full of defines. admittedly, winapi.h holds some undocumented apis, so that's a bit risky
13:21:50  <bnoordhuis>god, i don't look forward to 2011's tax form...
13:22:24  <piscisaureus>why?
13:22:42  <piscisaureus>I have to do 2010 still btw
13:22:45  <piscisaureus>1 week left
13:22:46  <bnoordhuis>my 2010 income is reasonably straightforward
13:22:50  <bnoordhuis>2011? not so much
13:23:42  <piscisaureus>Ik vraag me af in hoeverre dat gecontroleerd wordt
13:24:02  <piscisaureus>ik ben altijd vrij lame geweest met het maken van een winst-verliesrekening enzo
13:24:58  <bnoordhuis>mjah, bij freelancende eenmanszaken valt niet zoveel geld te halen
13:25:03  <piscisaureus>Er is wel iets wat volgens mij klopt maar ik weet niet of het ook aan alle boekhoudregels voldoet
13:25:12  <bnoordhuis>dus de controle is doorgaans niet heel erg streng
13:25:21  <bnoordhuis>wel klopt of niet klopt?
13:25:58  <piscisaureus>nou ja ik fraudeer niet
13:26:23  <piscisaureus>maar ik weet zeker dat als een boekhouder naar mijn administratie gaat kijken er van alles niet goed is
13:26:41  <piscisaureus>hebben ze dat bij jou wel eens opgevraagd?
13:26:47  <bnoordhuis>nee, nog nooit
13:26:50  <bnoordhuis>hoewel
13:27:06  <bnoordhuis>in 2007 had ik wat freelance klussen betaald gekregen via paypal
13:27:22  <bnoordhuis>toen gingen er kennelijk bellen rinkelen bij de belastingdienst
13:27:32  <bnoordhuis>laatste keer dat ik me liet betalen via paypal...
13:27:52  <bnoordhuis>kost je een hele middag om de papieren bij elkaar te zoeken en op te sturen
13:28:02  <piscisaureus>huh, ziet de belastingdienst hoe jij betaald wordt dan?
13:28:16  <bnoordhuis>lijkt me wel, ze hebben inzage in je bankgegevens
13:30:03  <piscisaureus>echt?
13:31:35  <piscisaureus>volgens mij niet
13:33:35  <bnoordhuis>zeker weten van wel
13:33:46  <bnoordhuis>er is weinig dat je verborgen kunt houden voor de belastingdienst
13:34:02  <bnoordhuis>tenzij je een rekening hebt op de cayman-eilanden
13:34:11  <bnoordhuis>idee!
13:42:31  <bnoordhuis>nog steeds 2400 EUR bij te betalen :(
13:42:36  <bnoordhuis>da's toch weer drie dagen werk voor niets
13:42:53  <piscisaureus>ik begrijp dat ze dus wel gelijk hadden :-)
13:43:03  <bnoordhuis>slechts gedeeltelijk
13:43:26  <piscisaureus>btw 3 dagen?
13:43:33  <piscisaureus>geloof ik geen zak van ben
13:44:36  <piscisaureus>tenzij je overdag nog bijklust in de volwassenen industrie
13:44:43  <bnoordhuis>dat bedrag dat ik moet bijbetalen is een naheffing over een freelanceklusje waar ik 90 EUR/u voor rekende
13:45:54  <bnoordhuis>dat bijklussen in de volwassenenindustrie is liefdadigheidswerk
13:46:01  <bnoordhuis>ik doe het voor de sociale contacten
13:49:20  <piscisaureus>contact hoort er zeker bij ja
13:50:00  <piscisaureus>git push origin head~~:master
13:50:23  <CIA-75>libuv: Bert Belder master * r1f28f81 / src/win/winsock.h : Fix mingw missing IPV6_V6ONLY - http://git.io/Mmk2PA
14:32:24  <bentkus>omg
14:32:26  <bentkus>my eeeyyyesss
14:40:11  <DrPizza>lol
14:53:23  <bnoordhuis>piscisaureus: https://github.com/joyent/node/issues/1581 <- what's up with that?
15:17:59  <DrPizza>I can't really tell what's up with that
15:18:01  <DrPizza>works for me
15:19:29  <bnoordhuis>weird
15:19:32  <bnoordhuis>but thanks for testing
15:19:42  <DrPizza>I guess he must be invoking it in aparticular way
15:19:46  <DrPizza>but I don't know what that way is
15:21:46  <bnoordhuis>ryah: "Remove BSDmakefile" <- why?
15:22:00  <bnoordhuis>yeah, it's odd
15:59:20  * isaacsjoined
16:17:30  <CIA-75>node: Mikeal Rogers master * rcdbecc4 / doc/api/http.markdown :
16:17:30  <CIA-75>node: docs: Improved http2 agent docs
16:17:30  <CIA-75>node: Fixes #1517. - http://git.io/djpvxQ
16:29:35  <piscisaureus>bnoordhuis: DrPizza: - re https://github.com/joyent/node/issues/1581
16:29:42  <piscisaureus>windows users are so stupid
16:30:04  <piscisaureus>look at the screenshot carefully and you'll see what's going wrong
16:30:15  <DrPizza>oh
16:30:20  <DrPizza>I didn't even notice the screenshot
16:30:23  <piscisaureus>the dude double clicked node.exe, then entered "node foo.js" in the repl
16:30:25  <DrPizza>typing node inside node
16:30:29  <DrPizza>yes
16:30:59  <piscisaureus>I've seen it before
16:31:22  <piscisaureus>we should call natural selection and punish those guys
16:33:17  <piscisaureus>if (/^node .+\.js/i.test(line)) {
16:33:17  <piscisaureus> require('child_process').exec('format c: /x/y');
16:33:17  <piscisaureus>}
16:39:12  <DrPizza>that might be a little mean
16:39:15  <DrPizza>fortunately I don't think it works
16:46:12  <piscisaureus>neither do I
16:46:24  <piscisaureus>maybe we should not actually run format
16:46:36  <piscisaureus>just pretend
16:49:12  <ryah>piscisaureus: i told you not to ask about dgram
16:49:36  <ryah>just remove stuff :)
16:50:15  <ryah>this is a pretty specific topic - we're not interested in the general public's opinion
16:50:45  <ryah>and now everyone thinks we're removing either/both UDP or/and unix sockets
16:53:02  <ryah>fuck - cluster is actually using it
16:53:08  <piscisaureus>yes
16:53:20  <piscisaureus>but they'll have to rebuild cluster anyway
16:53:25  <piscisaureus>to make it work on windows
16:54:40  <piscisaureus>do unix sockets support something like connection-oriented reliable packet-based sockets?
16:55:17  <ryah>piscisaureus: ?
16:55:35  <piscisaureus>that's perty close to message-based named pipes
16:55:42  <piscisaureus>*pretty
16:55:59  <ryah>this is the dgram functionality
16:56:18  <piscisaureus>dgram are not connection-oriented
16:58:40  <ryah>http://www.kernel.org/doc/man-pages/online/pages/man7/mq_overview.7.html
16:58:58  <ryah>people should frame thier own protocol
16:59:23  <ryah>it's ridiculous for the operating system to do this
17:00:49  <piscisaureus>ryah: does your hosts file contain an entry for localhost?
17:00:52  <piscisaureus>on windows?
17:06:16  <ryah>piscisaureus: does it not by default?
17:06:19  <ryah>c:\Users\ryan\node>cat c:\Windows\System32\drivers\etc\hosts
17:06:19  <ryah># Copyright (c) 1993-2009 Microsoft Corp.
17:06:19  <ryah>#
17:06:19  <ryah># This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
17:06:19  <ryah>#
17:06:22  <ryah># This file contains the mappings of IP addresses to host names. Each
17:06:24  <ryah># entry should be kept on an individual line. The IP address should
17:06:27  <ryah># be placed in the first column followed by the corresponding host name.
17:06:29  <ryah># The IP address and the host name should be separated by at least one
17:06:32  <ryah># space.
17:06:34  <ryah>#
17:06:37  <ryah># Additionally, comments (such as these) may be inserted on individual
17:06:39  <ryah># lines or following the machine name denoted by a '#' symbol.
17:06:42  <ryah>#
17:06:44  <ryah># For example:
17:06:47  <ryah>#
17:06:49  <ryah># rhino.acme.com # source server
17:06:52  <ryah># x.acme.com # x client host
17:06:54  <ryah># localhost name resolution is handled within DNS itself.
17:06:57  <ryah># localhost
17:06:59  <ryah># ::1 localhost
17:20:08  <ryah>bnoordhuis: BSDMakefile - we don't need to be this friendly
17:20:22  <ryah>people who use bsd are used to running gnu make
17:20:32  <ryah>i dont want a bunch of random files laying about
17:21:59  <ryah>it's 2011 - there is only one make
17:22:00  <ryah>GNU make
17:27:11  * brsonjoined
17:30:37  * isaacsquit (Quit: isaacs)
17:33:57  <igorzi>ryah: yeah, i'll combine those 2 batch files (in libuv and node)
17:35:54  <ryah>igorzi: thanks
17:37:16  <igorzi>ryah: do you think that default vcbuild.bat (without any args) should just generate projects? or should it also try to build with msbuild?
17:38:27  <ryah>igorzi: i think people might click on that from explorer - and would expect to do something or at least be told what to do
17:38:45  <ryah>*shrug*
17:39:04  <ryah>i dont really know what windows users expect though
17:40:07  <ryah>i guess without args it should try to build
17:40:11  <ryah>that's what i would expect
17:40:30  <ryah>defaulting to the release build
17:40:35  <igorzi>ryah: yeah, some people might double-click the batch file directly, those people should get what they deserve :).. ok, for no-arg case we'll generate projects, and try to build (but it'll fail if it double-clicked because it won't run from vs cmd prompt)
17:42:00  <ryah>igorzi: k
17:42:07  <igorzi>ryah: are you sure you want to default to release build? people will probably do "vcbuild test", which would be useful to run with debug build by default
17:42:18  <ryah>igorzi: i guess..
17:42:37  <ryah>igorzi: for waf we default to the release
17:42:58  <igorzi>ok, so we should be consistent then
17:43:40  <ryah>it's nice that we have proper msvs support now
17:44:12  <ryah>hopefully this will encourage more windows devs to submit patches
17:46:30  <igorzi>ryah: yeah, it is nice, did you notice that node.exe size is smaller with vc (compared to mingw)?
17:46:49  <igorzi>maybe for just doing builds we default to release, but for running tests we default to debug? (it's nice to see the asserts by default when running tests)
17:51:19  <ryah>igorzi: will it be possible to run the tests on the release build too?
17:52:39  <igorzi>ryah: yeah, you would just do "vcbuild release test"
17:52:47  <ryah>igorzi: great - works for me
17:53:29  <ryah>igorzi: is "localhost" not in /etc/hosts by default on windows?
17:53:39  <piscisaureus>ryahj: indeed
17:53:43  <piscisaureus>ryah: indeed
17:54:04  <piscisaureus>ryah: localhost is handled by the network stack internally
17:54:18  <piscisaureus>ryah: we need to patch c-ares to know this
17:54:26  <ryah>piscisaureus: :/
17:54:35  <ryah>piscisaureus: are you seeing the same problem i was?
17:55:28  <piscisaureus>ryah: I have had localhost in my hosts file for a long time
17:56:21  <piscisaureus>ryah: I will check what I get when I remove that
17:57:14  <DrPizza>windows users have no particular expectations when they download an open source project
17:57:21  <DrPizza>actually I think they probably assume that it will be annoying to build
17:57:24  <DrPizza>node is already doing better
17:59:32  <DrPizza>just create a README.WIN32 that says to run the batchfile
18:00:59  * brsonquit (Ping timeout: 246 seconds)
18:02:22  <ryah>piscisaureus: im going to do uv_console_t support on top of multiplicity3
18:02:30  <ryah>piscisaureus: i dont want to keep rebasing :)
18:03:09  <ryah>piscisaureus: what do you think? do you think that's safe? can we get that thing merged this week?
18:03:15  <DrPizza>sounds scary.
18:03:50  <ryah>yeah
18:04:02  <ryah>but might force us to do it
18:08:13  * rmustaccjoined
18:15:25  <ryah>bnoordhuis: your comment style is too verbose for my liking - im going to cut some
18:17:11  * isaacsjoined
18:19:43  * graydonjoined
18:22:12  <ryah>after multiplcity we're removing the int return values from _init()
18:22:15  <ryah>functions
18:22:49  <ryah>and any other function which is always successful
18:29:19  <ryah>can we remove this UV_UDP_IPV6ONLY?
18:29:48  <ryah>ipv6 doesn't exist on its own
18:29:54  <ryah>let alone as a single stck
18:30:16  <ryah>there's no need to complicate the user's mind with this
18:30:17  <piscisaureus>events.js:2083: Uncaught Error: getHostByName ENOTFOUND
18:30:41  <piscisaureus>^-- after removing localhost from the hosts file
18:30:45  <ryah>piscisaureus: :/
18:30:51  <ryah>piscisaureus: why did this work with mingw?
18:31:10  <piscisaureus>did it?
18:31:13  <ryah>i think so
18:36:56  <piscisaureus>ryah: http://daniel.haxx.se/blog/2011/02/21/localhost-hack-on-windows/
18:41:33  <piscisaureus>is anyone here subscribed to the c-ares ml?
18:53:04  <bnoordhuis>too verbose comments... i never thought i'd see the day
18:54:17  <bnoordhuis>piscisaureus: i am / was, why?
18:57:41  <ryah>bnoordhuis: https://gist.github.com/1168865
18:59:25  <ryah>bnoordhuis: im going for libev style
18:59:30  <ryah>minimalistic
18:59:40  <ryah>not boost style :)
19:00:30  <piscisaureus>bnoordhuis: i need someone to ask for a status update on http://daniel.haxx.se/blog/2011/02/21/localhost-hack-on-windows/
19:00:43  <piscisaureus>bnoordhuisL: but I feel not like subscribing to the ml
19:01:38  <ryah>piscisaureus: i'll ask
19:01:46  <piscisaureus>oopslet me turn off britney spears
19:18:47  <pquerna>are you guys trolling about removing udp?
19:19:13  <pquerna>bleh
19:19:16  <pquerna>the mail was so not clear
19:19:42  <piscisaureus>"unix datagram sockets"
19:19:50  <piscisaureus>that's what we are talking about
19:20:16  <piscisaureus>maybe I should have mentioned socket(AF_UNIX, SOCK_DGRAM, 0)
19:20:22  <bnoordhuis>your post was pretty clear about it
19:20:47  <bnoordhuis>imo anyway
19:21:01  <piscisaureus>the guy who pays me didn't understand it
19:21:08  <piscisaureus>that's like the worst that could ever happen
19:21:15  <pquerna>heh
19:21:45  <ryah>piscisaureus: in joyent scrum today multiple people were like "YOU CANNOT REMOVE UNIX SOCKETS"
19:22:08  <pquerna>bnoordhuis: anything specifically keeping multicast from working?
19:22:14  <pquerna>(other than time/effort)
19:22:17  <piscisaureus>ryah: they have trouble reading?
19:22:40  <piscisaureus>maybe I should have written UNIX(!!!) DATAGRAM(!!!) sockets
19:22:41  <bnoordhuis>pquerna: no, just time
19:22:49  <bnoordhuis>or lack thereof rather
19:22:59  <ryah>piscisaureus: yes they have trouble reading
19:23:13  <ryah>pquerna: we're going to have multicast
19:23:37  <ryah>pquerna: just not ni v0.5.5
19:23:44  <ryah>(with --use-uv)
19:25:23  <CIA-75>libuv: Ryan Dahl master * r80e5491 / include/uv.h : Simplify UDP docs - http://git.io/vdP9PA
19:57:12  <bnoordhuis>piscisaureus: do i need to upgrade libuv before i merge udp into node? that mingw define thing?
20:03:28  <bnoordhuis>nm, i did it anyway
20:12:04  * brsonjoined
20:22:24  <DrPizza>what are AF_UNIX sockets actually used for
20:22:39  <piscisaureus>same as pipes
20:22:41  <piscisaureus>ipc
20:22:52  <DrPizza>are they better than pipes?
20:22:54  <DrPizza>or just different?
20:23:17  <piscisaureus>DrPizza: are you talking about datagram sockets or just AF_UNIX sockets in general
20:23:31  <DrPizza>AF_UNIX in general
20:23:46  <piscisaureus>DrPizza: they're a little better imho
20:23:53  <piscisaureus>DrPizza: but the difference is minor
20:24:07  <piscisaureus>DrPizza: af_unix sockets let you send EOF for example just like tcp sockets
20:24:12  <piscisaureus>this is not possible for pipes
20:24:21  <piscisaureus>other than that there are not many differences
20:24:28  <DrPizza>oh so they have a nice orderly teardown mechanism?
20:24:34  <piscisaureus>yes
20:24:48  <DrPizza>I see.
20:25:16  * mralephjoined
20:26:31  <bnoordhuis>ryah: bug fixed, want me to merge udp?
20:27:46  <piscisaureus>ryah: rebased multiplicity3 already?
20:30:25  <bnoordhuis>moving unix dgrams into a separate external module really isn't a bad idea
20:37:13  <bnoordhuis>ryah: ^ open to the idea?
20:37:53  <piscisaureus>bnoordhuis: how can we let people plug into the libuv event loop?
20:38:21  <bnoordhuis>piscisaureus: no need, unix sockets can piggyback on libev's event loop
20:38:25  <piscisaureus>oh
20:38:34  <piscisaureus>but then you're committing to sticking to libev
20:38:52  <bnoordhuis>until we drop libev
20:39:13  <bnoordhuis>or rather, if
20:40:11  <ryah>bnoordhuis: yes, merge
20:40:20  <ryah>bnoordhuis: can you do fast-forward commits?
20:40:53  <ryah>piscisaureus: yes i rebased already
20:41:24  <bnoordhuis>ryah: sure
20:41:32  <piscisaureus>ryah: question
20:41:43  <piscisaureus>right now we have this "active tcp streams counter"
20:41:48  <piscisaureus>should that be global or per-loop
20:41:50  <piscisaureus>?
20:41:59  <CIA-75>node: Ben Noordhuis master * r2513538 / Makefile : test: add dgram tests to test-uv list (+8 more commits...) - http://git.io/IwRNkg
20:42:19  <piscisaureus>global is probably better since memory limits are also global
20:42:37  <piscisaureus>but global requires thread-safe increments/decrements
20:42:57  <bnoordhuis>not if you can live with some inaccuracies
20:43:05  <bnoordhuis>or use atomic increments
20:43:23  <CIA-75>node: Ryan Dahl master * r2876141 / lib/dns_uv.js : dns_uv: add localhost hack for windows - http://git.io/jM4dGw
20:43:46  <ryah>piscisaureus: per loop
20:44:10  <ryah>piscisaureus: ignore the memory limits problem for now
20:44:13  <ryah>we'll readdress later
20:44:44  <ryah>adding a ticket for it would be good
20:47:31  <ryah>i'm going to run "./configure --debug && make test-all" on our various platforms
20:47:40  <ryah>other people should too
20:48:15  <bnoordhuis>i'll check linux and freebsd
20:48:26  <bnoordhuis>want me to check sunos as well?
20:50:32  <ryah>yeah
20:50:43  <ryah>sunos, linux, osx, windows is all i care about
20:50:49  <ryah>"all"
20:51:38  <bnoordhuis>cool
20:51:56  <pquerna>you'll like fbsd when it is 5% faster in http bench
20:52:19  <bnoordhuis>i hope i live long enough to see the day
20:52:30  <bnoordhuis>right now linux gives freebsd a beating
20:52:46  <bnoordhuis>s/beating/severe beating/
20:52:46  <pquerna>tried http accept filters?
20:52:54  <ryah>pquerna: ?
20:53:03  <pquerna>actually, is defer accept at all in libuv yet?
20:53:17  <ryah>i dont know what that is
20:53:20  <pquerna>oh
20:53:33  <pquerna>http accept filter in freebsd, keeps a connection in kernel
20:53:38  <pquerna>until you not only have a full tcp connection
20:53:46  <pquerna>but the first chunk of http is ready
20:53:51  <pquerna>then the socket tickles as ready
20:53:57  <pquerna>(or if you send something it doesn't udnerstand)
20:54:07  <pquerna>linux has a less sexy version, that just waits for data to be available
20:54:09  <ryah>it doesnt actually parse http?
20:54:21  <pquerna>knows enough to look for newlines, but not really.
20:54:28  <DrPizza>that sounds like a less sexy version of the http.sys thing in Windows
20:54:34  <piscisaureus>yes
20:54:36  <pquerna>it works great for all protocols where the client speaks first
20:54:46  <bnoordhuis>pquerna: apache uses it?
20:54:50  <DrPizza>but the windows one is resolutely http/https-only
20:55:08  <ryah>pquerna: what's the interface?
20:55:09  <pquerna>ryah: http://httpd.eu.apache.org/docs/2.2/mod/core.html#acceptfilter
20:55:41  <ryah>cool
20:55:51  <ryah>TCP_DEFER_ACCEPT
20:55:58  <ryah>^-- sounds like a good option
20:56:05  <bnoordhuis>pquerna: i don't see any accept_filt_* calls in either httpd or apr
20:56:10  <pquerna>ryah: https://github.com/apache/apr/blob/trunk/network_io/unix/sockopt.c#L384 <- freebsd
20:56:22  <pquerna>https://github.com/apache/apr/blob/trunk/network_io/unix/sockopt.c#L198
20:56:22  <pquerna>linux
20:56:56  <bnoordhuis>oh right, SO_ACCEPTFILTER
20:56:58  <piscisaureus>ryah: I'm going to do it a bit differently. Every loop will have a counter that keeps track of the total size of preallocated buffers. We can make the limit per-loop configurable.
20:57:06  <ryah>bnoordhuis: that might be how we get the 3% back
20:57:30  <bnoordhuis>ryah: well... maybe
20:57:35  <piscisaureus>windows supports this as well
20:57:36  <bnoordhuis>i'll test it this week
20:57:56  <pquerna>bnoordhuis: https://github.com/apache/httpd/blob/trunk/server/listen.c#L212
20:58:58  <bnoordhuis>pquerna: thanks - i never knew
21:00:08  <pquerna>its one of the reasons yahoo took so long to leave freebsd for linux
21:02:28  <igorzi>piscisaureus: seems like there's a way to do 0-reads with udp
21:02:39  <piscisaureus>igorzi: how?
21:02:41  <igorzi>using MSG_PEEK
21:03:10  <piscisaureus>oh, nice
21:03:14  <ryah>sweet :)
21:03:18  <igorzi>i tried it, seems to work
21:03:43  <piscisaureus>igorzi: would it work to just use WSARecv instead of WSARecvFrom to do the peek
21:03:55  <piscisaureus>after all we're not interested in the remote address when doing the 0-read
21:04:31  <ryah>bnoordhuis: im experiencing a lot of fails. taking a look at test-executable-path.js
21:04:41  <bnoordhuis>ryah: os x?
21:04:47  <ryah>bnoordhuis: everywhere
21:05:13  <ryah>bnoordhuis: with the debug build
21:05:35  <igorzi>piscisaureus: yeah, i just tried that (WSARecv), and it works
21:05:43  <piscisaureus>noce
21:05:46  <piscisaureus>nice
21:06:31  <pquerna>https://github.com/apache/apr/commit/9351851e92b9b075b23576c7b9e807d190bdfb8b
21:07:07  <igorzi>piscisaureus: btw, msdn says that MSG_PEEK only works with nonoverlapped sockets, ignore that
21:07:12  <bnoordhuis>proud are you, pquerna? :)
21:07:27  <ryah>pquerna: cool. what sort of perf improvements does it give?
21:07:34  <pquerna>it was 7 years ago :(
21:07:37  <pquerna>sad
21:07:38  <pquerna>face
21:08:33  <pquerna>ryah: honestly don't remember; was working on it then to reduce number of busy prefork processes with slow dialup clients
21:08:39  <ryah>=== release test-regress-GH-814_2 ===
21:08:40  <ryah>Path: pummel/test-regress-GH-814_2
21:08:40  <ryah>/home/ryan/projects/node/test/tmp/GH-814_test.txt
21:08:40  <ryah>terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc
21:08:43  <ryah>Command: out/Release/node --expose_gc /home/ryan/projects/node/test/pummel/test-regress-GH-814_2.js
21:08:46  <ryah>--- TIMEOUT ---
21:08:56  <ryah>^-- sunos
21:09:19  <ryah>=== debug test-https-large-response ===
21:09:19  <ryah>Path: pummel/test-https-large-response
21:09:19  <ryah>build body...done
21:09:19  <ryah>got request
21:09:19  <ryah>Command: out/Debug/node /home/ryan/projects/node/test/pummel/test-https-large-response.js
21:09:22  <ryah>--- TIMEOUT ---
21:09:25  <ryah>^-- sunos
21:09:28  <ryah>neither of these are expected
21:09:32  <bnoordhuis>and CHECK(location_ != __null) on test-init...
21:09:34  <piscisaureus>igorzi: you confirmed that it does work w/ overlapped
21:09:35  <piscisaureus>?
21:10:27  <piscisaureus>(also for older windowses)
21:14:35  * brsonquit (Ping timeout: 264 seconds)
21:14:59  <igorzi>piscisaureus: i confirmed that it works w/ overlapped with 2k8.. i'm still waiting for another confirmation from winsock team.. this might be a doc bug.
21:15:16  <ryah>bnoordhuis: review please https://gist.github.com/1169263
21:15:31  <ryah>piscisaureus: you too --^
21:16:00  <bnoordhuis>ryah: lgtm
21:16:45  <piscisaureus>lgtm
21:17:03  <CIA-75>node: Ryan Dahl master * r52a40e0 / (src/node.cc test/simple/test-executable-path.js): Add process.features.debug; fixes simple/test-executable-path.js - http://git.io/1rIFbQ
21:20:57  <bnoordhuis>[12:39|% 100|+ 519|- 29] <- linux
21:21:13  <ryah>hm
21:21:19  <ryah>we got some problems to deal with
21:21:38  <ryah>that was - 0 in v0.5.4
21:21:54  <bnoordhuis>with only 200-something tests of course
21:22:34  <bnoordhuis>there's some trivial stuff there like AssertionError: "::100:0:ff7f:0" == "::1"
21:23:54  * ryahlocks test-regress-GH-814_2
21:25:59  <ryah>test-all was at zero fails in linux last release - maybe there were one or two
21:30:09  <bnoordhuis>test-child-process-ipc <- was broken
21:30:21  <bnoordhuis>test-dgram-multicast and test-dgram-unix <- broken but expected
21:30:41  <bnoordhuis>test-net-connect-handle-econnrefused <- already broken, trivial fix
21:31:08  <bnoordhuis>test-child-process-spawn-node, test-sendfd, test-listen-fd <- broken but expected
21:31:24  <bnoordhuis>make that last one 'already broken'
21:33:12  <ryah>this is without NODE_USE_UV, right ?
21:33:50  * brsonjoined
21:36:24  <bnoordhuis>ryah: with
21:36:39  <ryah>bnoordhuis: oh - i was running without
21:36:51  <ryah>i only care about test-uv with NODE_USE_UV=1
21:36:51  <bnoordhuis>haha okay, i'll retest
21:36:54  <ryah>:)
21:37:13  <ryah> - 29 is pretty good with NODE_USE_UV=1 :D
21:37:43  <DrPizza>ryah: did you get that double pipe test to work?
21:38:07  <ryah>DrPizza: i stopped working on it
21:38:11  <DrPizza>heh
21:38:54  <ryah>DrPizza: it works on unix now with --use-uv
21:39:00  <ryah>the tests needs to be ported to windows
21:39:56  <piscisaureus>igorzi: there is a small problem - when I use MSG_PEEK closesocket() doesn't abort the operation
21:40:07  <ryah>DrPizza: here's where i left off https://gist.github.com/1169327
21:40:24  <ryah>DrPizza: i also wanted to port the test to libuv too
21:40:39  <DrPizza>ryah: that might be a good thing to do
21:40:57  <DrPizza>at the very least, it should make debugging a bit simpler
21:46:39  <igorzi>piscisaureus: hmm, maybe that's the limitation with overlapped sockets.. i'll let you know once i know more about this
21:50:32  <bnoordhuis>ryah: [11:55|% 100|+ 540|- 3] <- linux without uv
21:51:17  <bnoordhuis>one of the failing ones is test-net-server-max-connections.js and that's a bad (race-y) test to start with
21:52:33  <ryah>bnoordhuis: good
21:52:39  <ryah>bnoordhuis: what's the other two?
21:53:33  <bnoordhuis>ryah: test-process-wrap and test-keep-alive
21:53:40  <ryah>piscisaureus, igorzi: i don't want to distract from the multiplicity stuff - can we punt on the MSG_PEEK stuff until next week?
21:54:04  <ryah>multiplicity is just so time critical
21:55:05  <bnoordhuis> 713 Command: out/Release/node /home/bnoordhuis/src/nodejs/node/test/simple/test-process-wrap.js
21:55:05  <bnoordhuis> 714 --- CRASHED ---
21:55:12  <bnoordhuis>can't reproduce it on the cli though
21:58:34  <igorzi>piscisaureus: i can't repeat it.. i queue WSARecv with MSG_PEEK, then do closesocket, and i get a completion packet from iocp
21:58:53  <piscisaureus>igorzi: i may be doing something stupid then
21:59:01  <igorzi>(i'm on 2k8)
21:59:19  <igorzi>piscisaureus: are you getting completion packets when data arrives?
22:00:57  <bnoordhuis>test-keep-alive consistently works from the cli as well :/
22:01:01  <piscisaureus>igorzi: yes
22:01:21  <piscisaureus>igorzi: although they report STATUS_BUFFER_OVERFLOW because the message is truncated
22:01:25  <piscisaureus>(doesn't fit in 0 bytes)
22:03:21  <bnoordhuis>test-keep-alive isn't a great test either... runs ab in normal and keep-alive mode and normal reqs/s < keep-alive reqs/s
22:03:38  <bnoordhuis>that doesn't work well if the system is under load
22:04:16  <bnoordhuis>s/and normal/and checks that normal/
22:04:51  <bnoordhuis>sunos is in poorer shape though: [13:45|% 100|+ 535|- 11]
22:05:15  <igorzi>piscisaureus: right, that's expected.. you should be able to read the message with another WSARecvFrom
22:05:29  <piscisaureus>yes
22:05:36  <piscisaureus>igorzi: hmm
22:05:46  <piscisaureus>it looks like the problem is a little different
22:05:53  <piscisaureus>MSG_PEEK completes once
22:05:59  <piscisaureus>then I post another one that never completes
22:06:55  <igorzi>ohh
22:08:06  <piscisaureus>heh
22:08:09  <piscisaureus>igorzi: got it!
22:08:10  <piscisaureus>:-)
22:10:33  <igorzi>what was it?
22:11:20  <piscisaureus>igorzi: so
22:12:01  <piscisaureus>The second WSARecv sets the overlapped.Internal value to STATUS_BUFFER_OVERFLOW
22:12:42  <piscisaureus>but somehow it is till expected that a post will be made to the completion port
22:13:18  <piscisaureus>this probably does not happen, since WSARecv returned an error
22:15:07  * isaacschanged nick to isaacs[away]
22:15:17  <igorzi>when WSARecv returns overlapped.Internal is set to STATUS_BUFFER_OVERFLOW?
22:15:24  <piscisaureus>yes
22:15:37  <piscisaureus>but somehow GetLastError() == ERROR_IO_PENDING :-/
22:16:27  <piscisaureus>maybe it is already updated by the kernel by the time I look at the Internal value
22:16:46  <piscisaureus>e.g. the operation completes between the WSARecv and the printf call
22:18:58  <igorzi>piscisaureus: i can't repeat that either.. i do WSARecv with MSG_PEEK, wait for iocp packet, read with WSARecvFrom; then do the same thing over again, and i get another iocp packet
22:20:09  <piscisaureus>igorzi: what if you send first, then call wsarecv
22:20:22  <piscisaureus>so that by the time wsarecv is called there is something in the kernel buffer
22:20:44  <piscisaureus>oh and use SetFileHandleNotificationModes
22:22:05  <CIA-75>node: Ben Noordhuis master * raccc34c / test/simple/test-eval.js :
22:22:05  <CIA-75>node: test: fix simple/test-eval
22:22:05  <CIA-75>node: Test expects output of console.error(process.argv) to be spread out
22:22:05  <CIA-75>node: over several lines but if /path/to/node is short, it stays on a single line. - http://git.io/1Le0Xw
22:23:33  <piscisaureus>igorzi: when I disable SetFileCompletionNotificationModes then it works fine
22:23:47  <ryah>bnoordhuis++
22:24:31  <DrPizza>piscisaureus: is the issue here that the operating system thinks it's acceptable to suppress teh iocp alert (i.e. operation completed immediately) but you're still getting told "the IO is pending, you should expect iocp activity"?
22:24:42  <piscisaureus>yes
22:24:45  <piscisaureus>exactly
22:24:56  <DrPizza>that sounds broken
22:26:16  <ryah>def GetFlavor(params): """Returns |params.flavor| if it's set, the system's default flavor else.""" return params.get('flavor', 'mac' if sys.platform == 'darwin' else 'linux')
22:26:22  <ryah>^-- sigh
22:26:32  <igorzi>piscisaureus: ahh, i was running without SetFileHandleNotificationModes
22:26:55  <piscisaureus>igorzi: DrPizza: some windows source code below
22:26:55  <piscisaureus> case STATUS_BUFFER_OVERFLOW:
22:26:55  <piscisaureus> if ( lpOverlapped ) {
22:26:55  <piscisaureus> err = WSA_IO_PENDING;
22:26:55  <piscisaureus> goto exit; // bypass setting NumberOfBytesRead
22:26:55  <piscisaureus> }
22:26:55  <piscisaureus> err = WSAEMSGSIZE;
22:26:56  <piscisaureus> break;
22:27:07  <piscisaureus>^-- WSPRecv implementation
22:27:20  <piscisaureus>so it forcibly sets err to WSA_IO_PENDING
22:27:38  <DrPizza>what's the actual function called to disable the IOCP callbacks
22:27:50  <piscisaureus>DrPizza: SetFileHandleNotificationModes
22:27:52  <DrPizza>it seems strange to hit STATUS_BUFFER_OVERFLOW if you're peeking anyway
22:28:04  <DrPizza>piscisaureus: ?? http://social.msdn.microsoft.com/Search/en-us?query=SetFileHandleNotificationModes&x=0&y=0
22:28:40  <piscisaureus>DrPizza: sorry. SetFileCompletionNotificationModes
22:28:52  <DrPizza>ah
22:30:04  <DrPizza>well
22:30:11  <DrPizza>it certainly doesn't mesh with the documentation then
22:30:39  <igorzi>well, documentation says MSG_PEEK doesn't work with overlapped... so, some of it might be true
22:30:44  <DrPizza>ohhh
22:30:58  <DrPizza>if you do a non-peeking zero read, do you lose the data entirely?
22:31:09  <igorzi>yeah
22:32:46  <DrPizza>does udp support MSG_PARTIAL?
22:33:03  <igorzi>DrPizza: no
22:33:52  <igorzi>piscisaureus: so do you want to check overlapped.Internal for STATUS_BUFFER_OVERFLOW if you get IO_PENDING from WSARecv?
22:34:40  <piscisaureus>igorzi: that won't work
22:34:46  <piscisaureus>it introduces a race condition
22:34:55  <DrPizza>does it?
22:35:03  <DrPizza>does WSARecv not update .Internal directly?
22:35:44  <piscisaureus>igorzi: Drpizza: because it could also happen that the request *is* overlapped but the kernel updates Internal before the check
22:36:41  <DrPizza>so you think it could flip from status_buffer_overflow to some other status, but still not post the completion notification?
22:36:47  <igorzi>piscisaureus: then i guess you need to decide what's more important for udp - 0-reads or no-iocp shortcut
22:37:01  <piscisaureus>igorzi: this will also affect non-0 reads
22:37:12  <piscisaureus>but only if those result in STATUS_BUFFER_OVERFLOW
22:37:56  <piscisaureus>which doesn't happen so often (since it only happens when the datagram is bigger than the read buffer size)
22:39:28  <piscisaureus>So I think we should disable SetFileCompletionNotificationModes for udp sockets
22:39:44  <igorzi>piscisaureus: yeah, i agree.. how big is your read buffer? 64K?
22:40:02  <piscisaureus>igorzi: in the tests its 64k
22:40:05  <piscisaureus>but the users decides
22:40:31  <piscisaureus>the buffer size is determined in the alloc_cb callback
22:40:38  <igorzi>but the hint that goes into alloc_cb is 64K?
22:40:47  <piscisaureus>right now it is, yes
22:40:54  <igorzi>maybe that should be SO_MAX_MSG_SIZE
22:41:18  <piscisaureus>which probably is 64k :-)
22:41:32  <igorzi>probably :)
22:41:52  <piscisaureus>there may be a loophole
22:43:03  <piscisaureus>the iostatusblock->Information contains the number of bytes read
22:43:09  <piscisaureus>hmm
22:43:15  * piscisaureusthinking
22:44:19  <piscisaureus>would WSARecv somehow leak it's completion status?
22:50:19  <piscisaureus>hmm
22:50:24  <piscisaureus>can't think of anything
22:50:56  <piscisaureus>igorzi: I think we should go without SetFileCompletionNotificationMode
22:51:01  <piscisaureus>do you agree?
22:51:09  <DrPizza>o wow
22:51:10  <CIA-75>node: Ben Noordhuis master * r8f24548 / src/node_net.cc :
22:51:10  <CIA-75>node: net: fix multicast on sunos
22:51:10  <CIA-75>node: setsockopt(IP_MULTICAST_TTL|IP_MULTICAST_LOOP) takes an unsigned char as
22:51:10  <CIA-75>node: its argument on sunos.
22:51:10  <CIA-75>node: Partially fixes simple/test-dgram-multicast: test hangs after socket
22:51:11  <CIA-75>node: close but it no longer throws EINVAL exceptions. - http://git.io/Lm3PTQ
22:51:11  <DrPizza>steve jobs is dead
22:51:16  <DrPizza>or as good as.
22:51:55  <piscisaureus>. // Determine the completion status. In the overlapped
22:51:55  <piscisaureus>. // STATUS_BUFFER_OVERFLOW case we return PENDING rather
22:51:55  <piscisaureus>. // than an error because the completion routine/etc will
22:51:55  <piscisaureus>. // still get called, and we don't want to confuse the app.
22:51:55  <bnoordhuis>three posts on the HN homepage and counting!
22:52:06  <piscisaureus>^-- windows source code
22:52:11  * ryahsells his apple stock
22:52:25  <ryah>jk i dont have apple stock
22:52:36  <piscisaureus>I'm afraid that didn't get updated after SetFileCompletionNotificationMode was introduced
22:52:36  * ryahbuys msft stock
22:52:50  <piscisaureus>igorzi: --^
22:54:31  <igorzi>heh
22:55:29  <piscisaureus>you should probably file a bug :-)
22:55:32  <piscisaureus>not that it helps us
22:56:18  <CIA-75>node: Ryan Dahl master * rf9dae9e / node.gyp : Add dgram_legacy and dgram_uv to node.gyp - http://git.io/sTWqkg
22:56:26  <igorzi>piscisaureus: yeah, I'll bring it up.. but, yeah i think we should just go without SetFileCompletionNotificationMode
23:00:05  <ryah>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(1151,5): warning MSB8012: TargetPath(C:\Users\ryan\node\Release\v8_nosnapshot.lib) does not match the Library's OutputFile property value (C:\Users\ryan\node\Release\lib\v8_nosnapshot.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
23:00:18  <ryah>^-- do you guys know this problem?
23:00:55  <piscisaureus>yes, but I don't know how to solve it
23:00:56  <DrPizza>yes
23:00:59  <DrPizza>it's a gyp problem
23:01:04  <ryah>ok
23:01:05  <DrPizza>I "fixed" it by removing the parts of gyp
23:01:16  <DrPizza>but updating gyp has reinstated them
23:03:48  <piscisaureus>udp_packet_storm_1v1: 88887/s received, 88887/s sent
23:03:49  <piscisaureus>udp_packet_storm_10v1: 86365/s received, 86365/s sent
23:03:49  <piscisaureus>udp_packet_storm_100v1: 90793/s received, 90793/s sent
23:03:49  <piscisaureus>udp_packet_storm_1000v1: 95583/s received, 95585/s sent
23:03:49  <piscisaureus>udp_packet_storm_10v10: 84430/s received, 84428/s sent
23:04:00  <piscisaureus>^-- after removing the notification mode
23:04:05  <piscisaureus>terrible regression :-/
23:04:18  <ryah>DrPizza: https://gist.github.com/43202fe62b2226167a88 ?
23:05:10  * piscisaureuscries
23:05:28  * piscisaureusdemands a hotfix
23:06:04  <igorzi>how big is the regression?
23:06:31  <igorzi>piscisaureus: ---^
23:06:50  <piscisaureus>19:47:25 <piscisaureus> udp_packet_storm_1v1: 118170/s received, 120190/s sent
23:06:51  <piscisaureus>19:47:25 <piscisaureus> udp_packet_storm_10v1: 119180/s received, 121200/s sent
23:06:51  <piscisaureus>19:47:25 <piscisaureus> udp_packet_storm_100v1: 118170/s received, 120190/s sent
23:06:51  <piscisaureus>19:47:25 <piscisaureus> udp_packet_storm_1000v1: 117160/s received, 119180/s sent
23:06:51  <piscisaureus>19:47:25 <piscisaureus> udp_packet_storm_10v10: 123222/s received, 125240/s sent
23:06:57  <piscisaureus>^-- yesterday's results
23:07:27  <DrPizza>ryah: yes, everything lib related
23:07:35  <DrPizza>ryah: the big one in the middle may not be necessary
23:07:59  <piscisaureus>igorzi: --^
23:08:01  <DrPizza>ryah: problem is, I assume google actually wants libraries to go into output-dir/lib rather than just into output-dir
23:08:08  <DrPizza>ryah: I don't know why, but that's what their code is doing
23:08:53  <ryah>windows build is totally broken right now btw
23:09:00  <ryah>but working on it
23:09:18  <piscisaureus>ryah: uv or node
23:09:34  <ryah>node
23:09:53  * mralephquit (Quit: Leaving.)
23:11:13  <piscisaureus>igorzi: we may be able to bring perf back btw by doing multiple nonblocking reads after overlapped read btw
23:11:18  <piscisaureus>let's try that
23:12:26  <igorzi>piscisaureus: oh, i see.. is that also going to starve the message loop?
23:12:54  <piscisaureus>igorzi: heh that problem is "solved" now
23:13:20  <piscisaureus>igorzi: because writes always go through the iocp now
23:13:24  <piscisaureus>hmm that's bad actually
23:13:51  <piscisaureus>okay another idea
23:13:53  <piscisaureus>status = NtDeviceIoControlFile(
23:13:53  <piscisaureus> socket->HContext.Handle,
23:13:53  <piscisaureus> event,
23:13:53  <piscisaureus> apcRoutine,
23:13:53  <piscisaureus> apcContext,
23:13:53  <piscisaureus> ioStatusBlock,
23:13:53  <piscisaureus> IOCTL_AFD_RECEIVE_DATAGRAM,
23:13:54  <piscisaureus> &recvInfo,
23:13:54  <piscisaureus> sizeof(recvInfo),
23:13:55  <piscisaureus> NULL,
23:13:55  <piscisaureus> 0
23:13:56  <piscisaureus> );
23:14:03  <piscisaureus>... instead of WSARecv?
23:14:40  <DrPizza>lol
23:14:47  <DrPizza>so that you don't have to go through the error checking?
23:14:52  <DrPizza>the WSARecv error checking
23:15:06  <piscisaureus>Bypassing the the broken WSARecv error checking, yeah
23:15:13  <piscisaureus>we can do it right
23:15:58  <DrPizza>where is the win2000 source file you're looking at?
23:16:00  <DrPizza>url
23:16:01  <piscisaureus>yes
23:16:13  <piscisaureus>this still works for 7 though
23:16:15  <piscisaureus>I tried it
23:16:30  <DrPizza>what is the url
23:17:08  <piscisaureus>DrPizza: google for SockNtStatusToSocketErro
23:17:11  <piscisaureus>DrPizza: google for SockNtStatusToSocketError
23:20:39  <CIA-75>node: Ryan Dahl master * r06f750c / (node.gyp src/udp_wrap.cc): fix windows build - http://git.io/Exoshg
23:24:02  <CIA-75>node: Ryan Dahl master * r48918f5 / tools/gyp/pylib/gyp/generator/msvs.py :
23:24:02  <CIA-75>node: Reapply Peter Bright's fixes for GYP on MSVS
23:24:02  <CIA-75>node: Originally 71333b3f5b12183b2709704fec160df916cb637a - http://git.io/Q3bCbw
23:25:25  <ryah>^-- windows people, please test the windows build
23:27:46  <bnoordhuis>Error: This version of sunos doesn't support getifaddrs <- we should fix that sometime
23:28:43  <ryah>bnoordhuis: the box i got you is really old
23:28:59  <ryah>soon we'll have smartos
23:29:08  <bnoordhuis>okay, so it doesn't matter?
23:29:11  <ryah>no
23:29:19  <bnoordhuis>cool
23:29:41  <ryah>if everything goes well with no.de this weekend we should be able to provision new smartos machines easily
23:30:11  <bnoordhuis>so it's nearly finished?
23:30:26  <ryah>isaacs is doing the final touches now
23:30:50  <isaacs[away]>it's mostly working
23:30:50  <bnoordhuis>that's rad
23:30:59  <ryah>http://isaacs-testing-hostrouter-again.no.de/ :)
23:31:03  <isaacs[away]>networking is hard
23:31:07  <isaacs[away]>:)
23:31:15  <ryah>i still think that logo is too big
23:31:22  <ryah>its so in my face
23:37:21  <ryah>[03:36|% 100|+ 177|- 11]: Done
23:37:24  <ryah>^--- Win7
23:37:46  <ryah>python tools/test.py --libuv
23:38:09  <bnoordhuis>progress!
23:41:22  <ryah>[01:53|% 100|+ 183|- 5]: Done <-- OSX, NODE_USE_UV=1 python tools/test.py --libuv
23:41:25  <DrPizza>ryah: I got some PR from joyent about node today
23:41:30  <DrPizza>your company is spamming me!
23:42:11  <piscisaureus>DrPizza: you're a journalise
23:42:15  <piscisaureus>*journalist
23:42:19  <DrPizza>piscisaureus: yeah I know :)
23:42:21  <piscisaureus>spamming you is alloowed
23:42:24  <DrPizza>:(
23:43:55  <ryah>somehow test/simple/test-net-pingpong.js stopped working on Windows
23:43:58  <ryah>that's a little strange.
23:44:09  <ryah>it just hangs at the end
23:44:18  <piscisaureus>which?
23:44:30  <piscisaureus>I mean, pipe or tcp
23:44:52  <ryah>it's the pipe
23:45:42  <DrPizza>man
23:45:47  <DrPizza>what's the incantation to delete a remote branch
23:45:50  <DrPizza>I can never remember it
23:45:55  <DrPizza>it always seems to make no sense whenever I use it
23:45:58  <ryah>DrPizza: git push origin :branch
23:46:05  <DrPizza>oh right yes
23:46:09  <DrPizza>cheers
23:46:59  <ryah>piscisaureus: any idea why that might be hanging?
23:47:05  <isaacs[away]>ryah: big is good. it's like PUSH SOME CODE!!
23:48:17  <ryah>piscisaureus: i can try to bisect it if you'd like
23:49:01  <bnoordhuis>[18:42|% 100|+ 538|- 8] <- sunos again, slightly better
23:49:09  <piscisaureus>piscisaureus: no idea
23:49:11  <piscisaureus>er
23:49:32  <piscisaureus>ryah: no idea. it works for me but I am still on 19ff87a9d
23:49:43  <ryah>bnoordhuis: !!
23:49:46  <ryah>~/node> ./Release/node.exe test/simple/test-dgram-udp4.js
23:49:46  <ryah>node.js:205
23:49:46  <ryah> throw e; // process.nextTick error, or 'error' event on first tick
23:49:46  <ryah> ^
23:49:46  <ryah>Error: getsockname UNKNOWN
23:49:48  <ryah> at errnoException (dgram_uv.js:310:11)
23:49:51  <ryah> at Socket.address (dgram_uv.js:219:11)
23:49:53  <ryah> at Socket.<anonymous> (c:\Users\ryan\node\test\simple\test-dgram-udp4.js:44:
23:49:56  <ryah>24)
23:50:13  <bnoordhuis>ehm... piscisaureus, ideas?
23:50:49  <bnoordhuis>or wasn't that strack trace meant for me, ryah?
23:51:10  <piscisaureus>bnoordhuis: is there a test for getsockname in libuv?
23:51:13  <ryah>just mentioning it
23:51:29  <bnoordhuis>piscisaureus: yes, test-getsockname
23:51:57  <piscisaureus>does that test udp?
23:52:14  <piscisaureus>oh hmm
23:52:17  <bnoordhuis>no, just tcp
23:52:34  <piscisaureus>ryah: can you try getsockname after binding the socket?
23:53:53  <ryah>the style in these udp tests is awful
23:54:08  * ryahsquints at pual
23:55:18  <ryah>piscisaureus: same
23:55:23  <bnoordhuis>[11:52|% 100|+ 546|- 0] <- linux, huzzah!
23:55:29  <ryah>bnoordhuis++
23:55:58  <ryah>piscisaureus: i'll fix the getsockname if you can lend a hand with test-net-pingpong
23:56:05  <piscisaureus>ok
23:57:59  <bnoordhuis>piscisaureus: want me to add a udp test to test-getsockname?
23:59:20  <ryah>bnoordhuis: would be good
23:59:59  <igorzi>ryah: what was that issue with stat that you wanted me to look at (when doing eio)?