00:00:01  <isaacs>or dart-io
00:00:04  <isaacs>or whatever
00:00:07  <piscisaureus_>yeah
00:00:11  <piscisaureus_>browsers should run lua
00:00:11  <piscisaureus_>+1
00:00:28  <piscisaureus_>except for starting arrays with 1 ***aargh****
00:00:44  <isaacs>the point is, int eh short term, we have to view deprecating things as a cost/benefit ratio
00:01:02  <piscisaureus_>let's just keep master in a working state :-)
00:01:09  <isaacs>and not let this devolve into legalism or democracy
00:01:11  <piscisaureus_>so people can actually test 0.9.x
00:01:15  <isaacs>yep
00:01:18  <isaacs>that too :)
00:02:10  <bnoordhuis>while we're on the subject of deprecation... https://github.com/joyent/node/issues/3579
00:02:38  <bnoordhuis>then again, cluster was and is experimental
00:08:26  * c4miloquit (Remote host closed the connection)
00:09:01  * c4milojoined
00:13:30  * c4miloquit (Ping timeout: 264 seconds)
00:13:41  <isaacs>bnoordhuis: your response is entirely appropriate.
00:13:44  <isaacs>and encouraging.
00:13:53  <isaacs>i can see we're all pretty much in agreement, which is nice.
00:14:03  <isaacs>just a communication problem (which i'm going to address in a second)
00:14:11  <piscisaureus_>isaacs: in that light, are we going to remove node-waf in the next node?
00:14:18  <piscisaureus_>that'll also be painful
00:14:28  <isaacs>piscisaureus_: yes. i don't know about node-waf
00:14:43  <isaacs>piscisaureus_: when there aren't any packages on npm that rely on it, sure.
00:14:45  <piscisaureus_>isaacs: maybe we could put it in an npm module or something
00:14:52  <isaacs>piscisaureus_: we ought to move it to an npm module *now*, yes.
00:15:10  <piscisaureus_>isaacs: so we can print "hey, node-waf is gone, but if you really need it: npm install -g node-waf"
00:15:26  <isaacs>but it'll need some of the goodness that node-gyp does, where it fetches the headers etc.
00:15:56  <piscisaureus_>isaacs: keeping backward compat for binary addons is also kind of a pain
00:16:00  <isaacs>yeah.
00:16:07  <piscisaureus_>isaacs: I mean, libuv is far less mature than node
00:16:13  <piscisaureus_>I expect stuff to change in there a lot
00:16:35  <piscisaureus_>on the bright side, the thing that most people need is not libuv's io - it's rather uv_poll, and timer, and queue_work
00:16:43  <piscisaureus_>that can keep working
00:17:05  <isaacs>piscisaureus_: it'll help to make that change asap in 0.9
00:17:21  <piscisaureus_>isaacs: which? you mean, libuv changes?
00:17:25  <isaacs>yeah
00:17:32  <piscisaureus_>isaacs: problem is, it's going to be a lot of work
00:17:38  <isaacs>true
00:17:44  <isaacs>it's going to be like most of 0.9 :)
00:17:50  <piscisaureus_>but it helps if we know where we're going
00:17:55  <isaacs>piscisaureus_: just get 0.9 done by, i duno, nodeconf.
00:17:56  <piscisaureus_>so I'll start working on a draft
00:18:02  <isaacs>piscisaureus_: then everyone can try it out
00:18:05  <piscisaureus_>yeah
00:18:07  <piscisaureus_>good point
00:18:08  <isaacs>a weekend's enough, right?
00:18:10  <isaacs>;P
00:18:20  * \toothrotquit (Ping timeout: 246 seconds)
00:18:47  <piscisaureus_>isaacs: I feel that setting the target for 0.8.1 at nodeconf was a little underambitious anyway
00:19:02  <piscisaureus_>isaacs: is that going out tomorrow btw?
00:19:19  <isaacs>piscisaureus_: yeah, just need to finish this email, merge in an npm retry fix, and then do it
00:19:23  <piscisaureus_>isaacs: cool
00:19:35  <piscisaureus_>lemme run make test-all on the joyent machine :-)
00:24:43  * \toothrotjoined
00:25:05  <CIA-108>node: Bert Belder master * rba0efd6 / (20 files in 10 dirs): Merge branch 'v0.8' (+15 more commits...) - http://git.io/3ok0Ew
00:25:26  <piscisaureus_>^-- had to unbreak master
00:28:57  * bcantrillquit (Quit: Leaving.)
00:35:26  <CIA-108>libuv: Ben Noordhuis v0.8 * rf6a02fb / src/unix/core.c : linux: don't use accept4() syscall after ENOSYS - http://git.io/BFNrzQ
00:35:27  <CIA-108>libuv: Ben Noordhuis v0.8 * r27cd5f0 / src/unix/linux/syscalls.c : linux: fix accept4() ENOSYS detection on i386 - http://git.io/xYW61Q
00:35:29  <CIA-108>libuv: Ben Noordhuis master * rf90d428 / test/test-spawn.c : test: fix unused function warning (+11 more commits...) - http://git.io/TuIJfA
00:35:30  <CIA-108>libuv: Ben Noordhuis v0.8 * r5b8a112 / common.gypi : darwin: compile at -O0 in debug builds - http://git.io/TbjuRQ
00:37:25  * travis-cijoined
00:37:25  <travis-ci>[travis-ci] joyent/libuv#469 (master - f90d428 : Ben Noordhuis): The build passed.
00:37:25  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/c6f2ef25c62b...f90d428b2962
00:37:25  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1734115
00:37:25  * travis-cipart
00:37:40  * travis-cijoined
00:37:40  <travis-ci>[travis-ci] joyent/libuv#470 (v0.8 - 5b8a112 : Ben Noordhuis): The build passed.
00:37:40  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/4a88b3b4b72d...5b8a1127fedb
00:37:40  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1734117
00:37:40  * travis-cipart
00:39:40  <bnoordhuis>damn, i checked in a line of code that's 83 characters long. the shame!
00:39:49  <piscisaureus_>isaacs: bnoordhuis: foei!
00:39:54  <piscisaureus_>er, not indutny
00:40:03  * piscisaureus_sighs
00:40:03  <bnoordhuis>and neither isaacs, i presume :)
00:40:38  <piscisaureus_>isaacs: bnoordhuis: I would like to really fix this sync / async stdio issue in 0.10
00:40:53  <isaacs>piscisaureus_: sure. post an issue. give it a milestone :)
00:41:13  <piscisaureus_>isaacs: bnoordhuis: it seems that both async and sync cause surprises for people, depending on what they are using it for
00:41:40  <piscisaureus_>so as a first step, I'd suggest we add the ability to do blocking writes to pipes and sockets in libuv
00:41:52  <bnoordhuis>i'm not surprised. it causes surprises for me too
00:42:16  <piscisaureus_>yes, it bites me every time. Seen that issue by andreasmadsen?
00:42:32  <bnoordhuis>piscisaureus_: i though you were going to propose dropping blocking i/o altogether...
00:42:35  <bnoordhuis>*thought
00:42:38  <piscisaureus_>no
00:43:11  <piscisaureus_>I'd like libuv to support both, but I think an async uv_write should never actually block
00:43:51  <piscisaureus_>(with the exception of tty writes - I don't care much about those, but I suppose it would be nice to make that consistent with the rest)
00:46:28  <piscisaureus_>isaacs: bnoordhuis: I don't know what the actual api in node should look like. It seems reasonable to make sure that console.log output doesn't get dropped on the floor when the process unexpectedly exits.
00:46:28  <piscisaureus_>But I think that at least there should be an option to write to stdin/stdout in an non-blocking fashion, regardless the type of it.
00:46:44  <piscisaureus_>so, stream._writeSync maybe? ...
00:47:23  <bnoordhuis>argh
00:47:33  <isaacs>piscisaureus_: hm. or maybe a TTYSyncStream class, like we have SyncWriteStream for when stdout is a file?
00:47:54  <isaacs>with a big warning that says "DO NOT USE"?
00:48:15  <piscisaureus_>isaacs: haha. But that would mean that people have to replace process.stdout by something else
00:48:16  <isaacs>but it'd be weird if console.log is sync, and process.stdout.write is not
00:48:23  <piscisaureus_>isaacs: why?
00:48:37  <isaacs>piscisaureus_: because sometimes you want to write like console.log, but without the \n
00:48:43  <piscisaureus_>isaacs: maybe you're right - I am not convinced
00:48:52  <piscisaureus_>isaacs: well, then you'd use process.stdout.writeSync
00:49:00  <isaacs>right...
00:49:14  <piscisaureus_>isaacs: the problem with TTYSyncStream is that TTYs are not the major point of concern - here - pipes are
00:49:57  <piscisaureus_>isaacs: plus, you're suggesting that people do "process.stdout = new require('tty').TTYSyncStream(0)" when they want it blocking?
00:49:58  <piscisaureus_>fuuuu
00:50:03  <piscisaureus_>no offense :-)
00:50:33  <isaacs>yeah, no, that's kind of awful
00:51:04  <piscisaureus_>isaacs: we could also do process.stdout.setBlocking(bool)
00:51:15  <isaacs>ooh.
00:51:19  <isaacs>yeah, that's probably the right way to go
00:51:29  <isaacs>and that should be a general TTYStream thing, maybe
00:51:49  <isaacs>actually... why not just have stdout be sync by default? i'm still not quite groking it...
00:51:55  <piscisaureus_>isaacs: a TTY is a particular type of device. process.stdout is a TTY stream if the stdout is a tty
00:52:01  <isaacs>right
00:52:17  <piscisaureus_>isaacs: it *is* blocking by default (except on windows when it's a pipe)
00:52:28  <isaacs>so, part of the issue is that process.exit() didn't flush it
00:52:34  * dapquit (Quit: Leaving.)
00:52:42  <isaacs>and "normal exit" would happen before it was done
00:52:52  <piscisaureus_>isaacs: but when people spawn node from node and use stdout to communicate, then blocking is a huge surprise
00:53:11  <isaacs>so you'd do console.log('foo');process.exit() and never get the message.
00:53:24  <piscisaureus_>isaacs: that used to be the problem in 0.4 and earlier, yes
00:53:28  <isaacs>right
00:53:54  <isaacs>but if it flushed, or held a ref or something so the process *didn't* exit until the write() was accepted, then i think that'd be fine
00:54:00  <isaacs>and console.log() could do a writeSync
00:54:12  <piscisaureus_>isaacs: that works, unless the process really crashes
00:54:18  <isaacs>sure
00:54:28  <piscisaureus_>isaacs: because this flushing has to be done by libuv and libuv won't do that when it's fucked up
00:54:29  <isaacs>and that's already kind of awful, since you get half-stacks and such
00:54:33  <piscisaureus_>yeah
00:54:38  <piscisaureus_>well stderr has always been blocking actually :-)
00:55:02  <piscisaureus_>although I believe the issues also extended into stderr at some point
00:55:17  <isaacs>i've seen cases where an abort() will cause it to get truncated, but that was probably a long time ago
00:55:34  <isaacs>or cases where i've got like 10 different node processes on the same terminal
00:55:36  <piscisaureus_>yeah, that could also be because glibc does some buffering internally
00:55:43  <isaacs>right
00:55:48  <isaacs>but those are edges we don't need to worry about
00:55:55  <piscisaureus_>we can also work around that
00:55:57  <isaacs>you should never need to |cat just to get all your output
00:56:02  <piscisaureus_>yeah
00:56:18  <isaacs>console should be blocking, since it's a debugging api
00:56:22  <isaacs>and timing matters.
00:56:30  <piscisaureus_>at some point in the 0.5 timeline we decided that stdio would always be blocking, except for pipes
00:56:39  <isaacs>but i think either setBlocking() or stdout.writeSync would be fine.
00:56:42  <piscisaureus_>so I did that on windows, but it was never done for unix (this is basically a libuv bug)
00:57:06  <piscisaureus_>so node blabla | cat would actually *not* work if that were correctly implemented :-)
00:58:59  <isaacs>heh
00:59:34  <isaacs>yeah, i think the key is console.*() needs to be blocking, and anything I write to process.std*() needs to get written before i exit.
00:59:46  <isaacs>within those constraints, I don't think anyone will care too much
00:59:51  * \toothrotquit (Ping timeout: 250 seconds)
01:01:10  * pieternquit (Quit: pietern)
01:01:34  <piscisaureus_>https://github.com/joyent/node/issues/3584
01:02:00  <piscisaureus_>isaacs: process.send is another one that needs attention
01:02:08  <piscisaureus_>isaacs: there are two problems here:
01:03:46  <piscisaureus_>* on windows, people have reported that workers were slowly "inflating" because they were all bombing the master process with messages, and the master couldn't keep up. There is no backpressure mechanism for process.send so this problem cannot be solved atm.
01:03:46  <piscisaureus_>* on unix, when you write small messages it doesn't matter much, because the pipe itself will buffer some data. However when you send a large message the worker will block for a significant amount of time.
01:03:59  <piscisaureus_>(remember that on unix the pipe is blocking)
01:13:10  <piscisaureus_>isaacs: btw, from a windows perspective, the 0.8 branch is in a good shape (just tested), so feel free to ship it whenever you feel like it
01:13:33  <isaacs>kewl, thanks
01:13:54  <isaacs>yeah, it'd be nice if send() returned false, at least.
01:14:04  <isaacs>(and also if it was a stream)
01:14:11  <isaacs>(and also if streams were good)
01:15:15  <piscisaureus_>:-)
01:15:19  <piscisaureus_>streams need fixing
01:15:26  <piscisaureus_>but I <3 streams
01:15:32  <piscisaureus_>but we should make them a little more consistent
01:15:36  <isaacs>yes
01:15:40  <isaacs>they don't need major work.
01:15:47  <isaacs>the just need the right polishing
01:16:06  <piscisaureus_>and write a guide on how to implement them (and maybe even a standard "streams interface" test)
01:16:07  <isaacs>i wanna have a sit-down (maybe virtual) with dominictarr and mikeal and maxogden.
01:16:11  <isaacs>yes.
01:17:04  <isaacs>and like, find out, what changes would make fstream, request, filed, node-tar, tap, eventstreams, dominode, etc. easier to do.
01:17:31  <isaacs>streams are nice to use, but kind of crap to implement.
01:17:46  <piscisaureus_>yeah
01:17:58  <piscisaureus_>and we need to "fix" stream.pipe
01:18:02  <piscisaureus_>give it a callback
01:18:28  <piscisaureus_>that is called once, after pipe is done or failed (and, optionally, the streams have been destroyed)
01:19:25  <piscisaureus_>Yay
01:19:32  <piscisaureus_>0.10 will be so much better than 0.8 :-)
01:21:24  * fjakobsquit (Read error: Connection reset by peer)
01:21:29  <CIA-108>libuv: Ben Noordhuis master * rc89df5b / (test/benchmark-list.h uv.gyp test/benchmark-async-pummel.c): bench: add another async handle benchmark - http://git.io/fEs_6A
01:21:30  <CIA-108>libuv: Ben Noordhuis master * r4c87666 / src/unix/async.c : unix: speed up uv_async_send() - http://git.io/Hzq_aA
01:22:30  * fjakobsjoined
01:23:31  * travis-cijoined
01:23:32  <travis-ci>[travis-ci] joyent/libuv#471 (master - 4c87666 : Ben Noordhuis): The build passed.
01:23:32  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f90d428b2962...4c87666a9363
01:23:32  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1734347
01:23:32  * travis-cipart
01:23:32  <isaacs>piscisaureus_: or maybe if not a cb on .pipe(), a guarantee that certain events will always be called.
01:23:46  <isaacs>like, exactly one of "end" or "error" will occur, always.
01:24:08  <isaacs>but not both
01:24:13  <piscisaureus_>isaacs: yeah
01:24:21  <piscisaureus_>isaacs: or "close" <-- i think that fits better :-)
01:24:33  <isaacs>piscisaureus_: "close" already means "the underlying resource is gone now"
01:24:39  <piscisaureus_>yeah
01:24:40  <isaacs>piscisaureus_: "end" is more general.
01:24:45  <isaacs>it means "no more data is coming"
01:24:57  <isaacs>but some emit end after error, sometimes long after.
01:25:13  <isaacs>error should mean "this stream is dead. please dispose of it"
01:25:17  <piscisaureus_>isaacs: "end" in my book means "no more data is coming and we've gracefully reached the end"
01:25:18  * fjakobsquit (Client Quit)
01:25:24  <isaacs>piscisaureus_: right.
01:25:28  <isaacs>you've crossed the finish line :)
01:25:31  <isaacs>you win
01:25:47  <isaacs>error = all bets are off. this stream is now poisonous.
01:25:50  <piscisaureus_>isaacs: but how's that for writable streams ?
01:26:05  <isaacs>piscisaureus_: maybe "end" is "all the data has been flushed to whatever it is i'm writing to"?
01:26:23  <isaacs>piscisaureus_: it sucks that there's no consistent way to know that a writable stream is done.
01:26:24  <piscisaureus_>isaacs: well, we can't do that because we have duplex streams
01:26:32  <isaacs>piscisaureus_: right
01:26:35  <isaacs>derp
01:26:46  <isaacs>we do "finish" on responses
01:26:50  <isaacs>maybe just bless that?
01:26:52  <piscisaureus_>isaacs: and "end" already means "the other end is done sending stuff, but if you have things to say, go ahed"
01:26:57  <isaacs>end, close, abort, finish...
01:27:02  <piscisaureus_>yeah
01:27:04  <isaacs>right
01:27:19  <isaacs>i feel like i've had this conversation at least hundreds of times.
01:27:20  <piscisaureus_>I have to sleep on that and play with it
01:27:23  <piscisaureus_>but yeah
01:27:24  <isaacs>it alwasy gets to this place.
01:28:11  <piscisaureus_>isaacs: https://gist.github.com/2910892
01:28:19  <piscisaureus_>isaacs: ^-- that should be simpler!
01:28:33  <piscisaureus_>isaacs: note that that code is almost exclusively edge case handling
01:28:40  <isaacs>piscisaureus_: yes.
01:29:54  <piscisaureus_>isaacs: so that's the reason I wanted a pipe callback. the "download" function should be doable with a one-liner, and that one-liner should tell you if it succeeded or not at the end, and it should clean up all the mess
01:30:11  <piscisaureus_>and the one liner should be longer than that ^^ sentence :-)
01:30:35  <piscisaureus_>er, *not* longer
01:30:39  <isaacs>ok, yes, then i agree.
01:35:30  * abraxasjoined
01:41:50  * IKchanged nick to ik
01:42:26  <piscisaureus_>isaacs: bnoordhuis: fix this -> https://github.com/joyent/node/issues/3558 ?
01:44:20  <isaacs>piscisaureus_: that's tricky. wasn't there another issue aobut listen('sock') NOT throwing EADDRINUSE if the socket already exists, and instead clobbering it?
01:45:28  <piscisaureus_>isaacs: no the thing is they do server.listen({host: "locahost", port: '/tmp/mypipe.sock'})
01:45:34  * CoverSli1ejoined
01:45:38  <piscisaureus_>isaacs: that actually worked in 0.6 but no longer in 0.8
01:45:56  <isaacs>piscisaureus_: yeah, same with listen('sock')
01:46:03  <isaacs>in 0.6 it clobbered any existing file that was there.
01:46:07  <isaacs>in 0.8 it raises enoent
01:46:10  <isaacs>er, eaddrinuse
01:46:17  <piscisaureus_>isaacs: no, that's another issue
01:46:29  * CoverSlidequit (Ping timeout: 264 seconds)
01:46:33  <piscisaureus_>isaacs: they can no longer do what I typed there, because the "" correct
01:46:54  <isaacs>i see.
01:46:57  * isaacsshrug
01:47:00  <isaacs>sure we can fix it. i dunno.
01:47:03  <isaacs>why not.
01:47:07  <isaacs>FIX ALL THE BUGS!
01:47:27  <piscisaureus_>isaacs: I don't care. I was like "meh" until this breaking code discussion :-)
01:47:32  <piscisaureus_>WHAT HAVE YOU DONE
01:47:52  <isaacs>yeah, i'm sure i'll hear about it.
01:47:54  <isaacs>0.8.2
01:47:57  <piscisaureus_>WHAT ARE WE SUPPOSED TO DO NOW, HUH
01:48:54  * bcantrilljoined
01:50:01  <piscisaureus_>who put all these quotes in loudbot?
01:50:10  <piscisaureus_>LOUDBOT, WHO WAS THAT?
01:51:03  <isaacs>LOUDBOT: WHOSAID
01:51:04  <LOUDBOT>isaacs: simcop2387-lap in ##turtles on freenode
01:51:08  <isaacs>LOUDBOT: WHOSAID
01:51:08  <LOUDBOT>isaacs: simcop2387-lap in ##turtles on freenode
01:51:19  <isaacs>oh, it only gives you one :)
01:55:20  <piscisaureus_>haha
01:55:27  <piscisaureus_>orly people actually say that
01:55:45  <piscisaureus_>loudbot sounds a little like the offline version of bnoordhuis
01:55:45  <isaacs>LOUDBOT: search clusters
01:55:47  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:55:50  <isaacs>LOUDBOT: whosaid
01:55:50  <LOUDBOT>isaacs: ldp in ##wall on freenode
01:56:00  <piscisaureus_>LOUDBOT: search bugs
01:56:01  <LOUDBOT>piscisaureus_: <apeiron:##turtles> YOU HAVEN'T FIXED ANY OF THE BUGS I POINTED OUT YESTERDAY HAVE YOU
01:56:06  <isaacs>LOUDBOT: twitlast
01:56:07  <LOUDBOT>isaacs: http://twitter.com/loudbot/status/218523006669041666 (apeiron/##turtles)
01:56:18  <isaacs>you should probably follow @loudbot
01:56:21  <isaacs>on the twitters
01:56:50  <piscisaureus_>LOUDBOT: search stimulated
01:56:51  <LOUDBOT>piscisaureus_: <sili:#perlcafe> I HAVENT BEEN STIMULATED IN AT LEAST 3 WEEKS
01:56:58  <piscisaureus_>LOUDBOT: whosaid
01:56:59  <LOUDBOT>piscisaureus_: sili in #perlcafe on freenode
02:00:58  <AvianFlu>LOUDBOT, search isaacs
02:03:47  * bcantrillquit (Quit: Leaving.)
02:04:55  * bcantrilljoined
02:04:59  * bnoordhuisquit (Ping timeout: 246 seconds)
02:05:16  <piscisaureus_>LOUDBOT, search AvianFly
02:05:18  <isaacs>piscisaureus_: you already updated v8. thanks!
02:05:20  <piscisaureus_>LOUDBOT, search AvianFlu
02:05:20  <LOUDBOT>piscisaureus_: <AvianFlu:#stackvm> BY PAINTING BIG RED X'S ON THE BACK OF THE SHEEP THAT KICK!
02:05:33  <AvianFlu>for the record
02:05:34  <piscisaureus_>isaacs: yeah, that was a pretty serious bug they fixed :-0
02:05:44  <AvianFlu>that's the punchline to "how do they practice safe sex in new zealand"
02:05:58  <piscisaureus_>ghe ghe
02:06:34  <piscisaureus_>LOUDBOT: search osama
02:06:35  <LOUDBOT>piscisaureus_: <GIR:#mefi> SHIT FRANK BLACK THE END FOR OSAMA?
02:09:34  <CIA-108>node: isaacs v0.8 * rc721604 / (131 files in 14 dirs): npm: Upgrade to 1.1.33 - http://git.io/NvmO2A
02:10:12  <piscisaureus_>OMG I AM SO EXCITED NPM JUST GOT UPGRADED TO 1.1.13
02:10:31  * brsonquit (Ping timeout: 245 seconds)
02:10:57  * bcantrillquit (Quit: Leaving.)
02:12:34  <CIA-108>node: isaacs v0.8 * r3644b0b / (3 files in 3 dirs): uv: upgrade to 5b8a112 - http://git.io/imMavg
02:12:45  <isaacs>piscisaureus_: 1.1.13?
02:13:05  <piscisaureus_>sorry I made a typo
02:13:08  <isaacs>i'm considering writing an npmbot that kicks anyone who uses any capital letters.
02:13:11  <piscisaureus_>but what has been said cannot be unsaid
02:13:19  <isaacs>piscisaureus_: indeed. it's immortalized in loudbot now
02:13:23  <isaacs>LOUDBOT: search NPM
02:13:24  <LOUDBOT>isaacs: <piscisaureus_:#libuv> OMG I AM SO EXCITED NPM JUST GOT UPGRADED TO 1.1.13
02:13:26  <isaacs>see?
02:13:34  <piscisaureus_>ouch
02:13:44  <isaacs>it's ok, people will just think it's old school
02:13:56  <AvianFlu>yeah, no timestamps ftw
02:14:01  <piscisaureus_>I better not say any bad stuff that
02:14:05  <piscisaureus_>LOUDBOT: search underage
02:14:20  <piscisaureus_>I mean, that's not good when you're applying for a job :-p
02:14:47  <piscisaureus_>I'm thinking loudbot should also post everything you say on your facebook page :-p
02:29:01  <CIA-108>node: isaacs v0.8.1-release * r840456a / (ChangeLog src/node_version.h): 2012.06.29, Version 0.8.1 (stable) - http://git.io/d7aWrQ
02:29:23  <isaacs>get your tests on^
02:39:57  * brsonjoined
02:43:48  * isaacstopic: test please http://nodejs.org/dist/v0.8.1/
02:44:06  <isaacs>test please http://nodejs.org/dist/v0.8.1/
02:44:19  * isaacsoff to build the binaries
03:09:51  <piscisaureus_>isaacs: lgtm (win)
03:10:04  <isaacs>this could be the first swish
03:10:17  <isaacs>man, 0.8 is SO much more solid.
03:10:21  <isaacs>than 0.6 ever was
03:11:49  <isaacs>make test-npm fails. that's weird.
03:11:55  <isaacs>because make test in npm works fine
03:16:06  <isaacs>oh, works as root
03:16:15  <isaacs>whatever. those tests are pointless anyway
03:27:31  <CIA-108>libuv: Ben Noordhuis master * r05e4ca5 / (3 files): test: fix test-gethostbyname to not use a DNS server on localhost - http://git.io/LMkisQ
03:27:31  <CIA-108>libuv: Ben Noordhuis master * ra0722de / (30 files in 3 dirs): c-ares: upgrade to 1.9.0 - http://git.io/NNlSHA
03:27:31  <CIA-108>libuv: Ben Noordhuis master * rc2381bc / (5 files in 3 dirs): c-ares: libuv-ify c-ares - http://git.io/4FoAUA
03:27:32  <CIA-108>libuv: saghul master * rb68600d / src/ares/ares_init.c : c-ares: ignore rogue DNS servers reported by windows - http://git.io/OrdB7w
03:27:32  <CIA-108>libuv: Bert Belder master * r6e5f36a / test/test-fs-event.c : Revert "test: improve clean-up in test-fs-event" - http://git.io/x8-t_w
03:29:29  * travis-cijoined
03:29:30  <travis-ci>[travis-ci] joyent/libuv#472 (master - 6e5f36a : Bert Belder): The build was broken.
03:29:30  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/4c87666a9363...6e5f36a2c330
03:29:30  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1734781
03:29:30  * travis-cipart
03:30:29  <CIA-108>libuv: Bert Belder master * r937d2c9 / (3 files): test: fix test-gethostbyname to not use a DNS server on localhost - http://git.io/IZpu-Q
03:30:29  <CIA-108>libuv: Saúl Ibarra Corretgé master * r3e425ab / (30 files in 3 dirs): c-ares: upgrade to 1.9.0 - http://git.io/kLcy8Q
03:30:29  <CIA-108>libuv: Ben Noordhuis master * r15cfcfd / (5 files in 3 dirs): c-ares: libuv-ify c-ares - http://git.io/_dShwA
03:30:30  <CIA-108>libuv: Saúl Ibarra Corretgé master * r5ee80f1 / src/ares/ares_init.c : c-ares: ignore rogue DNS servers reported by windows - http://git.io/JEdVIQ
03:30:31  <CIA-108>libuv: Bert Belder master * re9b17bc / test/test-fs-event.c : Revert "test: improve clean-up in test-fs-event" - http://git.io/FNo-ZA
03:32:37  * travis-cijoined
03:32:37  <travis-ci>[travis-ci] joyent/libuv#473 (master - e9b17bc : Bert Belder): The build is still failing.
03:32:37  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/4c87666a9363...e9b17bcc65da
03:32:37  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1734783
03:32:37  * travis-cipart
03:37:56  <CIA-108>libuv: Bert Belder v0.8 * rc2f9b49 / (3 files): test: fix test-gethostbyname to not use a DNS server on localhost - http://git.io/dSTLZg
03:40:00  * travis-cijoined
03:40:00  <travis-ci>[travis-ci] joyent/libuv#474 (v0.8 - c2f9b49 : Bert Belder): The build was broken.
03:40:00  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/5b8a1127fedb...c2f9b49ffc99
03:40:00  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1734794
03:40:00  * travis-cipart
03:42:31  * bcantrilljoined
03:46:14  <CIA-108>libuv: Bert Belder v0.8 * r7628b65 / (test/test-gethostbyname.c test/test-list.h): test: fix test-gethostbyname to not use a DNS server on localhost - http://git.io/JGRElg
03:48:42  * bcantrillquit (Quit: Leaving.)
03:48:43  * travis-cijoined
03:48:43  <travis-ci>[travis-ci] joyent/libuv#475 (v0.8 - 7628b65 : Bert Belder): The build is still failing.
03:48:43  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/c2f9b49ffc99...7628b6597e0d
03:48:43  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1734836
03:48:43  * travis-cipart
03:49:55  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
03:55:28  * theColejoined
04:05:18  * piscisaureus_joined
04:06:10  <CIA-108>libuv: Bert Belder master * r7628b65 / (test/test-gethostbyname.c test/test-list.h): test: fix test-gethostbyname to not use a DNS server on localhost - http://git.io/JGRElg
04:06:11  <CIA-108>libuv: Bert Belder master * r700f133 / : Merge branch 'v0.8' - http://git.io/O-G2rw
04:08:14  * travis-cijoined
04:08:14  <travis-ci>[travis-ci] joyent/libuv#476 (master - 700f133 : Bert Belder): The build is still failing.
04:08:14  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/e9b17bcc65da...700f1333e157
04:08:14  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1734899
04:08:14  * travis-cipart
04:15:14  * bcantrilljoined
04:42:30  * piscisaureus_quit (Ping timeout: 255 seconds)
04:51:04  * piscisaureus_joined
05:08:02  <CIA-108>node: isaacs v0.8 * r3e0757c / lib/fs.js : lint - http://git.io/Jlv9sg
05:15:21  <piscisaureus_>isaacs: there's some stuff missing in the change log:
05:17:53  <piscisaureus_>* https://github.com/joyent/node/issues/3560
05:17:54  <piscisaureus_>* https://github.com/joyent/node/issues/3554
05:17:54  <piscisaureus_>* fix v8 build when compiling with gcc 4.5 (may issues)
05:24:52  <CIA-108>node: isaacs v0.8 * r1747eef / doc/index.html : homepage: Update Claudio's title/link - http://git.io/USEXLA
05:38:33  * theColepart
05:44:05  * piscisaureus_quit (Ping timeout: 246 seconds)
05:46:16  * brsonquit (Ping timeout: 250 seconds)
05:47:59  * brsonjoined
05:53:10  * paddybyersjoined
05:53:11  * paddybyersquit (Client Quit)
05:56:49  * felixgejoined
05:56:49  * felixgequit (Changing host)
05:56:50  * felixgejoined
06:31:11  * felixgequit (Quit: felixge)
06:32:23  * felixgejoined
06:32:23  * felixgequit (Read error: Connection reset by peer)
06:33:11  * felixgejoined
06:33:11  * felixgequit (Changing host)
06:33:12  * felixgejoined
06:51:46  * stephankquit (Quit: *Poof!*)
06:55:33  * rendarjoined
07:11:22  * felixge_joined
07:11:22  * felixge_quit (Changing host)
07:11:22  * felixge_joined
07:13:09  * felixgequit (Ping timeout: 248 seconds)
07:13:10  * felixge_changed nick to felixge
07:30:15  * felixgequit (Quit: felixge)
07:38:08  * felixgejoined
07:38:08  * felixgequit (Changing host)
07:38:08  * felixgejoined
07:41:30  * felixgequit (Client Quit)
07:58:51  * theColejoined
07:59:20  * theColequit (Client Quit)
08:12:50  * ^3rdEdenjoined
08:18:43  <isaacs>ah, youer' right
08:18:45  <isaacs>thanks
08:18:47  * brsonquit (Quit: leaving)
08:19:13  <isaacs>indutny: are you familiar with stud? https://github.com/bumptech/stud
08:33:55  * felixgejoined
08:33:55  * felixgequit (Changing host)
08:33:55  * felixgejoined
08:36:29  <indutny>isaacs: kind of
08:36:46  <indutny>sup?
08:51:22  <^3rdEden>stunnel is faster :)
08:57:48  <isaacs>indutny: that's the one that i'm told is the one to use.
08:58:02  <indutny>isaacs: huh?
08:58:03  <isaacs>they've got some experimental memory-sharing thing so that the process cluster can all share the negotiation
08:58:07  <isaacs>indutny: stud
08:58:09  <indutny>ah, yes
08:58:17  <indutny>memory sharing is what others are using too
08:58:23  <indutny>but I don't think we can do that in node
08:58:33  <isaacs>indutny: it's software :)
08:58:33  <indutny>it won't work on windows, I suppose
08:58:45  <indutny>well, stud is
08:58:49  <isaacs>maybe not trivially :)
08:58:52  <isaacs>i mean, it all is
08:58:52  <indutny>but concept of memory sharing is, you know, concept
08:58:55  <isaacs>we'll just make ti work
08:58:58  <isaacs>:)
08:58:59  <indutny>ah, ok
08:59:01  <indutny>:)
08:59:03  <isaacs>windows is software, oto
08:59:09  <isaacs>does microsoft take patches?
08:59:12  <indutny>http://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx
08:59:13  <indutny>nope
08:59:21  <indutny>but they have some sort of shared memory over here
08:59:25  <isaacs>kewl
08:59:33  <indutny>so we can mmap on unixes and use that for MS
08:59:45  <indutny>but are we really hitting this?
09:00:44  <^3rdEden>isaacs if you are interested in the ssl termination performance you might be interested in; http://vincent.bernat.im/en/blog/2011-ssl-benchmark-round2.html
09:00:55  <isaacs>^3rdEden: kewl
09:01:09  <isaacs>if stunnel is faster, we should figure out why that is, also
09:07:21  <isaacs>^3rdEden: this article is awesome
09:07:34  <isaacs>it's also way too late to be trying to digest this
09:07:48  <isaacs>thanks!
09:10:27  <isaacs>gst
09:10:52  <^3rdEden>Glad it's helpfull
09:15:07  <CIA-108>node: isaacs v0.8.1-release * r2134aa3 / (AUTHORS ChangeLog src/node_version.h): 2012.06.29, Version 0.8.1 (stable) - http://git.io/s_p9jg
09:20:28  * hzjoined
09:26:18  <indutny>^3rdEden: nice
09:32:17  * bcantrillquit (Quit: Leaving.)
10:40:44  * abraxasquit (Remote host closed the connection)
10:41:43  * abraxasjoined
10:43:04  * abraxasquit (Remote host closed the connection)
10:49:14  * ^3rdEdenchanged nick to `3rdEden
11:21:20  * felixgequit (Quit: felixge)
11:22:08  * felixgejoined
11:22:08  * felixgequit (Changing host)
11:22:08  * felixgejoined
11:52:24  * felixgequit (Quit: felixge)
11:58:29  * benviequit
12:34:40  * bnoordhuisjoined
12:35:48  <indutny>bnoordhuis: hey ben
12:35:50  <indutny>how are you doing?
12:35:54  <bnoordhuis>indutny: hey
12:35:59  <bnoordhuis>doing fine. you?
12:36:03  <indutny>me too
12:39:22  <indutny>SVO->NYC tomorrow
12:39:23  <indutny>:)
12:52:50  <bnoordhuis>looking forward to it?
12:59:27  <indutny>bnoordhuis: yeah, kind of
12:59:35  <indutny>quite nervous about on-going stuff
12:59:38  <indutny>preparing, you know
12:59:50  <indutny>bnoordhuis: about SSL stuff
13:00:16  <indutny>what is our goal: make it faster, or make it faster than {XXX} ?
13:09:01  * piscisaureus_joined
13:16:52  <tjfontaine>feels weird getting pimped by piscisaureus_ on an issue
13:17:33  <piscisaureus_>tjfontaine: your project was just right for him. He can just go and hack his way with your dns module :-)
13:17:44  <tjfontaine>indeed
13:18:17  <tjfontaine>and OneDay the MagicalDiety will help me to get node-dns part of core, and all will be right in the world
13:18:32  <piscisaureus_>tjfontaine: have you benchmarked the thing etc?
13:19:24  <tjfontaine>piscisaureus_: I did in the early .7 days, it was performing near c-ares, at least it wasn't severely slower
13:19:29  <piscisaureus_>tjfontaine: I am not strictly opposed to doing DNS all in js but of course it has to be better than cares :-)
13:19:43  <tjfontaine>piscisaureus_: right, I figured that would be at least the first hurdle :)
13:19:50  <piscisaureus_>or atleast comparable and significantly easier to maintain
13:20:37  <piscisaureus_>tjfontaine: but I dig the project anyway because there are always people that want stuff like their own nameservers, or NAPTR queries, or whatever
13:20:53  <piscisaureus_>and they can just do that with node-dns, and if not, they can add it themselves
13:21:01  <tjfontaine>piscisaureus_: right, or have to do dnsbl queries against specific servers etc
13:21:14  <piscisaureus_>exactly
13:21:26  <piscisaureus_>so if it grows super popular at some point we might wanna use it
13:21:42  <piscisaureus_>there are not so many people using cares dns anyway
13:21:56  <tjfontaine>a guy who works on the pool.ntp.org stuff used it for a proof of concept real time metrics for their dns load
13:22:00  <piscisaureus_>most is just related to net.connect and http.query and those requests go through getaddrinfo
13:22:56  <indutny>piscisaureus_: hey man
13:23:08  <indutny>piscisaureus_: when are you planning to get to the USA?
13:23:51  <piscisaureus_>tjfontaine: also, cares has some issues - it doesn't cache results nor does it expose TTL. It also opens /etc/hosts on every request :-(. There is room for improvement for sure
13:24:02  <piscisaureus_>indutny: flying out tomorrow morning EU time
13:24:36  <piscisaureus_>And I'll be arriving saturday at 12 or so PDT
13:24:55  <tjfontaine>piscisaureus_: oh, caching and ttl (and virtually any other flag) are trivial to access in mine, and hosts can use a file watcher (but is disabled by default)
13:25:35  <indutny>piscisaureus_: nice, me too
13:25:40  <indutny>piscisaureus_: at 12:00 ?
13:25:44  <piscisaureus_>yeah
13:25:49  <indutny>I'm arriving at 1:55 pm
13:26:06  <indutny>are you flighing directly to Portland?
13:26:10  <piscisaureus_>indutny: yeah
13:26:14  <indutny>oh, ok
13:26:18  <indutny>I'm to NYC
13:29:00  <piscisaureus_>indutny: ah, but you are going to portland right?
13:29:06  <indutny>well, yes
13:29:10  <indutny>at July 1
13:29:41  <piscisaureus_>ah you're in NYC for some jitsu
13:31:18  <indutny>hahaha
13:31:21  <indutny>indeed
13:32:31  <piscisaureus_>tjfontaine: if you add an issue to libuv to expose the list of DNS servers that the host uses, maybe we will :-)
13:32:38  <piscisaureus_>tjfontaine: I would be okay with that.
13:33:41  <tjfontaine>piscisaureus_: I had one, that ben was willing to merge, it kinda abused the fact that cares is already exported
13:33:44  <tjfontaine>lemme find it
13:33:49  <piscisaureus_>tjfontaine: although conceptually it's a bit complicated because windows has a per-adapter dns server
13:33:58  <piscisaureus_>tjfontaine: but I am sure we can find a way
13:34:23  <tjfontaine>piscisaureus_: https://github.com/joyent/node/pull/3132
13:36:28  <tjfontaine>I mean, cares is probably never going away in libuv, so why not reuse the logic :)
13:36:44  <piscisaureus_>tjfontaine: cares is definitely going away from libuv :-)
13:36:47  <tjfontaine>hehe
13:36:48  <tjfontaine>ok
13:37:26  <piscisaureus_>tjfontaine: but we will probably keep it around in node for a while
13:37:42  <piscisaureus_>tjfontaine: but I kinda dig this project, so we should try to help you out here.
13:37:56  <tjfontaine>sounds good!
13:38:18  <piscisaureus_>tjfontaine: we could just put this "get the list of dns servers" in libuv directly and expose that as require('os').dnsServers() or something
13:39:34  <piscisaureus_>tjfontaine: and your dns stuff should be better because it does better caching is not so pathetic about parsing /etc/hosts all the time
13:39:55  <tjfontaine>well /etc/resolv.conf in that case
13:39:58  <tjfontaine>https://gist.github.com/3017990
13:40:05  <tjfontaine>trivial benchmark
13:40:25  <piscisaureus_>tjfontaine: no, I meant, cares reads /etc/hosts for every lookup
13:40:32  <tjfontaine>oh, yes that's absurd
13:41:23  <piscisaureus_>tjfontaine: oh my, so it is already faster?
13:41:36  <tjfontaine>piscisaureus_: nah, bigger is better in the bench module, so stock is faster
13:41:38  <piscisaureus_>oh wait no
13:42:25  <tjfontaine>but it's not way out in left field off performance
13:45:45  <piscisaureus_>tjfontaine: right, I think the gap could be much smaller. I'll do some experiments to see where the bottlenecks are
13:46:19  <tjfontaine>piscisaureus_: also, if you see design problems please don't hesitate to let me know
13:46:29  <piscisaureus_>tjfontaine: I won't :-)
13:46:39  <tjfontaine>:)
14:08:48  <tjfontaine>heh, with trivial caching my module is 9.66 times faster
14:11:03  <piscisaureus_>tjfontaine: how long are you caching?
14:11:15  <piscisaureus_>that probably doesn't matter for benchmark
14:11:16  <piscisaureus_>s
14:11:28  <tjfontaine>right, it was just "cache forever" scenario right there
14:15:10  * xaqjoined
14:26:20  <bnoordhuis>indutny: re ssl: 'make it faster' seems like a good start
14:26:31  <indutny>bnoordhuis: ok, got it ;)
14:26:55  <bnoordhuis>indutny: a benchmark that measures http vs https would be nice
14:27:10  <bnoordhuis>https used to be 10 times slower, haven't benchmarked it recently
14:27:26  <indutny>it should be much more slower
14:27:28  <indutny>like 60 times
14:27:30  <indutny>one one core
14:27:49  <indutny>http parsing overhead is minimal
14:28:19  <indutny>overhead is coming mostly from connection, which is free for http (just plain TCP), and very slow for SSL
14:31:49  * loladirojoined
14:40:40  * c4milojoined
14:45:25  <bnoordhuis>==29807== Process terminating with default action of signal 5 (SIGTRAP)
14:45:26  <bnoordhuis>==29807== at 0xC23C9D: v8::internal::OS::DebugBreak() (platform-linux.cc:389)
14:45:26  <bnoordhuis>==29807== by 0xC23C91: v8::internal::OS::Abort() (platform-linux.cc:371)
14:45:26  <bnoordhuis>==29807== by 0x8BA8CB: V8_Fatal (checks.cc:58)
14:45:26  <bnoordhuis>==29807== by 0x895B8F: v8::internal::Handle<v8::internal::Object>::operator*() const (handles-inl.h:65)
14:45:27  <bnoordhuis>==29807== by 0xA2FD27: v8::internal::JSObject::GetPropertyWithInterceptor(v8::internal::JSReceiver*, v8::internal::String*, PropertyAttributes*) (objects.cc:10290)
14:45:29  <bnoordhuis>==29807== by 0xA0DC3E: v8::internal::Object::GetProperty(v8::internal::Object*, v8::internal::LookupResult*, v8::internal::String*, PropertyAttributes*) (objects.cc:639)
14:45:32  <bnoordhuis>==29807== by 0xA0D59F: v8::internal::Object::GetProperty(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::LookupResult*, v8::internal::Handle<v8::internal::String>, PropertyAttributes*) (objects.cc:565)
14:45:36  <bnoordhuis>==29807== by 0xC4522A: v8::internal::LoadIC::Load(v8::internal::InlineCacheState, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::String>) (ic.cc:922)
14:45:39  <bnoordhuis>==29807== by 0xC4A4FA: v8::internal::LoadIC_Miss(v8::internal::Arguments, v8::internal::Isolate*) (ic.cc:2067)
14:45:42  <bnoordhuis>==29807== by 0x3F5DC580618D: ???
14:45:44  <bnoordhuis>^ that's bad
14:46:21  * loladiroquit (Remote host closed the connection)
14:46:22  <bnoordhuis>indutny, piscisaureus_: can you guys try this -> out/Debug/node -e 'require("net").connect(530, "", console.log)'
14:46:29  <indutny>yeah
14:46:31  <bnoordhuis>make sure it's a debug build
14:46:32  * loladirojoined
14:46:50  <indutny>on a master?
14:46:53  <bnoordhuis>yes
14:47:18  <piscisaureus_>bnoordhuis: which node version?
14:47:19  <indutny>I'll need to do a build first
14:47:24  <bnoordhuis>piscisaureus_: current master
14:47:27  <indutny>few minutes
14:47:31  <bnoordhuis>sure, no rush
14:48:09  <piscisaureus_>bnoordhuis: ehm
14:48:10  <piscisaureus_>D:\node4>debug\node.exe -e 'require("net").connect(530, "", console.log)'
14:48:10  <piscisaureus_>undefined:1
14:48:10  <piscisaureus_>^^^^^^^^^^^^^^^^^^^^^^^^^^
14:48:10  <piscisaureus_>SyntaxError: Unexpected token ILLEGAL
14:48:42  <bnoordhuis>piscisaureus_: what happens when you put it in a script?
14:49:07  <indutny>bbiab
14:49:17  <indutny>pizza is waiting
14:49:22  <indutny>:)
14:49:25  <bnoordhuis>heh
14:49:28  <piscisaureus_>bnoordhuis: weirdness
14:49:41  <bnoordhuis>piscisaureus_: how so?
14:49:41  <indutny>may be
14:49:43  <piscisaureus_>bnoordhuis: I get a "16 bit application not supported error"
14:49:46  <indutny>console.log.bind(console)
14:49:48  <bnoordhuis>hah, what?
14:50:10  <piscisaureus_>ah hm
14:50:11  <bnoordhuis>indutny: it also happens with function() {}
14:50:15  <piscisaureus_>my node.exe seems fucked
14:50:24  <indutny>ok
14:50:25  <indutny>brb
14:51:01  * loladiroquit (Ping timeout: 265 seconds)
14:51:21  <piscisaureus_>bnoordhuis: node master is b0rked
14:51:28  <piscisaureus_>bnoordhuis: I cannot run the repl, it crashes
14:51:45  <piscisaureus_>#
14:51:45  <piscisaureus_># Fatal error in d:\node4\deps\v8\src\handles-inl.h, line 65
14:51:45  <piscisaureus_># CHECK(reinterpret_cast<Address>(*location_) != kHandleZapValue) failed
14:51:45  <piscisaureus_>#
14:51:55  <bnoordhuis>yeah, i just did a `make test` and everything is failing
14:53:38  <piscisaureus_>bnoordhuis: unfortunately your patch to fix gcc 45 broke master for a while :-(
14:54:02  <bnoordhuis>piscisaureus_: on windows? i'll bisect it here
14:54:09  <bnoordhuis>back in three hours :(
15:01:55  <piscisaureus_>bnoordhuis: Fix #3521 Use an object as the process.env proto
15:02:04  <piscisaureus_>e3074689f501eea413c29b99defac29659a2b615
15:04:38  * loladirojoined
15:05:02  <bnoordhuis>e3074689f501eea413c29b99defac29659a2b615
15:05:06  <bnoordhuis>yep, same one
15:05:17  <CIA-108>node: Bert Belder master * r0581afe / (src/node.cc test/simple/test-process-env.js): Revert "Fix #3521 Use an object as the process.env proto" - http://git.io/56nXow
15:08:42  * loladiroquit (Ping timeout: 244 seconds)
15:12:29  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
15:16:43  <piscisaureus_>http://gizmodo.com/5922235/we-were-right-google-confirms-chrome-is-to-blame-for-crashing-macbooks
15:20:18  <bnoordhuis>http://programmers.stackexchange.com/questions/154733/my-boss-decided-to-add-a-person-to-blame-field-to-every-bug-report-how-can-i <- awesome, we should have that
15:20:58  <piscisaureus_>yeah
15:22:48  <piscisaureus_>bnoordhuis: return info.Data().As<Object>()->Get(property); <-- scary
15:23:14  <bnoordhuis>actually, i suggested that, seeing that it's always an object :)
15:24:16  <piscisaureus_>bnoordhuis: what about Object::New()->Get(property)
15:25:09  <bnoordhuis>might work, i'll try it
15:25:21  <bnoordhuis>info.Data()->ToObject() still triggers the assertion btw
15:26:10  <piscisaureus_>bnoordhuis: you also want scope.Close( around the return value
15:26:28  <bnoordhuis>hah, i was just going to say that
15:26:36  <bnoordhuis>and that's indeed what's triggering the assert
15:26:44  <piscisaureus_>hah
15:26:54  <piscisaureus_>bnoordhuis: I don't dig the accessorinfo stuff
15:27:19  <piscisaureus_>bnoordhuis: I don't know what properties the accessorinfo has, but suppose it has a property " foo"
15:27:27  <piscisaureus_>bnoordhuis: then process.env.foo will be that
15:27:44  <bnoordhuis>piscisaureus_: info.Data() is an empty object
15:27:57  <piscisaureus_>bnoordhuis: if it's empty, then why is it there?
15:28:04  <piscisaureus_>what is it?
15:28:10  <bnoordhuis>to make __proto__ work less unexpectedly
15:28:24  <bnoordhuis>check the commit, that'll probably explain it better than i would
15:29:06  <piscisaureus_>right, ok
15:29:21  <piscisaureus_>well, in that case I do dig
15:29:28  <piscisaureus_>so scope.Close would suffice
15:29:39  <bnoordhuis>yes
15:29:51  <bnoordhuis>i'll revert-revert
15:31:29  <piscisaureus_>haha
15:31:51  <piscisaureus_>bnoordhuis: I am leaning towards "revert immediately when it breaks stuff"
15:32:04  <bnoordhuis>piscisaureus_: a good policy
15:32:14  <piscisaureus_>bnoordhuis: I also reverted some patch by AvianFlu in libuv last night because it was no good
15:32:53  <bnoordhuis>piscisaureus_: oh? it looked okay to me
15:32:57  <piscisaureus_>bnoordhuis: another question - does test-gethostbyname work for you on libuv/master
15:33:14  <piscisaureus_>bnoordhuis: the test was somewhat fucked up
15:33:30  <piscisaureus_>bnoordhuis: it started the echo server and then set up cares to use the echo server as a dns server
15:33:40  <bnoordhuis>piscisaureus_: yes, it works for me
15:33:48  <piscisaureus_>bnoordhuis: and then at some point you removed the echo server helper
15:34:09  <bnoordhuis>piscisaureus_: it uses dns_server, not echo_server
15:34:18  <piscisaureus_>bnoordhuis: no, that's the benchmark
15:34:47  <piscisaureus_>bnoordhuis: https://github.com/joyent/libuv/commit/937d2c93ea2c826ae579ae93b7c2745c4b950cc6
15:34:56  <bnoordhuis>oh, right
15:34:58  <piscisaureus_>bnoordhuis: so I just removed all that stuff and it's working for me on win and linux
15:35:10  <piscisaureus_>bnoordhuis: but now it's failing on travis
15:36:20  <piscisaureus_>sadface
15:36:27  <bnoordhuis>http://travis-ci.org/#!/joyent/libuv <- 23 days ago? wut?
15:37:11  <piscisaureus_>bnoordhuis: http://travis-ci.org/#!/joyent/libuv/builds
15:37:33  <bnoordhuis>oh, and now it's a commit from 11 hours ago
15:38:04  <bnoordhuis>Assertion failed in test/test-gethostbyname.c on line 58: timeouts == 0
15:38:23  <piscisaureus_>uv_chdir('dir-that-may-not-exist')
15:38:23  <piscisaureus_>// don't check the result
15:38:23  <piscisaureus_>delete_all_the_files()
15:38:23  <piscisaureus_>bnoordhuis: ^ re Avianflu's patch it does
15:38:23  <piscisaureus_>
15:39:08  <AvianFlu>whoops! >.<
15:39:08  <bnoordhuis>ah, right. dangerous
15:40:27  <piscisaureus_>AvianFlu: I added this in the comments as well, but for clarity: I prefer to use uv_fs_unlink/rmdir over remove() because the uv stuff actually works here. remove() gives me EACCESS all the time.
15:41:59  <AvianFlu>makes sense. I'm glad you noticed
15:42:14  <bnoordhuis>piscisaureus_: EACCES? why?
15:45:37  * TheJHjoined
16:04:31  * bcantrilljoined
16:06:46  <piscisaureus_>bnoordhuis: I honestly don't know
16:12:50  * japjjoined
16:19:19  * mikealjoined
16:28:35  * dapjoined
16:43:17  * stephankjoined
16:45:02  * benviejoined
16:49:22  <isaacs>piscisaureus_: any other suggestions to the 0.8.1 changelog?
16:49:26  <isaacs>piscisaureus_: updated it
16:52:28  <bnoordhuis>isaacs: are you going to release 0.8.1 tonight?
16:54:01  <isaacs>bnoordhuis: yes, as soon as it's done building
16:54:08  <isaacs>unless there are objections :)
16:54:15  <bnoordhuis>no, not quite
16:54:49  <bnoordhuis>bcantrill reported an issue that i'll have a fix for later tonight
16:54:55  <isaacs>it's pretty minor. just wanna get out this round of bugfixing that you and bert did in libuv, and some npm updates.
16:55:03  <isaacs>bnoordhuis: yeah, i'll tell him that'll wait for 0.8.2
16:55:06  <isaacs>bnoordhuis: link?
16:55:07  <bnoordhuis>okay, cool
16:55:23  <bnoordhuis>no, i'm not done yet - it's that i know what the root cause is. now to fix it )
16:55:41  <isaacs>i mean, do you have a link to the issue?
16:55:48  <bnoordhuis>oh, that link :)
16:55:50  <isaacs>or was this a secret carrier-pigeon eyes-only kinda thing?
16:55:54  <bnoordhuis>https://github.com/joyent/node/issues/3586
16:56:01  <isaacs>great :)
17:05:48  * pieternjoined
17:05:49  * bcantrillquit (Read error: Connection reset by peer)
17:05:59  * perezdquit (Ping timeout: 244 seconds)
17:07:37  * perezdjoined
17:08:16  <isaacs>ok, i'm gonna drop it then
17:09:04  <japj>I'm standing by for retweets ;)
17:12:47  <japj>btw, I'm investigating the fs.watch api at work (I know it there is some inconsistencies in it) and I was wondering about something
17:13:14  <isaacs>tagged!
17:13:27  * mikeal1joined
17:14:13  <japj>on windows I did a fs.watch('somedir/somefile', cb) and when the file changed, the cb received 'somefile' instead of 'somedir/somefile' . any ideas on if that could be fixed in a consistent way?
17:14:46  * mikealquit (Ping timeout: 244 seconds)
17:14:58  <japj>I'm hesitant to submit issues on it, since it is an 'unstable' api
17:16:54  * philipsquit (Excess Flood)
17:18:02  * philipsjoined
17:21:32  <CIA-108>node: isaacs v0.8 * rbc71874 / doc/blog/release/v0.8.1.md : Blog post about 0.8.1 (+6 more commits...) - http://git.io/js_PhA
17:25:30  <isaacs>japj: i am not sure if it can be.
17:25:38  <isaacs>japj: go ahead and post an issue, though. we're good at closing those.
17:25:53  <isaacs>japj: generally, when i use fs.watch, i try to already know the filename ahead of time.
17:25:54  <japj>I think it might be a bug in libuv
17:25:58  <isaacs>since it's not guaranteed
17:27:02  <japj>well, if you specify the exact filename to watch for and a 'callback' fires for that file, then you know the exact filename (it is the one you specified when registering the fs watcher
17:27:30  <japj>apparently the dirname gets stripped off, resulting only the filename being in the callback
17:27:50  <japj>(the stripping happens in libuv if I understand the code correctly)
17:34:17  * bcantrilljoined
17:35:59  <bnoordhuis>piscisaureus_: https://github.com/bnoordhuis/libuv/compare/joyent:v0.8...v0.8 <- review?
17:36:48  <piscisaureus_>bnoordhuis: I'm fine with moving uv__connect
17:36:54  <piscisaureus_>until we make udp a stream _p
17:38:33  <mjr___>So should we us 0.8.1, or is it still not quite ready for battle?
17:38:37  * mjr___changed nick to mjr_
17:41:07  <isaacs>piscisaureus_: https://github.com/joyent/node/issues/3578#issuecomment-6636224 tomasz is our new msft contact?
17:41:14  <piscisaureus_>bnoordhuis: a pending connect should make the handle active right?
17:41:22  <piscisaureus_>isaacs: sorta. I think he would be there for advice
17:41:26  <isaacs>i see
17:41:37  <isaacs>because i would love to start assigning him bugs ;)
17:41:38  <piscisaureus_>isaacs: but I think we're doing without a msft contractor atm
17:41:43  <bnoordhuis>piscisaureus_: should it? it does now
17:42:57  <bnoordhuis>biab, dinner
17:43:08  <piscisaureus_>bnoordhuis: I though that a handle would be active if it was reading, or if there was a pending req
17:43:20  <piscisaureus_>bnoordhuis: I will not be back later. Have to sleep early and catch a flight
17:47:07  <piscisaureus_>japj: are there any other platforms that give you the full filename?
17:48:27  <japj>piscisaureus_: if the test is not failing on other platforms it isn't, but atleast it is what I expected
17:49:48  <japj>piscisaureus_: it could also be just an (nodejs) api documentation issue, since fs.watch says "Watch for changes on filename, where filename is either a file or a directory." and "The listener callback gets two arguments.... filename is the name of the file which triggered the event."
17:50:32  <japj>piscisaureus_: what I was doing was in the callback function, open the filename passed, but since it doesn't contain the exact same path (but only filename) that became totally useless
17:52:46  * TooTallNatejoined
17:53:03  <japj>piscisaureus_: does that make sense or not?
17:53:27  <piscisaureus_>japj: a sec, I am trying this on linux
17:53:47  <japj>if the current fs events tests pass on linux, it passes only the filename
17:53:55  <japj>cause that is what the test checks :)
17:55:18  <piscisaureus_>japj: yes, that's what it does
17:55:24  <piscisaureus_>japj: linux does the same
17:55:56  <japj>but conceptually, if you pass a full path to a file and it changes then it kinda makes sense to pass the the original input path back to the callback doesn't it?
17:56:00  <piscisaureus_>japj: it's very difficult to get watch right, because the different platforms wildly vary in the sort of stuff they support and what the exact semantics are
17:56:26  <piscisaureus_>japj: well, the user could rename one of the parent directories and we would never know
17:56:45  <piscisaureus_>japj: (this will totally break on windows btw, but that is a real bug now)
17:57:09  <japj>ah I see, renaming parents paths can be very ugly then
17:57:14  <piscisaureus_>japj: the only thing the kernel tells is is the filename relatively to the parent directory (on windows)
17:57:51  <piscisaureus_>japj: so I suppose it's now sort of up to you to figure it out. I would like to make fs.watch better but I'd say changing this is not a priority
17:57:59  <japj>well, then it actually only is usefull to pass a filename to the callback if you watch a directory?
17:58:09  <piscisaureus_>japj: yes
17:58:14  <piscisaureus_>that's true :-_
17:58:31  <piscisaureus_>japj: well, if you watch a file and it gets renamed, it's useful to get the new filename :-)
17:58:41  <piscisaureus_>but I don't know if we do that
17:58:43  <japj>ah, true;)
17:58:52  <piscisaureus_>I don't think so actually :-)
17:58:53  <piscisaureus_>ok
17:59:01  <japj>not sure
17:59:15  <piscisaureus_>japj: well the problem is those stupid "short" filenames
17:59:54  <piscisaureus_>japj: sometimes windows will give us a short filename and they it's up to us to figure out which file it meant. That works when the file only changes, but when it also gets renamed, or deleted, there's not much you can do
18:00:22  <piscisaureus_>I think this is actually the biggest problem with the windows api atm
18:01:53  <japj>well, I'll figure something out.. I'm just glad that I can have fs events when changes are happening (I'm working on something that detects new 'builds' on a unc path so we know there are new binaries to test. currently that is done by scanning a lot of directories on a regular basis)
18:02:07  <piscisaureus_>ah, yeah
18:02:13  <piscisaureus_>we really oughta give you recursive watching
18:02:27  <japj>piscisaureus_: recursive is not a problem for me
18:02:37  <piscisaureus_>it is for many people
18:02:40  <piscisaureus_>it would be nice to do that
18:03:00  <japj>piscisaureus_: since there is configuration for me that tells me what directories new builds will appear in (in a subdir)
18:03:29  <piscisaureus_>but for that we would have to build and fsevents and fanotify backend and say "no" to those poort souls that are running old linux/old mac os/solaris/bsd kernel
18:03:32  <japj>so for me it is enough that a new directory os added
18:03:38  <piscisaureus_>ah, right
18:03:41  <piscisaureus_>cool
18:03:46  <piscisaureus_>good that it works for you then :-)
18:03:59  <japj>and ofc, it is also nice to watch the config files for changes ;)
18:04:07  <piscisaureus_>Yeah
18:04:18  <piscisaureus_>I suppose it works fine as long as you are not doing too crazy stuff
18:04:54  <piscisaureus_>japj: in 0.8 fs.watchFile also works in windows
18:05:18  <piscisaureus_>but still doing the good old crazy stat polling
18:05:39  <japj>ah, then I don't want it ;)
18:05:51  <japj>btw.. just noticed fs.watchFile "Watch for changes on filename. The callback listener will be called each time the file is accessed."
18:06:02  <japj>what does "is accessed" mean?
18:06:03  * brsonjoined
18:06:15  <japj>:)
18:07:43  <japj>btw, any idea on what talks are being given on nodeconf (I am not going, but still interested in the topics)
18:08:01  <japj>I couldnt find an actual programme
18:15:05  <piscisaureus_>japj: it's sort of secret, and I don't even know (even tho I am speaking)
18:15:21  <piscisaureus_>japj: so, sorry. You should bug mikeal about that :-)
18:17:49  <japj>piscisaureus_: I assume everything will be recorded again?
18:18:01  <piscisaureus_>japj: I am assuming too :-)
18:18:05  <japj>piscisaureus_: so the rest of us will be able to watch it (eventually)
18:18:24  <piscisaureus_>japj: honestly, I have no idea
18:18:34  <piscisaureus_>japj: who knows, there may be a pay wall :-p
18:18:57  <japj>that is one of the nice things about current conferences, they record and provide videos (after a while)
18:18:59  <piscisaureus_>japj: I think they will first come to theatres and then to rent-only DVDs
18:19:28  <japj>piscisaureus_: I don't mind paying for videos, it is still a good way to learn an keep up with stuff
18:19:31  <piscisaureus_>japj: so, with TPB being blocked and all, you're sort of out of luck
18:19:39  <piscisaureus_>japj: I was just kidding :-p
18:19:46  <japj>piscisaureus_: no live streaming (through a nodejs video service)
18:19:58  <piscisaureus_>japj: again, I don't know
18:20:10  <japj>piscisaureus_: well, I bought a couple of videos from oreilly and peepcode in the past
18:20:37  <japj>but so far the jsconf and nodeconf videos have been freely accessable
18:20:51  <japj>although released in a long time span
18:21:43  <piscisaureus_>japj: I think they will be available, and given the nature of the conference they will probably be free too. And it'll probably take a long time again :-)
18:21:45  <japj>and since everything is happening so fast in node, then some parts are not 'actual'
18:24:23  <japj>piscisaureus_: are you already in the US or are you flying this weekend?
18:26:50  <piscisaureus_>early tomorrow morning
18:26:55  <piscisaureus_>I'm going offline now
18:26:58  <piscisaureus_>see you guys later
18:27:01  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:29:51  <creationix>isaacs, so on `npm ls` is there a way to make it use parent modules?
18:30:11  <creationix>so I have A and B at the top level and B depends on A
18:30:32  <creationix>it will show A as extraneous and B.A as UNMET
18:30:42  <creationix>but the code runs fine since node_modules looks up the tree
18:31:33  * mikeal1quit (Quit: Leaving.)
18:32:34  * mikealjoined
18:32:36  * mikealquit (Client Quit)
18:33:15  * mikealjoined
18:45:32  <isaacs>creationix: no, there's an issue on the read-installed package for that
18:46:50  <creationix>isaacs, cool
18:50:15  <TooTallNate>ircretary: seamless npmlogging looks really good! http://cl.ly/320o2W39390p102x1L2c
18:50:15  <ircretary>TooTallNate: I'm not sure what to do with that command. Ask for help in PM.
18:50:23  <TooTallNate>isaacs: ^ rather
18:54:31  <isaacs>TooTallNate: nice :)
19:02:17  * isaacstopic: Liberty. Unity. Velocity.
19:16:10  * paddybyersjoined
19:19:04  <TooTallNate>isaacs: /me wants an npm flag to force node-gyp over node-waf
19:19:23  <TooTallNate>i.e. their package.json still specifies a "preinstall" to node-waf, but there's a binding.gyp file already
19:19:30  <TooTallNate>i guess they should just fix it though...
19:20:01  <japj>what package?
19:21:21  <indutny>bnoordhuis: you're super awesome
19:21:23  <indutny>Also, Ben Noordhuis is a beast in @nodejs core. Some great folks working on it.
19:29:36  <isaacs>TooTallNate: that's not a bad idea.
19:29:38  <isaacs>--no-waf
19:29:40  <isaacs>or something
19:30:21  <isaacs>TooTallNate: butit's tricky when the package.json explicitly states to use waf
19:30:31  <isaacs>TooTallNate: i'd recommend just a pull req in that case.
19:39:21  * mikealquit (Quit: Leaving.)
19:44:54  <isaacs>http://registry.npmjs.org/-/scripts?scripts=install,preinstall,postinstall&match=\bnode-waf\b
19:44:57  <isaacs>277 packages.
19:45:12  <isaacs>we can't reasonably deprecate node-waf until that list is much shorter
19:48:19  * paddybyersquit (Quit: paddybyers)
19:51:56  * mikealjoined
19:52:30  * hzquit (Disconnected by services)
19:52:33  * hzjoined
19:53:22  <japj>finally the query that I been waiting for
19:56:12  <japj>isaacs: is there a way to sort that list to most popular / recently updated?
19:56:18  * c4miloquit (Remote host closed the connection)
19:57:20  * c4milojoined
19:57:56  <japj>isaacs: when I tried to have a go at it last month, I found there a couple of old/abandond addons. it probably makes most sense to actively try and update modules that are recently maintained
20:01:30  <japj>isaacs: and at one moment in time I got insane enough to actually try and write a waf2gyp converter
20:03:49  <tjfontaine>glwat
20:13:41  <isaacs>japj: not that query, no
20:32:01  * dapquit (Quit: Leaving.)
20:32:29  * dapjoined
20:37:25  <TooTallNate>ughhh, node-waf sucks :p
20:39:09  * `3rdEdenjoined
20:40:29  <TooTallNate>i think with the lipo'd node binary, node-waf defaults to building 32-bit addons or somethin
20:40:50  <TooTallNate>when i switch back to a manually compiled version it builds 64-bit by default again
20:40:52  <TooTallNate>weird
20:42:31  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
20:48:16  * TooTallNatejoined
21:13:03  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
21:22:33  * mikealquit (Quit: Leaving.)
21:33:59  <japj>isaacs: https://gist.github.com/3020469#file_results.txt is a the current list of addons with node-waf in their scripts sorted by most recently updated one first
21:35:29  <japj>isaacs: included in the gist is the source of the thing I used to generate it with.
21:35:56  * pieternquit (Ping timeout: 245 seconds)
21:36:08  <japj>isaacs: first one on the list is node-canvas, and it supports "engines": { "node": ">= 0.4.0 && < 0.9.0" }
21:37:09  <japj>isaacs: wil a node 0.4 related npm "know" that it needs to run node-waf when a wscript is available?
21:39:19  <japj>isaacs: if people support node>=0.6 I think we can just have them remove the preinstall entry
21:40:18  <japj>isaacs: since npm (read-package-json) will detect the presence of a wscript and make it work
21:43:26  <TooTallNate>japj: yes, older version of npm "know" to use node-waf if there's a wscript file but no "preinstall" phase
21:43:48  <TooTallNate>japj: nice list btw :)
21:46:43  <japj>TooTallNate: so that means we could just use the "jistu repo bot" to fork all those repositories and remove the preinstall line from the package.json
21:47:15  <japj>TooTallNate: although some modules probably don't have a binding.gyp yet (but that's ok for now I guess)
21:47:20  <TooTallNate>japj: possibly, but that doesn't mean that there's a binding.gyp file present
21:47:22  <TooTallNate>right
21:47:23  <TooTallNate>:p
21:47:32  * rendarquit
21:47:34  <TooTallNate>idk, you'd have to consult isaac about it
21:47:54  <TooTallNate>cause even the current npm will add a "preinstall" for you specifying `node-gyp rebuild`
21:48:02  <japj>I know
21:54:07  * c4miloquit (Remote host closed the connection)
22:07:51  <creationix>Anyone know what would cause an EBADF error?
22:08:06  <creationix>I have a parent and child process talking to each-other over stdio
22:08:50  <creationix>The stack just starts with Pipe.onread
22:27:48  <isaacs>bnoordhuis: ARG! HandleScope, my old nemesis!
22:27:52  <isaacs>thanks
22:28:53  <isaacs>japj: since that line is added by npm when there's a wsript file, it's likely not actually in the package.json in their repo
22:32:18  <japj>isaacs: the first package I looked at (node-canvas) actually has a preinstall node-waf entry https://github.com/LearnBoost/node-canvas/blob/master/package.json#L9
22:33:11  <japj>isaacs: the second package on the list has an install entry https://github.com/mapnik/node-mapnik/blob/master/package.json#L49
22:36:45  * mralephjoined
22:36:50  <bnoordhuis>creationix: test case?
22:37:07  <mraleph>dap: hi
22:37:13  <dap>mraleph: hi :)
22:37:25  <mraleph>dap: so do you have full memory available for inspection?
22:37:48  * japjquit (Quit: off to see mr sandman)
22:38:15  <dap>yeah. in fact, our methodology is *very* simplistic: we just scan the heap and look for things that are valid objects. so we may well be picking up dead ones, and if there's some way to tell from the object itself, that would be great.
22:38:26  <dap>but at the very least, we know there are 36,000 actual such objects in memory :)
22:38:32  <dap>even if V8 doesn't think they're in use.
22:39:01  <mraleph>dap: if you have an object at address X then page containing this object starts at X & ((1 << 20) - 1)
22:39:45  <mraleph>dap: flags_ are the 4th word on the page
22:40:13  <dap>mraleph: interesting! where in the source can I get those details?
22:40:20  <mraleph>dap: spaces.h
22:40:34  <mraleph>dap: you need to check 5th bit (corresponds to IN_FROM_SPACE)
22:41:01  <mraleph>if it's set then this page belongs to new space but it is not in use at this moment and contains only garbage
22:41:26  <dap>This is great info. The tool has already proved useful, but being able to prune objects we know are just garbage would be very valuable.
22:42:14  <mraleph>that would allow you to prune new space. with old space situation is worse. there is not easy way to see if it's alive or not.
22:42:42  <dap>well, it's still a help.
22:43:16  <mraleph>for some spaces you can interate the page from the start by jumping from one object to another, with free areas marked in a special way.
22:43:58  <mraleph>but that's not for all and not always. there is a lot of logic there related to imprecise lazy sweeping
22:44:28  <mraleph>so I don't have a recipe for you… we just do a special GC when we need to iterate over the whole heap to collect objects.
22:45:54  <dap>That's okay. this is the kind of thing where any kind of insight can be extremely valuable. It's like shining a flashlight into a dark room. It doesn't have to be a bright spotlight :)
22:47:47  <mraleph>:-)
22:48:03  <mraleph>ok, please tweet results… I am going to sleep now :-)
22:48:07  * mralephquit (Quit: Leaving.)
22:56:41  <isaacs>dap, mraleph: Awesome
22:56:50  <isaacs>dap: showing only non-gc'd objects would be so wonderful there.
22:57:10  <isaacs>dap: also, you can do `node --expose-gc` and then call gc() periodically.
22:57:29  <isaacs>dap: not good for production usage, since it'd be slow, but you'd probably see way fewer Arguments objs
22:57:50  <dap>isaacs: interesting
23:00:20  * piscisaureus_joined
23:01:24  * dapquit (Quit: Leaving.)
23:01:57  * dapjoined
23:18:33  <tjfontaine>piscisaureus_: I did some more benches, not that it would be a common use case to hammer an upstream cache, but cares can churn through 20K q/s where as I maxed out at 1.8K q/s, the flame graph seems to indicate the biggest win for cares is that it gets to operate out of the main thread, here are the relevant graphs http://xm.atxconsulting.com/c-ares.svg http://xm.atxconsulting.com/node-dns.svg
23:19:23  <piscisaureus_>tjfontaine: cares doesn't operate out of the main thread...
23:19:47  <tjfontaine>oh, well then I have some serious work to do
23:20:37  <piscisaureus_>tjfontaine: that looks like a graph for cares. Do you also have one for node-dns?
23:20:51  <tjfontaine>it must have got cut off, http://xm.atxconsulting.com/node-dns.svg
23:22:00  <tjfontaine>it just felt like c-ares was still processing udp in the background
23:22:57  <piscisaureus_>hmm, node's udp seems to be rather efficient here, nice :-)
23:24:12  <piscisaureus_>tjfontaine: it looks like your code is rather heavy on ES getters/setters
23:24:28  <piscisaureus_>also you have massive stacls
23:24:30  <piscisaureus_>*stacks
23:24:46  <tjfontaine>ya, I can thin those out and remove the pretty get/set's
23:26:34  <bnoordhuis>piscisaureus_: shouldn't you be in bed?
23:26:40  <piscisaureus_>tjfontaine: I think you could also win a lot by not creating such a shitload of closures
23:26:42  <bnoordhuis>or are you already at schiphol?
23:26:43  <piscisaureus_>bnoordhuis: couldn't sleep
23:26:45  <bnoordhuis>hah
23:27:01  <piscisaureus_>don't disturb me tho, I'm polishing my talk
23:27:11  <piscisaureus_>otherwise everybody will make fun of libuv after nodeconf
23:27:34  * dapquit (Quit: Leaving.)
23:27:42  <tjfontaine>piscisaureus_: heh, this is the type of feedback I was looking for, thanks :)
23:28:04  * dapjoined
23:28:17  <piscisaureus_>tjfontaine: I think you can make much more efficient parsers by making it a little more like a state machine
23:28:26  <piscisaureus_>tjfontaine: for details, you should talk to felixge when he is around
23:28:41  <tjfontaine>ok
23:29:44  * AvianFluquit (Quit: Leaving)
23:33:21  <bnoordhuis>piscisaureus_: send me the slides when you're done
23:34:14  <piscisaureus_>bnoordhuis: take a look at philips' slides if you're bored: http://ifup.org/slides/libuv-osb/#1
23:34:28  <bnoordhuis>i envy that domain name
23:34:43  <bnoordhuis>awesome animation btw
23:45:12  <philips>heh, thanks guys :)
23:53:09  * hzquit