00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:36:21  * lohkeypart
00:36:37  * lohkey_joined
00:36:37  * lohkey_quit (Client Quit)
01:06:55  * brsonquit (Ping timeout: 260 seconds)
01:07:24  * brsonjoined
01:14:06  * bradleymeckquit (Quit: bradleymeck)
01:38:11  * LOUDBOTquit (*.net *.split)
01:38:11  * ircretaryquit (*.net *.split)
01:38:11  * russell_hquit (*.net *.split)
01:38:11  * niska`quit (*.net *.split)
01:38:11  * rvaggquit (*.net *.split)
01:38:13  * DrPizzaquit (*.net *.split)
01:38:13  * karupaneruraquit (*.net *.split)
01:38:13  * loladiroquit (*.net *.split)
01:38:13  * Benviequit (*.net *.split)
01:38:13  * mmaleckiquit (*.net *.split)
01:38:13  * Raltquit (*.net *.split)
01:38:13  * chrisdickinsonquit (*.net *.split)
01:38:13  * MI6quit (*.net *.split)
01:38:14  * bazquit (*.net *.split)
01:38:14  * Gottoxquit (*.net *.split)
01:40:24  * MI6joined
01:49:58  * loladirojoined
01:49:58  * Benviejoined
01:50:07  * karupanerurajoined
01:51:38  * MI6quit (*.net *.split)
01:58:53  * joshthecoderquit (Quit: Leaving...)
01:59:22  * russell_hjoined
01:59:22  * niska`joined
01:59:22  * rvaggjoined
01:59:22  * DrPizzajoined
02:00:23  * Gottoxjoined
02:02:07  * bradleymeckjoined
02:03:28  * mmaleckijoined
02:03:28  * Raltjoined
02:03:28  * chrisdickinsonjoined
02:03:33  * CAPSLOCKBOTjoined
02:03:37  * LOUDBOTjoined
02:04:04  * piscisaureus_joined
02:04:20  <piscisaureus_>where is bnoordhuis when you need him
02:04:59  * MI6joined
02:05:11  * ircretaryjoined
02:16:04  * dap1quit (Quit: Leaving.)
02:34:26  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:38:02  * brsonquit (Ping timeout: 250 seconds)
02:39:37  * brsonjoined
02:44:22  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:30:51  * brsonquit (Quit: leaving)
03:31:42  * AvianFluquit (Read error: Connection reset by peer)
03:32:01  * AvianFlujoined
03:40:16  * AvianFluquit (Read error: Connection reset by peer)
03:41:00  * AvianFlujoined
03:42:41  * bradleymeckquit (Quit: bradleymeck)
03:46:06  * jmar777joined
04:06:09  * joshthecoderjoined
04:16:46  * TooTallNatejoined
04:18:42  * bradleymeckjoined
04:23:03  * bradleymeckquit (Ping timeout: 245 seconds)
04:34:25  * jmar777quit (Remote host closed the connection)
04:35:01  * jmar777joined
04:39:18  * jmar777quit (Ping timeout: 245 seconds)
04:52:26  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:54:10  * AvianFluquit (Ping timeout: 246 seconds)
05:28:47  * TooTallNatejoined
05:31:19  * TooTallNatequit (Client Quit)
06:09:18  * AvianFlujoined
06:24:40  * warzquit
07:07:55  * mjr_quit (Quit: mjr_)
07:23:01  * rendarjoined
07:34:53  * benoitcquit (Changing host)
07:34:53  * benoitcjoined
07:38:36  * karupaneruraquit (Excess Flood)
07:40:29  * karupanerurajoined
07:53:42  * stagasjoined
08:28:10  <deoxxa>so um
08:28:11  <deoxxa>windows ce
08:30:40  <yawnt>wat
08:31:26  <deoxxa>well, i'm wondering if windows ce is a supported platform for libuv
08:31:32  <deoxxa>not sure what version yet
08:31:47  <deoxxa>but it looks like i have to port some code to run on windows ce
08:31:50  <deoxxa>(which will be "fun")(
08:32:59  <deoxxa>i'm not finding a ton of information on the subject
08:33:31  <yawnt>lol
08:33:33  <yawnt>"fun"
08:34:53  <deoxxa>it actually looks like a fun project - i might be putting software on ticket machines in busses/train stations/trams/etc
08:35:10  <deoxxa>this'll be easily my widest deployment of a piece of software
08:35:48  <deoxxa>the "trial" group is like 150 units
08:40:06  <indutny>:)
08:40:19  <indutny>I'm not sure if it'll work...
08:40:30  <indutny>but why not :P
08:41:32  <deoxxa>yeah, i'm not even sure how i'm going to test it
08:41:36  <deoxxa>i don't have a windows ce device :/
08:42:10  <indutny>well
08:42:13  <indutny>you can setup vm
08:42:20  <indutny>if you'll be able to get disk image
08:42:48  <deoxxa>yeah
08:58:45  * joshthecoderquit (Quit: Linkinus - http://linkinus.com)
09:08:18  * loladiroquit (Quit: loladiro)
09:08:51  * loladirojoined
09:38:48  * bnoordhuisjoined
09:49:23  * loladiroquit (Quit: loladiro)
10:22:20  * AvianFluquit (Remote host closed the connection)
10:43:28  * hzjoined
11:24:30  * felixgejoined
11:24:30  * felixgequit (Changing host)
11:24:30  * felixgejoined
11:48:59  * bnoordhuisquit (Ping timeout: 255 seconds)
13:26:31  * AndreasMadsenjoined
13:34:54  * stagasquit (Ping timeout: 264 seconds)
13:57:37  * roxlujoined
13:57:43  <roxlu>hi !
13:59:00  <roxlu>last week someone here told me libuv works on iOS too, I'm wondering how I can compile libuv for iOS?
14:16:38  * jmar777joined
14:26:08  * jmar777quit (Remote host closed the connection)
14:26:44  * jmar777joined
14:27:31  * felixgequit (Quit: felixge)
14:30:58  * jmar777quit (Ping timeout: 245 seconds)
15:20:41  * bradleymeckjoined
15:29:44  * piscisaureus_joined
15:44:18  * piscisaureus_quit (Ping timeout: 245 seconds)
15:44:42  * bradleymeckquit (Quit: bradleymeck)
16:14:27  <rendar>when libuv receives async I/O completion from the OS, does it call the relative callback in 1 only thread, or does it use a pool of threads? or can do both..? (e.g. a pool with only 1 thread)
16:15:16  <mmalecki>rendar: iirc callback is called in originating thread
16:15:35  <mmalecki>thread pool is an implementation detail
16:21:58  <rendar>hmm
16:22:42  <rendar>mmalecki: but with libuv will i have multithreading or libuv is single threaded?
16:23:42  <mmalecki>libuv has a thread pool for doing I/O
16:24:10  <mmalecki>also you can do uv_work which will put work into that thread pool
16:26:03  <rendar>i see
16:30:26  <rendar>mmalecki: so if it has a thread pool, what happen if a an asynchronous socket i have open with libuv receives 2 packets "HELLO",5 and "WORLD",5 and 2 threads T1, T2 are choosen to deliver these 2 packets to the correct "object", what if T2 executes first than T1 ? will my callback receive before "WORLD" than "HELLO" ?
16:34:41  * jmar777joined
16:35:51  * jmar777quit (Remote host closed the connection)
16:36:25  * jmar777joined
16:39:38  * stagasjoined
16:40:33  * jmar777quit (Ping timeout: 245 seconds)
17:05:11  * mjr_joined
17:08:53  <mmalecki>rendar: only actual i/o is performed in the thread pool
17:09:49  <mmalecki>your code is executed in one thread only
17:10:27  <rendar>oh i see
17:11:20  <rendar>mmalecki: but even if the code is execute in one thread, what about the thread pool receives 2 packets, and 2 different threads take care of these 2 packets? how order is achieved there? does the OS think about it?
17:12:39  <mmalecki>hmm, I have no idea actually
17:12:44  <mmalecki>sorry
17:13:17  <rendar>ok, thanks anyway
17:13:18  <rendar>:)
17:17:52  * AvianFlujoined
17:28:20  * dapjoined
17:31:38  * dapquit (Client Quit)
17:42:27  * felixgejoined
17:42:27  * felixgequit (Changing host)
17:42:27  * felixgejoined
18:01:59  * tomshredsjoined
18:05:45  * tomshredsquit (Client Quit)
18:05:58  * c4milojoined
18:24:04  * loladirojoined
18:29:00  * stagasquit (Ping timeout: 264 seconds)
18:29:46  <isaacs>kablooey
18:29:49  <MI6>joyent/node: isaacs master * 01db736 : Merge branch 'streams2' (+72 more commits) - http://git.io/LgirpA
18:30:35  <isaacs>few more fixes, but it's behaving correctly now.
18:56:57  * bnoordhuisjoined
19:08:52  <AndreasMadsen>^^ - wow, big day
19:14:33  * ericktjoined
19:20:47  * TooTallNatejoined
19:36:40  * warzjoined
19:36:40  * warzquit (Changing host)
19:36:40  * warzjoined
19:39:20  <isaacs>TooTallNate: did you try explicitly casting it to 'void (*)(uv_work_t *, int)'?
19:39:47  <TooTallNate>isaacs: that will work fine
19:39:55  <isaacs>TooTallNate: i think there's a type that's defined in uv for that
19:39:58  <TooTallNate>i just didn't wanna touch code :p
19:40:11  <isaacs>(uv_after_work_cb)write_after
19:40:11  <TooTallNate>isaacs: ya for sure, can we #ifdef that?
19:40:20  <TooTallNate>i mean for backwards compat
19:40:24  <TooTallNate>in my code
19:40:25  <isaacs>TooTallNate: casting to uv_after_work_cb will work backwards
19:40:32  <isaacs>TooTallNate: it's the definition of uv_after_work_cb that changed
19:40:40  <TooTallNate>isaacs: when was that type added?
19:40:52  <isaacs>TooTallNate: dunno. ask piscisaureus
19:40:57  <TooTallNate>ok
19:41:03  <TooTallNate>i think it's brand new though ;)
19:41:13  <isaacs>but yeah, having to touch code at all sucks.
19:41:25  <isaacs>we need to start a "Changes from v0.8 to v0.10" wiki page.
19:42:07  <TooTallNate>indeed
19:42:10  <TooTallNate>first entry!
19:42:17  <TooTallNate>well, streams2 of course, haha
19:42:26  <TooTallNate>but theoretically you don't have to update your code for that
19:42:47  * ericktquit (Quit: erickt)
19:44:10  * ericktjoined
19:44:36  <TooTallNate>isaacs: ohh lucky us! uv_after_work_cb does exist in v0.8 already
19:44:38  * TooTallNatehappy dance
19:48:36  * c4miloquit (Remote host closed the connection)
19:49:38  <isaacs>nice
19:50:55  <TooTallNate>isaacs: so at least keeping it backwards compat is easy: https://github.com/rbranson/node-ffi/commit/fdeff41ae8b1cca31d4707d7b61253c45181b8fa
20:15:05  <MI6>joyent/libuv: Ben Noordhuis master * 273cecc : unix: don't memset(0) in uv_udp_init() It's inconsistent with other init - http://git.io/bFGDvg
20:16:48  * travis-cijoined
20:16:48  <travis-ci>[travis-ci] joyent/libuv#959 (master - 273cecc : Ben Noordhuis): The build passed.
20:16:49  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/c6c5b7a901d2...273cecc56ff5
20:16:49  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3680792
20:16:49  * travis-cipart
20:17:34  * stagasjoined
20:26:29  <bnoordhuis>ircretary: tell piscisaureus https://github.com/joyent/node/pull/4386 <- review?
20:26:29  <ircretary>bnoordhuis: I'll be sure to tell piscisaureus
20:32:53  <isaacs>bnoordhuis: i went ahead nad merged streams2 on (--no-ff)
20:33:15  <bnoordhuis>isaacs: yep, saw it
20:33:18  <isaacs>bnoordhuis: we can fix any further streams2 issues on master. it's doing correct behavior now, but not quite optimal in all cases.
20:33:27  <bnoordhuis>quite optimal being performance drops?
20:33:33  <isaacs>bnoordhuis: yeah.
20:33:33  <bnoordhuis>*not quite
20:34:00  <bnoordhuis>no biggie. i'll remove the usleep(5000) to compensate
20:34:02  <isaacs>nothing unfixable, and i have a todo list with a few issues that are pretty easy to address
20:34:07  <isaacs>bnoordhuis: nice :)
20:34:13  <isaacs>i figured you had a good reason for that
20:34:15  <isaacs>also: https://github.com/joyent/node/wiki/Api-changes-between-v0.8-and-v0.10
20:34:35  <bnoordhuis>btw, that reminds me - gc idle notifications
20:34:53  * isaacstopic: liberal utopian vacation ~ https://github.com/joyent/node/wiki/Api-changes-between-v0.8-and-v0.10 ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
20:35:08  <bnoordhuis>what are we going to do with it? it doesn't work well (or at all) with larger heaps
20:35:35  <bnoordhuis>it's the thing were people to switch to --nouse-idle-notification to avoid it
20:35:40  <isaacs>right
20:35:45  <isaacs>maybe we should jsut remove it?
20:35:46  <isaacs>i don't know
20:36:01  <isaacs>mjr_ tells me it's universally bad, but he's kind of biased towards the "large heap" use case.
20:36:11  <isaacs>what do you recommend?
20:36:36  <bnoordhuis>i suggest removing it
20:36:56  <bnoordhuis>i tinkered with a different approach (timer handle + check handle)
20:37:10  <roxlu> bnoordhuis, is there a make option to compile a static lib from libuv for ios?
20:37:33  <bnoordhuis>but it probably has the same issue as the current approach, only reduced a little
20:37:54  <bnoordhuis>roxlu: not really. if `make libuv.a` doesn't work, you'll have to patch it
20:38:07  <isaacs>bnoordhuis: what about just switching the parity on the flag?
20:38:20  <isaacs>bnoordhuis: node --use-idle-notification if you want it
20:38:28  <bnoordhuis>isaacs: well, it's a v8 flag
20:38:29  <isaacs>(parity? i think i mean valence..)
20:38:31  <isaacs>oh, ok
20:38:33  <roxlu>bnoordhuis: I added the source files to my project now which works (though need to debug a crash when I close app)
20:38:45  <isaacs>right
20:38:52  <roxlu>bnoordhuis: any plans on using cmake in the future?
20:38:53  <isaacs>well, we could make it a node flag
20:38:57  * AndreasMadsenquit (Remote host closed the connection)
20:39:05  <bnoordhuis>roxlu: no plans whatsoever
20:39:22  <bnoordhuis>i've considered autotools but then again, i like plain makefiles
20:39:28  <roxlu>hehe
20:39:39  <isaacs>$ node --v8-options | grep idle
20:39:40  <isaacs> --use_idle_notification (Use idle notification to reduce memory footprint.)
20:39:40  <roxlu>then.. any plans for a ios makefile?
20:39:40  <isaacs> --send_idle_notification (Send idle notifcation between stress runs.)
20:40:10  <isaacs>bnoordhuis: we could check to see if they've explicitly asked it to use them, and if so, send them, otherwise don't bother.
20:40:29  <bnoordhuis>isaacs: i don't know. part of the problem is that the current solution is really crappy
20:40:43  <bnoordhuis>it checks if the heap > 128M, then starts calling V8::GC() all the time
20:40:53  <bnoordhuis>that 128M is hard-coded btw
20:41:05  <bnoordhuis>good indicator of the general level of crappiness
20:41:23  <bnoordhuis>roxlu: can't you patch up the makefile? i'll merge the patch
20:41:56  <roxlu>bnoordhuis: I'm not so familiar with plain makefiles... I'm with familiar with cmake though
20:43:14  <bnoordhuis>roxlu: we won't be switching to cmake. we have gyp and makefiles atm and that's good (and work) enough
20:43:34  <TooTallNate>isaacs: man, definitely seeing some weirdness on master now
20:43:40  <TooTallNate>npm won't install all my deps
20:44:51  <TooTallNate>maybe i need to update npm :\
20:45:42  <TooTallNate>weird… ok that seemed to help
20:46:12  <isaacs>TooTallNate: yeah, previos versions of npm used a version of node-tar that had a bug which was only triggered when pause() actually works
20:46:25  <TooTallNate>ok cool
20:46:33  <isaacs>TooTallNate: turned an if(){} into a while(){} and it fixed it
20:46:44  <TooTallNate>getting weird segfaults from node-ffi now, haven't figured out why yet
20:47:08  <isaacs>bnoordhuis: go ahead and rip it out. if anyone barks about it, we can put it back easily enough
20:47:20  <isaacs>bnoordhuis: at the very least, the default should be to *not* do it
20:47:26  <txdv>O bnoordhuis is here, already being terrorized by people
20:47:45  <bnoordhuis>isaacs: okay, will do (tomorrow)
20:49:52  * AndreasMadsenjoined
20:50:58  <isaacs>bnoordhuis: thanks
20:58:03  * ericktquit (Quit: erickt)
21:06:06  * ericktjoined
21:07:14  * bradleymeckjoined
21:10:47  <TooTallNate>isaacs: is stderr somehow getting buffered now?
21:11:04  <TooTallNate>i'm seeing it not be fully flushed which is very strange
21:11:20  <TooTallNate>but it's flushed if redirected to a file :\
21:13:03  <isaacs>TooTallNate: hm. maybe _write isn't being called synchronously
21:13:12  <isaacs>TooTallNate: yeah, i see that
21:13:18  <isaacs>TooTallNate: it's a bug :)
21:15:17  <txdv>what are you discussing/
21:15:18  <txdv>streams2?
21:16:05  * bnoordhuisquit (Ping timeout: 255 seconds)
21:16:39  <isaacs>TooTallNate: hm... do you have a reliable test?
21:16:46  <isaacs>txdv: no, we're discussing node-master :)
21:16:50  <isaacs>txdv: (same thing)
21:17:05  <TooTallNate>isaacs: not that doesn't use other modules yet
21:17:13  <isaacs>TooTallNate: ok
21:17:15  <txdv>Hm
21:17:29  <txdv>Do a blog post about streams2?
21:17:34  <txdv>pretty please :>
21:17:43  <TooTallNate>isaacs: but a lot of my modules use tj's "debug", and that's where i'm seeing it
21:17:50  <isaacs>i see
21:19:23  * bradleymeckquit (Quit: bradleymeck)
21:21:27  <isaacs>TooTallNate: here's a test: https://gist.github.com/4299339
21:21:36  <isaacs>TooTallNate: (warning, dumps a lot of crap to stderr)
21:21:49  <isaacs>it *should* be always ending on 'z'
21:21:52  <isaacs>but i see it not ending on z
21:22:30  * TooTallNaterunning it
21:22:36  <isaacs>oh, wait, no
21:22:39  <isaacs>it doesn't get to z :)
21:23:33  <isaacs>https://gist.github.com/4299363
21:23:38  <isaacs>and that one works fine
21:23:39  <isaacs>crap
21:23:56  <isaacs>makes a neat pattern on the screen, though
21:24:36  <TooTallNate>isaacs: i think multiple stderr.write() calls will trigger it
21:24:47  <TooTallNate> or console.error()
21:25:10  <isaacs>ahhhhh
21:25:11  <isaacs>found it
21:25:15  <isaacs>yeah, multiple writes is it
21:25:22  <isaacs>https://gist.github.com/4299370
21:25:26  <isaacs>that's a bug, alright
21:25:35  <isaacs>the writes queue up, and never happen
21:25:41  <isaacs>probably because of something getting nextTick'd
21:25:43  <isaacs>kewl
21:25:45  <isaacs>nice find :)
21:26:02  <TooTallNate>:D
21:26:13  <txdv>will streams be depreceated with streams2?
21:26:17  <TooTallNate>isaacs: a segmentation fault was causing it for me rather than process.exit() :p
21:26:50  <TooTallNate>something seems to be messed up with the way node-ffi does async callbacks on v0.9 :\
21:26:50  <TooTallNate>https://travis-ci.org/rbranson/node-ffi/jobs/3682066
21:27:42  <isaacs>even as a child process it fails
21:27:49  <isaacs>txdv: no
21:27:56  <isaacs>txdv: check the doc in the /topic
21:29:20  <isaacs>TooTallNate: nice find. yes, this is a bug. i'll fix it (tomorrow)
21:29:42  <TooTallNate>txdv: you basically now have the option use a readable stream pull style (new way) or push style (old way)
21:30:23  <TooTallNate>isaacs: kewl, glad i'm not just going crazy… now to figure out this segfault
21:30:32  <isaacs>TooTallNate: kewl, got a test that breaks when it's run as a child proc, too
21:30:41  <isaacs>TooTallNate: so i can make a test for this
21:30:52  <TooTallNate>excellent
21:30:53  <isaacs>i was worried it was going to turn out to be a TTY bug rather than a net socket bug
21:30:56  <isaacs>those suck
21:31:05  <isaacs>there's a test that's been failing for ages when run directly, but isn't ever run
21:31:12  <isaacs>because `make test` isn't a tty
21:31:21  <rendar>well, when the OS receives an asynch io request, it will be processed from the libuv threadpool, the thread from the pool processes only the request, then the real execution of the callback is remainded to another thread (?) which one? or is executed from the thread of the pool?
21:31:58  <TooTallNate>isaacs: so you have an idea of what's causing it, it sounds like
21:32:20  <isaacs>TooTallNate: yeah
21:33:24  <isaacs>console.error('x'); console.error('x'); process.exit()
21:33:52  <TooTallNate>isaacs: bingo
21:34:15  <isaacs>the second call to write() doesn't call _write synchronously, even though the first call to _write returned synchronously
21:35:39  <TooTallNate>so state.writing must not be getting get to false in time?
21:36:27  <TooTallNate>s/get/set
21:36:54  * Chip_Zeroquit (Ping timeout: 244 seconds)
21:37:26  <isaacs>not sure exactly
21:37:34  <TooTallNate>isaacs: what's the "sync" flag for?
21:38:09  <isaacs>i dunno, i have to page all that code back into memory
21:38:18  <isaacs>gonna do it tomorrow :)
21:42:12  * Chip_Zerojoined
21:49:01  <TooTallNate>ok i think i figured out my segfault at least :)
21:49:08  <TooTallNate>was calling Buffer::Data() on the thread pool
21:49:14  <TooTallNate>bad joo joo
22:01:00  <TooTallNate>good 'ol gdb to the rescue :)
22:03:00  <TooTallNate>ok awesome :) got my Spotify -> node-speaker example working
22:03:06  <TooTallNate>with node-master that is
22:03:13  <TooTallNate>isaacs: good stuff man!
22:05:31  * ericktquit (Quit: erickt)
22:13:19  <isaacs>TooTallNate: the 'sync' flag is so that it knows if _write() called the cb synchronously
22:13:31  <TooTallNate>isaacs: ok that's what i though
22:13:33  <isaacs>TooTallNate: if write() returns false, and also emits 'drain' in teh same tick, then you don't have a chance to adda 'drain' listener
22:14:10  <TooTallNate>ok damage control setting down now :p
22:14:21  <TooTallNate>still a lot of uv_queue_work() calls to update :\
22:14:27  <TooTallNate>but i'll get around to that
22:15:02  <isaacs>i think what's happening is that the second write() gets put in the buffer (because the first isn't done yet, maybe?) and it shouldn't be
22:23:10  <isaacs>TooTallNate: i see. this will be solved by the change i have to make to speed up net.js anway
22:23:22  <TooTallNate>isaacs: sgtm
22:23:23  <isaacs>TooTallNate: er, to speed up net streams
22:23:33  <TooTallNate>isaacs: hey don't forget to update node-gyp in npm before 0.9.4!
22:23:44  <isaacs>TooTallNate: the issue is that for stderr, it's actually treating stderr as an async net stream
22:23:50  <isaacs>(and stdout)
22:23:59  <TooTallNate>ahhh
22:24:00  <TooTallNate>not right
22:24:02  <TooTallNate>haha
22:24:27  <isaacs>so, it's waiting for afterWrite to be called before it calls the Writable stream API's cb that was passed to _write()
22:24:49  <isaacs>i need a way to split up the "ok, write more" message, from the "i finished writing that thing" message.
22:25:03  <isaacs>because the way it is now, that's a pretty big efficiency loss.
22:25:22  <isaacs>i fixed up all the js bottlenecks, but that's why it's actually spending more time on the tcp stuff itself
22:26:05  <TooTallNate>isaacs: i see you already updated node-gyp in npm/master so disregard last statement
22:26:14  <TooTallNate>isaacs: but don't forget to update npm in node before next release ;)
22:26:22  <isaacs>yeah
22:26:30  <isaacs>i'll update it in 0.8 and then merge in, probably
22:26:38  <isaacs>though, now that streams2 is in, v0.8 merges are gonna be hellacious
22:26:48  * isaacsaway again
22:26:49  <TooTallNate>oh gawd
22:29:50  <isaacs>TooTallNate: https://gist.github.com/4299905
22:29:59  <isaacs>TooTallNate: more simplified test case
22:30:39  <isaacs>TooTallNate: the problem is that it never gets to afterWrite, because of the process.exit
22:32:13  <TooTallNate>isaacs: so is that a problem at the binding level or libuv or what?
22:33:21  <isaacs>https://gist.github.com/4299932 <-- fixes it for most streams
22:34:19  <isaacs>ok, gotta go back to doing laundry
22:34:31  * isaacsis playing hookey by writing code
22:34:52  <isaacs>TooTallNate: but i think that https://gist.github.com/4299932 changes the semantics slightly
22:35:18  * ericktjoined
22:35:33  <mjr_>isaacs: do people really depend on idle notifications to bring their memory usage down? Even in a "small heap" case, it seems like asking for trouble to have things like idle notification.
22:35:54  <isaacs>mjr_: we don't turn it on until your heap reaches 128M
22:36:05  <isaacs>mjr_: and it's kind of crappy
22:36:14  <mjr_>Which is paradoxically when you want to turn idle notifications off.
22:36:18  <isaacs>mjr_: my guess is that no one depends on it, becasue everyone who knows what it is turns it off.
22:36:38  * isaacsbbiab
22:36:46  <mjr_>The main reason to keep it, IMO is if you have TONS of node processes, but most of them don't do much work.
22:37:25  <mjr_>And you want to take your heaps from 64MB to something 32 or whatever.
22:48:04  * ericktquit (Quit: erickt)
22:54:44  <isaacs>mjr_: yeah, we can make it opt-in
22:54:47  <isaacs>mjr_: but meh.
22:55:07  * rendarquit
22:55:15  <isaacs>mjr_: i'll ping the guys at joyent and see how they feel about it
22:55:32  <isaacs>i know we run a lot of little node processes
23:04:22  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
23:18:51  * bradleymeckjoined
23:19:17  * toothrchanged nick to toothrot
23:20:29  * hzquit
23:29:03  * bradleymeckquit (Quit: bradleymeck)
23:31:18  * piscisaureus_joined
23:31:28  <piscisaureus_>ircretary: notes
23:34:40  <isaacs>it's piscisaureus_! hooray!
23:34:42  <isaacs>all is saved now
23:35:55  <piscisaureus_>isaacs: sup?
23:42:36  <isaacs>so, i think i figured out the net.Socket problem
23:42:44  <isaacs>which it turns out is also why stdout and stderr are not flushing
23:43:10  <piscisaureus_>isaacs: ok, nice
23:43:20  <isaacs>but, it means if you do write(chunk,cb) then cb() gets called right away if handle.writeQueueLength is 0
23:43:23  <piscisaureus_>isaacs: so I wasn't even aware there was still a problem actually
23:43:31  <isaacs>well, it wasn't, but it is now :)
23:43:41  <piscisaureus_>wait
23:43:41  * isaacsis a necromancer of bugs
23:43:58  <isaacs>it flushes, but only the first write gets out if you do an immediate process.exit
23:44:00  <piscisaureus_>isaacs: I think the callback would be made on the next tick right?
23:44:08  <piscisaureus_>ah
23:44:17  <piscisaureus_>isaacs: this has been a problem since the day node was created
23:44:33  <piscisaureus_>isaacs: it is actually also the reason that stdout is now blocking, much to my disapproval
23:44:36  <isaacs>well, actually, i can make sure that the callback passed to write() is nextTicks
23:45:02  <isaacs>blocking stdout/err is unsurprising.
23:45:06  <piscisaureus_>isaacs: I am pretty sure that if you use write_req.oncomplete, it will never be called synchronously
23:45:06  <isaacs>we're not going to change that
23:45:10  <isaacs>but yes, it is a huge pita
23:45:13  <isaacs>piscisaureus_: yes.
23:45:33  <isaacs>piscisaureus_: so, that's the thing, i dont' wait for writeReq.oncomplete to all the callback to _write() and then the problem disappears
23:45:42  <isaacs>i only wait for writeReq.oncomplete if the writeQueueLength > 0
23:45:51  <piscisaureus_>isaacs: hmm I though at some point we decided we could change it, as long as we made console.log sync
23:46:11  <piscisaureus_>ah yes
23:46:32  <piscisaureus_>isaacs: the writeQueueSize just serves as a hint to whether write() should return true or false
23:47:05  <isaacs>right
23:47:22  <isaacs>well, though, return value from write() is now a bit more configurable
23:47:23  <isaacs>but yeah
23:47:50  <isaacs>effectively, i'm interacting with the underlying socket the same way that 0.8 does, with this change
23:49:29  <piscisaureus_>isaacs: sounds good
23:51:18  <isaacs>k, i'll land it with a test tonight or tomorrow
23:53:14  * AndreasMadsenquit (Remote host closed the connection)