00:02:02  <igorzi>did you have a case where you needed HasOverlappedIoCompleted(&pipe->read_req.overlapped)? or are you just trying to be careful?
00:02:27  <piscisaureus>igorzi: I can imagine where it is needed. It's defensive yeah
00:03:29  <igorzi>looks fine.. definitely becoming more complicated :)
00:03:44  <piscisaureus>igorzi: if there are other requests pending on the iocp then those are processes first
00:04:15  <piscisaureus>if that takes some time the timer callback may be called before process_read_req
00:04:53  <piscisaureus>also HasOverlappedIoCompleted is very cheap, it just checks if overlapped.Internal != STATUS_IO_PENDING
00:05:05  <piscisaureus>igorzi: yes the complexity is a bit scary
00:05:43  <piscisaureus>igorzi: does 50ms seem fine
00:05:47  <piscisaureus>should it be more / less?
00:06:12  * brsonquit (Ping timeout: 240 seconds)
00:07:21  <igorzi>i think it's fine.. we'll need to run with some real scenarios to see if it needs to be adjusted (IIS will be a real scenario)
00:07:49  <igorzi>piscisaureus: btw. i also wanted to do SetFileCompletionNotificationModes for pipes.. do you see any issues?
00:08:03  <piscisaureus>not really
00:08:04  <piscisaureus>no
00:08:05  * brsonjoined
00:09:12  <piscisaureus>how do I run the uv tests now?
00:11:59  <bnoordhuis>piscisaureus: NODE_USE_UV=1 python tools/test.py --libuv simple pummel
00:12:00  <igorzi>open vs cmd-prompt, and run vcbuild test
00:12:23  * isaacsquit (Quit: isaacs)
00:12:33  <piscisaureus>ok but the --test-uv set is gone?
00:18:11  <bnoordhuis>yes
00:18:22  <bnoordhuis>if you mean `make test-uv`
00:18:33  <ryah>piscisaureus: what do you mena?
00:18:45  <piscisaureus>yes I meant test-uv
00:18:54  <bnoordhuis>oh wait no
00:18:57  <bnoordhuis>they're still there
00:19:05  <ryah>piscisaureus: make test-uv still works
00:19:11  <ryah>if you'r eusing make
00:19:15  <piscisaureus>oh ok
00:19:19  <ryah>otherwise python tools/test.py --libuv simple
00:19:20  <piscisaureus>mingw
00:19:28  <piscisaureus>I moved to msvc now
00:19:37  <ryah>yeah so just use tools/test.py directly
00:21:26  <DrPizza>this pipe timer is ghetto
00:21:41  <CIA-75>libuv: Bert Belder master * r27c52a6 / src/win/tcp.c : win: stop reading on tcp receive error - http://git.io/TEb7fg
00:21:41  <CIA-75>libuv: Bert Belder master * r39aac4a / (include/uv-win.h src/win/pipe.c): win: better shutdown for pipes - http://git.io/NyXOcA
00:21:45  <piscisaureus>DrPizza: ghetto?
00:21:46  <DrPizza>can't we just trust applications not to shut the pipe until the two ends have mutually agreed that it's a good time to do so?
00:22:45  <piscisaureus>we can't trust test-net-pingpong
00:22:53  <DrPizza>piscisaureus: complex and not altogether elegant
00:23:28  <DrPizza>so all this is because pingpong has no shutdown sequence, and a flush/close sequence fails the test?
00:24:10  <piscisaureus>DrPizza: it fails because it relies on the pipe being half-open for a while
00:25:15  <piscisaureus>DrPizza: one end sends PING + EOF, then expects to receive PONG + EOF
00:26:58  <DrPizza>which you can't do on Windows because you can't send EOF, you can only close the pipe and hence can't receive anything
00:26:59  <DrPizza>right
00:27:00  <DrPizza>so
00:27:10  <DrPizza>either change the test so that it has semantics compatible across both systems
00:27:21  <DrPizza>or use pipe pairs so you can kill one direction without killing the other
00:27:22  <DrPizza>no?
00:27:47  <piscisaureus>DrPizza: can you use pipe pairs to talk to mssql?
00:27:50  <piscisaureus>I don't think so
00:28:09  <DrPizza>no, but MSSQL doesn't depend on half-open connections
00:28:18  <DrPizza>(it can't, Windows doesn't do half-open pipe connections)
00:28:26  <piscisaureus>I know
00:29:01  <DrPizza>and the test will still fail I think if my system is being slow
00:29:06  <DrPizza>(if it doesn't get the PONG back in time)
00:29:26  <piscisaureus>DrPizza: yes, it is sort of a race condition
00:29:51  <piscisaureus>we considered that the alternatives are worse - not supporting stream.end for pipes in node
00:30:04  <piscisaureus>besides 50ms is pretty long
00:30:15  <piscisaureus>I dare you to make it fail the pingpong test
00:30:17  <DrPizza>depends how stressed my system is x_X
00:30:43  <DrPizza>but which is worse, not offering stream.end, or offering stream.end that might weirdly fail on stressed systems
00:30:58  <piscisaureus>not offering it
00:31:32  <piscisaureus>it would break stream.pipe for example
00:32:10  <piscisaureus>maybe it is not true
00:32:13  <DrPizza>have you got a branch with the changes merged in
00:32:16  <piscisaureus>that not offering it is worse
00:32:25  <piscisaureus>time will tell
00:32:32  <DrPizza>I don't think there are any good solutions here
00:32:42  <DrPizza>but I think I would rather not have operations that are unreliable/unsafe, in general
00:32:43  <DrPizza>I think.
00:34:06  <DrPizza>maybe
00:39:56  <CIA-75>node: Bert Belder master * r6ab4a4c / (3 files in 2 dirs): Upgrade libuv to 39aac4a5 - http://git.io/4SLPtA
00:40:18  <piscisaureus>DrPizza: ^-- try and make that fail
00:40:31  <piscisaureus>I agree that it is far from ideal
00:40:40  <ryah>sigh.
00:40:46  <ryah>this is far from ideal...
00:41:06  <ryah>50 ms timeout?
00:41:18  <piscisaureus>well
00:41:21  <piscisaureus>change it to whatever
00:41:22  <piscisaureus>10ms
00:41:24  <piscisaureus>1ms
00:41:38  <piscisaureus>10s
00:43:16  <piscisaureus>ryah: we can still decide to throw on stream.end()
00:43:27  <piscisaureus>whatever it's your project
00:44:07  <ryah>bert i apologize - my insistence that we not change test-net-pingpong might be been bad
00:44:17  <ryah>we can't throw on stream.end()
00:44:47  <ryah>it's not a good situation. we should probably change the test to behave differently
00:45:12  <piscisaureus>changing the test doesn't solve your problem
00:45:13  <DrPizza>for example, for the sake of the test, you could have an app-level shutdown protocol
00:45:24  <DrPizza>like send "PINGEND" for the last ping
00:46:23  <DrPizza>sender marks as notionally closed (unwritable, but handle still open), then continues to perform reads until it sees PONGEND and then it closes the handle
00:47:19  <piscisaureus>it solves nothing just the test
00:47:41  <DrPizza>but it's just the test that has a problem, if we assume that "real" pipe users on Windows will have a shutdown protocol
00:47:55  <piscisaureus>so we throw on .end?
00:48:13  <piscisaureus>I suggest ryah and drpizza sort this out now
00:48:21  <DrPizza>no, just mark it as "closed" in uv
00:48:47  <piscisaureus>After 5 hours of supposedly wasted work I'm taking a break
00:48:51  <DrPizza>so further writes will throw, but further reads can proceed
00:48:57  <DrPizza>well let me try the patch
00:49:15  <piscisaureus>DrPizza: you'll only create a deadlock
00:49:19  <piscisaureus>it doesn't solve anything
00:49:32  <igorzi>piscisaureus: this solution doesn't get in a way if apps do agree on some shutdown protocol, right?
00:49:39  <piscisaureus>indeed
00:49:43  <piscisaureus>np whatsoever
00:49:51  <DrPizza>right, unless the application is busy
00:49:55  <DrPizza>and can't reply in 50 ms
00:50:48  <igorzi>DrPizza: if you don't want this then don't use shutdown
00:51:02  <piscisaureus>DrPizza: if there is an application level shutdown mechanism then nobody will call end/destroy before agreeing that the connection is done
00:51:17  <piscisaureus>exactly
00:51:30  <piscisaureus>using shutdown should be un-suggested
00:51:34  <DrPizza>so which ~node~ methods are safe
00:51:41  <DrPizza>which ones invoke this behaviour
00:51:46  <piscisaureus>.end()
00:51:56  <DrPizza>so I can destroySoon() to just flush and shut
00:52:03  <piscisaureus>DrPizza: right now that doesn't work
00:52:06  <piscisaureus>but it will
00:52:09  <DrPizza>ok
00:52:21  <DrPizza>on unix is destroy equivalent to destroySoon?
00:52:35  <piscisaureus>DrPizza: https://github.com/joyent/libuv/issues/157
00:52:37  <piscisaureus>DrPizza: no
00:52:51  <piscisaureus>DrPizza: destroy doesn't flush the user-mode buffer, destroySoon does
00:52:55  <DrPizza>oh, I thought the buffer flushing was only a windows issue
00:53:14  <piscisaureus>DrPizza: that's the kernel buffer
00:53:20  <piscisaureus>the user-mode buffer is the write queue in libuv
00:53:21  <DrPizza>oh you mean the uv write queue, not just the kernel buffer I see
00:53:26  <DrPizza>yes ok
00:55:15  <DrPizza>question, does "real" win32 pipe code ever rely on the ability to do uncoalesced zero writes?
00:55:56  <piscisaureus>*shrug*
00:56:00  <piscisaureus>prolly not
00:56:09  <piscisaureus>but the real question is
00:56:20  <piscisaureus>does real win32 code never accidentally write 0 bytes?
00:56:25  <DrPizza>true
00:56:34  <DrPizza>also, does anything other than SQL Server ever actually use named pipes
00:56:41  <piscisaureus>mysql does
00:56:47  <DrPizza>really? interesting.
00:57:10  <DrPizza>so databases <3 named pipes
00:57:16  <ryah>:)
00:57:29  <ryah>piscisaureus: im really sorry - but i dont find this 50ms timeout okay
00:57:59  <ryah>we need to remove the graceful shutdown behavior from our pipe tests
00:58:07  <ryah>users simply can't depend on it
00:58:13  <DrPizza>make it app-level
00:58:22  <DrPizza>piscisaureus: ok, it's built at last
00:58:30  <DrPizza>which test is it
00:58:58  <ryah>test/simple/test-net-pingpong
01:02:57  * graydonquit (Quit: Leaving.)
01:03:42  <ryah>i dont know - maybe it's okay
01:04:08  <ryah>it seems rather arbitrary and long
01:04:15  <ryah>feels bad
01:04:29  <ryah>similar to TIME_WAIT
01:05:14  <igorzi>take it down to 5ms?
01:06:12  <piscisaureus>you might as well take it down to 1ms or 10ms
01:06:20  <piscisaureus>it's all 16ms in the end
01:06:37  <DrPizza>heh
01:06:43  <ryah>okay let's think
01:06:49  <ryah>is this going to show up in any benchmarks?
01:07:06  <ryah>does it effect make test-bench on libuv?
01:07:42  <piscisaureus>let's try
01:09:51  <piscisaureus>we can make it really small probably by not using timer but using uv_idle instead
01:10:24  <DrPizza>piscisaureus: that sounds a little more elegant, so reap when the system is no longer busy
01:10:47  <piscisaureus>well - when this process is no longer busy
01:10:56  <piscisaureus>you can't tell the status of the remote end
01:11:04  <DrPizza>oh right, yes.
01:14:18  <bnoordhuis>http://meta.slashdot.org/story/11/08/25/1245200/Rob-CmdrTaco-Malda-Resigns-From-Slashdot <- 1300 comments
01:14:50  <bnoordhuis>both steve jobs and cmdrtaco... the internet as we know it is ending
01:15:06  <ryah>sorry guys - im getting pulled into a firefight right now
01:15:26  <ryah>the joys of working for a hosting company
01:15:48  <piscisaureus>the 50ms doesn't seem to affect pipe-pound
01:16:10  <bnoordhuis>ryah: sorry about that, i'll turn off my LOIC
01:18:59  <DrPizza>what the hell
01:19:11  <DrPizza>the not-for-resale batteries that came with this mouse have died after less than a week
01:38:22  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:41:52  * piscisaureusjoined
01:45:12  <ryah>bnoordhuis: let's do this release
01:45:48  <bnoordhuis>ryah: right
01:45:48  <ryah>bnoordhuis: actually let's put it off until tomorrow
01:45:57  <bnoordhuis>ryah: right :)
01:45:58  <ryah>sorry - too much stuff going on
01:46:05  <bnoordhuis>no worries
02:25:32  * brsonquit (Ping timeout: 246 seconds)
02:49:32  <piscisaureus>heh
02:49:43  <piscisaureus>mssql requires message-based pipes
02:49:51  <piscisaureus>http://msdn.microsoft.com/en-us/library/ee301358.aspx
02:52:02  <ryah>oh god
02:52:29  <ryah>i'm not sure what is worse - the shit show that's happening at no.de or windows pipes
02:52:40  <piscisaureus>heh
02:52:45  <piscisaureus>what's happening with no.de
02:52:48  <DrPizza>piscisaureus: lol srsly?
02:53:03  <DrPizza>(about message-based pipes)
02:53:42  <piscisaureus>see the link
02:53:47  <ryah>broken
02:54:10  <piscisaureus>ryah: about the same then
02:55:03  <piscisaureus>DrPizza: maybe it's not actually a requirement
03:05:35  <DrPizza>piscisaureus: yeah looking at a java TDS implementation it looks like it's using byte-mode pipes
03:05:44  <piscisaureus>yeah?
03:05:45  <piscisaureus>phew
03:05:54  <DrPizza>http://jtds.svn.sourceforge.net/viewvc/jtds/branches/jTDS%201.2%20%28stable%29/src/main/net/sourceforge/jtds/jdbc/SharedNamedPipe.java?revision=1107&view=markup
03:06:03  <DrPizza>that's using smbnamedpipe from jcifs
03:06:08  <DrPizza>http://jcifs.sourcearchive.com/documentation/1.3.12-1/SmbNamedPipe_8java-source.html
03:06:13  <DrPizza>and that defaults to byte-mode I think
03:06:31  <piscisaureus>DrPizza: there's "read mode" and "open mode"
03:06:39  <piscisaureus>they're both byte mode?
03:06:46  <DrPizza>it looks so
03:12:47  <piscisaureus>yes
03:13:19  <piscisaureus>otherwise it'd have been opened with SmbNamedPipe.PIPE_TYPE_RDWR | SmbNamedPipe.PIPE_TYPE_TRANSACT
03:20:03  <DrPizza>yeah
03:21:38  <bnoordhuis>off to bed
03:21:41  <bnoordhuis>night, guys
03:22:04  * bnoordhuisquit (Quit: Leaving)
03:24:47  <piscisaureus>yay bye me too
03:28:55  <ryah>night
03:34:36  * isaacsjoined
04:01:27  * piscisaureusquit (Ping timeout: 258 seconds)
04:58:43  * isaacsquit (Quit: isaacs)
06:26:09  <igorzi>ryah: was that "new net.Socket(2)" issue the only thing that's blocking NPM support?
06:30:39  <ryah>igorzi: unclear if that's the only issue
06:30:48  <ryah>that's the current one
06:33:13  <igorzi>ryah: is the goal to have it working for 0.5.6?
06:39:14  <ryah>yeah once we have the tty stuff in - we should be able to do that
06:39:19  <ryah>at least for fd 0,1,2
07:43:06  * mralephjoined
08:27:44  * mralephquit (Quit: Leaving.)
09:09:13  <CIA-75>libuv: Igor Zinkovsky fs * r0e322fa / (13 files in 5 dirs): uv_fs & uv_work APIs - http://git.io/_Z5iWQ
10:16:52  <CIA-75>libuv: Igor Zinkovsky master * re954b4c / (vcbuild.bat create-msvs-files.bat): merge create_msvs_files.bat and vcbuild.bat into vcbuild.bat - http://git.io/qKAC8Q
12:49:17  * piscisaureusjoined
12:53:24  * bnoordhuisjoined
12:58:20  <piscisaureus>bnoordhuis: are we going to drop file descriptor passing too?
12:58:48  <piscisaureus>mornin', btw :-)
12:59:59  <bnoordhuis>piscisaureus: morning :)
13:00:03  <bnoordhuis>i don't know
13:00:17  <bnoordhuis>fd passing is a very useful thing to do
13:00:24  <piscisaureus>I agree
13:00:27  <bnoordhuis>but it's rather unix centric i assume
13:02:21  <piscisaureus>bnoordhuis: we need to do it on windows
13:02:24  <piscisaureus>I think
13:03:16  <piscisaureus>bnoordhuis: we should provide a "suggested way" of doing inter-node ipc that's 100% cross-platform
13:03:16  <bnoordhuis>how does it work on windows?
13:03:59  <piscisaureus>for ipc with other applications we can just keep the platform-specific stuff (unix dgrams)
13:05:29  <piscisaureus>bnoordhuis: you can dup a fd to another process
13:05:45  <piscisaureus>(so the fd you get can't be used by you, but it can be used by the other process)
13:06:00  <piscisaureus>then you need to send it to the other process yourself
13:06:10  <bnoordhuis>let me get this straight
13:06:19  <bnoordhuis>process A dups its fd
13:06:28  <bnoordhuis>it can't use the result but it can send the dup to process B?
13:06:33  <piscisaureus>yes
13:06:35  <bnoordhuis>okay
13:06:44  <piscisaureus>when dup()ing you have to specify the target process pid
13:07:01  <piscisaureus>bnoordhuis: for sockets its a little more complicated
13:07:12  <bnoordhuis>oh dear, tell me
13:07:23  <piscisaureus>for sockets you call WSADuplicateSocket, giving it the socket fd and the target process pid
13:07:32  <piscisaureus>it gives you back a big struct
13:07:43  <piscisaureus>you need to send the struct to the other side
13:08:03  <piscisaureus>then the other side can create a socket duplicate by using that struct
13:08:17  <bnoordhuis>and sending that struct is done how?
13:08:26  <bnoordhuis>just regular ipc?
13:08:28  <piscisaureus>yes
13:08:36  <piscisaureus>so you need to send it as a blob
13:09:08  <bnoordhuis>"ik ben een meisje he mama?" <- kindje dat net voorbij m'n huis liep
13:09:16  <piscisaureus>bnoordhuis: that's why I was talking about a "ipc pipe" with a custom protocol that would be understood by libuv
13:09:31  <piscisaureus>bnoordhuis: dus jij rende naar buiten en sprak "laat mij maar even kijken?"
13:09:36  <bnoordhuis>precies :)
13:09:42  <bnoordhuis>dokter ben to the rescue
13:10:12  <bnoordhuis>how would that ipc pipe concept work?
13:10:18  <piscisaureus>youtube time: http://www.youtube.com/watch?v=rAPbLbwCDak
13:10:23  <bnoordhuis>oh god
13:10:25  <piscisaureus>bnoordhuis: so about this ipc
13:10:27  * bnoordhuisclicks
13:13:15  <bnoordhuis>piscisaureus: yes, about this ipc
13:14:49  <piscisaureus>bnoordhuis: sorry
13:15:00  <piscisaureus>bnoordhuis: remember the new fork() api?
13:15:07  <piscisaureus>you can send messages to other nodes
13:15:12  <piscisaureus>this needs to support fd's too
13:15:25  <bnoordhuis>yes
13:15:39  <piscisaureus>on linux this works by opening a 4th stream to the child process
13:16:13  <piscisaureus>on windows we could do this too, but additionally we should specify this pipe is not a "raw" stream of data, but a minimal protocol is used
13:16:36  <piscisaureus>so libuv on the other side can parse it and turn messages into sockets / fds again
13:17:08  <bnoordhuis>sounds simple enough, conceptually anyway
13:17:12  <piscisaureus>the protocol can be simple
13:18:02  <piscisaureus>I mean, have messages in the type
13:18:02  <piscisaureus><type> <length> <payload>
13:18:02  <piscisaureus>type: [user_message, handle, socket ]
13:19:13  <bnoordhuis>add a version field so different versions of node can speak to each other
13:19:23  <bnoordhuis>but i get your point
13:22:00  <piscisaureus>bnoordhuis: I guess we can hang on to socket.write with a file descriptor for unix sockets too
13:22:10  <piscisaureus>it just won't work for regular pipes on windows
13:23:34  <bnoordhuis>er... what does that mean? 'hang on to'?
13:23:43  <piscisaureus>bnoordhuis: stick to it
13:23:55  <bnoordhuis>i know what 'hang on to' means :)
13:24:08  <bnoordhuis>let me rephrase it: what do *you* mean?
13:24:20  <piscisaureus>bnoordhuis: not remove it
13:24:44  <bnoordhuis>right, but that makes it inconsistent across platforms
13:24:54  <piscisaureus>bnoordhuis: yes but so what
13:25:06  <bnoordhuis>and i don't want to have to explain to windows users why feature x doesn't work on their platform
13:25:07  <piscisaureus>we should just document that it doesn't work on windows
13:28:42  <bnoordhuis>i suppose i can live with that
13:29:53  <piscisaureus>bnoordhuis: there's one thing still
13:30:38  <bnoordhuis>piscisaureus: don't keep me in suspense!
13:30:50  <piscisaureus>what if process a creates 2 process, b and c, so you end up having a B-A-C topology
13:31:24  <piscisaureus>what if B now wants to set up an ipc pipe to C
13:31:52  <bnoordhuis>i don't know
13:31:59  <bnoordhuis>well, i do know on unices
13:32:12  <bnoordhuis>but i don't know how it'd work on windows
13:32:14  <piscisaureus>yeah there you just create an unix socket
13:33:13  <piscisaureus>maybe we should talk to learnboost about their experiences with it
13:33:30  <piscisaureus>they probably have a better overview of what needs to be done
13:34:00  <bnoordhuis>you mean the cluster guys?
13:34:05  <piscisaureus>yes
13:34:09  <piscisaureus>visionmedia et al
13:34:16  <bnoordhuis>tj in #node.js
13:34:24  <bnoordhuis>he's almost always around
13:34:34  <bnoordhuis>^ great alliteration there
13:35:01  <piscisaureus>you should become a digtur
13:36:41  <bnoordhuis>rozen zijn rood
13:36:48  <bnoordhuis>meestal dan
13:36:54  <bnoordhuis>viooltjes zijn blauw
13:37:00  <bnoordhuis>behalve de paarse in mijn tuin
13:37:12  <bnoordhuis>waar ging het ook alweer over?
13:37:21  <bnoordhuis>^ a work of beauty *snif*
13:38:05  <DrPizza>the problem with duplicating handles is the IOCP interactions
13:38:13  <DrPizza>it's not handles that are bound to IOCPs, it's kernel objects
13:39:28  <piscisaureus>yes that's also a problem
13:39:37  <piscisaureus>one that can be worked around, though
13:40:08  <DrPizza>how will you solve it?
13:40:42  <piscisaureus>DrPizza: overlapped.hEvent to a valid event
13:41:05  <DrPizza>how does that help
13:42:07  <piscisaureus>DrPizza: you can use registerwaitforsingleobject to wait for the event to complete
13:42:32  <piscisaureus>then in the callback we can manually drop the overlapped in the iocp
13:42:50  <DrPizza>so you mean instead of using the IOCP directly, you do a thread wait and then post to the child process's iocp
13:42:52  <DrPizza>hmm
13:43:21  <DrPizza>and that suppresses the IOCP notification in the parent process?
13:43:29  <piscisaureus>yes
13:43:33  <DrPizza>hm
13:43:35  <piscisaureus>I am not sure that is even necessary
13:43:45  <piscisaureus>but if needed (hEvent |= 1) will do
13:44:07  <DrPizza>oh yes, of course, the stupid hEvent flag
13:45:13  <piscisaureus>DrPizza: it's probably not the fastest we can do
13:45:25  <DrPizza>no, but I'm not sure what better option there is.
13:45:30  <piscisaureus>but at least for sockets it requires some macro magic and that's it
13:45:50  <piscisaureus>for accepting it's prolly okay
13:46:55  <piscisaureus>DrPizza: what is the better option?
13:47:13  <DrPizza>hm?
13:47:15  <DrPizza>I don't know of one
13:47:24  <piscisaureus>"no, but I'm not sure what better option there is."
13:47:28  <piscisaureus>which do you consider?
13:47:33  <DrPizza>?
13:47:48  <piscisaureus>oh nvm then
13:48:01  <piscisaureus>I was under the impression that you had another idea
13:48:04  <DrPizza>no
13:48:11  <DrPizza>I was saying I can't really see anything better
13:48:14  <DrPizza>well I guess
13:48:31  <DrPizza>piscisaureus: getting everything running with multithreading and 64-bit would be the "better option"
13:48:52  <piscisaureus>... and with proper error isolation
13:49:34  <DrPizza>yes, though I think ryah had some ideas about improving that
13:51:00  <DrPizza>I mean that doesn't help if you get a native code error, but nothing can save you then
13:51:20  <piscisaureus>DrPizza: it's a problem
13:51:49  <piscisaureus>It's very useful to have multiple node processes
13:51:58  <piscisaureus>and going one down is survivable
13:52:14  <piscisaureus>er
13:52:19  <piscisaureus>*one going down
13:52:57  <piscisaureus>I wonder what people are actually sharing
13:53:01  <piscisaureus>listening sockets, sure
13:53:09  <piscisaureus>connected sockets?
13:53:40  <DrPizza>it's hard to see what else
13:53:48  <DrPizza>even connected sockets feel unlikely
13:54:10  <piscisaureus>Open files (e.g. a logfile?) <-- seems useless
13:54:32  <DrPizza>you'd think youd' be better off piping all your logging to one process
13:54:37  <DrPizza>so that it all gets written in order, etc.
13:54:53  <piscisaureus>you can do that by opening in append mode
13:54:57  <piscisaureus>but more importantly
13:55:06  <piscisaureus>you can just open the file in multiple processes
13:55:11  <piscisaureus>so why bother?
13:55:30  <DrPizza>what "append" mode
13:55:33  <DrPizza>there is no append mode
13:55:41  <DrPizza>ther eis only "position the file pointer at the end of the file by default"
13:55:52  <piscisaureus>nono
13:55:56  <DrPizza>overlapped writes still have to maintain their own position
13:55:58  <piscisaureus>let me look it up
13:56:05  <piscisaureus>not true for files in append mode
13:56:13  <piscisaureus>position is ignored then
13:56:48  <DrPizza>oh interesting
13:57:06  <DrPizza>so yo uask for append without write
13:57:11  <DrPizza>weird.
13:57:17  <piscisaureus>You can get atomic append on local files by opening a file with FILE_APPEND_DATA access and _without_ FILE_WRITE_DATA access. If you do this then all writes will ignore the the current file pointer and be done at the end-of file.
13:57:36  <DrPizza>If only the FILE_APPEND_DATA and SYNCHRONIZE flags are set, the caller can write only to the end of the file, and any offset information about writes to the file is ignored. However, the file will automatically be extended as necessary for this type of write operation.
13:58:01  <DrPizza>I wonder if that's still true for overlapped I/O
13:58:38  <piscisaureus>I think it is
13:58:43  <piscisaureus>append is a special problem
13:58:55  <piscisaureus>because there's a race condition risk
13:59:15  <DrPizza>so as long as each program batches up its writes so that it writes an entire log line at a time
13:59:19  <DrPizza>they can't get interleaved or damaged
13:59:38  <piscisaureus>exactly
14:00:18  <piscisaureus>Although I think there was some limit to the maximum size of an "atomic" write
14:00:34  <piscisaureus>But I can't find it now
14:01:04  <piscisaureus>something like "if your write more that ### kb then your write might be interleaved with others"
14:01:10  <DrPizza>hmm
14:01:13  <piscisaureus>damn my typing sucks
14:01:52  <piscisaureus>okay but this is OT
14:02:24  <piscisaureus>what else would one want to share?
14:02:24  <piscisaureus>listening socket <- yes
14:02:24  <piscisaureus>connected socket <- hmm, maybe
14:02:24  <piscisaureus>file <- probably not
14:02:47  <DrPizza>I think even connected sockets are "probably not"
14:02:56  <DrPizza>well what else can you make handles to
14:02:57  <DrPizza>piipes
14:02:58  <DrPizza>pipes*
14:03:00  <DrPizza>consoles
14:03:34  <piscisaureus>we should prolly verify this with tj
14:03:39  <DrPizza>pipes I would think are the same as sockets
14:03:40  <piscisaureus>maybe even ask on the mailing list
14:03:43  * piscisaureusducks
14:03:43  <DrPizza>listening pipes yes, connected pipes no
14:04:46  <DrPizza>consoles probably make no real sense
14:05:07  <DrPizza>piscisaureus: well the issue is not just "what are people sharing", it's "should they be doing things a different way"
14:08:10  <DrPizza>because as you say, they could be sharing file handles, but that's hardly evidence that it's useful or necessary!
14:08:49  <DrPizza>piscisaureus: I think the better route would be to say that you can ONLY share listening pipes/sockets, and then see how loud the complaints are.
14:08:50  <DrPizza>:D
14:14:06  <piscisaureus>yes probably
14:17:32  * igorziquit (Ping timeout: 252 seconds)
14:32:04  <piscisaureus>I'm going to write a demo that does prefork on windows
14:33:59  <DrPizza>meh
14:34:04  <DrPizza>fuck multirpocess
14:34:20  <DrPizza>processes are slow and expensive
14:34:26  <DrPizza>threads are slightly less slow and slightly less expensive
14:34:40  <piscisaureus>chrome uses a zillion processes
14:34:44  <piscisaureus>works like a charm
14:35:19  <DrPizza>chrome doesn't attempt to spawn hundreds of processes a second
14:35:29  <piscisaureus>we're not going to do that
14:35:31  <DrPizza>and has insane bloated memory usage
14:35:47  <piscisaureus>we're not going to do that
14:35:53  <DrPizza>heh
14:36:06  * pquernaquit (*.net *.split)
14:36:13  <piscisaureus>if you have 4 cores you should spawn 4 nodes
14:36:13  <piscisaureus>upfront
14:36:19  <piscisaureus>^-- not heavyweight or?
14:36:43  * pquernajoined
14:36:58  <DrPizza>oh if it's just process per core rather than perconnectoin then that's ok
14:37:06  <piscisaureus>oh man
14:37:17  <piscisaureus>DrPizza: you really thought it would be per-connection?
14:37:32  <DrPizza>sure
14:37:33  <DrPizza>I mean
14:37:45  <DrPizza>the only upside to processes is greater isolatoin
14:37:57  <DrPizza>so why wouldn't you do process per connection?
14:38:11  <piscisaureus>DrPizza: heh
14:38:12  <piscisaureus>well
14:38:19  <DrPizza>after all, if you're going for greater isolation shouldn't you go for the most isolation possible?
14:38:28  <piscisaureus>ideally yes
14:38:55  <piscisaureus>but that doesn't play nice with what node is good in
14:39:08  <piscisaureus>which is sustaining > 10K idle connections
14:39:10  <DrPizza>and stuff like apache prefork is (or at least was, maybe it's different now) process per connection
14:39:30  <DrPizza>so it's not exactly unheard of
14:39:39  <piscisaureus>I know
14:39:50  <DrPizza>it's just horrible!
14:39:54  <piscisaureus>You should watch ryan's introduction to node
14:40:18  <DrPizza>I think I have
14:40:35  <DrPizza>but eh
14:40:37  <piscisaureus>1 thread/process per connection is not good for 10k open connections
14:41:14  <DrPizza>I'm not sure how true that actually is
14:41:42  <piscisaureus>Go ahead
14:41:56  <piscisaureus>spawn 20k threads
14:41:57  <piscisaureus>good luck
14:42:03  <DrPizza>easy.
14:42:54  <piscisaureus>on x64 it could work
14:43:11  <piscisaureus>try it with a 32-bit process
14:43:18  <DrPizza>should be fine on x86 too
14:43:25  <DrPizza>unless yourun out ofhandlesor something
14:43:33  <piscisaureus>you run out of address space
14:43:37  <DrPizza>why?
14:43:40  <DrPizza>minimum stack is just 1 page
14:44:16  <piscisaureus>DrPizza: the reserved space of the address space is much bigger
14:44:18  * DrPizzaquit (Excess Flood)
14:44:21  * DrPizzajoined
14:44:22  <piscisaureus>typically 2mb or so I think
14:44:26  <DrPizza>welp
14:44:30  <DrPizza>excess flood???
14:44:38  <piscisaureus>because otherwise the stack could not grow
14:44:45  <piscisaureus>because the stack needs to be linear
14:44:51  <piscisaureus>it can't be shattered over the address space
14:44:53  <DrPizza>I must have missed some lines
14:45:15  <DrPizza>you can create a thread with 1 page of stack
14:45:24  <DrPizza>that's 4096 bytes
14:45:26  <DrPizza>that's a lot!
14:45:34  <DrPizza>if a problem can'tbe solved with 4096 bytes of stack
14:45:41  <DrPizza>it's probably not worth solving
14:46:08  <piscisaureus>4096 bytes of stack is waaaai to small
14:46:20  <piscisaureus>I wonder if you would actually be able to call v8 with that
14:46:29  <bnoordhuis>i doubt it
14:46:31  <bnoordhuis>but let's try
14:46:35  <DrPizza>heh
14:46:47  <bnoordhuis>the linux kernel uses 4k stacks
14:47:00  <bnoordhuis>and they have to go to great pains to fit within that space
14:47:09  <DrPizza>yeah windows kernel stacks are quite small too
14:48:56  <piscisaureus>drpizza: http://blogs.msdn.com/b/oldnewthing/archive/2005/07/29/444912.aspx
14:49:57  <DrPizza>ooh 64kb huh
14:49:59  <DrPizza>interesting
14:50:26  <DrPizza>alpha AXP?
14:50:28  <DrPizza>gtfo.
14:51:26  <bnoordhuis>alpha?
14:51:38  <DrPizza>yes
14:51:54  <bnoordhuis>i'm probably missing some context here
14:52:24  <DrPizza>piscisaureus: although it's not really clear why you can't get 16 stack frames within each 64 kiB allocation
14:52:38  <DrPizza>piscisaureus: since it knows the pages are free, after all
14:54:32  <bnoordhuis>DrPizza: enlighten me about that alpha thing?
14:55:18  <DrPizza>bnoordhuis: memory allocation granularity on windows is 64 kiB (even though pages are just 4 kiB) due to a desire to improve Alpha AXP performance
14:55:25  <DrPizza>Alpha AXP had no 32-bit load, apparently
14:55:35  <DrPizza>so 32-bit fixups required two operations
14:56:00  <DrPizza>using memory granularity of 64 kiB meant that only one operation was needed
14:56:06  <bnoordhuis>right, starts to make sense now
14:56:07  <bnoordhuis>thanks :)
14:58:13  <piscisaureus>man I don't even know how stdio for child processes works in uv :-(
15:03:36  <bnoordhuis>TCP_DEFER_ACCEPT <- 4-5% speed-up on loopback
15:08:36  <CIA-75>node: koichik master * r43cdbec / test/simple/test-tls-client-abort.js :
15:08:36  <CIA-75>node: test: simple/test-tls-client-abort fails on SunOS
15:08:36  <CIA-75>node: Fixes #1583. - http://git.io/qoBzjQ
15:09:39  <bnoordhuis>damn, node knockout is big this year
15:09:50  <bnoordhuis>310 teams, 10 or 15 locations
15:10:46  <bnoordhuis>and i like that firms like sequoia capital are sponsoring it
15:10:57  <bnoordhuis>we're getting enterprise-y!
15:13:16  <piscisaureus>there's a lot of sponsors
15:13:28  <piscisaureus>but why is that needed
15:13:37  <piscisaureus>or is joyent just cashing in?
15:13:53  <bnoordhuis>prices, organization
15:14:09  <bnoordhuis>food, drink, maybe rent
15:14:29  <bnoordhuis>only the sun goes up free of charge
15:14:34  <bnoordhuis>to mutilate a dutch saying
15:14:41  <piscisaureus>not for long it aint's
15:14:52  <piscisaureus>I am patenting that
15:15:11  <DrPizza>lol
15:15:15  <bnoordhuis>there's a lot of prior art though :)
15:16:00  <piscisaureus>since when does that matter?
15:16:06  <bnoordhuis>i'm going to patent invalidating patents through prior art
15:16:14  <bnoordhuis>i'm so meta!
15:16:16  * isaacsjoined
15:16:17  <piscisaureus>msft patented the pgup and pgdown key a few years ago
15:16:27  <bnoordhuis>not in the 'big brother' kind of sense though
15:17:02  <bnoordhuis>hey isaacs, how's no.de coming along?
15:17:06  <piscisaureus>"Method and apparatus for enlightening the world"
15:17:08  <isaacs>it's coming
15:17:21  <bnoordhuis>still on schedule for this weekend?
15:18:47  <DrPizza>piscisaureus: lol
15:20:54  <piscisaureus>garrett serrack (coapp) is doing a coapp contest this weekend
15:20:54  <piscisaureus>[17:18] <piscisaureus> FearTheCowboy: bad timing
15:20:54  <piscisaureus>[17:19] <piscisaureus> it's node knockout this weekend
15:20:54  <piscisaureus>[17:19] <FearTheCowboy> F(%&K
15:20:54  <piscisaureus>[17:19] <FearTheCowboy> lol
15:21:16  <DrPizza>hah
15:37:19  <bnoordhuis>so... tcp quick ack mode: good or bad?
15:41:43  <bnoordhuis>doesn't make a difference with loopback but that's not surprising
15:41:51  <bnoordhuis>i need a real network to test this on...
15:44:37  <ryah>hello
15:45:33  <indutny>hello
15:45:34  <indutny>:)
15:45:48  <indutny>ryah: sorry, I was away for couple days
15:46:20  <ryah>indutny: np - we've been busy
15:46:31  <indutny>ryah: About OpenSSL - I'm not preparing any patches, it's already patched by google
15:52:49  <ryah>indutny: yeah
15:52:52  <ryah>i noticed that
15:53:02  <indutny>so it needs no patching
15:53:04  <indutny>:)
15:55:27  <ryah>igor++
16:00:26  <bnoordhuis>yay, my daughter can sit up straight
16:00:34  <bnoordhuis>for five minutes straight too, i should add
16:00:35  <bnoordhuis>go her!
16:06:17  <CIA-75>libuv: Erick Tryzelaar master * r6793b53 / (6 files in 4 dirs):
16:06:18  <CIA-75>libuv: Allow custom data for uv_getaddrinfo. Fixes #155.
16:06:18  <CIA-75>libuv: This now requires uv_getaddrinfo_init to be called
16:06:18  <CIA-75>libuv: to initialize a uv_getaddrinfo_t before
16:06:18  <CIA-75>libuv: uv_getaddrinfo is called. - http://git.io/gYAIBw
16:06:18  <CIA-75>libuv: Clifford Heath master * rbeb1590 / src/eio/config_darwin.h : eio: Mac OSX 10.5 (Leopard) does not have fdatasync - http://git.io/D5zzeQ
16:08:18  <bnoordhuis>hmm... i don't think we want that first commit yet...
16:08:53  <CIA-75>libuv: Clifford Heath master * r835782a / src/eio/config_darwin.h : eio: Mac OSX 10.5 (Leopard) does not have fdatasync - http://git.io/CFHRPQ
16:11:03  <CIA-75>node: Ben Noordhuis master * r5e765fe / (deps/uv/src/eio/config_darwin.h deps/uv/vcbuild.bat): uv: upgrade to 835782a - http://git.io/0195bQ
16:16:18  * piscisaureusquit (Ping timeout: 258 seconds)
16:53:59  * graydonjoined
17:00:09  <ryah>win2k3 is so calming
17:00:12  <ryah>i really like it
17:00:16  <ryah>nice green hills
17:03:30  <DrPizza>lol
17:30:51  * rmustaccjoined
17:31:58  * brsonjoined
17:34:10  <CIA-75>node: Ryan Dahl master * r8af0abd / Makefile : prepare for release - website under new user - http://git.io/K8zyiQ
17:34:12  <CIA-75>node: Ryan Dahl master * r16b3f2c / lib/dns_uv.js : Fix dns_uv.lookup order - http://git.io/bg9xgA
17:42:18  * igorzijoined
17:49:31  * mralephjoined
17:54:20  <ryah>https://github.com/joyent/node/issues?milestone=1&state=open
17:54:27  <ryah>^-- v0.5.5 milestone complete
17:54:32  <ryah>(mostly by bumping issues)
17:55:33  * ryahtopic: v0.5.6 issues https://github.com/joyent/node/issues?state=open&milestone=2
17:58:37  <igorzi>ryah: you ok with this: https://gist.github.com/1173978?
17:59:13  <igorzi>https://gist.github.com/1173978
17:59:16  <ryah>igorzi: sure
17:59:58  <CIA-75>libuv: Igor Zinkovsky master * r183178a / README : update readme with vcbuild.bat instructions - http://git.io/s6K8eQ
18:00:05  <ryah>igorzi: the fs stuff looks good. i tested in win2k3
18:00:19  <igorzi>ryah: ok, land in main?
18:00:22  <ryah>yes please
18:03:45  <CIA-75>libuv: Igor Zinkovsky master * r25175c7 / (13 files in 5 dirs): uv_fs & uv_work APIs - http://git.io/tBtAnw
18:04:01  <ryah>igorzi++
18:04:13  <ryah>im going to do the unix side right now
18:10:40  * piscisaureusjoined
18:15:35  * piscisaureus_joined
18:15:52  <piscisaureus_>igorzi!
18:15:54  <piscisaureus_>nice work
18:16:40  * piscisaureusquit (Ping timeout: 260 seconds)
18:26:42  <CIA-75>libuv: Ryan Dahl master * r7cad73a / (include/uv-unix.h src/uv-unix.c test/test-fs.c): Fix build for UNIX - http://git.io/qamnNA
18:28:35  * isaacsquit (Quit: isaacs)
18:30:02  <piscisaureus_>igorzi: hey
18:30:40  <piscisaureus_>if I don't specifiy options.stdout_stream for a uv child process, will it output to the console then?
18:31:02  <piscisaureus_>or will the child process not be able to write to stdout at all?
18:49:28  * piscisaureus_changed nick to piscisaureus
18:50:51  <ryah>piscisaureus: your colors are all strange
18:51:01  <piscisaureus>my colors?
18:51:05  <ryah>piscisaureus: that's what should happen
18:51:05  <ryah>yes
18:51:13  <ryah>im not sure if windows actually does that
18:51:18  <bnoordhuis>piscisaureus: your lines are black
18:51:27  <piscisaureus>hmm
18:51:37  <piscisaureus>maybe triallian is fuckin up
18:51:37  <bnoordhuis>but i like that - because my background color is black too
18:51:44  <piscisaureus>trillian
18:52:23  <piscisaureus>let me restart it
18:52:32  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:53:56  * piscisaureusjoined
18:54:10  <ryah>piscisaureus: http://tinyclouds.org/bert.png
18:54:35  <piscisaureus>oh hmm
18:54:40  <piscisaureus>maybe it's fixed now?
18:54:44  <ryah>yes
18:55:35  <igorzi>piscisaureus_: i think it'll write to console
18:55:46  <piscisaureus>igorzi: ok.
18:55:51  <piscisaureus>I'll try anyway
18:56:08  <ryah>can you guys hit http://coldredlemur2.no.de/
18:56:22  <piscisaureus>I'm writing a prefork server with libuv on windows
18:56:34  <piscisaureus>ryah: yes, works
18:56:40  * bnoordhuisfires up his LOIC
18:56:44  <igorzi>ryah: works for me
18:56:58  <igorzi>piscisaureus: btw, i got some more feedback about 0-reads for udp
18:57:06  <piscisaureus>ok?
18:57:08  <bnoordhuis>ryah: wfm too if i'm supposed to see the node logo
18:57:20  <piscisaureus>igorzi: what?
18:57:43  <igorzi>basically, with RCVBUF=0 it's easy to lose arrivals if the arrival rate is high
18:58:22  <piscisaureus>igorzi: will it drop items from the queue?
18:58:34  <igorzi>piscisaureus: yes it could
18:58:37  <piscisaureus>on peek?
18:58:56  <piscisaureus>what are we supposed to do?
18:59:17  <piscisaureus>also, did someone confirm the STATUS_BUFFER_OVERFLOW bug?
18:59:26  <igorzi>still waiting on that
18:59:57  <igorzi>there's no flow control in udp.. so when the buffer is full new arrivals will just get dropped
18:59:58  <piscisaureus>I was thinking that WSARecvMsv might not have that bug btw
19:01:58  <igorzi>skype crashed
19:02:01  <DrPizza>if you want to reduce packet loss with UDP aren't you better off indiscriminately issuing large (64 kiB) overlapped reads
19:02:13  <DrPizza>(in a loop)
19:02:33  <piscisaureus>DrPizza: why large?
19:02:42  <ryah>piscisaureus, igorzi, bnoordhuis: call?
19:02:42  <piscisaureus>hey guys
19:02:49  <piscisaureus>I missed the call
19:02:52  <DrPizza>piscisaureus: 64 kiB == no possibility of truncation
19:03:20  <igorzi>ryah: yep.. i missed it too, skype crashed on me
19:03:39  <piscisaureus>I want to answer with my phone
19:03:43  <bnoordhuis>sure
19:03:44  <piscisaureus>but its not ringing
19:03:46  * ryahwaits a sec
19:04:05  <piscisaureus>yes wait a bit
19:06:05  <piscisaureus>hey
19:06:07  <piscisaureus>I can't talk
19:06:12  <piscisaureus>ryah: I'll just listen in
19:06:17  <DrPizza>piscisaureus: so instead of trying to right-size the buffer (and having to make two calls) just use a safe-sized buffer and issue the read.
19:08:13  <piscisaureus>Yes I am on a train
19:10:34  <bnoordhuis>https://github.com/bnoordhuis/httpd-accfilt
19:12:24  <piscisaureus>ryah: no
19:12:40  <piscisaureus>well I am trying to get a prefork server going on windows
19:12:40  <piscisaureus>yes
19:12:43  <piscisaureus>sorry about that
19:12:47  <piscisaureus>I really can't talk here
19:13:00  <bnoordhuis>on the train, are you?
19:13:09  <piscisaureus>plus it'll be super annoying for you too
19:13:25  <ryah>piscisaureus: with uv multiplicity?
19:13:36  <piscisaureus>no with multiple processes
19:13:41  <piscisaureus>just to check if it works
19:13:52  <ryah>with the accept thread?
19:13:57  <piscisaureus>hmm
19:13:59  <piscisaureus>similar
19:14:13  <piscisaureus>one process uses iocp proper
19:14:18  <piscisaureus>the other one uses events
19:14:32  <ryah>hm
19:14:49  <piscisaureus>you have other stuff in mind
19:14:57  <piscisaureus>I could also work on multiplicity
19:15:12  <piscisaureus>or on solving this pipe problem
19:15:14  <ryah>it would be really great to have multiplicity landed :)
19:15:21  <ryah>the pipe problem can wait
19:15:46  <piscisaureus>the pipe problem pissed me off yesterday, I don't want to work on that for the next couple of days
19:15:55  <piscisaureus>so let me work on multiplicity
19:16:04  <ryah>id say strategy for multiplicity is to work on the multiplicity3 branch
19:16:08  <ryah>once its working there
19:16:10  <ryah>rebase
19:16:13  <ryah>which will be hard
19:16:18  <piscisaureus>hmm
19:16:19  <ryah>cause we just landed the fs stuff
19:16:20  <piscisaureus>it depends
19:16:24  <piscisaureus>oh heh
19:16:26  <piscisaureus>yes
19:16:27  <ryah>well "hard"
19:16:28  <DrPizza>piscisaureus: I wanted to take a look at the pipe thing some more, I'm suspicious that the test is a little misleading, so I want to investigate that further
19:16:42  <piscisaureus>DrPizza: go ahead
19:16:57  <ryah>piscisaureus: yes im sorry for the pipe problem
19:17:05  <piscisaureus>I kind of agree that this timeout solution doesnt actually solve anything
19:17:08  <ryah>piscisaureus: i take the blame for windows sucking
19:17:22  <ryah>i was actually at the meeting where they decided on this behavior in '98
19:17:27  <DrPizza>piscisaureus: yes, I'm sorry if yesterday it sounded like I was being rude about the work you did, that wasn't my intent
19:18:13  <piscisaureus>it's allright guys
19:22:19  <ryah>(no - just kidding - i wasnt at that meeting)
19:22:25  <DrPizza>lol
19:22:26  <piscisaureus>oh
19:22:31  <piscisaureus>really
19:22:37  <DrPizza>ryah: indeed not, I think the behaviour has been there since 1993 :p
19:22:42  <piscisaureus>1998 seemed a bit late also
19:22:54  <DrPizza>and was probably decided several years before that.
19:23:04  <piscisaureus>I think it was designed in 1989 or so
19:23:16  <piscisaureus>by ibm
19:23:27  <DrPizza>naah
19:23:32  <DrPizza>the question is, what do VMS pipes do
19:35:38  <piscisaureus>ryah: did you finish your greenthread stuff btw
19:35:49  <piscisaureus>?
19:46:48  <piscisaureus>Never mind, I am going
19:46:55  <piscisaureus>good luck guys
19:47:03  <piscisaureus>have fun with NKO
19:48:57  * isaacsjoined
19:51:11  <ryah>piscisaureus: no
19:51:17  <ryah>no.de started breaking
19:51:21  <ryah>or - started working
19:51:29  <ryah>depending on your perspective
19:52:33  * piscisaureusquit (Ping timeout: 258 seconds)
19:53:13  <ryah>we're calling the "green thread thing" "domains" now
19:53:26  <ryah>because people dont like the term
19:54:23  * brsonquit (Ping timeout: 240 seconds)
20:01:05  * brsonjoined
20:07:33  <CIA-75>node: Ryan Dahl master * r028908a / (44 files in 7 dirs): Upgrade V8 to 3.5.8 - http://git.io/TuVBqA
20:16:49  <CIA-75>node: Ryan Dahl master * rf1996ff / (5 files in 4 dirs): (log message trimmed)
20:16:49  <CIA-75>node: Merge remote branch 'origin/v0.4'
20:16:49  <CIA-75>node: Conflicts:
20:16:49  <CIA-75>node: AUTHORS
20:16:49  <CIA-75>node: ChangeLog
20:16:49  <CIA-75>node: doc/api/stdio.markdown
20:16:50  <CIA-75>node: doc/index.html
20:28:44  <pquerna>please add a thing where if you detect XML in a buffer object, the core just calls abort();
20:28:47  <pquerna>xml-in-node--
20:29:26  <DrPizza>lol
20:29:50  * ryahquit (Quit: leaving)
20:29:58  * ryahjoined
20:30:31  <CIA-75>node: Ryan Dahl master * r7d38a3b / src/node_buffer.cc : Fix build - due to V8 API change - http://git.io/NvavfQ
20:30:44  <pquerna>all our apis officially are supposed to have both xml and json right; trying to fight the fight to just dump xml. its gonna be two weeks to fix both outputting and input of xml. sigh.
20:31:09  <ryah>why is that so painful?
20:31:42  <pquerna>1) our object model was built around doing all of it in json, our serializer doesn't have enough information to make 'pretty' xml
20:32:01  <pquerna>things like plurals/singular element names, not just calling all arrays '<list>'
20:32:29  <pquerna>2) reversing all of it, without pulling in libxml2... well I think we will end up having to pull in a dom-ish parser
20:32:37  <pquerna>because while issacs hacky sax thing is nice
20:32:42  <pquerna>its just not enough
20:33:24  <pquerna>(reversing all of it, so when you POST/PUT a document up to us, we convert it to something the rest of our code understands)
20:36:15  <pquerna>and then there is the actual libxml2 binding: https://github.com/polotek/libxmljs
20:36:21  <pquerna>which afaik, has not had... positive reviews
20:36:37  <ryah>no
20:36:43  <ryah>i think it's broken
20:36:49  <ryah>you coming over tonight pquerna
20:36:54  <pquerna>so, 2 weeks.
20:36:56  <ryah>i have a new feature i want to tell you about
20:37:07  <DrPizza>sax-style parsing is the natural model for node surely
20:37:17  <pquerna>sure
20:38:35  <DrPizza>clearly I need to go to SF and see real life node users in the flesh
20:42:08  <CIA-75>node: Ben Noordhuis master * r790f13d / configure : Fix typo in configure script - http://git.io/MHDSrQ
20:46:02  <bnoordhuis>DrPizza: there's a knockout meetup in londen too, i think
20:50:02  * piscisaureusjoined
21:07:10  <ryah>people are provisioning
21:07:13  <ryah>http://abadore.no.de/
21:07:15  <ryah>it's working
21:07:20  <ryah>so far...
21:12:22  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:47:47  * piscisaureusjoined
21:58:42  * piscisaureusquit (Ping timeout: 246 seconds)
22:08:03  * mralephquit (Quit: Leaving.)
22:13:49  * indutnyquit (Read error: Connection reset by peer)
22:13:49  * johnm1234_quit (Remote host closed the connection)
22:14:43  * johnm1234_joined
22:24:53  * johnm1234_quit (Ping timeout: 252 seconds)
23:19:19  <CIA-75>node: Ben Noordhuis master * rd2d53d4 / (4 files in 3 dirs): Bump version to v0.5.5 - http://git.io/3io7aw
23:28:19  <CIA-75>node: Ben Noordhuis master * r8342f31 / src/node_version.h : Now working on 0.5.6 - http://git.io/ocJq9g
23:43:53  * bnoordhuisquit (Ping timeout: 245 seconds)
23:46:13  * bnoordhuisjoined
23:50:18  <igorzi>ryah: https://github.com/igorzi/node/commit/a54b6125632812b3febb4a9978ab177394e2a6c2
23:51:44  <DrPizza>igorzi: needs a "generate projects only" goal
23:52:07  * arlolrajoined
23:52:18  <igorzi>DrPizza: there's "nobuild" option
23:52:54  <DrPizza>oh
23:52:57  <igorzi>DrPizza: is that sufficient? or do you need something else?
23:52:57  <DrPizza>I guess that works
23:53:48  <DrPizza>oh it looks like that does the job
23:53:49  <DrPizza>yes
23:53:51  <DrPizza>that's fine