00:00:33  <igorzi>https://github.com/joyent/node/issues/1565 ?
00:01:00  <ryah>igorzi: yeah
00:01:27  <piscisaureus>bnoordhuis: yeah +1
00:01:47  <bnoordhuis>cool, will do
00:04:32  <ryah>how do i start the msvs debugger with arguments?
00:04:50  <piscisaureus>ryah: right click the startup project
00:04:52  <piscisaureus>properties
00:04:56  <piscisaureus>debugging
00:06:25  <ryah>got it - thanks
00:06:42  <ryah>this whole visual debugging thing is hilarious
00:08:12  <piscisaureus>why?
00:08:42  <ryah>doesn't seem like anyone would use it
00:08:56  <piscisaureus>you can still use gdb if you want to
00:09:00  <piscisaureus>just build with mingw
00:09:15  <igorzi>ryah: you can use windbg now too
00:09:20  <ryah>true - but im excited to try msvs
00:09:59  <DrPizza>igorzi: lol!
00:10:08  <DrPizza>igorzi: I love how you try to sell that as a feature :p
00:10:27  <DrPizza>ryah: the debugger is perhaps the biggest single reason anyone uses visual studio
00:10:47  <igorzi>DrPizza: :).. i tried gdb, and i'm very happy to be able to use windbg now
00:11:02  <DrPizza>igorzi: oic I've been using MSVS for weeks
00:11:33  <ryah>http://tinyclouds.org/debugging-windows.png
00:11:35  <ryah>:D
00:11:47  <ryah>i feel like a real windows dev now
00:11:52  <DrPizza>lol
00:12:19  * ryahbrowses various menus
00:12:23  <ryah>hehe
00:14:46  <bnoordhuis>:)
00:15:05  <igorzi>ryah: you should try writing some c# :)
00:16:38  <piscisaureus>igorzi: what do you think about NtDeviceIoControlFile(IOCTL_AFD_RECEIVE_DATAGRAM) btw?
00:16:49  <DrPizza>c# is becoming a very strange language
00:16:53  <DrPizza>it doesn't really know what it wants to be
00:17:11  <DrPizza>it's gaining some quite interesting features (lambdas, yield, async)
00:17:30  <DrPizza>but is IMO hamstrung by bad backwards compatibility decisions and C-esque syntax
00:18:08  <ryah>erik meijer was here the other day showing off some event stream c# stuff
00:18:13  <ryah>looked pretty awesome
00:18:19  <DrPizza>is that using StreamInsight?
00:18:26  <igorzi>ryah: on nice
00:18:30  <DrPizza>or just some C#' thing?
00:19:00  <ryah>http://msdn.microsoft.com/en-us/library/hh242985(v=VS.103).aspx <-- this
00:19:31  <DrPizza>aaah
00:19:32  <DrPizza>Rx
00:19:42  <ryah>how do you evaluate a variable in msvs?
00:19:45  <DrPizza>yeah, Rx is another thing which is kind of weird
00:19:50  <ryah>when you're stopped on a break point
00:19:56  <DrPizza>ryah: mouse over it, look at it in the autos/locals/watch window
00:20:12  <DrPizza>ryah: type its name in the immediates window
00:20:34  <piscisaureus>yes how can you miss that theres a zillion ways to do that
00:20:37  <piscisaureus>:-/
00:20:44  <igorzi>piscisaureus: i don't know.. not too fond of it.. there might be other things that won't work if we go down that path
00:20:59  <DrPizza>igorzi: what MS really needs to do is to make the VC++ immediates/commands window use windbg behind the scenes, so you get the good looks of MSVS with all the windbg extensions and capabilities
00:21:09  <piscisaureus>igorzi: it's degenerate I agree
00:21:21  <piscisaureus>igorzi: but what do you think will break?
00:21:22  <ryah>and if i have an errno - how do i find out what symbol goes with it?
00:21:34  <ryah>(normally i'd grep /usr/include/sys/errno.h)
00:21:34  <piscisaureus>a windows errno?
00:21:36  <ryah>yeah
00:21:44  <DrPizza>ryah: grep winerror.h
00:21:47  <DrPizza>I think that's the filename
00:21:52  <DrPizza>something like that
00:21:53  <piscisaureus>ryah: http://msdn.microsoft.com/en-us/library/ms681381%28v=VS.85%29.aspx
00:22:10  <ryah>oh that's useful
00:22:12  <DrPizza>ryah: find something that says ERROR_IO_PENDING, right click, go to definition
00:22:13  <DrPizza>then grep that file
00:22:15  <DrPizza>or look on MSDN
00:23:31  <DrPizza>piscisaureus: does the iocontrol route work?
00:24:24  <piscisaureus>DrPizza: it did for tcp sockets
00:24:28  <piscisaureus>didn't try with udp
00:24:51  <igorzi>piscisaureus: don't know, like you said it doesn't look like they did the work to make it work with SetFileCompletionNotificationModes.. you just found one issue with it, but there may be more
00:25:15  <DrPizza>igorzi: it sounds like they did do the work, since it isn't sending the notification
00:25:22  <piscisaureus>igorzi: yeah, we'll find it out :-)
00:25:27  <DrPizza>igorzi: they just didn't make the userland wrapper process the error codes properly
00:25:28  <DrPizza>no?
00:26:09  <piscisaureus>yes there's this strange hack that turns STATUS_BUFFER_OVERFLOW into WSA_IO_PENDING
00:26:10  <igorzi>DrPizza: that can be accomplished with a VS extension.. i've seen one here, there may be others out there
00:26:22  <DrPizza>igorzi: orly, sounds interesting
00:26:55  <piscisaureus>hey msvs gurus
00:27:00  <piscisaureus>can I switch to another thread
00:27:04  <piscisaureus>so I can see it's stack
00:27:10  <DrPizza>piscisaureus: sure, double click it in the threads window
00:27:25  * piscisaureusrolls eyes
00:27:33  <DrPizza>lol
00:27:43  <piscisaureus>no threads window on my screen
00:28:23  <piscisaureus>oh man there's a dropdown in the toolbar
00:28:30  <DrPizza>haha
00:28:30  <igorzi>ctl+alt+H
00:28:37  <DrPizza>yeah get the window open
00:28:41  <DrPizza>so you can freeze threads etc.
00:28:48  <piscisaureus>oh nice
00:28:51  <piscisaureus>thanks igorzi
00:29:51  <ryah>using this debugger is really making be feel bad. how do you guys work like this?
00:30:02  <DrPizza>wow
00:30:03  <ryah>i guess im just missing all the short cuts
00:30:11  <DrPizza>using gdb makes me want to throw my computer out the window
00:30:13  <ryah>but it seems so slow to use
00:30:15  <DrPizza>I don't know how people use that!
00:30:27  <piscisaureus>slow?
00:30:33  <piscisaureus>you mean like wait long times?
00:30:43  <ryah>like i have to move my hand to the mouse, scroll down
00:30:46  <ryah>scroll up
00:30:50  <ryah>hover over something
00:31:03  <piscisaureus>learn the shortcuts yeah
00:31:13  <igorzi>ryah: you should give windbg (or cdb) a try
00:31:17  <bnoordhuis>piscisaureus: https://github.com/bnoordhuis/libuv/commit/21451df <- udp test
00:31:40  <bnoordhuis>ollydbg!
00:31:45  <bnoordhuis>just saw a new release
00:32:14  <DrPizza>ryah: my mousing hand is normally on the mouse anyway
00:32:30  <bnoordhuis>you type with one hand?
00:32:42  <DrPizza>bnoordhuis: I don't type in the debugger, generally
00:32:59  <bnoordhuis>i do
00:33:06  <bnoordhuis>i like that gdb is pretty scriptable
00:34:34  <ryah>igorzi: next bug i fix i'll use windbg
00:34:38  <piscisaureus>ah, I think where the pipe breaks
00:35:09  <bnoordhuis>pquerna: http://apache.slashdot.org/story/11/08/24/2213201/Apache-Warns-Web-Server-Admins-of-DoS-Attack-Tool
00:36:56  <pquerna>hrm, geuss i should read the security list :)
00:38:03  <pquerna>range filter --
00:38:47  * graydonquit (Quit: Leaving.)
00:40:06  <igorzi>ryah: piscisaureus: some eio functions allocate buffers (to store results), which are owned by eio.. in case of async call - eio frees the buffer after dispatching the callback. since we'll support sync and async functions in libuv, i was thinking that we let libuv allocate the buffer, but then the caller needs to free it
00:40:12  <igorzi>what do you think?
00:40:50  <CIA-75>libuv: Ryan Dahl master * r40efa9c / (src/win/handle.c src/win/udp.c): win: Fix uv_getsockname for UDP - http://git.io/comgBg
00:41:04  <DrPizza>can't uv free it?
00:41:43  <piscisaureus>ryah: sorry
00:41:48  <piscisaureus>that was 5:30am work
00:41:52  <piscisaureus>yesterdat
00:42:03  <igorzi>it can for async, but not for sync (unless we require uv_close_req or something)
00:42:11  <ryah>piscisaureus: that's why you should go to bed earlier :)
00:42:30  <DrPizza>igorzi: oh right because sync has no callback it just returns with a buffer
00:42:37  <igorzi>right
00:42:38  <DrPizza>sorry, was forgetting that
00:43:59  <CIA-75>node: Ryan Dahl master * r90da533 / (5 files in 4 dirs): Upgrade libuv to 40efa9c - http://git.io/0YOz0w
00:46:59  <ryah>is it just me or does the msvs build take a LONG time?
00:47:14  <piscisaureus>just you?
00:47:21  <piscisaureus>for me it's much faster than mingw
00:47:27  <piscisaureus>especially building v8
00:47:56  <ryah>~/node> ./Release/node.exe test/simple/test-dgram-udp4.js
00:47:56  <ryah>server is listening on 0.0.0.0:20989
00:47:57  <ryah>client wrote 17 bytes.
00:47:57  <ryah>server got: A message to send from 127.0.0.1:64247
00:47:58  <ryah>client got: A message to send from 127.0.0.1:20989
00:48:24  <ryah>(works)
00:49:20  <piscisaureus>hmm
00:49:39  <piscisaureus>node.js:205
00:49:39  <piscisaureus> throw e; // process.nextTick error, or 'error' event on first tick
00:49:39  <piscisaureus> ^
00:49:39  <piscisaureus>Error: read UNKNOWN
00:49:39  <piscisaureus> at errnoException (net_uv.js:564:11)
00:49:40  <piscisaureus> at Pipe.onread (net_uv.js:333:20)
00:49:48  <piscisaureus>^-- happens on EOF :-/
00:50:13  <piscisaureus>and the uv_last_error().code == UV_EOF really
00:51:31  * isaacs[away]changed nick to isaacs
00:53:20  <ryah>piscisaureus: could be related to this change: cf2e68d960750dbe36367463168764d7a32ddcb9
00:53:43  <piscisaureus>ah
00:53:49  <piscisaureus>yeah I can see that it fails there
00:53:53  <piscisaureus>let me track that down too
00:54:27  <ryah>piscisaureus: this pipe thing is also breaking test/simple/test-repl.js, i think
00:56:59  <ryah>it's really unfortunate that windows uses backslashes for paths
00:57:10  <ryah>since they are the escape character..
00:57:25  * piscisaureuscalls bill again
00:57:38  <DrPizza>ryah: node needs to provide a path delimiter so that paths can be built up in user code in a platform independent way
00:57:46  <DrPizza>fs.DIRECTORY_SEPARATOR
00:57:53  <ryah>DrPizza: sure
00:57:57  <piscisaureus>bill thinks forward slashes should have been the directory separator
00:58:10  <piscisaureus>ryah: Igorzi: windows can deal with / just fine
00:58:12  <piscisaureus>use that
00:58:19  <piscisaureus>er
00:58:22  <DrPizza>no, windows cannot deal with / "just fine"
00:58:22  <CIA-75>libuv: Ben Noordhuis master * r738e2da / (test/test-getsockname.c test/test-list.h): test: add udp getsockname test - http://git.io/LKWGxQ
00:58:31  <DrPizza>_most_ bits of Windows can deal with / _most_ of the time
00:58:40  <DrPizza>but LFNs (> MAX_PATH) cannot
00:58:46  <piscisaureus>DrPizza: like, which bit?
00:58:58  <piscisaureus>oh really
00:59:02  <piscisaureus>we should replace that then
00:59:02  <DrPizza>long paths, \\?\ style ones, must use backslashes
00:59:09  <piscisaureus>oh yeah
00:59:22  <piscisaureus>long paths must also prepend \\?\
00:59:29  <piscisaureus>we should deal with that in libuv
00:59:32  <DrPizza>I think they may have some extra constraints, like not allowing internal ..\ as well
00:59:45  <piscisaureus>maybe not double \\ too
00:59:53  <DrPizza>so they must be full absolute paths
01:00:12  <piscisaureus>DrPizza: we also have path.resolve etc
01:00:19  <piscisaureus>irons the path
01:01:52  <DrPizza>I do wonder sometimes if Java's rather verbose file handling is the right model to follow.
01:01:55  <piscisaureus>I like that msvc knows to rebuild node_javascript when a .js has changed
01:02:05  <piscisaureus>gyp++
01:02:06  <DrPizza>the Java File class is not a file
01:02:13  <DrPizza>it is an abstracted notion of filename with path
01:02:28  <DrPizza>and contains various operations for constructing paths and files in a platform-independent way
01:03:23  <ryah>[12:45|% 100|+ 544|- 2]: Done <-- OSX, make test-all
01:03:26  <piscisaureus>ryah: it looks like errno is not defined in net_uv.js
01:03:36  <bnoordhuis>piscisaureus: it's set in node.cc
01:03:43  <ryah>piscisaureus: errno is set in C++
01:03:59  <piscisaureus>er i should go bed
01:04:15  <DrPizza>lol
01:05:24  <ryah>piscisaureus: yes go to sleep :)
01:11:58  * rmustaccpart
01:13:39  <ryah>~/node> fsutil.exe file createnew "c:\Users\ryan\node\test\tmp\big" 10485760
01:13:40  <ryah>The FSUTIL utility requires that you have administrative privileges.
01:13:43  <ryah>groan
01:13:50  <ryah>nothing can ever be easy, can it?
01:14:10  <DrPizza>hmm
01:14:24  <DrPizza>that's a bit annoying
01:14:30  <DrPizza>since that particular operation obviously doesn't need privileges
01:15:03  <ryah>we should just write some utilities in python
01:15:22  <DrPizza>yes, that would probably be easiest
01:21:12  <piscisaureus>ryah: okay, I am going to bed
01:21:19  <piscisaureus>I have figured out what was wrong with the pipe
01:21:41  <piscisaureus>it boils down to it being impossible to shutdown a pipe on windows
01:21:53  <piscisaureus>(plus a bug)
01:22:03  <piscisaureus>ryah: we should decide what we want to do with this
01:22:28  <ryah>piscisaureus: those tests were working before - so it seems like we should be able to make them work
01:22:37  <ryah>piscisaureus: but go to bed - we'll discuss later
01:22:40  <piscisaureus>yes
01:22:44  <piscisaureus>see ya
01:23:37  <ryah>bnoordhuis: we should hold the release until this pipe bug is fixed
01:23:43  <bnoordhuis>ryah: okay
01:23:58  <bnoordhuis>sleep tight, piscisaureus
01:24:34  <bnoordhuis>ryah: moving unix dgrams into a separate module? good idea or not?
01:32:17  <piscisaureus>bnoordhuis: thanks
01:32:25  <piscisaureus>the pipe bug btw is unfixable on windows
01:32:47  <DrPizza>what's the bug?
01:32:49  <piscisaureus>of course I can make the test pass but I can easily write another valid test that will fail
01:32:58  <DrPizza>is it more to do with the inability to tell the other end that you've closed the pipe?
01:33:02  <piscisaureus>yes
01:33:17  <DrPizza>hmm yes
01:33:36  <DrPizza>is the intent still to have a kind of "IPC pipe" with a well-established protocol for shutdown?
01:33:37  <piscisaureus>basically pipes on windows should not support stream.end; just stream.destroySoon().
01:33:40  <DrPizza>(zero write)
01:33:49  <piscisaureus>won't be zero write
01:33:58  <piscisaureus>I don't want to think about that now
01:34:16  <DrPizza>hmm, I thought an un-coalesced zero write was the easiest approach
01:40:14  <DrPizza>ryah: https://github.com/joyent/node/pull/1584
01:41:22  <DrPizza>ryah: small gyp change that makes MSVS include node's .h files in its tree
02:13:19  <ryah>DrPizza: thanks
02:13:24  <CIA-75>node: Peter Bright master * r64b4168 / node.gyp : Add headers to improve the IDE experience. - http://git.io/ffM6Vw
02:14:50  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:16:25  <ryah>bnoordhuis: not sure about the unix dgram situation
02:16:36  <ryah>i don't think people really want it
02:16:43  <ryah>they just think they do
02:16:56  <ryah>which is why we should not ask them about it
02:17:00  <bnoordhuis>hah
02:18:15  <DrPizza>much better to remove features, and if people notice get them to justify their actual use case
02:18:22  <DrPizza>rather than ask them and get a load of bullshit "what-if" nonsense
02:18:44  * piscisaureusjoined
02:19:01  <ryah>our job is to provide a simple means of making network servers - i dont think unix dgrams further that goal
02:19:06  <ryah>i could be wrong
02:20:15  <bnoordhuis>cluster seems to use it for stateless communication between instances
02:20:29  <bnoordhuis>but i suppose unix stream sockets would work for that too
02:24:39  <bnoordhuis>double-checked it, stream sockets would work just as well for them
02:31:34  <ryah>suyes
02:31:39  <ryah>*yes
02:35:37  <ryah>anyway - we're going to be pulling cluster's functionality into core
02:35:59  <ryah>listen(800, { share: true }); ...etc
02:42:41  * piscisaureusquit (Ping timeout: 258 seconds)
02:48:32  * brsonquit (Ping timeout: 240 seconds)
02:58:00  * isaacsquit (Quit: isaacs)
03:18:16  <ryah>ragel is such a great piece of software
03:24:29  <bnoordhuis>hah, you think so?
03:38:38  <ryah>yeah it really changed how i think about servers
03:38:48  <ryah>thought
03:43:28  * isaacsjoined
04:40:53  * bnoordhuisquit (Ping timeout: 268 seconds)
05:32:28  <isaacs>anyone know where ssh configs get set when you're using PuTTY?
05:36:17  <DrPizza>they get put in the registry
05:40:46  <DrPizza>HKCU\Software\SimonTatham
07:39:11  * isaacsquit (Quit: isaacs)
08:02:49  * mralephjoined
08:58:15  * mralephquit (Quit: Leaving.)
09:01:34  * mralephjoined
09:13:52  * mralephquit (Quit: Leaving.)
09:34:05  * mralephjoined
09:43:29  * mralephquit (Quit: Leaving.)
10:49:02  * piscisaureusjoined
12:00:55  * bnoordhuisjoined
12:34:12  <bnoordhuis>piscisaureus: you around?
12:35:23  <piscisaureus>yay
12:35:56  <piscisaureus>but are you?
12:41:45  <piscisaureus>bnoordhuis:
12:42:06  <bnoordhuis>piscisaureus: i am
12:42:16  <bnoordhuis>feel like ripping out UV_UDP_IPV6ONLY?
12:42:36  <piscisaureus>well
12:42:37  <piscisaureus>whatever
12:42:50  <piscisaureus>I bet you can do the windows part as well
12:43:06  <bnoordhuis>removing code is always easier than writing it :)
12:43:14  <piscisaureus>exactly
12:43:14  <bnoordhuis>i'll remove the flags arg to uv_udp_bind* as well
12:43:19  <piscisaureus>good
12:43:52  <bnoordhuis>piscisaureus: what are you working on? that pipes thing?
12:44:09  <piscisaureus>bnoordhuis: the udp bug
12:44:17  <piscisaureus>bnoordhuis: the pipe thing is a design issue
12:44:30  <bnoordhuis>piscisaureus: udp bug == loop starvation issue?
12:44:34  <piscisaureus>we need to decide what to do together
12:44:51  <bnoordhuis>i want us to drink tea and eat biscuits
12:44:55  <bnoordhuis>hmm, biscuits!
12:45:07  <piscisaureus>bnoordhuis: no it is the STATUS_BUFFER_OVERFLOW problem
12:45:23  <bnoordhuis>i've probably missed that discussion
12:46:05  <piscisaureus>I can explain that but only on skype if you care
12:46:14  <bnoordhuis>hah okay, in half an hour or so?
12:46:26  <piscisaureus>whatever you like
12:46:33  <bnoordhuis>i'll ping you in a bit
13:07:33  <piscisaureus>bnoordhuis: later also okay?
13:07:42  <piscisaureus>moet mijn rijbewijs aanvragen
13:07:43  <bnoordhuis>piscisaureus: sure
13:07:55  <bnoordhuis>have fun :)
13:07:59  <piscisaureus>fun :-/
13:08:02  <piscisaureus>ja tuurlijk
13:08:42  <piscisaureus>heb jij hem eigenlijk al?
13:09:26  <bnoordhuis>nee
13:09:29  <bnoordhuis>ik heb mijn vriendin
13:11:52  <bnoordhuis>i still think deferred socket creation is a daft idea
13:12:08  <piscisaureus>claft?
13:12:18  <bnoordhuis>daft, silly, stupid, moronic
13:12:52  <bnoordhuis>there's calls to uv__udp_maybe_deferred_bind littered over the code
13:13:00  <piscisaureus>okay change it
13:13:05  <piscisaureus>but do it consistently
13:13:08  <piscisaureus>for tcp and udp
13:13:19  <bnoordhuis>whose idea was it? yours or ryah's?
13:13:20  * piscisaureusgone
13:13:26  <piscisaureus>don't recall
13:13:26  <bnoordhuis>hf piscisaureus :)
13:13:29  <piscisaureus>prolly ryah
13:14:53  <piscisaureus>I thin kthe idea was to make tcp_init unfallt unfallible
13:15:00  <piscisaureus>not sure
13:27:14  <DrPizza>yes, ryah was planning to make the inits unfailailable.
13:49:48  <ryah>i had a good idea last night
13:49:50  <ryah>:)
13:50:33  <ryah>i think i can implement it quickly. new feature for node.
13:50:56  <bnoordhuis>the suspense! it's killing me!
13:51:35  <ryah>green threads
13:51:43  <ryah>very fast ones
13:52:10  <bnoordhuis>er, like fibers?
13:52:25  <ryah>no. you'll see. i dont want to spoil it. :)
13:52:54  <bnoordhuis>consider my interest piqued
14:01:54  <ryah>piscisaureus: do you have time for a call about the pipe issue?
14:02:05  <ryah>i have a call for 1 hour, but then i should be free
14:02:40  <piscisaureus>ryah: I have time now
14:02:49  <piscisaureus>or, whenever
14:02:57  <piscisaureus>probably the next 3 hours or so at least
14:03:15  <ryah>piscisaureus: okay i'll ping you in about an hour
14:03:36  <piscisaureus>bnoordhuis: should I still explain the udp bug?
14:04:03  <bnoordhuis>piscisaureus: sure
14:04:15  <piscisaureus>okay
14:04:19  <piscisaureus>let me turn off justin bieber
14:04:22  <piscisaureus>then I'll call you
14:04:39  <bnoordhuis>i like justin bieber
14:04:46  <bnoordhuis>i'm going to get me a justin bieber haircut
15:26:01  <ryah>piscisaureus: now?
15:26:07  <ryah>bnoordhuis: want to join too?
15:26:39  <ryah>http://ldapjs.org/ <-- checkout this awesomeness
15:26:54  <ryah>(dont tweet that - still private)
15:28:22  <piscisaureus>let me turn off leekspin first
15:28:44  <piscisaureus>ryah: yeah ok
15:46:07  <piscisaureus>ryah: http://www.youtube.com/watch?v=1wnE4vF9CQ4
15:59:36  <piscisaureus>ryah: can we skype again?
15:59:42  <piscisaureus>I think a timeout trick may work
15:59:53  <piscisaureus>to do something not quite correct but reasonable
16:00:14  <piscisaureus>or hmm maybe not skype
16:00:16  <piscisaureus>it's just
16:01:33  * rmustaccjoined
16:02:06  <ryah>piscisaureus: back
16:02:09  <ryah>yes lets skype
16:02:15  <piscisaureus>what if we do this:
16:02:15  <piscisaureus>1. flush the usermode buffer and the kernel buffer
16:02:15  <piscisaureus>2. start a timer.
16:02:15  <piscisaureus> (every time we receive something we restart the timer)
16:02:15  <piscisaureus>3. after having not received something for a while,
16:02:16  <piscisaureus> - report EOF to the read callback
16:02:16  <piscisaureus> - implicitly stop reading
16:02:17  <piscisaureus> - close the pipe
16:02:17  <piscisaureus>4. the other end then sees ERROR_PIPE_BROKEN
16:02:39  <piscisaureus>5. ERROR_PIPE_BROKEN gets mapped to EOF as well
16:03:31  <ryah>the timer must be very small
16:03:41  <ryah>like 1 tick
16:04:08  <piscisaureus>maybe use uv_check for it?
16:04:17  <ryah>1. flush user space buffer, once this is done
16:04:19  <DrPizza>I don't see how any of that is safe, zero writes are a legitimate thing to do to a pipe
16:04:26  <ryah>2. queue completion packet
16:04:32  <DrPizza>how can you impose this policy on generic pipes?
16:04:51  <ryah>3. on completion packet - try to read - if you read something go to 2
16:05:02  <ryah>if not close
16:05:19  <piscisaureus>ryah: hmm
16:05:41  <piscisaureus>what if the other end needs some time to process your last write before it returns?
16:05:43  <DrPizza>if you know it's libuv on both ends, do a zero write and then wait for a zero write in response, as an ack.
16:05:53  <ryah>piscisaureus: then its fucked
16:06:16  <ryah>im guessing most pipe users have a graceful shutdown at a protocol layer
16:06:23  <piscisaureus>all of them sure
16:06:24  <ryah>so hopefully that doesn thappen
16:06:31  <piscisaureus>http is also fine
16:06:50  <piscisaureus>because the client writes everything first
16:07:05  <piscisaureus>ryah: ok
16:07:25  <piscisaureus>ryah: but I still want to expose the flush-kernel-buffer function as such
16:07:56  <piscisaureus>so desroySoon has the same semantics as http
16:07:58  <ryah>why?
16:08:04  <piscisaureus>^
16:08:16  <ryah>destroySoon = flush user buffer, close
16:08:22  <ryah>we can do that with libuv now
16:08:28  <piscisaureus>ryah: not exactly
16:08:37  <piscisaureus>ryah: tcp sockets do a graceful disconnect if you close()
16:08:44  <ryah>no
16:08:44  <piscisaureus>the kernel send buffer doesn't get discarded
16:08:47  <DrPizza>the pipe user will only say desotrySoon when they've received their "end of message" application-level data
16:08:57  <DrPizza>piscisaureus: I thought flushing was sufficient?
16:09:00  <DrPizza>to let the remote end read
16:09:05  <DrPizza>i.e. you could flush then close and it would be safe
16:09:18  <piscisaureus>ryah: for pipes the kernel send buffer gets discarded
16:09:31  <piscisaureus>DrPizza: yes it is sufficient
16:09:32  <ryah>piscisaureus: well you need to flush that on close
16:09:39  <piscisaureus>ryah: allright
16:09:39  <DrPizza>so...
16:09:44  <DrPizza>app knows it needs to tear down the pipe
16:09:44  <ryah>close should always flush the kernel send buffer
16:09:49  <DrPizza>it calls pipe.close()
16:09:53  <DrPizza>uv flushes the pipe
16:09:55  <DrPizza>and closes the handle
16:09:59  <DrPizza>and the other end is happy
16:10:07  <DrPizza>because the other end is what told the app to close it in the first place
16:10:40  <piscisaureus>ryah: okay - but flushing is pretty complicated
16:10:56  <piscisaureus>ryah: it requires to go to the thread pool etc
16:10:59  <ryah>piscisaureus: when would you not want to flush - if you have outbound data
16:11:09  <ryah>you almost never want to discard that
16:11:15  <DrPizza>flushing is always safe to do
16:11:15  <ryah>and in unix we cannot discard it
16:11:23  <DrPizza>worst case, the buffer gets discarded because the other end closes the handle
16:11:47  <ryah>uv_close = flush kernel. im sorry that windows doesn't do that automatically
16:12:20  <piscisaureus>ryah: on unix you discard with setsockopt(fd, SO_DONTLINGER, &yes) before close
16:12:27  <piscisaureus>but yeah your point is valid
16:12:34  <piscisaureus>you almost never want to do this
16:12:59  <ryah>linger is something different AFAIK
16:13:07  <piscisaureus>ryah: no
16:13:08  <ryah>that's about waiting for the fin packet of the other side
16:13:38  <ryah>whether close() should block until its recved
16:13:48  <piscisaureus>ryah: there are several linger options
16:14:55  <piscisaureus>ryah: basically there are:
16:14:55  <piscisaureus>- close() blocks
16:14:55  <piscisaureus>- the kernel tries to deliver the kernel send buffer for a finite amount of time
16:14:55  <piscisaureus>- forced disconnect. the other end sees ECONNRESET
16:16:00  <piscisaureus>ryah: oh i see
16:16:07  <piscisaureus>linux does not have the last option
16:18:16  <ryah>piscisaureus: so does this sound like a plan for the pipe shutdown?
16:18:22  <piscisaureus>ryah: yes
16:18:25  <ryah>piscisaureus: wait one tick?
16:18:36  <ryah>ok
16:18:44  <piscisaureus>maybe a little more
16:18:45  <piscisaureus>?
16:18:53  <ryah>2 ticks?
16:18:56  <piscisaureus>heh
16:19:04  <ryah>just wait one tick
16:19:33  <ryah>end() - flush user buffer - queue packet - read - if read something queue packet again
16:19:52  <ryah>when you cant read something flush kerenl, close
16:20:03  <ryah>any uv_writes that happen in the meantime cause error
16:20:38  <ryah>this should be enough to get most of our tests working
16:20:47  <ryah>and i think practically it's not going to matter
16:20:50  <ryah>for most users
16:24:37  <piscisaureus>ryah: ok
16:24:49  <piscisaureus>ryah: we should probably document it anyway though
16:24:59  <ryah>yes
16:25:16  <piscisaureus>ryah: and I still think 1 tick may be very low. It can be like < 0.01 ms
16:26:14  <piscisaureus>this is gonna be complicated to implement
16:27:00  <ryah>piscisaureus: is there an easy way we can get test-net-pingpong working again?
16:27:06  <ryah>and do the better fix later?
16:27:13  <piscisaureus>yes
16:27:23  <ryah>let's do that - i just want that test passing
16:28:49  <ryah>and let's get an issue going for discussion of named pipe shutdown
16:34:11  <ryah>piscisaureus: are you doing NKO?
16:34:30  <piscisaureus>NKO
16:34:31  <piscisaureus>?
16:36:26  <piscisaureus>ryah: ^
16:37:01  * bnoordhuisquit (Ping timeout: 252 seconds)
16:39:19  <ryah>node knockout
16:39:31  <ryah>http://joyeur.com/2011/08/24/events-node-js-knockout/
16:40:00  <piscisaureus>ryah: oh
16:40:04  <piscisaureus>ryah: I am not in a team
16:40:09  <piscisaureus>so, no
16:40:11  <piscisaureus>are you?
16:40:16  <ryah>nope
16:40:30  <ryah>i get to fix bugs all weekend
16:41:31  <piscisaureus>I am writing a multiplayer version of gorilla.bas
16:41:41  <piscisaureus>to demo node
16:47:29  * bnoordhuisjoined
16:48:22  <bnoordhuis>dishwashers! rage!
16:48:29  <bnoordhuis>i hate today's household appliances
16:48:43  <bnoordhuis>beep beep beep and no indication of what's wrong
16:48:57  <piscisaureus>bnoordhuis: attach a debugger
16:49:24  <bnoordhuis>i did try a hard reboot :)
16:49:47  <piscisaureus>I thought unix hackers didn't do that
16:50:11  <bnoordhuis>no, but i'm pretty sure my dishwasher isn't running a unix
16:50:14  <bnoordhuis>well, maybe netbsd
16:51:24  <bnoordhuis>i believe the ldapjs thing's already leaked
16:51:31  <piscisaureus>I really don't understand what drives these people to maintain all these exotic os-es
16:51:45  <piscisaureus>I mean what's the poing of having fbsd and netbsd and openbsd
16:51:58  <piscisaureus>there's probably another zillion other flavors that nobody uses
16:52:00  <bnoordhuis>subscribe to their mailing lists and you'll soon find out :)
16:52:12  <bnoordhuis>but at the core it's clashing egos
16:52:56  <DrPizza>in the case of openbsd, it's because theo de raadt is a sociopath
16:54:06  <ryah>ldap.js seems so super useful
16:54:32  <bnoordhuis>not to the nosql crowd :)
16:54:38  <bnoordhuis>but yeah, it's pretty neat
16:54:38  <piscisaureus>ldap isn't that what corporate address books use?
16:55:18  <ryah>ldap.js + node on windows + the millions of exchange servers sitting around
16:55:30  <piscisaureus>ok so
16:55:38  <piscisaureus>this replaces active directory?
16:55:44  <piscisaureus>don't tell igorz
16:56:16  <bnoordhuis>AD is-a ldap, so to speak
16:56:34  <bnoordhuis>or a superset of, really
16:57:15  <piscisaureus>according to wikipedia
16:57:25  <piscisaureus>AD == ldap + dns + kerberos
16:57:34  <piscisaureus>which of these is not possible with node?
16:58:18  <bnoordhuis>dns? or dhcp?
16:58:25  <piscisaureus>no dns
16:58:59  <piscisaureus>I don't think you can easily write a dns server in node
16:59:05  <bnoordhuis>sure you can
16:59:07  <piscisaureus>someone should try though
16:59:12  <piscisaureus>sure it is possible
16:59:24  <bnoordhuis>i did a while ago, the basics of anyway
16:59:51  <bnoordhuis>actually, i think there's a fairly complete dnsd implementation already
17:00:08  <bnoordhuis>but only authorative, not recursive and no zone transfers
17:00:19  <bnoordhuis>*authoritative
17:01:44  <bnoordhuis>i suspect proper kerberos support is a lot harder to implement
17:07:24  <ryah>piscisaureus: ETA on test-net-pingpong fix?
17:10:52  <piscisaureus>ryah: dinner now
17:11:40  <bnoordhuis>ryah: what's the #1 prio for this week? improving http_simple performance?
17:13:56  <ryah>bnoordhuis: #1 priority right now is getting v0.5.5 out
17:13:59  <ryah>then perf
17:14:13  <bnoordhuis>anything that needs to be done on the unix side?
17:14:46  <ryah>bnoordhuis: yes. 1sec
17:14:51  <bnoordhuis>sure
17:15:26  <ryah>bnoordhuis: http://github.com/joyent/node/issues/1512
17:15:52  * bnoordhuislocks #1512
17:20:23  * brsonjoined
17:24:36  <CIA-75>node: Nathan Rajlich v0.4 * r0c91a83 / (lib/util.js test/simple/test-console-not-call-toString.js):
17:24:36  <CIA-75>node: util: isRegExp() should not call toString() on its argument
17:24:36  <CIA-75>node: An overloaded toString() method may have side effects
17:24:36  <CIA-75>node: so don't call it for a simple type check.
17:24:36  <CIA-75>node: Back-port of 54b409d to the v0.4 branch. - http://git.io/r4b9Xg
17:39:20  * graydonjoined
17:47:33  <DrPizza>ryah: I still want to hear more about your green threads idea.+
17:47:49  <ryah>DrPizza: im going to try to make a demo right now
17:48:19  <ryah>basically it's collection of uv handles
17:48:51  <ryah>any new handles that result from some callback from those handles get added to the collection
17:49:05  <ryah>kill = destroy the collection + handles
17:49:41  <ryah>uncaught exceptions can then be handled locally
17:49:52  <ryah>the "green thread" is killed
17:50:03  <ryah>nothing is parallel or blocking
17:50:28  <DrPizza>I must be missing something
17:50:31  <DrPizza>I will wait for the demo
17:50:58  <DrPizza>each green thread is a collection of handles?
17:51:16  <ryah>yes
17:51:33  <DrPizza>and it'll just execute each callback in turn until it explicitly yields?
17:51:50  <ryah>it'll be scheduled by libuv
17:52:38  <DrPizza>but how will libuv pre-empt each callback?
17:52:52  <ryah>nothing blocks - no need to preempt
17:53:19  <DrPizza>so if a callback does a for(;;) {} it'll just hang?
17:53:28  <ryah>yes
17:53:58  <ryah>although i think i can add a watchdog timer
17:54:07  <ryah>which will kill the current thread if it blocks too long
17:54:48  <ryah>not sure if interrupting v8 like that is possible
17:54:59  <DrPizza>hmm
17:57:16  <ryah>yes v8::V8::TerminateExecution() will work for that
17:59:26  <DrPizza>can that be safely called asynchronously?
17:59:26  <ryah>damn it. i just layed out my grand plans for everyone to see.
17:59:31  <DrPizza>:o
17:59:34  <ryah>:)
17:59:48  <ryah>yes i think so - that's its purpose
18:00:00  <DrPizza>ah
18:00:10  <DrPizza>I wasn't sure if it was for some kind of an abort() to be called from within the JS context
18:00:19  <ryah>but the watchdog stuff is just a cherry on top
18:00:29  <ryah>the real win here is the "kill" operation
18:00:50  <DrPizza>howso
18:01:25  <ryah>it allows one to contain problems
18:01:30  <igorzi>ryah: so each isolate would execute in its own "green thread"? or..?
18:01:40  <ryah>igorzi: no this is inside a single isolate
18:02:09  <ryah>say you have a server with 10000 connections
18:02:16  <ryah>and one of them hits an exception somehow
18:02:20  <ryah>it brings down the entire system
18:02:35  <DrPizza>a native code exception you mean?
18:02:37  <ryah>this is what i'm trying to solve
18:02:47  <ryah>a javascript layer exception
18:02:50  <DrPizza>or will an unhandled javascript exception bring it down too?
18:03:15  <ryah>an unhandled javascript exception is the use case im addressing
18:04:16  <igorzi>so then each connection gets its own "green thread"?
18:04:23  <ryah>yeah
18:04:48  <ryah>perhaps a connection makes an outbound http request, starts a few timers, and does some disk access
18:05:00  <ryah>all of those operations will be added to the "green thread" collection
18:05:11  <ryah>if one of them fails somehow - all will be terminated
18:05:18  <igorzi>ok, and "green thread" doesn't map to an OS thread 1-1, right? it's just an abstraction?
18:05:25  <ryah>right
18:05:36  <ryah>N green threads to one OS thread
18:05:48  <ryah>it's just some sugar
18:06:18  <ryah>well i guess it's not sugar - there's some meat
18:06:30  <igorzi>ok, it's sort of a handle tree, where instead of killing each handle you can kill the entire tree
18:06:37  <ryah>yeah
18:06:46  <igorzi>neat
18:06:56  <ryah>not a tree but a set
18:08:03  <igorzi>sure, but logically each handle will probably have a child & parent handle?
18:08:04  <ryah>yes - and the important thing for us - starting them costs nothing
18:08:16  <DrPizza>is there no good place to simply install a javascript try/catch?
18:08:51  <ryah>DrPizza: we have a try catch around the whole process
18:08:59  <igorzi>i don't think it's just about js try/catch, it's also about doing the proper cleanup
18:09:03  <ryah>process.on('uncaughException', function(E) { ... })
18:09:07  <ryah>^-- this handles that
18:09:20  <ryah>so you can prevent the process from going down
18:09:28  <ryah>but the problem is you're often left in a bad state
18:09:35  <ryah>since you didn't handle something correctly
18:09:38  <DrPizza>igorzi: if it's going to be tearing down v8 then there won't be much scope for cleanup
18:09:42  <ryah>you've still got all these timers and open connections
18:09:59  <ryah>so it turns out no one actually uses process.on('uncaughException')
18:10:19  <DrPizza>they can't just get GCed?
18:10:23  <ryah>what we want is to be able to have an acception and clean up
18:10:35  <igorzi>why would tearing down v8 be needed?
18:11:01  <ryah>DrPizza: not tearing down V8 - just the thread and its handles
18:11:28  <DrPizza>oh so the v8::terminateexecution still leaves v8 usable and resumable?
18:11:37  <DrPizza>it's an orderly termination?
18:12:08  <ryah>yeah, we'll catch the terminateexecution in c++, kill the thread that was running, then return to the event loop
18:12:18  <ryah>for the watchdog timer
18:13:11  <ryah>but as i said, im not really concerned about people blocking on compute - more concerned about being able to clean up connections
18:13:42  <igorzi>right, it seems that the callback taking too long (for which terminateexecution is needed) is really orthogonal to this idea of cleaning up a collection of handles anyway
18:13:46  <ryah>although we can have all sorts of cool stuff
18:13:54  <ryah>thread.maxRunTime = 500;
18:13:55  <DrPizza>hmm
18:14:07  <ryah>thread.priority = 10;
18:14:18  <ryah>^-- libev has priority for all its watchers
18:14:27  <ryah>(we'd need to addd support to the windows backend)
18:15:11  <ryah>thread.priority = 10 would change the priority for all associated handles
18:15:50  <ryah>which basically determines which order their handled in the event queue
18:16:17  <ryah>*they're
18:16:24  * ryah<- idiot
18:16:44  <ryah>okay. im going to implement this now. hopefully i can be done for the presentation tomorrow at NKO
18:28:50  * pquernaquit (Changing host)
18:28:50  * pquernajoined
18:30:57  <jmp0>c00l
18:31:26  <jmp0>i'm not sure if issue 32 is a riddle or just a request
18:36:08  * piscisaureusquit (Read error: Connection reset by peer)
18:36:48  <bnoordhuis>jmp0: both :)
18:37:23  <bnoordhuis>but i think the goal is to test what happens when the read end of a pipe has gone away
18:39:35  <bnoordhuis>it won't raise EPIPE on unices, come to think of it
18:39:58  <bnoordhuis>the pipe is really a unix socket so if nothing's listening, the client gets ECONNREFUSED
18:46:53  <jmp0>hah, but don't give it all away! i expect that this exploration will lead somewhere.. a tour around the system perhaps :)
18:48:54  <ryah>http://ntotten.com/2011/08/nodejs-on-windows-azure/
18:53:35  * piscisaureusjoined
18:56:35  <bnoordhuis>piscisaureus ryah igorzi: call time?
18:56:44  <piscisaureus>oh
18:56:47  <piscisaureus>yeah
18:56:58  <piscisaureus>but let me turn off dj korsakoff first
18:57:09  <bnoordhuis>not dj tiesto?
18:57:12  <bnoordhuis>he the best
18:57:42  * ryahis listening to dj korsakoff now
18:57:47  <ryah>sounds pretty fun :)
18:58:16  <piscisaureus>it's very bombastic (is that english?)
18:58:25  <bnoordhuis>yes
19:01:21  <ryah>igorzi: skype?
19:01:29  <igorzi>yeah, just signed in
19:06:20  <bnoordhuis>ich will built node.js on Opensuse <- cute!
19:19:18  <piscisaureus>bauen
19:20:03  * mralephjoined
19:20:16  <bnoordhuis>bitte m�chte ich node punkt js am opensuse bauen, danke sehr!
19:21:44  <ryah>igorzi: readdir sucks
19:23:08  <ryah>igorzi: im worried that having the user free the memory is going to be too confusing
19:23:23  * rmustaccpart
19:24:51  <ryah>igorzi: maybe uv_async_req_cleanup(uv_async_req*)
19:25:03  <ryah>igorzi: that does seem nicer
20:00:12  <piscisaureus>oh man
20:00:23  <piscisaureus>this pipe problem requires suck ugly hacks
20:00:24  * johnm1234_quit (Remote host closed the connection)
20:01:59  * indutnyquit (Remote host closed the connection)
20:06:25  * johnm1234_joined
20:09:12  * brsonquit (Ping timeout: 276 seconds)
20:10:17  * brsonjoined
20:10:23  * johnm1234_quit (Remote host closed the connection)
20:10:28  * johnm1234_joined
20:12:30  <bnoordhuis>http://news.ycombinator.com/item?id=2925547 <- this pisses me off
20:12:37  <bnoordhuis>fucking real networks
20:12:46  <piscisaureus>yes me too
20:13:16  <piscisaureus>these ex parte decisions are so fucked up
20:13:26  <bnoordhuis>yeah - seriously, wtf?
20:13:43  <piscisaureus>igorzi: hey
20:13:50  <bnoordhuis>and how can a civil case get your house searched and your property taken?
20:14:12  <piscisaureus>yes, indeed
20:14:24  <piscisaureus>even without a reasonable process upfront
20:14:53  <bnoordhuis>i'm going to try and send that guy some money
20:15:10  <bnoordhuis>i want to see him *destroy* real
20:15:35  <DrPizza>I don't think he will succeed.
20:15:36  <piscisaureus>http://blog.iusmentis.com/2011/08/25/realnetworks-wil-smartegeld-om-hyperlink/
20:15:41  <DrPizza>I think it's shitty to go after hyperlinkers.
20:15:48  <DrPizza>But RealAlternative is totally against the law.
20:16:10  <DrPizza>And the "DNS" angle makes no sense at all.
20:16:24  <piscisaureus>it does
20:16:35  <DrPizza>no it doesn't, you can't cache Web pages over DNS.
20:16:35  <piscisaureus>this guy just had a site that linked some downloads
20:16:37  <DrPizza>DNS entries, sure.
20:16:39  <piscisaureus>like firefox etc
20:16:53  <DrPizza>Sure, but change the page with the hyperlink and DNS has nothing to do with it.
20:17:18  <piscisaureus>maybe I don't really understand with the dns angle
20:17:43  <DrPizza>"RealNetworks claims Edskes failed to remove the link to the software, and the reference in the DNS directories existed after February 12, 2010."
20:17:48  <DrPizza>^^ makes no sense to me
20:17:56  <piscisaureus>indeed
20:17:58  <piscisaureus>bullshit
20:19:16  <piscisaureus>his site: http://codecpack.nl/
20:19:54  <piscisaureus>not exactly the pirate bay
20:21:08  <bnoordhuis>i'm going over to real's amsterdam office and piss in their mailbox >:(
20:21:38  <piscisaureus>oh, don't bother
20:21:52  <piscisaureus>you'll find an empty office in a corridor of empty offices
20:22:01  <piscisaureus>if they're in holland they're only here for tax reasons
20:22:10  <bnoordhuis>hah, true that
20:23:07  <bnoordhuis>then i'll go into politics and have a law passed that taxes foreign companies 100% of gross income
20:23:52  <bnoordhuis>and makes installing spyware a mortal crime
20:24:07  <piscisaureus>\o/ ben for president
20:24:31  <piscisaureus>arnoud engelfriet should be a politician though
20:25:45  <bnoordhuis>Het lijkt me een goed idee om een regel in te voeren dat advocaten persoonlijk aansprakelijk zijn als ze een ex parte verzoek indienen dat later vernietigd wordt. Omdat het een procedure zonder tegenspraak is, moet de rechter afgaan op de informatie die de advocaat aandraagt. En als die niet blijkt te kloppen, dan moet dat consequenties hebben. <- fully concur
20:30:26  * isaacsjoined
20:30:27  <igorzi>ryah: piscisaureus: sorry, i was in a meeting
20:30:49  <igorzi>ryah: uv_async_req_cleanup sounds good.. you want to use it for sync and async calls?
20:31:04  <piscisaureus>igorzi: i don't remember what I had to ask :-(
20:34:33  <ryah>igorzi: yeah - using it for both sounds good
20:38:32  <piscisaureus>hmm.
20:38:49  <piscisaureus>ryah: net-pingpong does rely on half-open pipes :-/
20:39:26  <ryah>piscisaureus: somehow it was passing before
20:39:34  <piscisaureus>ryah: I know
20:39:50  <piscisaureus>ryah: it's because there was some delay build-in
20:40:15  <piscisaureus>but I added an optimization that avoids using the thread pool
20:40:39  <ryah>ah
20:42:40  * piscisaureuspomders more
20:50:54  * indutnyjoined
20:58:36  <igorzi>http://tomasz.janczuk.org/2011/08/hosting-nodejs-applications-in-iis-on.html
20:58:51  <igorzi>ryah: piscisaureus: DrPizza: ----^
20:59:38  <DrPizza>igorzi: interesting, it's an ISAPI (or whatever the new IIS API is called) fork?
21:00:19  <igorzi>DrPizza: it's a module (just like fastcgi module is)
21:00:24  <DrPizza>yes
21:00:28  <DrPizza>the new extension API
21:00:32  <igorzi>yes
21:00:34  <DrPizza>IIS7 (maybe 6 too?)
21:00:51  <bnoordhuis>test/simple/test-zerolengthbufferbug.js <- weird
21:01:03  <bnoordhuis>if i run it with libuv, there's two sockets being created, as expected
21:01:17  <bnoordhuis>but with legacy, there's a third socket being created somewhere
21:01:53  <DrPizza>igorzi: is this spawning node.exe as a kind of persistent background process?
21:02:10  <DrPizza>hm, yes, seems to be
21:02:14  <DrPizza>it talks to node over pipes
21:03:06  <DrPizza>igorzi: interesting
21:03:12  <igorzi>right, it's actually very similar to how fastcgi module works, only it uses http as the protocol
21:03:23  <DrPizza>igorzi: I would still prefer libuv http.sys support :)
21:03:36  <DrPizza>but it's a nice stopgap
21:04:22  <igorzi>DrPizza: these are different scenarios, you get a bunch of extra functionality with iis. but yeah, having a straight http.sys support would be good if you don't care about that.
21:04:33  <DrPizza>yeah, so this hooks into IIS logging etc.
21:04:36  <DrPizza>which is nice
21:06:32  <DrPizza>igorzi: the kind of thing I'd be more interested in is having node grab http://*:80/websockets/ or something along those lines, so I can use javascript at both ends of the connection
21:07:54  <igorzi>yeah, right now you can't really do that i guess
21:15:13  <bnoordhuis>/ Ensure we have a dummy fd for EMFILE conditions. <- found it
21:21:35  <ryah>bnoordhuis: is that the solaris bug?
21:22:30  <piscisaureus>igorzi: so this Tomasz is the msft guy working on iis support?
21:22:36  <piscisaureus>or is this an unrelated project?
21:22:54  <igorzi>piscisaureus: yeah, he's the msft guy who's working on iis support
21:23:13  <igorzi>(he's also usually on tuesday calls :))
21:23:20  <piscisaureus>oh
21:23:21  <piscisaureus>hehe
21:23:27  <piscisaureus>i never hear him?
21:23:51  <bnoordhuis>ryah: no, that's a node feature :)
21:23:54  <igorzi>right, he usually just listens
21:23:56  <bnoordhuis>it's that EMFILE trick
21:24:33  <bnoordhuis>ryah: but i'm getting closer
21:24:51  <piscisaureus>kind of nice he uses github
21:24:52  <bnoordhuis>i'm 95% sure it's a ipv4-vs-ipv6 thing
21:28:20  <ryah>fucking ipv6
21:30:17  <DrPizza>everything will be much easier when we ditch ipv4
21:30:36  <DrPizza>in the year 2417
21:30:48  <bnoordhuis>personally i'll wait until ipv8
21:34:32  <bnoordhuis>-server.listen(common.PORT, function() {
21:34:32  <bnoordhuis>- http.get({ port: common.PORT }, function(res) {
21:34:32  <bnoordhuis>+server.listen(common.PORT, '127.0.0.1', function() {
21:34:32  <bnoordhuis>+ http.get({ host: '127.0.0.1', port: common.PORT }, function(res) {
21:34:33  <bnoordhuis>:/
21:34:41  <bnoordhuis>that's all it takes...
21:51:10  <bnoordhuis>ryah: [01:10|% 100|+ 184|- 4]: Done <- sunos
21:51:19  <bnoordhuis>however... the hack is not pretty
21:51:59  <bnoordhuis>ryah piscisaureus: https://gist.github.com/5ebbafe376f05ea6bf1d <- review please? :/
21:52:38  <piscisaureus>bnoordhuis: didn't ryah land a similar patch already?
21:52:51  <DrPizza>I'm sure I saw a commit message about a similar issue
21:52:55  <bnoordhuis>piscisaureus: that was windows-only, wasn't it?
21:53:00  <piscisaureus>yes
21:53:20  <piscisaureus>hmm
21:53:28  <bnoordhuis>yeah, this is actually a few lines below that one
21:54:01  <piscisaureus>bnoordhuis: I think c-ares specifies that if you look up AF_UNSPEC then it should prefer ipv4 over ipv6
21:54:13  <piscisaureus>this seems to be broken
21:54:38  <bnoordhuis>doesn't AF_UNSPEC say 'give me whatever the system prefers'?
21:56:07  <piscisaureus>bnoordhuis: oh hmm it's the reverse
21:56:17  <piscisaureus>it tries ipv6 first
21:56:35  <piscisaureus>the old binding did it differently - it looked for ipv4 first, then looked for ipv6
21:56:42  <piscisaureus>by making 2 separate uv calls
21:56:53  <bnoordhuis>so... suggestions?
21:56:53  <piscisaureus>maybe that should be restored
21:57:12  <piscisaureus>but I think this will do as a temporary hack
21:57:48  <bnoordhuis>the thing with temporary hacks is
21:57:53  <bnoordhuis>that people forget about them
21:58:05  <bnoordhuis>if there's a proper way to solve it, i'd rather use that
22:04:35  * mralephquit (Quit: Leaving.)
22:06:32  <bnoordhuis>piscisaureus: what i don't get
22:06:50  <bnoordhuis>oh wait, i /do/ get it
22:06:54  <bnoordhuis>listen(self, '0.0.0.0', port, 4); <- binds to ipv4
22:07:13  <bnoordhuis>connect('localhost') <- resolves to either 127.0.0.1 or ::1
22:07:21  <bnoordhuis>fucking ipv6
22:12:05  <ryah>bnoordhuis: hmm
22:12:18  <ryah>bnoordhuis: what is causing this to fail?
22:12:33  <ryah>this hack is really undesirable
22:12:38  <bnoordhuis>ryah: localhost resolves to ::1 on sunos
22:12:41  <bnoordhuis>yes
22:13:30  <bnoordhuis>listen should listen on 0.0.0.0 and ::0 if you don't give specify an address
22:13:37  <bnoordhuis>-give
22:14:45  <bnoordhuis>of course that will create further issues
22:15:59  <ryah>listen should always be 0.0.0.0
22:16:10  <ryah>if no address is given
22:16:22  <ryah>never ::0 - only if specified
22:16:40  <ryah>ryan@ryannode:~% host localhost
22:16:41  <ryah>localhost has address 127.0.0.1
22:16:41  <ryah>localhost has IPv6 address ::1
22:16:49  <ryah>^-- seems to resolve to 127.0.0.1
22:16:58  <bnoordhuis>scroll up to what piscisaureus said
22:17:17  <bnoordhuis>it could be a 'feature' of c-ares that it tries to resolve ipv6 first, ipv4 second
22:18:56  <ryah>1sec - patch
22:23:37  <CIA-75>libuv: Ben Noordhuis master * r6490c6a / src/uv-unix.c : unix: improve accept4 syscall feature check - http://git.io/xTKayg
22:23:44  <CIA-75>node: Ben Noordhuis master * r576b116 / (3 files in 2 dirs): uv: upgrade to 6490c6a - http://git.io/m0UHpQ
22:28:30  <ryah>bnoordhuis: https://gist.github.com/1172182
22:29:08  <igorzi>ryah: piscisaureus: for eio_custom equivalent, do you think it's better to have its own req type (instead of using uv_fs_req_t).. maybe uv_custom_tp_t?
22:29:24  <piscisaureus>yes +!
22:29:29  <bnoordhuis>ryah: yeah, i think that's what piscisaureus proposed
22:29:52  <bnoordhuis>so lgtm provided it actually works :)
22:30:04  <ryah>bnoordhuis: i havent tested
22:30:39  <bnoordhuis>ryah: i'm testing it now
22:30:47  <ryah>igorzi: just because it's not a fs thing?
22:31:19  <ryah>igorzi: uv_tp_call_t ?
22:32:08  <igorzi>yea
22:32:12  <piscisaureus>uv_work_t?
22:32:24  <piscisaureus>ryah: close_cb is optional right?
22:32:45  <piscisaureus>can be null
22:33:04  * graydonquit (Quit: Leaving.)
22:33:17  <bnoordhuis>ryah: [01:09|% 100|+ 184|- 4]: Done <- good
22:33:53  <ryah>bnoordhuis: cool
22:34:04  <ryah>piscisaureus: yes
22:34:14  <ryah>uv_work_t sounds good :)
22:34:20  <piscisaureus>I'm almost done with the pipe hack
22:34:29  <piscisaureus>it's already pretty close to the final solution
22:34:41  <piscisaureus>(and pretty complex :-()
22:34:50  <ryah>piscisaureus is the master of making windows unix-y
22:35:12  <bnoordhuis>msft should hire you in that case, piscisaureus!
22:35:25  <piscisaureus>They already tried
22:35:55  <igorzi>ryah: piscisaureus: void uv_work(uv_work_t* req, uv_work_cb cb);
22:36:12  <piscisaureus>yes looks good
22:36:23  <piscisaureus>it can't fail?
22:37:33  <ryah>piscisaureus: return values to check are annoying
22:37:49  <bnoordhuis>...
22:38:25  <igorzi>yeah, i guess we need to add a ret value
22:38:33  <ryah>im afraid uv_work() might be too ambiguous
22:40:01  <piscisaureus>uv_queue_work?
22:40:04  <piscisaureus>uv_send_work
22:40:06  <piscisaureus>uv_do_work
22:40:25  <ryah>uv_tp_call() ?
22:41:39  <ryah>naming things is hard
22:41:45  <igorzi>uv_queue_work?
22:41:57  <ryah>igorzi: what do you like best?
22:42:06  <igorzi>i think i like uv_queue_work
22:42:14  <ryah>uv_queue_work it is then
22:42:15  <ryah>:)
22:43:19  <ryah>void uv_queue_work(uv_work_t* req, uv_after_work_cb cb); ?
22:44:39  <igorzi>ok, yeah after_work makes sense
22:44:50  <ryah>void uv_queue_work(uv_work_t* req, uv_work_cb cb, uv_after_work_cb after); ?
22:45:07  <ryah>probably need a void* there too
22:47:14  <igorzi>i'm inheriting these reqs after uv_req_t, which already has void* data
22:47:34  <igorzi>hmm, now i wonder whether i should be inheriting uv_req_t?
22:47:54  <bnoordhuis>yes
22:48:19  <bnoordhuis>it's a request to perform some action asynchronously
22:48:27  <igorzi>actually yes, we do need both type and data
22:51:14  <igorzi>void uv_queue_work(uv_work_t* req, uv_work_cb cb, uv_after_work_cb after);
22:52:04  <igorzi>if it fails.. dispatch uv_after_work_cb with an error? or let uv_queue_work return an error?
22:53:56  <piscisaureus>ha!
22:53:58  <piscisaureus>seems to work
23:31:36  * jmp0quit (Ping timeout: 260 seconds)
23:31:55  * jmp0joined
23:34:39  <piscisaureus>ryah: igorzi: can you review / try this: https://gist.github.com/1172313
23:34:45  <piscisaureus>(pick one)
23:38:05  <igorzi>piscisaureus: trying+reviewing now
23:38:22  <piscisaureus>it should fix test-net-pingpong and test-repl
23:44:20  <piscisaureus>. /* Did the pipe get closed because of shutdown? */
23:44:20  <piscisaureus>. if (handle->handle == INVALID_HANDLE_VALUE &&
23:44:20  <piscisaureus>. (handle->flags & UV_HANDLE_SHUT)) {
23:44:20  <piscisaureus>. uv_pipe_read_eof(handle, uv_null_buf_);
23:44:20  <piscisaureus>. }
23:44:20  <piscisaureus>^-- not necessary, removing that
23:44:45  * graydonjoined
23:48:14  <igorzi>both tests are passing
23:49:41  * jmp0quit (Ping timeout: 260 seconds)
23:50:01  * jmp0joined
23:56:10  <igorzi>piscisaureus: eof_timer_cb - the comment should say "calling ReadFile"
23:56:54  <piscisaureus>igorzi: yeah
23:59:13  <piscisaureus>igorzi: if we'll do non-0 reads for pipes it's getting even more complicated btw :-(