00:00:06  <DrPizza>ryah: have a forwarding function that retrieves the function object from the void* and calls that
00:00:23  <ryah>piscisaureus: yes i think that's something we can do
00:00:27  <ryah>piscisaureus: but not now
00:01:08  <ryah>another stratagy is to split the header file into several
00:01:14  <ryah>and have uv-tcp.a libraries
00:01:19  <ryah>uv-pipe.a
00:01:36  <ryah>uv-cares.a
00:01:37  <ryah>etc
00:03:24  <ryah>piscisaureus: i think if we get to the uv_listen(..., share = true)
00:03:31  <ryah>its going to be pretty awesome
00:07:07  <piscisaureus>ryah: https://github.com/joyent/libuv/blob/master/src/win/req.c#L92-148
00:07:07  <piscisaureus>painful to split up without #defines --^
00:08:12  <ryah>we need more docs
00:08:39  <ryah>by which i mean comments in the header file
00:09:24  <piscisaureus>I wonder how the rust guys delt with that
00:09:32  <piscisaureus>I believe they have a release that uses uv now
00:09:43  <piscisaureus>"release" or whatever a build
00:10:07  <ryah>i just notified graydon today that we're starting the mulitiplicty effort over
00:11:16  <piscisaureus>what did he say?
00:11:25  <ryah>he said cool
00:11:30  <piscisaureus>I'd think rust's requirements are pretty specific
00:11:40  <piscisaureus>they'd be better off with the iocp model
00:14:46  <piscisaureus>https://github.com/graydon/rust/blob/master/src/rt/rust_uv.cpp#L295-301
00:14:53  <piscisaureus>platform!
00:15:14  <CIA-95>libuv: Igor Zinkovsky zero_reads * rff7d1ef / src/win/tcp.c : Issue the read_cb with 0-bytes in case of read_stop - http://bit.ly/rbUuv4
00:15:22  <igorzi>iscisaureus: --^
00:15:36  <piscisaureus>hat's me :-)
00:15:51  <DrPizza>piscisaureus: whoa, if that's really necessary (the rust snippet) that is rather sad
00:15:57  <DrPizza>but they don't have to use direct initialization
00:16:02  <piscisaureus>no
00:16:36  * graydonprofesses ignorance, didn't write that part
00:17:10  <piscisaureus>\o/ he's alive
00:17:55  <graydon>piscisaureus: you think we should be .. bypassing uv entirely?
00:18:08  <DrPizza>so what is this rust thing
00:18:30  <bnoordhuis>ryah: re comments in header file: i'll add them
00:18:35  <piscisaureus>graydon: bypassing uv for what? You mean, writing your own libuv?
00:18:53  <graydon>piscisaureus: "they'd be better off with the iocp model" <-- wondering what you mean by this
00:19:06  <piscisaureus>graydon: oh :-)
00:19:27  <ryah>graydon: we're debating how we're going to dispatch events in libuv when we have multiple threads
00:19:39  <piscisaureus>graydon: on libuv callbacks are bound to the thread that runs the loop atm
00:19:45  <ryah>graydon: if handles should be stuck to a single thread - or if they should get events on every thread (the iocp model)
00:20:19  <ryah>we need a constructor for uv_buf
00:20:26  <piscisaureus>yes
00:20:32  <ryah>i'll add it
00:20:44  <DrPizza>ryah: what are v8's threading requirements
00:21:14  <piscisaureus>DrPizza: you can only run a vm on one thread at a time
00:21:24  <graydon>piscisaureus: ah, ok, I over-read the statement. I don't know exactly which is best for us but either is better than "all events hit one thread", which I think is the current strategy :)
00:21:26  <ryah>what piscisaureus said
00:21:41  <DrPizza>so uv callbacks that in turn call node callbacks that in turn call javascript callbacks need to run on the "right" thread
00:21:53  <piscisaureus>DrPizza: yeah
00:22:02  <DrPizza>so how is there a decision to make?
00:22:17  <DrPizza>or is the question "does uv find the right thread, or do you leave that up to the calling code"?
00:22:18  <ryah>i think we're fairly agreed that we want to know where our events will happen
00:22:39  <ryah>that is that libuv takes care of it
00:22:39  <piscisaureus>yes - it's the only way to make it play nice with v8
00:22:53  <ryah>a handle is tied to a "loop"
00:23:08  <piscisaureus>a loop runs on 1 thread
00:23:11  <DrPizza>I'm sure you could do it in node
00:23:14  <DrPizza>but it seems much better to do it in uv
00:23:21  <DrPizza>make handles have loop affinity
00:23:41  <piscisaureus>ryah: although we could still add the ability to run a loop on multiple threads
00:23:48  <piscisaureus>if we're willing to deal with a lot of locking
00:24:04  <DrPizza>I mean, I could see a case for having an OPTION of marking a loop as thread-neutral
00:24:05  <DrPizza>er
00:24:07  <DrPizza>of marking a HANDLE
00:24:09  <DrPizza>not a loop
00:24:22  <DrPizza>of saying "oh you can call these callbacks on any old thread"
00:24:37  <ryah>piscisaureus: yeah i think in libev we can simply call ev_run() in multiple threads
00:25:17  <piscisaureus>ryah: I don't think so - libev doesn't protect it's structures
00:25:51  <igorzi>piscisaureus: yay or nay? (https://github.com/joyent/libuv/commit/ff7d1ef8905b79d44b5c64a58c3a3534bd991af3)
00:26:19  <piscisaureus>igorzi: yes I was trying to dig through it :-)
00:26:32  <ryah>piscisaureus: you're right
00:28:15  <piscisaureus>igorzi:
00:28:15  <piscisaureus>+ /* Report 0-byte read to give the caller a chance to free the buffer. */
00:28:15  <piscisaureus>+ uv_set_sys_error(WSAEWOULDBLOCK);
00:28:15  <piscisaureus>+ handle->read_cb((uv_stream_t*)handle, 0, handle->read_buffer);
00:28:43  <piscisaureus>If we're here than something was read, right?
00:28:49  <piscisaureus>*then
00:28:59  <piscisaureus>why not just report what you've read
00:29:17  <piscisaureus>instead of lying that you read 0
00:30:21  <igorzi>piscisaureus: ok.. that wouldn't go against what read_stop was trying to do, right?
00:30:44  <piscisaureus>igorzi: well, we decided that read_stop doesn't immediately block read_cb callbacks
00:30:53  <piscisaureus>it just stops reading as early as possible
00:30:57  <piscisaureus>also
00:31:15  <piscisaureus>otherwise, if you resume later you'll miss that piece of data
00:31:40  <piscisaureus>I think this branch could just go away
00:32:26  <piscisaureus>igorzi: so it would be
00:32:27  <piscisaureus>if (!(handle->flags & UV_HANDLE_TCP_ZERO_READ)) {
00:32:27  <piscisaureus> if (InternalHigh > 0) {
00:32:27  <piscisaureus> // Read something
00:32:27  <piscisaureus> } else {
00:32:27  <piscisaureus> // EOF
00:32:27  <piscisaureus> }
00:32:28  <piscisaureus> goto done;
00:32:28  <piscisaureus>}
00:33:40  <piscisaureus>UINT should be unsigned int or just int -- it's not a value that we pass into the windows api
00:33:45  <piscisaureus>apart from that lgtm
00:34:07  <igorzi>piscisaureus: ok, thanks
00:36:51  * piscisaureusbully
00:37:59  <piscisaureus>slurp: reset
00:39:13  <ryah>review pleae https://gist.github.com/1153020
00:39:57  <piscisaureus>+1
00:40:12  <igorzi>piscisaureus: btw, in your pseudo-code above, we don't always want to go to done if (!(handle->flags & UV_HANDLE_TCP_ZERO_READ)), right? in case we did read something, we might need to keep reading in the while loop.
00:40:37  <piscisaureus>igorzi: maybe
00:41:15  <piscisaureus>igorzi: but we should do that only if the overlapped read call filled the buffer completely
00:41:24  <igorzi>piscisaureus: yes, exactly
00:41:57  <bnoordhuis>ryah: lgtm but s/Construtor/Constructor/
00:42:43  <ryah>thanks
00:43:09  <ryah>bnoordhuis: which editor do you use btw?
00:43:13  <ryah>(so i can judge you)
00:43:19  <bnoordhuis>ryah: vim or eclipse
00:43:26  <bnoordhuis>or ed!
00:43:29  <CIA-95>libuv: Ryan Dahl master * re5a938f / (include/uv.h src/uv-common.c test/echo-server.c): Add uv_buf_init() constructor - http://bit.ly/oeqNjg
00:43:30  <ryah>really?
00:43:35  <ryah>you can use ed?
00:43:35  <bnoordhuis>ed? no
00:43:48  <bnoordhuis>that is, can use it, don't like to
00:44:13  <piscisaureus>is that like edlin?
00:44:22  <bnoordhuis>but ed and worked better than the vi that was installed on our solaris 9 system :)
00:44:30  <ryah>graydon, robarnold: http://bit.ly/oeqNjg use this instead of https://github.com/graydon/rust/blob/master/src/rt/rust_uv.cpp#L295-301
00:44:53  <bnoordhuis>what about you, ryah?
00:44:58  <ryah>vim
00:45:00  <graydon>cat
00:45:15  <bnoordhuis>dd /dev/sda
00:45:23  <bnoordhuis>i win
00:45:35  <bnoordhuis>ryah: what do you use for auto-completion?
00:45:45  <ryah>^n
00:45:55  <bnoordhuis>yeah, that's the thing
00:45:57  <graydon>$ ls -l `which dd` `which cat`
00:45:57  <graydon>-rwxr-xr-x 1 root root 60064 2010-09-21 11:32 /bin/cat
00:45:58  <graydon>-rwxr-xr-x 1 root root 60120 2010-09-21 11:32 /bin/dd
00:46:03  <graydon>I think the minimalism prize goes to cat, sir
00:46:04  * mralephquit (Quit: Leaving.)
00:46:19  <bnoordhuis>i'd switch to vim completely if autocomplete in eclipse wasn't 10x better
00:46:30  <graydon>(60kb though? for shame)
00:46:35  <bnoordhuis>graydon: only if you cat /dev/sda
00:46:36  <ryah>autocomplete - psh
00:46:44  <piscisaureus>cat is still an executable
00:46:54  <ryah>bnoordhuis: ctrl+n is good enough
00:46:55  <piscisaureus>copy con is da shit
00:47:02  <bnoordhuis>ryah: bwahaha
00:47:05  <ryah>although - maybe i just dont know the joys of a real ide :)
00:47:18  <ryah>ive only ever used vim
00:47:19  <CIA-95>libuv: Igor Zinkovsky master * r422c139 / (include/uv-win.h src/win/internal.h src/win/tcp.c): Windows: Pre-allocate buffers for overlapped WSARecv if the number of active tcp streams is below 50. - http://bit.ly/o99CYw
00:47:26  <robarnold>ryah: thanks for the link. will add that to my todo list
00:47:39  <ryah>igorzi++
00:47:50  <piscisaureus>yes igorzi++
00:47:52  <ryah>igorzi: got any benchmark numbers?
00:48:53  <igorzi>ryah: i'll run uv bench right now on windows & linux (same machine)
00:49:49  <ryah>arlo is going to hook up libuv's benchmarks to http://arlolra.no.de/ soon
00:49:54  <ryah>which will be very helpful
00:49:59  <bnoordhuis>sweet
00:50:10  <bnoordhuis>helpful and painful both, i suspect
00:50:13  <piscisaureus>Oh nice
00:50:29  <piscisaureus>Does he hook the build bots for this?
00:50:39  <piscisaureus>s/bots/slaves/
00:51:11  <piscisaureus>ryah: or do you mean --use-uv benchmarks?
00:52:06  <ryah>piscisaureus: "make bench" in libuv
00:52:26  <ryah>getting funding, as always, for this stuff is like pulling teeth
00:52:57  <piscisaureus>your company is too poor
00:53:13  <ryah>stingy i think is the correct word :)
00:53:42  <piscisaureus>sad
00:54:20  <piscisaureus>ryah: but what do you need funding for?
00:54:25  <ryah>for arlo
00:54:30  <piscisaureus>oh heh
00:55:22  <ryah>im going to cut v0.4.11 unless there are any objections?
00:55:32  <bnoordhuis>why would there be?
00:55:40  <piscisaureus>0.4 is not my branch
00:55:48  <piscisaureus>not invented here
00:56:00  <bnoordhuis>dit is niet mijn branch, vriend!
00:56:11  <piscisaureus>bnoordhuis: muhahahaha
00:56:25  <bnoordhuis>^ dutch meme
00:56:26  <ryah>vriend is how you spell friend?
00:56:30  <bnoordhuis>yep
00:56:34  * ryahshakes his head
00:56:51  <ryah>you dutch people...
00:57:11  <bnoordhuis>go on
00:57:43  <ryah>immer mit ihren lustige gebaute worten
00:59:10  <ryah>deutsch ist normal und hoert sich guet aus - dutch ist kommish.
00:59:45  <bnoordhuis>hoert :)
00:59:49  <ryah>english is also normal sounding
01:00:01  <ryah>and naturally i cant speak germany
01:00:55  <piscisaureus>this accent-free german spelling looks really weird to me
01:01:54  <bnoordhuis>so how long did you live in germany, ryah?
01:02:35  <ryah>bnoordhuis: 2.5 years
01:03:09  <bnoordhuis>how old are you anyway?
01:03:45  <bnoordhuis>and how did you end up in germany?
01:04:19  <ryah>30, gf
01:04:51  <bnoordhuis>ah figures, that's how i ended up in the randstad here
01:05:12  <piscisaureus>good for you
01:05:27  <piscisaureus>you don't really want to die in eanske do you?
01:05:33  <bnoordhuis>hah
01:05:46  <bnoordhuis>enschede is quite alright for a place where there's nothing to do
01:05:55  <bnoordhuis>friendly people, low rents
01:06:20  <bnoordhuis>i had a 60m2 apartment for EUR 250/m
01:06:29  <bnoordhuis>you're not going to find that here
01:06:35  <piscisaureus>oh man
01:06:53  <piscisaureus>here it's like 3x that
01:06:53  <ryah>O_O
01:08:18  <piscisaureus>bnoordhuis besides that 10 years ago
01:08:24  <piscisaureus>well ok 9
01:08:29  <ryah>sf sucks - i have a ~40m^2 place for $1300
01:08:38  <bnoordhuis>hah, damn
01:08:41  <piscisaureus>oh shit
01:08:46  <ryah>and its really the cheapest
01:08:57  <bnoordhuis>that's why i never considered moving to silicon valley
01:09:30  <piscisaureus>$ 1300 x 0.68 = E 844
01:09:41  <bnoordhuis>yeah, for 40m2
01:09:44  <piscisaureus>Normal price range here
01:09:49  <piscisaureus>but smal-ish yeah
01:09:57  <bnoordhuis>my mortgage is less than that
01:10:12  <piscisaureus>hmm
01:10:17  <piscisaureus>I should move to gouda then
01:10:28  <bnoordhuis>yeah, gouda is okay
01:10:39  <bnoordhuis>relatively cheap
01:10:41  * ryahshould eat gouda...
01:10:42  <piscisaureus>sounds almost ubelievably cheap
01:10:46  <bnoordhuis>nice people, lots of water and green
01:10:54  <bnoordhuis>i did bleed the sellers dry
01:10:59  <bnoordhuis>they were in something of a bind
01:11:29  <bnoordhuis>paid less than 190K, go me
01:12:20  <piscisaureus>If you buy a house for 190k you get 40m2 these days
01:12:41  <bnoordhuis>in leiden?
01:12:43  <bnoordhuis>eh, delft
01:13:04  <piscisaureus>well ok it may not be so bad
01:13:06  <piscisaureus>http://www.funda.nl/koop/delft/0-200000/
01:13:57  <bnoordhuis>fun fact: friends in enschede bought a house for 96K this year
01:14:05  <bnoordhuis>admittedly it needs some work
01:14:07  <bnoordhuis>but still
01:14:24  <bnoordhuis>it's got a big-ass garden too
01:14:56  <piscisaureus>I want to move to Den Bosch
01:14:59  * ryahneeds to move back to eu
01:15:07  <bnoordhuis>heh
01:15:14  <bnoordhuis>den bosch? why?
01:15:33  <piscisaureus>I want to be able to reach amsterdam in a reasonable amount of time
01:15:39  <piscisaureus>my gf is going to work in Eindhoven
01:15:48  <bnoordhuis>the only good thing that comes out of brabant is the intercity
01:15:59  <piscisaureus>I like den bosch
01:16:03  <piscisaureus>not as good as groningen btw
01:16:07  <bnoordhuis>meh
01:16:15  <bnoordhuis>better than eindhoven, i'll give it that
01:16:18  <piscisaureus>sure
01:16:23  <piscisaureus>eindhoven is terrible
01:16:25  <bnoordhuis>but that's not much of a challenge
01:16:50  <bnoordhuis>what about maastricht?
01:16:59  <piscisaureus>too far from everything
01:17:59  <piscisaureus>I should find me a gf without a job
01:18:05  <piscisaureus>so I can live where I want
01:18:12  <piscisaureus>(like ben :-p)
01:18:33  <bnoordhuis>hah
01:20:28  <DrPizza>dutch makes my ears hurt
01:21:59  <piscisaureus>english dislocates my jaw
01:22:53  * graydonquit (Quit: Leaving.)
01:22:58  <DrPizza>well...
01:23:01  <DrPizza>you are doing it wrong!
01:23:35  <bnoordhuis>i don't hate english
01:23:46  <bnoordhuis>but it's kinda a wussy language
01:23:50  <bnoordhuis>no hard vowels to speak of
01:24:01  <bnoordhuis>how can you cuss in that?
01:26:01  <DrPizza>wtf is hard vowel
01:26:02  <ryah>http://nodejs.org/docs/v0.4.11/#download
01:26:05  <ryah>^-- can you test
01:26:06  <DrPizza>how can a vowel be hard
01:27:07  <bnoordhuis>DrPizza: http://translate.google.com/#nl|en|garage
01:27:46  <DrPizza>that sounds awful
01:28:58  <bnoordhuis>that google bot pronounces it rather sedately actually, colloquial dutch is much coarser
01:31:17  <piscisaureus>#download?
01:31:44  <bnoordhuis>looks okay to me, no dead links or anything
01:34:15  <ryah>test the build please :)
01:35:22  <bnoordhuis>aside, we should provide md5 / sha1 hashes of the tarballs
01:37:45  <ryah>yeah...
01:37:53  <ryah>we talked about it this week
01:37:57  <ryah>we might start signing them
01:39:59  <bnoordhuis>as in `gpg --sign`?
01:40:47  <bnoordhuis>maybe overkill, i meant putting up a list of md5 hashes so you know your download isn't corrupted
01:41:52  <bnoordhuis>0.4.11 builds, running tests
01:42:43  <bnoordhuis>tests pass
01:44:30  <ryah>thanks
01:47:00  <CIA-95>node: Ryan Dahl v0.4 * ra745d19 / (5 files in 3 dirs): Bump version to v0.4.11 - http://bit.ly/r0mHSq
01:47:00  <CIA-95>node: Ryan Dahl v0.4 * rdc57872 / src/node_version.h : Now working on v0.4.12 - http://bit.ly/riuiuF
01:48:01  <ryah>im force pushing v0.4
01:48:04  <ryah>over isaacs commit
01:48:08  <ryah>i fixed it up a little
01:48:11  <CIA-95>node: isaacs v0.4 * rb4712bf / doc/api/url.markdown : Close #1544 Document slashesDenoteHost flag in url.parse - http://bit.ly/nQvYWm
01:48:13  <ryah>s/fixed/fucked/
01:48:33  <isaacs>was just a doc patch.
01:48:35  <isaacs>no biggie
02:15:08  <CIA-95>libuv: Bert Belder spawnext * r8ed2ffb / src/win/process.c : Windows: when searching path, look only for .com and .exe files - http://bit.ly/otwF5x
02:15:14  <piscisaureus>^-- igorzi: can you review this?
02:16:03  <ryah>why do you want this?
02:16:21  <DrPizza>piscisaureus: can't you just leave the searching up to CreatePRocess?
02:16:23  <ryah>this search path stuff is so painful :/
02:16:28  <DrPizza>CreateProcess already has its own rules for searching
02:16:33  <DrPizza>does uv need to impose its own?
02:17:00  <piscisaureus>DrPizza: CreateProcess doesn't search at all
02:17:07  <DrPizza>yes it does
02:17:55  <DrPizza>just pass the whole lot as lpCommandLine, don't bother with lpApplicationName
02:18:13  <DrPizza>It will also attempt to append .exe
02:18:19  <DrPizza>though .com must be set explicitly
02:19:13  <DrPizza>or are you wanting to use lpApplicationName and emulate the lpCommandLine rules?
02:20:09  <piscisaureus>I don't care how we do it as long as it works right
02:20:30  <piscisaureus>why does it not try .com
02:20:37  <DrPizza>it just doesn't
02:20:38  <piscisaureus>seems like it almost got it right
02:21:04  <DrPizza>it will add the .exe if necessary
02:21:06  <DrPizza>but not .com
02:21:22  <DrPizza>(if you use lpCommandLine)
02:22:26  <DrPizza>if lpApplicationName is blank and you use lpCommandLine, it will both add the .exe, and also search the path, current directory, etc.
02:22:42  <DrPizza>s/blank/null/
02:23:06  <piscisaureus>we should consider that for simplicity sake
02:23:25  <piscisaureus>but people should be able to spawn "format c:" :-p
02:28:34  <piscisaureus>DrPizza: "If lpApplicationName is NULL, the module name portion of lpCommandLine is limited to MAX_PATH characters."
02:28:39  <piscisaureus>^-- also unfortunate
02:28:43  * isaacsquit (Quit: isaacs)
02:28:53  <piscisaureus>oh wait that's just the file name
02:28:54  <DrPizza>true, but rarely disastrous
02:28:57  <DrPizza>yes
02:29:11  <DrPizza>so you're allowed MAX_PATH before the actual program arguments
02:29:55  <piscisaureus>Searching "The directory from which the application loaded." at the very first doesn't make me happy
02:30:22  <piscisaureus>And not using .com
02:30:22  <piscisaureus>For the rest the search procedure seems reasoable
02:30:40  <DrPizza>perhaps, but it's what people are most likely to expect, I think
02:30:58  <piscisaureus>DrPizza: search the current directory first
02:31:01  <piscisaureus>that makes more sense
02:31:33  <DrPizza>well, it's done that way so that you can set CWD to be somewhere such as where your documents are stored
02:31:44  <DrPizza>but still have the program in program files
02:31:51  <DrPizza>so if the program tries to spawn its child processes
02:32:05  <DrPizza>it'll look in its own directory first
02:32:10  <DrPizza>rather than your document directory
02:32:15  <DrPizza>which makes sense
02:34:42  * brsonquit (Ping timeout: 276 seconds)
02:35:30  <piscisaureus>DrPizza: I want to use rules that people are reasonable familiar with, hence the attempt to follow cmd semantics.
02:35:30  <piscisaureus>Also I'd rather not have that "bla" (=spawn in node) and "cmd /c" (=exec in node) start different programs.
02:36:55  <DrPizza>I don't think cmd's semantics are even defined anywhere
02:37:09  <DrPizza>cmd can do all sorts of weird stuff
02:37:19  <DrPizza>its logic is more akin to ShellExecute
02:37:26  <piscisaureus>generally it looks in cmd, then searches path
02:37:48  <piscisaureus>if it doesn't find a file it tries appending extensions from pathext
02:38:17  <DrPizza>which libuv can't do
02:38:21  <DrPizza>unless it wants to shellexecute
02:38:32  <DrPizza>because you can't createprocess anything other than .exe or .com
02:38:43  <piscisaureus>indeed
02:39:05  <piscisaureus>(unless you rename a .exe to .bat :-p)
02:39:44  <bnoordhuis>night, guys
02:39:49  <piscisaureus>DrPizza: I propose to leave it in for a while
02:39:57  <piscisaureus>bnoordhuis: night.
02:40:18  <piscisaureus>DrPizza: we'll throw it out when we find more problems / it gets painful to maintain
02:40:24  <DrPizza>hrm
02:40:33  <DrPizza>I dunno, I don't really like it as is
02:40:34  <DrPizza>it's not createprocess semantics
02:40:42  <DrPizza>it's not cmd semantics
02:40:46  <DrPizza>it's just somewhere in between
02:40:52  <DrPizza>and not actually documented!
02:41:54  <piscisaureus>yeah
02:42:06  <piscisaureus>maybe I prefer spawnvpe semantics then
02:42:08  <DrPizza>If anything
02:42:16  <DrPizza>you should take the command name
02:42:22  <DrPizza>pass it to SearchPath()
02:42:26  <DrPizza>and use that result for lpApplicationName
02:42:37  <piscisaureus>searchpath is even worse
02:42:55  <piscisaureus>iirc -) let me have a look again
02:42:57  <DrPizza>searchpath does CWD -> system path
02:43:40  <DrPizza>it's still not an exact match
02:43:45  <DrPizza>but it's not far off
02:44:11  * bnoordhuisquit (Ping timeout: 240 seconds)
02:45:24  <piscisaureus>DrPizza: file:///C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/crt/src/spawnve.c
02:46:17  <piscisaureus>er
02:46:17  <piscisaureus>file:///C:/Program%20Files%20%28x86%29/Microsoft%20Visual%20Studio%2010.0/VC/crt/src/spawnvpe.c
02:47:25  <DrPizza>that if statement starting on line 89 is the most awful thing I have ever seen
02:48:10  <piscisaureus>no indentation also :-/
02:53:15  <DrPizza>man
02:53:22  <DrPizza>check out that lpReserved2 stuff it does in dospawn.c
02:53:32  <DrPizza>that's some crafty bullshit
02:53:39  <DrPizza>cbReserved2
02:53:39  <DrPizza> Reserved for use by the C Run-time; must be zero.
02:53:39  <DrPizza>lpReserved2
02:53:39  <DrPizza> Reserved for use by the C Run-time; must be NULL.
02:53:45  <DrPizza>but VC++ uses it!
02:54:28  <piscisaureus>DrPizza: you're looking at the c run-time source code
02:54:33  <DrPizza>sure
02:54:35  <piscisaureus>it is allowed to do that
02:54:36  <DrPizza>but
02:54:38  <DrPizza>no
02:54:44  <DrPizza>I'm looking at ~a~ C runtime source code
02:54:49  <DrPizza>~Windows~ doesn't ship with a C runtime
02:54:55  <DrPizza>you could be using borland
02:55:20  <piscisaureus>DrPizza: we could abuse it to pass additional handles to a child process
02:55:31  <DrPizza>VC++ is using undocumented techniques to pass handles to child processes
02:55:40  <DrPizza>that only the VC++ runtime understands
02:55:48  <piscisaureus>Yeah I know
02:56:17  <piscisaureus>DrPizza: it does this because exec() is supposed to replace the process image and keep file descriptors open
02:56:31  <DrPizza>sure
02:56:44  <DrPizza>I wonder if replicating it would be useful
02:56:51  <DrPizza>as a way of passing handles to children
02:56:55  <piscisaureus>it's awful
02:56:58  <DrPizza>yes
02:57:01  <DrPizza>I agree
02:57:10  <piscisaureus>but moreover - it's completely pointless
02:57:19  <piscisaureus>who uses that when you can't have fork() ?
02:57:43  <DrPizza>automatic handle sharing, you mean?
02:57:59  <DrPizza>passed through hokey magical methods
02:58:36  <piscisaureus>I mean: actually using the file descriptors that the "parent" process sent you
03:00:03  <DrPizza>it all looks very janky
03:10:26  <piscisaureus>DrPizza: https://github.com/joyent/libuv/issues/122#issuecomment-1833050
03:42:34  <DrPizza>piscisaureus: comment added
03:58:58  <igorzi>ryah: i just realized that when booting the machine into linux, /proc/cpuinfo only shows 2 processors (the machine has 2 cpus x 6 cores each)
04:00:23  <igorzi>how do i get it to recognize other cores? (i see all the cores in the bios, and windows recognizes all of them)
04:32:36  * CIA-95quit
04:33:02  * CIA-75joined
05:22:01  * piscisaureusquit (Ping timeout: 258 seconds)
07:07:23  * mralephjoined
07:59:05  * mralephquit (Quit: Leaving.)
08:10:25  <CIA-75>libuv: Igor Zinkovsky pound-fixes * rdcf8770 / test/benchmark-pound.c : Fix pipe-pound and clean-up - http://bit.ly/oFboc3
08:12:26  <igorzi>ryah: this fixes pound bench for pipes, and also does some clean-up. please review.
08:16:29  <igorzi>i tried running the pound benchmark on another windows machine (2-proc), and i see much more stable numbers with your change. i think we should land it as soon as possible.
12:36:59  * piscisaureusjoined
13:07:22  * bnoordhuisjoined
13:20:09  <bnoordhuis>piscisaureus: you can start on udp if you like
13:22:12  <bnoordhuis>piscisaureus: btw, https://github.com/joyent/node/issues/1553
13:33:24  <piscisaureus>bnoordhuis: so process.on('SIGINT') crashes. That is unexpected but maybe it's not bad for the time being.
13:33:59  <bnoordhuis>piscisaureus: i wasn't sure if it's actually supposed to work on windows
13:34:07  <piscisaureus>It's not
13:34:28  <piscisaureus>It crashes because the signal watcher is disabled in windows btw
13:34:34  <piscisaureus>s/in/on
13:38:46  <bnoordhuis>piscisaureus: https://gist.github.com/cc11217bf271d8a897c7 <- udp api 1.0
13:39:04  <bnoordhuis>rfc please
13:40:14  <piscisaureus>bnoordhuis: "The remainder has been truncated."
13:40:59  <bnoordhuis>piscisaureus: yes?
13:40:59  <piscisaureus>Shouldn't that be "The remainder will be received in the next callback invocation?"
13:41:06  <piscisaureus>I thought that was the idea
13:41:47  <piscisaureus>bnoordhuis:
13:41:47  <piscisaureus>"MSG_PARTIAL This flag is for message-oriented sockets only. On output, this flag indicates that the data is a portion of the message transmitted by the sender. Remaining portions of the message will be transmitted in subsequent receive operations. A subsequent receive operation with MSG_PARTIAL flag cleared indicates the end of the sender's message.
13:41:47  <piscisaureus>As an input parameter, this flag indicates that the receive operation should complete even if only part of a message has been received by the service provider."
13:41:55  <bnoordhuis>well... it's something i have to test still
13:42:09  <bnoordhuis>but i think the unices only give you one shot to read a dgram
13:42:45  <piscisaureus>bnoordhuis: http://msdn.microsoft.com/en-us/library/ms683242%28v=vs.85%29.aspx
13:43:16  <bnoordhuis>let's stick to udp for now, shall we? :)
13:43:23  <piscisaureus>To what unix signals would the CTRL_(C|BREAK|CLOSE|LOGOFF)_EVENT map?
13:44:04  <bnoordhuis>ctrl-c, ctrl-break -> sigint
13:44:16  <bnoordhuis>what's ctrl-close and ctrl-logoff?
13:44:34  <bnoordhuis>ctrl-close is sigterm
13:44:39  <piscisaureus>close if you close the console window
13:44:55  <piscisaureus>logoff and shutdown are not extremely important
13:45:03  <bnoordhuis>ctrl-logoff -> no equivalent
13:45:35  <bnoordhuis>ctrl-shutdown is usually a sigterm followed by a sigkill a little later
13:45:49  <piscisaureus>ok but sigkill is not received right?
13:45:55  <bnoordhuis>no, never
13:46:52  <bnoordhuis>ctrl-shutdown -> just sigterm is okay
13:54:31  <bnoordhuis>you know, udp send should probably have a flags argument too
13:55:01  <bnoordhuis>or maybe... the only thing you'd use it for is UDP_CORK
13:55:13  <bnoordhuis>and when do you actually use that?
13:57:59  <piscisaureus>UDP_CORK?
14:00:14  <bnoordhuis>piscisaureus: instructs the kernel not to send data you write to the socket until you disable UDP_CORK again
14:00:35  <bnoordhuis>iow, folds multiple writes into a single dgram
14:03:45  <bnoordhuis>piscisaureus: let's rethink UV_UDP_PARTIAL, things work differently on unices
14:04:12  <bnoordhuis>i can ioctl(FIONREAD) to find out how many bytes are pending
14:04:47  <bnoordhuis>ah, but the size argument to alloc_cb is called suggested_size of course
14:05:50  <DrPizza>piscisaureus: shouldn't windows wire up the ctrl-c handler into being SIGINT?
14:05:57  <DrPizza>I realize it's not th esame
14:06:01  <DrPizza>and that windows doesn't really have signals
14:06:58  <DrPizza>oh bnoordhuis already suggested that
14:06:59  <DrPizza>sorry
14:07:23  <DrPizza>I should read through my whole buffer before commenting
14:08:41  <bnoordhuis>piscisaureus: let's make it the responsibility of alloc_cb to provide a large enough buffer
14:09:20  <bnoordhuis>dgrams are small by their nature so it's not an unreasonable assumption
14:14:26  <piscisaureus>bnoordhuis: what's wrong with UV_UDP_PARTIAL?
14:15:23  <bnoordhuis>piscisaureus: MSG_TRUNC on unices means 'incomplete read, remainder discarded'
14:29:58  <piscisaureus>bnoordhuis: okay
14:30:23  <piscisaureus>bnoordhuis: but we still might want to report to the user that the receive was incomplete
14:30:32  <bnoordhuis>piscisaureus: yeah
14:30:47  <bnoordhuis>how does that work on windows?
14:30:49  <piscisaureus>maybe we can set status to -1 and set the error code to UV_ETRUNC?
14:31:22  <piscisaureus>bnoordhuis: well
14:31:45  <piscisaureus>on windows (I assume) it will discard the rest of the packet if I dont specify the MSG_PARTIAL flag
14:32:11  <bnoordhuis>'maybe we can set status to -1 and set the error code to UV_ETRUNC?' <- that sucks, loses data
14:32:24  <piscisaureus>which data?
14:32:33  <piscisaureus>we can still return the buf can't we?
14:32:49  <bnoordhuis>yes but the api consumer has to take special care
14:32:58  <piscisaureus>true
14:33:03  <piscisaureus>okay so maybe not
14:33:07  <bnoordhuis>if (error && error == UV_ETRUNC) { } else if (error) { }
14:33:10  <bnoordhuis>^ sucks
14:33:29  <piscisaureus>well we have special care for UV_EOF too
14:33:44  <bnoordhuis>yeah, that sucks as well
14:34:08  <bnoordhuis>should have been status == 0 and a zero read
14:34:09  <piscisaureus>maybe we should expand the 'status" arg a bit then :-)
14:34:31  <bnoordhuis>what do you propose?
14:36:00  <piscisaureus>if (status == 0) {
14:36:00  <piscisaureus> // Yay! \o/
14:36:00  <piscisaureus>} else if (status == UV_EOF) {
14:36:00  <piscisaureus> // Go home
14:36:00  <piscisaureus> if (buf.base) free(buf.base);
14:36:01  <piscisaureus>} else {
14:36:01  <piscisaureus> // Sadface :-(
14:36:02  <piscisaureus> if (buf.base) free(buf.base);
14:36:02  <piscisaureus>}
14:39:36  <piscisaureus>bnoordhuis: my further thoughts are expressed at the end of this song: http://www.youtube.com/watch?v=hH7SRF8T3F8&feature=related#t=2m48s
14:39:49  <bnoordhuis>youtube zombie :)
14:40:00  <bnoordhuis>how do you get any work done?
14:40:04  <bnoordhuis>pquerna: ^
14:40:07  <piscisaureus>I don't. Why?
14:40:36  <piscisaureus>bnoordhuis: btw it looks like i will have to use msg_partial after all
14:40:42  <bnoordhuis>yeah, why?
14:40:44  <piscisaureus>since we want to do 0 reads
14:41:08  <piscisaureus>and truncating every package after the 0th byte seems somewhat unreasonable
14:41:22  <bnoordhuis>i'm not following
14:41:41  <bnoordhuis>oh wait, are you talking about that windows optimization?
14:41:45  <piscisaureus>bnoordhuis: we don't poll()
14:41:57  <piscisaureus>bnoordhuis: no, the non-optimized case
14:42:16  <piscisaureus>where we read 0 bytes first to figure out that there is stuff in the kernel read buffer
14:42:22  <piscisaureus>then we use nonblocking reads to get the data out
14:42:42  <bnoordhuis>like ioctl(FIONREAD) on unices?
14:42:55  <piscisaureus>bnoordhuis: well we don't actually call fionread
14:42:57  <piscisaureus>hmm
14:43:20  <piscisaureus>maybe it's not a bad idea to use that when reading datagrams btw
14:43:39  <bnoordhuis>yes
14:43:45  <bnoordhuis>the downside is that you do two syscalls
14:49:58  <piscisaureus>yeah
14:50:21  <piscisaureus>Yes that may be unfortunate
14:59:35  <piscisaureus>I think on windows fionread may actually not return the full length of the udp message if it's long
14:59:39  <piscisaureus>so that makes it less usable
14:59:55  <bnoordhuis>right, that's no good
15:00:18  <bnoordhuis>out of curiosity: why doesn't it return the full length?
15:00:45  <piscisaureus>oh igorzi if only i could look at the windows source ♫
15:01:07  <piscisaureus>bnoordhuis: because it truncates to the socket read buffer
15:01:23  <bnoordhuis>oh right
15:01:27  <piscisaureus>but in the windows kernel socket read buffers are somewhat fluid
15:01:40  <piscisaureus>they might actually grow very big etc
15:01:41  <bnoordhuis>that's another think we want to tune sometime
15:01:44  <bnoordhuis>*thing
15:01:47  <piscisaureus>yes
15:01:54  <piscisaureus>well the socket read buffers on windows are quite ok
15:02:01  <piscisaureus>send buffers however are not well-managed
15:02:15  <bnoordhuis>on linux the defaults are alright
15:02:33  <bnoordhuis>but tuning send and receive buffers can help with throughput / latency
15:02:50  <piscisaureus>on windows boosting the send buffer size increases throughput
15:02:54  <bnoordhuis>that's a flag i probably want to add in the future
15:02:57  <piscisaureus>(on fast networks)
15:03:05  <bnoordhuis>UV_OPTIMIZE_THROUGHPUT vs UV_OPTIMIZE_LATENCY
15:03:20  <bnoordhuis>for both tcp and udp
15:05:09  <piscisaureus>bnoordhuis: that's not really a tradeoff on windows I think
15:05:32  <piscisaureus>bnoordhuis: it's more ... throughput/latency vs high number of open sockets
15:10:43  <bnoordhuis>piscisaureus: you don't have stuff like TCP_CORK vs TCP_NODELAY?
15:11:33  <bnoordhuis>one common optimization for high throughput apps is to increase the send buffer and set TCP_CORK
15:11:44  <bnoordhuis>so multiple writes get buffered and sent as one big packet
15:19:28  <piscisaureus>bnoordhuis: there is TCP_NODELAY
15:19:54  <piscisaureus>bnoordhuis: node already has an api for that (socket.SetNoDelay)
15:20:27  <piscisaureus>there's no cork afaict
15:20:35  <piscisaureus>bnoordhuis: so what do we do with msg_trunc?
15:21:22  <bnoordhuis>piscisaureus: i'm open to suggestions
15:22:12  <piscisaureus>bnoordhuis: ok so
15:22:15  <piscisaureus>we do truncate
15:22:29  <piscisaureus>the question is just how we are going to report a truncated message to the user
15:22:41  <piscisaureus>I don't know - pick anything
15:22:53  <bnoordhuis>we can set UV_UDP_TRUNCATED or something
15:22:59  <piscisaureus>ok
15:23:04  <bnoordhuis>but the behaviour needs to be consistent across operating systems
15:23:05  <piscisaureus>lets do that
15:23:16  <piscisaureus>have a test for that
15:25:44  <bnoordhuis>yep, on it
15:27:24  * isaacsjoined
15:30:09  <piscisaureus>bnoordhuis: can you land the API btw?
15:30:17  <piscisaureus>or what we have so far?
15:30:24  <bnoordhuis>i suppose so
15:30:43  <piscisaureus>I will try to have a somewhat working implementation today
15:30:58  <bnoordhuis>piscisaureus: you can pull from my repo's udp branch
15:31:04  <piscisaureus>ok
15:32:04  <CIA-75>libuv: Bert Belder master * r8ed2ffb / src/win/process.c : Windows: when searching path, look only for .com and .exe files - http://bit.ly/otwF5x
15:32:27  <piscisaureus>DrPizza: ^-- I landed it, but the path scanning might still be dropped at some point
15:33:43  <piscisaureus>DrPizza: I checked out the SearchPath solution. SearchPath is kinda neat, the only think is that it can only search for one extension
15:33:50  <piscisaureus>afaict
15:45:00  <piscisaureus>bnoordhuis: I'm not completely happy with uv_dup_init6
15:45:12  <bnoordhuis>piscisaureus: speak up
15:45:32  <piscisaureus>it's going to make the upd_wrap ugly
15:45:37  <piscisaureus>*udp
15:45:56  <bnoordhuis>you want to unify it?
15:46:01  <piscisaureus>Yes I think so
15:46:08  <piscisaureus>bnoordhuis - or
15:46:11  <piscisaureus>we can do it later
15:46:18  <piscisaureus>the functions wil be the same anyway on windows
15:46:32  <bnoordhuis>the trouble is, what happens if you try to send a ipv6 dgram over a ipv4 socket?
15:46:32  <piscisaureus>(except for one handle->flags flag)
15:46:53  <piscisaureus>bnoordhuis: err
15:47:02  <bnoordhuis>separating the api lets you handle such corner cases cleanly
15:47:44  <bnoordhuis>but it's not perfect right now
15:47:56  <bnoordhuis>full separation would mean a distinct uv_udp6_t type
15:47:59  <piscisaureus>udp_init should not do anything, just init some stuff in the handle struct
15:48:14  <piscisaureus>we'll create sockets lazily anyway
15:48:22  <piscisaureus>so if people want ipv6 they can bind
15:48:27  <bnoordhuis>piscisaureus: uv_udp_init creates the socket on unix
15:48:34  <piscisaureus>eh ok... why?
15:48:45  <bnoordhuis>doing it lazy is troublesome
15:48:48  <piscisaureus>i think tcp sockets are lazily created
15:48:53  <bnoordhuis>especially with the create -> recv case
15:49:10  <bnoordhuis>you don't know what type of socket to create
15:49:20  <bnoordhuis>and defaulting to ipv4 kind of sucks, explicit is better
15:49:43  <piscisaureus>bnoordhuis: then have people call bind or (uv_udp_set_af) before or something?
15:50:16  <bnoordhuis>requiring people to bind is slightly silly
15:50:29  <bnoordhuis>for stuff like dns you just want to grab a socket and send the dgram
15:50:39  <bnoordhuis>you don't care what port it listens on
15:50:44  <piscisaureus>bnoordhuis: the bind does not need to actually do anything
15:51:05  <piscisaureus>if you call bind('::', 0) it can just do nothing just record it's ipv6
15:51:31  <bnoordhuis>i suppose
15:51:43  <bnoordhuis>doing it in one library call leaves less room for mistake though
15:52:24  <piscisaureus>bnoordhuis: also, in the send case it's not a problem really
15:52:39  <bnoordhuis>no, it's specifically for the recv case
15:52:56  <piscisaureus>bnoordhuis: but in the recv case you'll generally want to bind anyway
15:53:05  <piscisaureus>because binding to a random port is really exotic
15:53:19  <piscisaureus>it's not so bad to let people explicitly bind port 0 in that case
15:53:24  <bnoordhuis>no, not really
15:53:31  <bnoordhuis>imagine a p2p network
15:53:42  <bnoordhuis>you set up a receiver first on a random port
15:53:51  <bnoordhuis>and once you decide to get to work
15:53:54  <bnoordhuis>you start sending packets
15:54:04  <piscisaureus>bnoordhuis: okay so -
15:54:11  <piscisaureus>that is kind of exotic isn't it?
15:54:20  <piscisaureus>what's wrong with calling bind first then?
15:54:21  <bnoordhuis>we want botnets right?
15:54:44  <bnoordhuis>having to call bind with a specific port sucks
15:54:55  <bnoordhuis>having to call bind with 0 (ephemeral) sucks too
15:55:04  <bnoordhuis>the first because you need to decide on a port number
15:55:21  <bnoordhuis>the second because if you forget to do that, things will break
15:55:28  <bnoordhuis>iow i like RAII
15:56:24  <piscisaureus>bnoordhuis: https://github.com/joyent/node/blob/master/src/tcp_wrap.cc#L109-114
15:56:31  <piscisaureus>this is what i'm concerned about
15:57:25  <bnoordhuis>solvable
15:57:33  <piscisaureus>you're now forcing the wrap to do lazy uv_udp_initx because at wrap creation time you don't know the af
15:58:48  <bnoordhuis>well... maybe
15:59:07  <bnoordhuis>it's solvable for node because the handles are created lazily
15:59:23  <piscisaureus>bnoordhuis: btw on windows you need to bind anyway
15:59:32  <bnoordhuis>yeah, why?
16:00:02  <piscisaureus>bnoordhuis: it's just a requirement for the WSASendTo / WSARecvFrom api
16:00:11  <piscisaureus>bnoordhuis: it's common
16:00:14  <piscisaureus>ConnectEx has that too
16:00:17  <bnoordhuis>god, windows sucks
16:00:29  <bnoordhuis>okay, deferred it is with the requirement to call bind
16:00:42  <piscisaureus>\o/
16:00:49  <piscisaureus>being stubborn ftw!
16:01:08  <bnoordhuis>but you'll have to explain to me why the winsock api works like that
16:01:29  <piscisaureus>bnoordhuis: remember the youtube link ^^ ?
16:01:33  <piscisaureus>listen carefully
16:01:35  <piscisaureus>it's all there
16:02:39  <piscisaureus>I wonder if that's the what "thinking" sounds like for mraleph
16:04:10  <bnoordhuis>i didn't actually watch the video
16:04:14  <bnoordhuis>so this is all going over my head
16:04:50  <piscisaureus>yes ignorance is bliss isn't it bnoordhuis?
16:05:11  <bnoordhuis>one of the few things i learned from you piscisaureus
16:06:07  <bnoordhuis>piscisaureus: so we're going back to a single uv_udp_init(uv_udp_t *handle)?
16:06:20  <piscisaureus>bnoordhuis yeah shure
16:06:22  <piscisaureus>*sure
16:06:25  <piscisaureus>wait
16:06:35  <bnoordhuis>what about socket flags? passed to uv_udp_init or uv_udp_bind?
16:06:46  <piscisaureus>I'm gonna call you
16:06:54  <piscisaureus>I want to go off irc
16:06:57  <piscisaureus>so distracting
16:07:18  <bnoordhuis>hah
16:07:19  <bnoordhuis>skype?
17:07:42  * graydonjoined
17:09:39  <bnoordhuis>piscisaureus: https://github.com/bnoordhuis/libuv/compare/udp
17:09:42  * bnoordhuisis off to dinner
17:10:11  <igorzi>bnoordhuis: yesterday i discovered that the machine that i've been dual-booting into windows and linux only recognizes 1 core per cpu on linux (/proc/cpuinfo only shows 2 processors, while the machine has 2 cpus x 6 cores each).. what can i try to get linux to recognize the other cores?
17:10:48  <igorzi>or anyone else? ----^
17:18:50  <piscisaureus>hmm
17:19:00  <piscisaureus>I have no clue
17:22:28  <piscisaureus>igorzi: what type of processors are in there?
17:24:28  <piscisaureus>igorzi: also, what distribution are you running and what is your kernel version?
17:25:06  <igorzi>piscisaureus: it's AMD Opteron 2431
17:26:43  <igorzi>piscisaureus: it's Fedora distro, kernel version 2.6.35.6-45.fc14.x86_64
17:30:40  * brsonjoined
17:35:57  <CIA-75>libuv: Ryan Dahl master * rd77e979 / include/uv.h : Fix spelling - http://bit.ly/qa3u6x
17:40:50  <igorzi>ryah: piscisaureus: eio functions have this signature: eio_req* (..., eio_cb cb, void *data)
17:40:59  <igorzi>for moving them to libuv, i was thinking this: void (..., uv_some_new_req_t* req);
17:41:15  <ryah>igorzi: that's preferable
17:41:21  <ryah>igorzi: also a uv_loop_t arg
17:41:28  <igorzi>oh right
17:41:29  <ryah>oh wait we havne't landed that yet
17:41:40  <ryah>but we should land that soon
17:41:51  <ryah>piscisaureus: what's the status on multiplicity?
17:41:54  <piscisaureus>ryah: if you land that now I think you're gonna have problems with ben
17:42:00  <ryah>yeah
17:42:05  <piscisaureus>an me btw
17:42:14  <piscisaureus>ryah: haven't started on multiplicity yet
17:42:15  <ryah>ben easily rebase it i think
17:42:23  <ryah>ok
17:42:25  <piscisaureus>ryah: I'm doing udp right now
17:42:31  <piscisaureus>should be done tonight
17:43:34  <igorzi>ryah: btw, are you ok with this? https://github.com/joyent/libuv/commit/dcf87708194c2fbd8780a2b2b3e9aeb2bd0e33ea
17:43:37  <igorzi>can we land it?
17:43:40  <piscisaureus>igorzi: I can't find much about this multicore problem.
17:44:15  <piscisaureus>igorzi: you might try to upgrade your kernel to 2.6.35.14 but the changelogs don't mention this problem
17:44:51  <igorzi>piscisaureus: is there a good place that tells you how to do that?
17:47:46  <ryah>igorzi: im seeing a problem on osx related to that patch - debugging now
18:03:44  <ryah>bnoordhuis: how does SO_ERROR work actually? i thought it actually returned the error code
18:03:49  <ryah>but it seems it sets errno with the code?
18:20:49  <ryah>bnoordhuis: /* We don't check for EINPROGRESS. Think about it: the socket
18:20:50  <ryah> * is either there or not.
18:20:53  <ryah> */
18:20:54  <ryah>:/
18:21:06  <ryah>it appears im getting that on osx
18:44:50  <bnoordhuis>ryah: SO_ERROR should return the error in &error
18:45:12  <bnoordhuis>or raise EBADF if sockfd is invalid
18:45:24  <bnoordhuis>EINPROGRESS on a unix socket?
18:46:00  <ryah>bnoordhuis: no i was wrong - still figuring out what's happening
18:46:32  <bnoordhuis>igorzi: can you gist the output of /var/log/dmesg?
18:47:05  <igorzi>bnoordhuis: will do in about 20 min (booted back into windows now)
19:00:06  <ryah>call?
19:00:27  <igorzi>yep
19:03:31  <DrPizza>piscisaureus: I personally would be quite happy with only looking for .exe
19:04:09  <DrPizza>piscisaureus: spawnvpe doesn't look for .com, nor does CreateProcess, and I think .coms are rare enough that people can spell it out explicitly
19:08:10  <bnoordhuis>ryah: https://gist.github.com/cc11217bf271d8a897c7
19:08:14  <bnoordhuis>^ api
19:16:49  <ryah>bnoordhuis: can uv_udp_recv_cb just pass sockaddr_in by value?
19:17:20  <bnoordhuis>ryah: no because you don't know if it's a sockaddr_in or sockaddr_in6
19:17:35  <ryah>but this constraint of "Valid for the duration * of the callback.
19:17:36  <ryah>"
19:17:40  <ryah>seems a bit annoying
19:17:54  <bnoordhuis>yeah, the callee needs to make a copy
19:18:21  <bnoordhuis>alternative is to have a uv_sockaddr struct that's the union of sockaddr_in and sockaddr_in6
19:18:25  <bnoordhuis>but well...
19:18:27  * mralephjoined
19:18:51  <ryah>nah, it's okay
19:18:51  <bnoordhuis>i'm open to suggestion though
19:19:26  <ryah>my other question: do we really need scatter/gather stuff for uv_udp_send?
19:19:39  <ryah>can we not just send a single buf?
19:20:02  <ryah>well i guess it doesnt matter
19:20:28  <ryah>which syscall do you use?
19:20:35  <ryah>is there a sendv?
19:20:42  <bnoordhuis>recvmsg and sendmsg
19:20:53  <bnoordhuis>linux has sendmmsg btw
19:20:58  <bnoordhuis>but only since 2.6.37 i think
19:21:11  <ryah>struct msghdr <- has iovec ?
19:21:14  <bnoordhuis>yes
19:21:17  <ryah>k
19:21:33  <ryah>cool - looks good
19:21:36  <bnoordhuis>good :)
19:22:18  <bnoordhuis>re scatter/gather: i followed what uv_tcp_write accepts
19:23:08  <piscisaureus>DrPizza: spawnvpe looks for .com .exe .bat .cmd. (if it finds .bat or .cmd it prepends cmd /c)
19:23:18  <DrPizza>it does?
19:25:05  <piscisaureus>DrPizza: it calls spawnve. Look here: file:///C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/crt/src/spawnve.c
19:26:28  <DrPizza>oh kinda
19:26:41  <DrPizza>but it has a broken algorithm
19:26:49  <DrPizza>it gets faked out by ANY . in the path
19:27:28  * DrPizzawas trying for a directory with a . in its name
19:28:17  <DrPizza>unless I had a bug
19:28:35  <DrPizza>oh maybe I was trying to call the wrong thing
19:28:36  <DrPizza>hm
19:29:10  <DrPizza>yes, never mind
19:29:57  <DrPizza>where does it do the cmd /c stuff?
19:30:14  <DrPizza>anyway
19:30:17  <DrPizza>that's stupid behaviour
19:30:20  <DrPizza>it should not try to add those extensions
19:33:18  <piscisaureus>DrPizza: hmm. I kinda like it
19:33:28  <piscisaureus>does the same as cmd then
19:33:29  <DrPizza>it's just so arbitrary
19:33:33  <DrPizza>they're not PATHEXT
19:33:47  <piscisaureus>in linux is it possible to spawn a shell script with exec()
19:33:56  <piscisaureus>or will it just do binaries?
19:35:21  <piscisaureus>I kinda like prepending cmd /c
19:35:28  <piscisaureus>maybe we should do that too
19:35:36  <bnoordhuis>piscisaureus: execve() works for shell scripts
19:37:13  <ryah>piscisaureus: yes
19:51:11  * brsonquit (Ping timeout: 240 seconds)
19:51:31  * brsonjoined
19:53:27  <bnoordhuis>guess we can nuke cmake support
19:53:32  <bnoordhuis>HP is killing off webos
19:53:39  <ryah>?
19:53:43  <bnoordhuis>http://techcrunch.com/2011/08/18/its-official-hp-kills-off-webos-phones-and-the-touchpad/
19:54:13  <piscisaureus>HP will continue to explore options to optimize the value of webOS software going forward.
19:54:22  <bnoordhuis>yeah, marketing speech :)
19:54:29  <ryah>oh shit
19:56:20  <piscisaureus>time to get node in android then
19:56:53  <bnoordhuis>i'll start c2java
19:57:13  <piscisaureus>bnoordhuis: why?
19:57:39  <bnoordhuis>i kid, i know you can run c / c++ on android devices
19:59:12  <bnoordhuis>i don't understand HP tbh
19:59:24  <bnoordhuis>they buy palm in 2010 primarily because of webos
19:59:47  <bnoordhuis>and a year later they kill it
20:00:19  <ryah>patents
20:00:39  <bnoordhuis>that's probably it
20:00:41  <piscisaureus>palm should have a good number of them
20:01:35  <ryah>at least thats what a senior engineer at palm told me when the acquisition happened
20:01:50  <piscisaureus>ryah: that patents are the problem?
20:01:52  <ryah>he left shortly after :)
20:02:00  <ryah>no that that's why they bought it
20:02:20  <piscisaureus>maybe they plan on selling the patents to big G
20:03:24  <piscisaureus>I mean they bought palm for "only" $ 1.2b
20:03:52  <ryah>man.. if only i had a couple billion dollars
20:04:21  <piscisaureus>yeah then what?
20:04:34  * ryahforgets sorry
20:04:41  <ryah>i'd like buy some company
20:04:41  <ryah>:)
20:05:11  * isaacsquit (Quit: isaacs)
20:05:36  <piscisaureus>ah
20:05:45  <piscisaureus>so is that why you have been saving on pants?
20:07:50  <piscisaureus>21:55:34 <ryah> piscisaureus: yahoo, facebook, msft, palm don't count?
20:07:59  <piscisaureus>1 down!
20:10:12  <piscisaureus>bnoordhuis: http://www.businessinsider.com/fed-worried-about-european-banks-2011-8
20:10:12  <piscisaureus>time to run to the atm!
20:28:20  <ryah>gah
20:28:26  <ryah>this stupid unix pipe stuff
20:44:59  * isaacsjoined
21:03:12  <ryah>bnoordhuis: https://github.com/joyent/libuv/blob/d77e9795d394ca8e4e9537ef5466a0901ddc869c/src/uv-unix.c#L1997
21:03:18  <ryah>bnoordhuis: why EV_CUSTOM?
21:03:51  <bnoordhuis>ryah: no particular reason
21:13:43  <bnoordhuis>ryah: why does uv__write (when it's written everything) defer the write_cb to the next tick?
21:15:21  <ryah>bnoordhuis: so that callbacks are always handled async
21:15:37  <bnoordhuis>ryah: but uv__write itself already runs on a later tick right?
21:15:51  * brsonquit (Ping timeout: 240 seconds)
21:16:06  <bnoordhuis>oh wait, no
21:16:17  <ryah>so we try to write immediately - if we do the next tick gets the write_cb
21:16:29  <ryah>otherwise we wait for the event loop to notify that fd is writable then do it
21:16:34  <bnoordhuis>i was looking at uv__stream_io
21:16:35  <ryah>the idea being you dont want to wait
21:16:42  <bnoordhuis>right
21:17:11  <ryah>ive got this really strange bug...
21:18:14  <bnoordhuis>tell me
21:20:30  * brsonjoined
21:24:33  * brsonquit (Client Quit)
21:24:51  * brsonjoined
21:33:27  <piscisaureus>bugs are normal. it's strange if it works
21:36:39  <bnoordhuis>maybe with your code >:)
22:02:02  <piscisaureus>bnoordhuis:
22:02:08  <piscisaureus>here?
22:02:19  <bnoordhuis>piscisaureus: yes
22:02:33  <piscisaureus>bnoordhuis: with tcp we're pretty picky about reporting errors
22:02:48  <bnoordhuis>go on
22:02:52  <piscisaureus>e.g. if bind() returns EADDRINUSE we don't actually report that but we wait for connect or listen
22:03:01  <piscisaureus>this the same for udp?
22:03:20  <bnoordhuis>no, because there's no connect or listen
22:03:38  <piscisaureus>bnoordhuis: ok so but should I report the error from read_start / send then?
22:03:55  <piscisaureus>how does this work on ulix?
22:04:20  <bnoordhuis>piscisaureus: in libuv or in unix in general?
22:04:47  <piscisaureus>bnoordhuis: what does unix do? report eaddrinuse from bind or only from the next socket operation after bind?
22:05:11  <bnoordhuis>it's reported by bind()
22:05:32  <piscisaureus>then why is it not reported by bind for tcp sockets?
22:05:52  <bnoordhuis>tcp in libuv stores the error in a field and emits it later on
22:06:09  <bnoordhuis>deferring the error is a good thing probably
22:06:14  <piscisaureus>hmm
22:06:27  <bnoordhuis>if we don't, you get these annoying uncatchable exceptions in node
22:06:58  <bnoordhuis>how does it work on windows btw?
22:07:22  <piscisaureus>bnoordhuis: on windows I *also* store the error and defer it until listen is called
22:07:35  <bnoordhuis>okay
22:07:42  <piscisaureus>ryah: why did we decide to do this again?
22:13:39  <ryah>piscisaureus: bind deferred errors?
22:13:48  <ryah>it was to smooth the differences between windows and unix
22:14:29  <ryah>there are differences in the different unixes too irrc
22:14:34  <ryah>iirc
22:15:04  <ryah> /* If we get a ECONNREFUSED wait until the next tick to report the
22:15:04  <ryah> * error. Solaris wants to report immediately--other unixes want to
22:15:04  <ryah> * wait.
22:15:05  <ryah> */
22:15:21  <piscisaureus>maybe we did it all because we were not sure that EADDRINUSE would be reported by bind
22:15:35  <piscisaureus>so in case it does, we wait for listen()
22:15:43  <piscisaureus>bnoordhuis: do we want this for udp too?
22:15:48  <bnoordhuis>ryah, what you say is true for ECONNREFUSED but not for EADDRINUSE i think
22:15:58  <bnoordhuis>piscisaureus: well...
22:16:03  <ryah>bnoordhuis: perhaps
22:16:09  <ryah>i'd be happy to not defer it
22:16:18  <ryah>if we can get every platform conforming
22:16:46  <bnoordhuis>piscisaureus: what about windows?
22:16:52  <bnoordhuis>it's a natural fit for unices
22:18:47  <piscisaureus>bnoordhuis: on windows EADDRINUSE is reported by bind
22:19:10  <bnoordhuis>let's go with reporting it directly then
22:19:21  <piscisaureus>bnoordhuis: ok... for now
22:19:53  <piscisaureus>bnoordhuis: after we finish this let's remove the error deferring code from tcp_bind
22:19:58  <piscisaureus>see if we can get consistent behavior
22:20:01  <bnoordhuis>piscisaureus: yep
22:21:08  <piscisaureus>bnoordhuis: let's see if I can dig the discussion up
22:21:24  <piscisaureus>(too bad slurp wasn't there)
22:21:41  <bnoordhuis>piscisaureus: what discussion?
22:21:49  <CIA-75>libuv: Igor Zinkovsky master * r56b09db / src/win/tcp.c : windows: set accept socket to INVALID_SOCKET in case of accept failure - http://bit.ly/oJpUxi
22:22:28  <piscisaureus>bnoordhuis: when ryan an I decided on this. I remember it was a long night.
22:31:18  <CIA-75>libuv: Ryan Dahl master * rac1ce29 / (test/benchmark-pound.c test/echo-server.c): Improve pound benchmark by reconnecting in close_cb - http://bit.ly/qebnVs
22:31:19  <CIA-75>libuv: Igor Zinkovsky master * rf6c25a1 / test/benchmark-pound.c : Fix pipe-pound and clean-up - http://bit.ly/rnkL5e
22:31:57  <CIA-75>libuv: Ryan Dahl master * r1231193 / test/benchmark-pound.c : pound: only display connect errors on DEBUG - http://bit.ly/qVLh8w
22:32:58  <piscisaureus>bnoordhuis: hey
22:33:06  <bnoordhuis>piscisaureus: ho
22:33:19  <piscisaureus>bnoordhuis: je krijgt het niet kado
22:33:54  <piscisaureus>bnoordhuis: but... it seems that we do this error deferring because linux reports eaddrinuse from listen() not bind()
22:34:30  <bnoordhuis>piscisaureus: aw... you may be right
22:34:37  <bnoordhuis>both bind and listen can report eaddrinuse
22:34:43  <bnoordhuis>god, posix sucks
22:34:52  <piscisaureus>bnoordhuis: it's somewhere in here: https://gist.github.com/1155444
22:34:53  <piscisaureus>:-)
22:35:36  <bnoordhuis>piscisaureus: what about windows?
22:35:52  <piscisaureus>it reports on bind proper
22:36:04  <ryah>piscisaureus, bnoordhuis: you should add a note about this in linux
22:36:28  <ryah>sorry - add a comment about why we're deferring it
22:36:32  <ryah>so we don't have to do this again :)
22:36:35  <bnoordhuis>right
22:39:01  <bnoordhuis>you know, linux doesn't actually report eaddrinuse from listen, only bind
22:39:18  <bnoordhuis>i checked the unix, ipv4 and ipv6 stacks
22:41:53  <piscisaureus>bnoordhuis: I don't believe you
22:42:05  <bnoordhuis>piscisaureus: why not?
22:42:12  <piscisaureus>bnoordhuis: because I observed it doing that myself
22:42:26  <bnoordhuis>what kernel?
22:42:33  <piscisaureus>hmm
22:42:47  <piscisaureus>what kernel was I running on april 25th?
22:42:53  <piscisaureus>I don't know
22:43:05  <piscisaureus>something that ships with ubuntu 10.10 or 11.04
22:43:45  <bnoordhuis>how did you observe it? test case?
22:44:12  <piscisaureus>bnoordhuis: we used to have a test case that checks if bind returns EADDRINUSE
22:44:39  <piscisaureus>it failed me on linux
22:45:01  <bnoordhuis>do you know what commit you were at?
22:45:17  <piscisaureus>bnoordhuis: i can figure that out
22:45:39  <bnoordhuis>i can too if it's the latest on 25/04 :)
22:47:29  <bnoordhuis>oh, it's all academic
22:47:35  <ryah>sigh. configure-gyp is so tedious
22:47:37  <bnoordhuis>freebsd does return EADDRINUSE from listen
22:48:50  <bnoordhuis>https://github.com/joyent/node/commit/fcf9cfa1374bbbc0e77dd77908b55d45d7735450#commitcomment-539728 <- this guy
22:50:38  <bnoordhuis>piscisaureus: so what are we going to do?
22:50:55  <bnoordhuis>deferring the error to send / recv seems... dunno, ugly
22:51:19  <bnoordhuis>and confusing
22:51:19  <piscisaureus>bnoordhuis: does freebsd return EADDRINUSE from sendto / recvfrom?
22:51:34  <bnoordhuis>piscisaureus: i should hope not
22:52:38  <bnoordhuis>piscisaureus: was that a serious question?
22:53:05  <piscisaureus>bniirdhuis: ok we're not going to defer errors
22:53:29  <bnoordhuis>you don't use tab completion, do you? :)
22:53:45  <piscisaureus>bniirdhuis: no
22:53:49  <bnoordhuis>haha
22:56:21  <piscisaureus>bnoordhuis: try https://github.com/joyent/libuv/commit/0a7c19e19ecd8ecb623c1eca34d2ecfaeb7307bf
22:56:21  <piscisaureus>but remove the oio_listen call from the bind_error_addrinuse call
22:56:45  <bnoordhuis>okay, i'll give it a spin
23:04:24  <piscisaureus>bnoordhuis: re this guy
23:04:33  <bnoordhuis>yeah?
23:04:33  <piscisaureus>bnoordhuis: why is that more cutting edge js?
23:04:41  <bnoordhuis>i have no idea :)
23:04:57  <bnoordhuis>seems he's worried about the use of a local
23:05:37  <bnoordhuis>i agree it's bad abusing locals - but only in the real world, not in computer programs
23:06:10  <piscisaureus>also I fail to see what's the problem with the --use-uv snippet
23:17:59  <bnoordhuis>piscisaureus: it's just one of those guys, you know
23:18:23  <piscisaureus>bnoordhuis: they're rare. I feel like trolling him.
23:22:11  * mralephquit (Quit: Leaving.)
23:22:20  <ryah>bnoordhuis: what's the deal with 421b6e89aa58d1cdc3344d6fadb878f7b37eee1c
23:23:19  <bnoordhuis>ryah: crypto: fix incorrect ssl shutdown check?
23:23:39  <ryah>it seems correct to me
23:23:43  <ryah>mjr is asking about it
23:23:51  <bnoordhuis>look closely :)
23:24:02  <ryah>i mean the fix seems correct
23:24:08  <bnoordhuis>right, it is
23:24:21  <bnoordhuis>Connection::ReceivedShutdown was always returning true before
23:24:34  <ryah>yeah
23:24:39  <ryah>that's pretty big actually :)
23:25:13  <ryah>maybe it has exposed another bug for mjr
23:25:34  <bnoordhuis>that seems likely
23:25:42  <ryah>which is good
23:29:37  <ryah>i asked him to join - hopefully we'll get some good news
23:33:59  <piscisaureus>you mean, a bug == good news?
23:34:10  <bnoordhuis>a known bug is
23:34:14  <bnoordhuis>an unknown bug isn't
23:34:30  <bnoordhuis>can't fix unknown bugs!
23:34:53  <ryah>there are very very tricky unknown bugs in tls
23:35:03  <ryah>i had to give up on them
23:35:17  <ryah>but many we'll get a better examination
23:35:23  <ryah>s/many/maybe
23:35:35  <DrPizza>maybe pquerna can solve all your tls woes
23:35:53  <ryah>he probably could if he had the time :)
23:51:29  <ryah>https://groups.google.com/forum/#!topic/nodejs/cwYaZ0H7xAk
23:56:15  <piscisaureus>hmm. works for me
23:58:26  <piscisaureus>Should I ask him about his windows version etc?
23:59:17  <bnoordhuis>piscisaureus: yes