00:00:26  <mjr_>But curiously, it's always in the case where we are telling the client, "no actual data right now" tiny little JSON string response.
00:00:30  <piscisaureus_>bnoordhuis: what is config/piii vs config/k8 for?
00:01:06  <bnoordhuis>piscisaureus_: they're ia32 vs x64 configs
00:01:14  <bnoordhuis>pii and k8 are openssl nomenclature
00:01:22  * bradleymeckquit (Quit: bradleymeck)
00:01:22  <piscisaureus_>bnoordhuis: ah, right
00:01:28  <piscisaureus_>bnoordhuis: k8 is what?
00:01:34  <mjr_>isaacs: also about half of those write/alloc stacks don't have any of our code in them at all.
00:01:35  <bnoordhuis>piscisaureus_: x64
00:01:40  <piscisaureus_>right
00:01:45  <bnoordhuis>isaacs: i'll look at it tomorrow, have to get up early
00:01:57  <isaacs>bnoordhuis: cool, thanks.
00:02:07  <isaacs>bnoordhuis: btw, the positions in the stacks are incorrect, i think
00:02:29  <bnoordhuis>isaacs: okay, noted
00:02:36  <isaacs>but the function names are valid
00:02:46  <mjr_>I can supply the source code to where it intersects our code if that helps.
00:02:51  <bnoordhuis>trondn: v0.6 is the stable branch
00:02:56  <bnoordhuis>mjr_: sure, that would help
00:03:00  <bnoordhuis>okay, gotta go
00:03:04  <bnoordhuis>sleep tight, guys
00:03:04  <isaacs>g'nite ben
00:03:10  <mjr_>Is there a way to get V8 to compute line numbers on everything
00:03:11  <mjr_>?
00:03:43  <mjr_>Because I could just run all processes with that so jsstack would be more useful everywhere.
00:05:00  <trondn>bnoordhuis: hmm.. running make test there doesn't look good on my mac? is it supposed to pass all tests?
00:07:29  * bnoordhuisquit (Ping timeout: 246 seconds)
00:07:32  <dap>mjr_: Sorry, just catching up . This is probably too arcane to be very helpful, but if you ever throw an exception whose stack contains a given file and get the stacktrace for it, V8 will compute line numbers for that file and we'll have them forever.
00:08:09  <dap>mjr_: For debugging, it would be great to have node tell V8 to compute line numbers on all files when you "require" them. I don't know how that would impact start time, or if anyone would care (I wouldn't)
00:08:12  <isaacs>dap: if you just do `new Error()` in that file, will it have the same effect?
00:08:14  <mjr_>So in each file, just make an Error object?
00:08:19  <dap>isaacs: new Error().stack, yes
00:08:31  <mjr_>oh wow, OK
00:08:33  <TooTallNate>mjr_: you'll need to access .stack
00:08:52  <mjr_>Sounds good. I'll put that in all of our files.
00:08:56  <isaacs>mjr_: require.extensions[".js"] = function() { new Error().stack; orig.apply(this, arguments) }(require.extensions[".js"])
00:09:02  <isaacs>mjr_: you could just put that in one place
00:09:11  <mjr_>oh, exciting.
00:09:19  <isaacs>er, return orig.apply(this, arguments)
00:09:23  <isaacs>AOP is actually magic.
00:09:25  <isaacs>:)
00:10:43  <isaacs>oh, actually, that stack trace will dodge your code
00:11:40  <dap>yeah, that probably won't quite work because the stacktrace won't include the file you're about to include
00:12:05  <mjr_>I can just do new Error().stack at the top of every file.
00:13:00  <dap>mjr_: cool. I also write https://raw.github.com/davepacheco/tools/master/bin/filepos, though that's also a little tricky because node wraps with the file before handing it off to V8, so the position will be off by a few chars.
00:14:31  <mjr_>Interesting.
00:14:48  <mjr_>So on an somewhat related matter, how can I get a usable core file from node when it gets stuck in TLS
00:14:50  <mjr_>?
00:14:53  * xaqjoined
00:14:57  <dap>gcore
00:14:58  <mjr_>I tried ggore, but those core files aren't readable by gdb
00:15:02  <mjr_>er, gcore.
00:15:18  <mjr_>If I kill -SIGABRT, they seem to be readable.
00:15:20  <dap>oh. I don't know anything about GDB's support for SunOS core files
00:15:39  <mjr_>So the trick is that neither bnoordhuis nor I speak mdb
00:15:46  <mjr_>Even though it seems like mdb is awesome.
00:16:02  <dap>I'm honestly not sure what you can get from GDB anyway?
00:16:07  <mjr_>And mdb has your jsstack action in it.
00:16:35  <dap>right
00:16:38  <mjr_>I'm not actually sure either, but bnoordhuis says that this is what he needs to fix this problem.
00:16:51  <mjr_>I think he thinks that the badness is somewhere in libuv.
00:16:55  * orlandovftwquit (Ping timeout: 245 seconds)
00:17:32  <dap>But he doesn't know how to get a GDB-usable core file either (without killing the process)?
00:17:36  <isaacs>here's the thing you only have to do once:
00:17:37  <isaacs>require("module").wrapper[0] += 'new Error().stack;'
00:17:37  <dap>(I assume you want to avoid killing the process)
00:18:13  <mjr_>dap, the process is stuck and needs to be killed
00:18:21  <mjr_>So killing is actually a useful side effect. :)
00:18:29  <dap>oh, so is "kill -ABORT" a fine solution then?
00:19:03  <mjr_>I guess so. I'm not sure if that makes a core file that is then less usable somehow in mdb
00:19:42  <mjr_>But I'm happy to just abort them if that's the best way to get a core file that everybody can use.
00:19:50  <dap>Both core files are fine for MDB.
00:20:17  <mjr_>Excellent.
00:20:36  <mjr_>Speaking of which, I got one right now
00:22:38  <mjr_>So I guess I'll relay this to bnoordhuis tomorrow when our schedules overlap.
00:24:22  <rphillips>does libuv have a way to get the current time in milliseconds in a cross platform way?
00:27:16  <TooTallNate>rphillips: there's uv_hrtime() but that's nanoseconds, not milli
00:27:29  <rphillips>that works. thanks
00:31:07  <piscisaureus_>bnoordhuis: ?
00:31:45  * mralephquit (Quit: Leaving.)
00:32:25  <TooTallNate>piscisaureus_: he went to bed already
00:32:32  <piscisaureus_>the slacker
00:32:39  <TooTallNate>hahaha
00:32:48  * dapquit (Quit: Leaving.)
00:34:21  <tjfontaine>damn his circadian rhythm
00:35:20  <piscisaureus_>I wonder why we are not building opennsl without socket support
00:36:12  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
00:39:10  <piscisaureus_>We could just add -DOPENSSL_NO_SOCK=1
00:39:26  <piscisaureus_>Where is pquerna when you need him :-/
00:39:31  <tjfontaine>sounds reasonable to me
00:39:52  * TooTallNatejoined
00:40:13  <piscisaureus_>ircretary: tell bnoordhuis Why are we not compiling openssl with -DOPENSSL_NO_SOCK ?
00:40:13  <ircretary>piscisaureus_: I'll be sure to tell bnoordhuis
00:40:48  <tjfontaine>man trillian hates irc :)
00:43:05  <piscisaureus_>tjfontaine: huh why?
00:43:38  * pieternquit (Quit: pietern)
00:44:36  <tjfontaine>piscisaureus_: because your copy/paste always keeps your color, and then trillian sends it as such
00:45:01  <piscisaureus_>tjfontaine:, oh, that's not unreasonable is it?
00:45:27  <tjfontaine>piscisaureus_: only because my background is black, and your foreground text is black :)
00:50:03  <piscisaureus_>ircretary: tell bnoordhuis Also, https://gist.github.com/2356006
00:50:03  <ircretary>piscisaureus_: I'll be sure to tell bnoordhuis
01:08:34  * orlandovftwjoined
01:09:16  * pijewskiquit (Quit: Leaving.)
01:11:03  * trondnquit (Quit: Leaving.)
01:12:47  * abraxasjoined
01:28:20  * orlandovftwquit (Ping timeout: 260 seconds)
01:29:59  * xaqquit (Remote host closed the connection)
01:32:18  <CIA-99>node: isaacs v0.6 * rd0365fd / Makefile : Makefile: minor nit - http://git.io/Fev3Ig
01:32:19  <CIA-99>node: isaacs v0.6 * r8b82abb / (4 files in 3 dirs): Fix #3089 Build changelog.html for website - http://git.io/UhZkNA
01:33:45  * trondnjoined
01:35:46  <CIA-99>node: isaacs master * r3ba9519 / Makefile : Makefile: minor nit - http://git.io/pg6RZw
01:35:47  <CIA-99>node: isaacs master * re066074 / (4 files in 3 dirs): Fix #3089 Build changelog.html for website - http://git.io/rqlEhw
01:35:56  * xaqjoined
01:37:57  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:39:33  <perezd>TooTallNate: yt?
01:39:51  * travis-cijoined
01:39:51  <travis-ci>[travis-ci] joyent/node#711 (v0.6 - 8b82abb : isaacs): The build is still failing.
01:39:51  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/e8067cb...8b82abb
01:39:51  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1062567
01:39:51  * travis-cipart
01:42:13  <TooTallNate>perezd: ya for a sec
01:43:42  <perezd>is it standard practice to create/destroy uv_async whenever calling into a v8 extension?
01:44:00  <perezd>ie: per function, is it a lot of overhead?
01:44:51  <TooTallNate>perezd: i'm not entirely sure. what are you trying to do exactly?
01:45:55  <perezd>basically, we're calling uv_async_init and doing some work, that increments a refcount
01:45:56  <perezd>a
01:46:04  <perezd>and because that refcount != 0, the node process stays open
01:46:27  <perezd>so we can call uv_close and then the process exits
01:46:45  <perezd>so, generally, what I am asking is, should it be considered "cheap
01:46:47  <perezd>"
01:47:02  <perezd>to call uv_async_init/uv_close within every function I expose to javascript via v8 extensions
01:47:04  <perezd>to do async work?
01:47:29  <TooTallNate>well usually that's not needed
01:47:40  <TooTallNate>what kind of async work is it? something on another thread?
01:47:48  <perezd>yes it is
01:48:33  <perezd>we have our own threadpool, and we'd like a one way channel to wake up the main loops from our threads
01:49:25  * travis-cijoined
01:49:25  <travis-ci>[travis-ci] joyent/node#712 (master - e066074 : isaacs): The build is still failing.
01:49:25  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/7b71fd0...e066074
01:49:25  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1062570
01:49:25  * travis-cipart
01:50:37  <perezd>whats the proper way to use the API for libuv in that case?
01:52:43  <TooTallNate>perezd: uv_async i think is correct in this case. though i think usually you'd just need 1
01:53:02  <TooTallNate>perezd: honestly you'd be better off asking one of the libuv gurus when they're back online :p
01:53:13  <perezd>so does it make sense to open/close it many times (ie: once per C call?)
01:54:23  <TooTallNate>perezd: not to me, but again, i'm not a guru :p
01:55:22  <TooTallNate>perezd: but one per "action" is probably ok
01:55:31  <TooTallNate>perezd: node-ffi creates one per async function call
01:56:02  <perezd>yes we noticed
01:56:03  <perezd>:)
01:56:09  <perezd>thats why we were wondering if it was costly
01:56:33  <perezd>who would you consider a libuv guru?
01:57:38  <TooTallNate>perezd: piscisaureus and bnoordhuis
01:57:48  <ryah>perezd: uv_async_t sounds right
01:57:56  <TooTallNate>perezd: i'm curious as well if there's optimizations that node-ffi could do
01:58:02  <perezd>ryah: the bigger question is the cost of
01:58:04  <perezd>it
01:58:07  <TooTallNate>perezd: frankly that part of the codebase hasn't been touched in ages
01:58:34  <ryah>perezd: on unix uv_async is the self-pipe trick
01:58:51  <ryah>http://cr.yp.to/docs/selfpipe.html
01:58:54  <perezd>ryah: ie: if I have a C function like create_foo that does some async work and should fire a cb in the main thread, is it reasonably "performant" to close it, and then reopen it later if I need to do another async thing
01:59:17  <perezd>reopen a new one later that is
01:59:29  <ryah>close what/
01:59:40  <ryah>the uv_async ?
01:59:41  <perezd>uv_close
01:59:43  <perezd>yeah
01:59:52  <ryah>i think you should just leave it open
01:59:57  <perezd>that causes the process to hang
01:59:59  <perezd>open
01:59:59  <ryah>use a single one to wake up the main thread
02:00:02  <perezd>even though its not doing anything
02:00:07  <perezd>because it incrs the refcount
02:00:24  <perezd>should I manually decr refcount?
02:00:41  <TooTallNate>perezd: node-ffi deals with the refcount manually
02:00:50  <TooTallNate>uv_ref() and uv_unref()
02:01:03  <ryah>perezd: i'm not sure the overhead - i believe there is only one pipe
02:01:08  <ryah>so it might not be bad to have multiple
02:01:16  <perezd>okay, will try it out and report back
02:01:17  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
02:02:26  * brsonquit (Quit: leaving)
02:05:30  * perezdquit (Quit: perezd)
02:19:16  * isaacsquit (Remote host closed the connection)
02:27:24  * bradleymeckjoined
02:30:21  * orlandovftwjoined
02:30:28  * perezdjoined
02:40:05  * trondnquit (Ping timeout: 260 seconds)
02:44:32  * c4milojoined
02:58:06  * trondnjoined
02:59:35  * bradleymeckquit (Quit: bradleymeck)
02:59:55  * mikealquit (Quit: Leaving.)
03:06:41  * xaqquit (Remote host closed the connection)
03:12:41  * mikealjoined
03:15:05  * dylukesjoined
03:21:46  * mikealquit (Quit: Leaving.)
03:23:06  * mikealjoined
03:28:31  * bulatshakirzyanojoined
03:43:37  * orlandovftwquit (Ping timeout: 246 seconds)
03:50:48  * mikealquit (Quit: Leaving.)
04:00:09  * mikealjoined
04:03:21  * orlandovftwjoined
04:04:46  * c4miloquit (Quit: c4milo)
04:16:45  * orlandovftwquit (Ping timeout: 252 seconds)
04:32:11  * mikealquit (Quit: Leaving.)
04:32:15  * orlandovftwjoined
04:34:31  * mikealjoined
04:52:48  * felixgejoined
04:52:48  * felixgequit (Changing host)
04:52:48  * felixgejoined
04:52:58  <felixge>mikeal: ping
04:54:17  <mikeal>pong
04:58:34  * xaqjoined
05:21:00  * c4milojoined
05:54:21  * dylukesquit (Quit: Pipes are broken. Sending packets via Fedex.)
06:15:02  * isaacsjoined
06:35:22  * stephankquit (Quit: *Poof!*)
06:41:26  * mikealquit (Quit: Leaving.)
06:55:15  * mikealjoined
07:01:13  * Marakjoined
07:07:29  * rendarjoined
07:07:51  * paddybyersjoined
07:15:59  * c4miloquit (Quit: c4milo)
07:17:19  * benviequit
07:17:44  * txdv_joined
07:22:17  * txdvquit (Ping timeout: 276 seconds)
07:26:57  * benviejoined
08:12:14  * orlandovftwquit (Ping timeout: 245 seconds)
08:20:39  <felixge>mikeal: still there? sorry, didn't see your reply earlier
08:34:07  <isaacs>anyone else seeing like almost every test failing in master?
08:34:22  <isaacs>on osx
08:46:24  * bulatshakirzyanoquit (Quit: Computer has gone to sleep.)
09:17:28  * felixge_joined
09:17:28  * felixge_quit (Changing host)
09:17:28  * felixge_joined
09:18:32  * felixgequit (Read error: Connection reset by peer)
09:18:38  * felixge__joined
09:18:38  * felixge__quit (Changing host)
09:18:38  * felixge__joined
09:19:10  * felixge_quit (Read error: Connection reset by peer)
09:29:25  * isaacsquit (Remote host closed the connection)
09:45:09  * xaqquit (Remote host closed the connection)
09:46:49  * xaqjoined
10:34:10  * xaqquit (Read error: Connection reset by peer)
10:35:27  * xaqjoined
10:58:00  <saghul>igorzi i'm getting these: |+ 117|- 16]
11:05:39  * bnoordhuisjoined
11:38:48  * abraxasquit
11:43:03  * dshaw_quit (Quit: Leaving.)
11:54:38  * piscisaureus_joined
12:27:00  <piscisaureus_>bnoordhuis: yt?
12:28:49  * c4milojoined
12:29:00  <bnoordhuis>piscisaureus_: yes
12:29:06  <bnoordhuis>have to go soon though
12:29:16  <piscisaureus_>bnoordhuis: you seen my openssl comments
12:29:17  <piscisaureus_>?
12:29:21  <bnoordhuis>piscisaureus_: yep
12:29:27  * piscisaureus_changed nick to piscisaureus
12:29:31  <bnoordhuis>i'm working on making it compile with OPENSSL_NO_SOCK
12:29:43  <bnoordhuis>apparently that doesn't disable bio_dgram on windows :)
12:31:48  <bnoordhuis>presumably OPENSSL_NO_DGRAM will fix that
12:32:46  * felixge__quit (Quit: felixge__)
12:33:12  * felixgejoined
12:33:12  * felixgequit (Changing host)
12:33:12  * felixgejoined
12:40:19  <piscisaureus>bnoordhuis: also, we might be able to turn off tty support
12:40:26  <piscisaureus>bnoordhuis: afaict it does not work on windows
12:40:34  <piscisaureus>bnoordhuis: so no reason to define TERMIOS or something
12:40:37  <bnoordhuis>piscisaureus: i tried that but it's not possible to compile it out
12:40:53  <bnoordhuis>which annoys me no end
12:41:00  <piscisaureus>bnoordhuis: huh, it compiles fine for me even though none of the tty interfaces is supported.
12:41:48  <bnoordhuis>piscisaureus: yes. but if you remove ui_openssl.c from the list, it'll fail to link
12:43:13  <bnoordhuis>okay, i'm off to pick up mees from the kinderdagverblijf
12:43:14  <piscisaureus>bnoordhuis: hmm ok so on windows OPENSSL_SYS_MSDOS is also defined...
12:43:58  * pfox___joined
12:45:08  * bradleymeckjoined
13:00:52  * bradleymeckquit (Quit: bradleymeck)
13:01:22  <saghul>bnoordhuis I'll go to fix some stuff to a datacenter on friday, no idea of the return time :-S
13:06:31  <piscisaureus>bnoordhuis: btw - your openssl branch fails many tests
13:06:40  <piscisaureus>most of them seem to be unrelated to openssl btw
13:06:45  <piscisaureus>but you might want to rebase it
13:14:21  <bnoordhuis>piscisaureus: it's the libuv upgrade from last night
13:14:32  <bnoordhuis>saghul: oh, too bad
13:14:37  <piscisaureus>bnoordhuis: oh? that's broken then.
13:14:39  <piscisaureus>hmm
13:15:10  <bnoordhuis>piscisaureus: i think it's mostly refcount errors
13:15:31  <bnoordhuis>at least, the couple of tests i checked were refcount < 0 errors
13:15:32  <piscisaureus>bnoordhuis: did you hack up the windows refcounting?
13:15:35  <bnoordhuis>no
13:15:49  <piscisaureus>bnoordhuis: so why do I see so many crashes on windows then? :-/
13:16:22  <piscisaureus>will investigate
13:16:29  <bnoordhuis>piscisaureus: `git rebase -i` away the libuv commit, then run the tests again
13:16:38  <piscisaureus>k
13:16:39  <bnoordhuis>(rebuild node first, of course)
13:17:18  <piscisaureus>bnoordhuis: thanks for explaining it to me :-).
13:17:27  <bnoordhuis>piscisaureus: my pleasure :)
13:17:39  <piscisaureus>bnoordhuis: now can you explain to me these weird codez in the .c files?
13:17:56  <bnoordhuis>piscisaureus: in openssl or libuv?
13:18:01  <piscisaureus>bnoordhuis:
13:18:13  <piscisaureus>for (i = 0; i < 4; i++)
13:18:21  <piscisaureus>bnoordhuis: what is that supposed to do?
13:18:28  <bnoordhuis>haha, yeah right
13:20:56  <saghul>bnoordhuis next time! :-)
13:23:53  <piscisaureus>bnoordhuis: the ui stuff seems impossible to hack out
13:24:03  <piscisaureus>bnoordhuis: or ... not impossible, but it would be invasive
13:24:03  <bnoordhuis>piscisaureus: yes, it needs a patch. i may write one
13:24:08  <piscisaureus>bnoordhuis: so, do it anyway
13:24:22  <piscisaureus>bnoordhuis: I can do it (actually I have mostly done it)
13:24:33  <bnoordhuis>piscisaureus: sure. make sure to forward it upstream :)
13:24:46  <piscisaureus>bnoordhuis: hide it behind an #ifdef I suppose?
13:24:57  <bnoordhuis>i don't want to float too many patches on top of openssl though
13:25:14  <bnoordhuis>piscisaureus: the convention in openssl is #ifndef OPENSSL_NO_XXX
13:25:22  <piscisaureus>OPENSSL_NO_UI
13:25:24  <piscisaureus>\:-)
13:25:24  <bnoordhuis>yes
13:27:28  <piscisaureus>openssl is such a mess :-(
13:27:55  <piscisaureus>the ui stuff is splattered all over the place
13:28:22  <piscisaureus>bnoordhuis: how receptive are the openssl guys to patches?
13:28:35  <bnoordhuis>piscisaureus: i don't know. i never sent in patches
13:28:46  <bnoordhuis>but seeing what a mess openssl is, i'd say they're pretty receptive :)
13:30:12  <piscisaureus>bnoordhuis: so why did you upgrade to 1.0.0f and not 1.0.0h or 1.1.0 ??
13:30:20  <piscisaureus>er, 1.0.1
13:30:39  <bnoordhuis>piscisaureus: i stole it from chromium
13:30:46  <bnoordhuis>btw, https://github.com/bnoordhuis/node/commit/01bf2d4 <- compiles on windows now
13:30:55  <bnoordhuis>without patching any openssl files, that is
13:31:43  <piscisaureus>bnoordhuis: yeah, winsock.h won't be #include'd if you compile without socket support
13:31:49  <piscisaureus>so all the fuckups are disabled
13:31:53  <bnoordhuis>yay!
13:32:23  <piscisaureus>why are camellia and mdc2 off?
13:32:37  <trondn>hmm.. which platforms are tested before a release?? I've tried the v0.6 on debian and macosx and both fails running make test?
13:33:00  <bnoordhuis>piscisaureus: because they're patented :/
13:33:26  <bnoordhuis>trondn: there are a couple of tests that always fail on unices
13:33:33  <piscisaureus>bnoordhuis: rc5, idea are not?
13:33:53  <bnoordhuis>those too
13:34:11  <trondn>bnoordhuis: oh.. why doesn't it just skip them tests if they're not applicable??? I'm trying to figure out if I can have confidence in my build or not ;)
13:34:32  <trondn>the fact that I've never been able to run make test makes me a bit scared if I can build stuff on top of it..
13:34:33  <bnoordhuis>trondn: because they're applicable but impossible to fix :)
13:35:10  <bnoordhuis>for example, one test fails because there is no good cross-platform approach to file locking on unices
13:35:12  <trondn>where can I find out what I should expect to work or not?
13:35:18  <bnoordhuis>here :)
13:36:43  <trondn>ok so which tests should I expect to fail on the following platforms: macosx, linux and solaris? that's the 3 platforms I'm currently redesigning a program to use libuv for..
13:37:42  <bnoordhuis>trondn: which tests are failing for you?
13:42:10  <trondn>debian linux: http://pastebin.com/HUa5fmYj
13:42:50  <trondn>macosx http://pastebin.com/2Q8ktTHj
13:44:59  <piscisaureus>trondn: pipe_bind_addrinuse is probably not fixable on unix
13:45:22  <piscisaureus>trondn: the other tests catch very obscure edge cases that you are very unlikely to encounter :-)
13:45:45  <piscisaureus>trondn: but they should be fixed, by bnoordhuis :-)
13:46:24  <piscisaureus>I am unsure about process_ref btw
13:46:29  <trondn>it would be really nice if the test text could print out a note about such things… given that it's more than a page with "failing" tests it makes me curious if I can use it or not...
13:46:48  * `3rdEdenjoined
13:58:37  <bnoordhuis>trondn: is that master or v0.6?
13:58:47  <bnoordhuis>the ref tests are expected to fail in master right now
13:59:18  <trondn>bnoordhuis: v06
13:59:46  <trondn>I'm going to vive it a shot in a prototype and see if it works for me :)
13:59:53  * pfox___quit (Remote host closed the connection)
13:59:58  <bnoordhuis>hmm, seems someone backported those ref tests to v0.6
14:00:25  <bnoordhuis>trondn: ignore them, they shouldn't really be there
14:01:53  <bnoordhuis>piscisaureus: you still working on that openssl patch? if not, i'm going to merge the upgrade into master
14:02:21  <piscisaureus>bnoordhuis: I am working on it
14:02:30  <piscisaureus>bnoordhuis: the v0.6 ref tests that fail are genuine failures
14:02:40  <piscisaureus>bnoordhuis: I discovered them and fixed them in uv-win
14:02:49  <piscisaureus>bnoordhuis: those are not backported tests
14:02:53  <bnoordhuis>oh. no one ever tells me anything :(
14:03:04  <piscisaureus>bnoordhuis: I am pretty sure I did :-)
14:03:05  * mikealquit (Quit: Leaving.)
14:03:23  <bnoordhuis>but was i sober?
14:03:37  <piscisaureus>bnoordhuis: are you ever?
14:04:27  <bnoordhuis>certainly
14:04:36  <bnoordhuis>31 august 2006
14:04:48  <piscisaureus>ah that was a remarkable day
14:04:51  <bnoordhuis>the day i ran out
14:04:54  <bnoordhuis>never forget!
14:05:10  <bnoordhuis>that reminds me
14:05:23  <bnoordhuis>mmalecki[zzz]: you still coming to appsterdam?
14:05:55  <piscisaureus>trondn: you probably want to be coding against master
14:05:57  <piscisaureus>btw
14:06:27  <piscisaureus>trondn: there are some api changes coming but nothing that will make your life (more) miserable
14:06:45  <trondn>piscisaureus: ok :)
14:07:59  * pfox___joined
14:09:06  * `3rdEdenquit (Quit: Leaving...)
14:09:16  * mikealjoined
14:20:32  * mmalecki[zzz]changed nick to mmalecki
14:20:33  * bradleymeckjoined
14:20:39  <mmalecki>bnoordhuis: amsterdam, yeah
14:21:00  <bnoordhuis>mmalecki: good. start practicing already
14:21:01  <mmalecki>bnoordhuis: even tho I might get kicked out of my place for doing this. whatever :)
14:21:09  <mmalecki>practicing what?
14:21:13  <bnoordhuis>drinking beer
14:21:16  <bnoordhuis>you'll need it
14:21:42  <mmalecki>hahaha, silly Ben, wants to drink more beer than me
14:22:01  <bnoordhuis>mmalecki: you know the stats right?
14:22:12  <mmalecki>bnoordhuis: I don't think I do
14:22:20  <bnoordhuis>only the czechs drink more beer than we do
14:22:31  * bradleymeckquit (Client Quit)
14:22:32  <mmalecki>oh, really? will see!
14:22:33  <bnoordhuis>and let me remind you that i lived in the czech republic for a while
14:23:25  <mmalecki>oh, I believe we should set up some date
14:23:53  <mmalecki>[0] should be arriving now
14:24:01  <bnoordhuis>date? sorry maciej, i don't swing that way
14:24:50  <mmalecki>lol
14:25:16  <trondn>bnoordhuis: where are you located?
14:25:24  <bnoordhuis>trondn: the netherlands
14:25:31  <trondn>ah. ok..
14:25:43  <trondn>we're not that far behind on drinking up in norway ;)
14:25:53  <piscisaureus>bnoordhuis: Ok I am going to use another approach. The UI is too mixed up with other code.
14:25:57  <trondn>but mostly moonshine ;)
14:25:59  <bnoordhuis>it's awfully expensive for you guys though
14:26:04  <bnoordhuis>hah, exactly
14:26:09  <piscisaureus>bnoordhuis: so I am just going to add a dummy ui instead
14:26:28  <trondn>bnoordhuis: _everything_ is fucking expensive for us...
14:26:33  <bnoordhuis>piscisaureus: okay. but i would like to merge the upgrade today :)
14:26:57  <bnoordhuis>trondn: but you get a lot back for it, like... eh...
14:27:11  <trondn>exactly ;)
14:27:31  <trondn>well, we can make fun of the swedes I guess..
14:27:38  <trondn>thats about it
14:27:48  <bnoordhuis>and the finnish
14:27:56  <bnoordhuis>then again, everyone does
14:28:45  <trondn>Why is it so $%^&* boring to make presentations?
14:29:41  <mmalecki>bnoordhuis: btw, when I'm back, I might have to live at a hotel
14:31:07  <bnoordhuis>mmalecki: how so?
14:32:05  <mmalecki>bnoordhuis: my parents want to kick me out because I don't care about school anymore :)
14:32:05  * mikealquit (Quit: Leaving.)
14:32:15  <mmalecki>I'm not even mad
14:33:14  <bnoordhuis>i thought you already moved out?
14:33:54  <mmalecki>bnoordhuis: no, because it didn't pay off. see, I'm leaving to US soon, so I thought these 3 months wouldn't be that bad. also, some crazy law stuff
14:34:57  <bnoordhuis>you're moving to the USA? how/why?
14:36:19  <mmalecki>bnoordhuis: magic! also, see your PM :)
14:46:12  <bnoordhuis>smartos is full of fail...
14:46:27  * bnoordhuisbears his cross stoically
14:46:52  <mmalecki>I kind of like it, actually
14:47:06  <mmalecki>except zones stuff and chroots
14:47:17  <benvie>f school
14:56:33  <CIA-99>libuv: Ben Noordhuis master * r42d3533 / (src/unix/udp.c test/test-udp-options.c):
14:56:33  <CIA-99>libuv: unix: fix udp_options test on OS X and Solaris
14:56:33  <CIA-99>libuv: setsockopt(IP_TTL) will happily let you set a TTL > 255 on OS X, cap it.
14:56:33  <CIA-99>libuv: -1 or 0 is a valid TTL on Linux but not portable, deny it. - http://git.io/jW1QZA
14:58:43  * travis-cijoined
14:58:44  <travis-ci>[travis-ci] joyent/libuv#184 (master - 42d3533 : Ben Noordhuis): The build is still failing.
14:58:44  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/3c41597...42d3533
14:58:44  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1066871
14:58:44  * travis-cipart
15:19:31  * perezdquit (Quit: perezd)
15:22:51  * josephgquit (Quit: josephg)
15:24:52  <bnoordhuis>piscisaureus: i want to remove fs_event_close_in_callback
15:25:30  <bnoordhuis>that test creates a watcher, generates a couple of file events, then enters the loop
15:26:00  <bnoordhuis>but kqueue doesn't report those events
15:27:55  <piscisaureus>bnoordhuis: why not?
15:28:06  <piscisaureus>bnoordhuis: I want to keep the test, but you can disable it on mac if you want
15:30:33  * dapjoined
15:31:05  * trondnquit (Quit: Leaving.)
15:32:26  * felixgequit (Quit: felixge)
15:32:32  <bnoordhuis>piscisaureus: why not... you ask difficult questions
15:32:43  <bnoordhuis>the short answer is "because it doesn't"
15:35:26  * perezdjoined
15:35:29  * felixgejoined
15:37:49  <piscisaureus>bnoordhuis: seems like the test catches two bugs, then :-)
15:38:16  <piscisaureus>bnoordhuis: usleep(5e5) before uv_run doesn't fix it?
15:40:28  * elijah-mbpjoined
15:40:57  * bradleymeckjoined
15:42:34  * mikealjoined
15:46:53  * mikealquit (Ping timeout: 246 seconds)
15:59:55  * isaacsjoined
16:05:01  * bulatshakirzyanojoined
16:09:44  * orlandovftwjoined
16:18:14  * pijewskijoined
16:20:11  <piscisaureus>bnoordhuis: does openssl ever report any error strings or can we also set OPENSSL_NO_ERR ?
16:24:15  <piscisaureus>bnoordhuis: https://gist.github.com/2360332
16:31:18  * trondnjoined
16:31:59  * bulatshakirzyanoquit (Quit: Computer has gone to sleep.)
16:43:07  <isaacs>piscisaureus, bnoordhuis: any idea on this? https://github.com/joyent/node/commit/0db4dc0024eaa538bf4913d6bf256a18126de2ba#commitcomment-1196660
16:43:50  <isaacs>i can bisect through the libuv commits if necessary, it's just a bit tedious. if you have a clue that would help, please share.
16:45:04  <piscisaureus>isaacs: I have no clue, but I am also seeing random crashes on windows after the last libuv update
16:46:56  <isaacs>seems like it was good on ab8c3b8
16:47:02  <isaacs>(the last libuv update before this one)
16:47:04  <isaacs>i'll bisect
17:00:17  <isaacs>is there a way to just clean uv and build a new node on top of it, without having to do distclean?
17:00:23  <isaacs>rebuilding v8 all the time is awful
17:00:53  <tjfontaine>that's a gyp question, but you could probably help yourself some using ccache
17:00:56  * mikealjoined
17:03:38  * mikealquit (Client Quit)
17:04:30  * dapquit (Quit: Leaving.)
17:05:17  * dapjoined
17:05:35  * dapquit (Client Quit)
17:06:06  * dapjoined
17:07:21  * xaqquit (Remote host closed the connection)
17:09:09  * stephankjoined
17:09:22  <isaacs>ed395e0619ab50d86c960e839525a0a5e8259b66 is the first bad commit
17:09:25  <isaacs>bnoordhuis, piscisaureus ^
17:09:51  * mikealjoined
17:11:53  <isaacs>at least, on os x. if you're seeing random crashes on win32, then that's a bit odd, since this only appears to touch unix
17:13:52  * TooTallNatejoined
17:15:44  <piscisaureus>isaacs: I think git be
17:15:46  <piscisaureus>er
17:15:56  <piscisaureus>git bisect has an option to check out only a particular folder
17:16:15  <piscisaureus>and there should be no need to do a distclean, just git clean -fdX deps/uv
17:18:32  <isaacs>piscisaureus: when i just remove out/**/*uv* it doesn't rebuild those things
17:18:41  <isaacs>piscisaureus: it just tries to rebuild node and fails
17:19:01  <isaacs>piscisaureus: and i'm testing by replacing the uv in node-master
17:25:57  <piscisaureus>ircretary: tell bnoordhuis https://gist.github.com/2360332
17:25:57  <ircretary>piscisaureus: I'll be sure to tell bnoordhuis
17:26:11  <piscisaureus>isaacs: I will bisect the windows issues myself
17:32:35  * orlandovftwquit (Ping timeout: 246 seconds)
17:33:12  * bradleymeckquit (Quit: bradleymeck)
17:35:01  * xaqjoined
17:48:25  * mikealquit (Quit: Leaving.)
17:53:10  * toothrquit (Ping timeout: 240 seconds)
17:54:02  * mralephjoined
17:54:23  * mikealjoined
18:02:02  <mraleph>piscisaureus: zomg y u spread links to highly questionable patches on twitter :-(
18:07:22  * orlandovftwjoined
18:08:02  <piscisaureus>mraleph: it looked reasonable to me. what's wrong with it?
18:08:55  <mraleph>piscisaureus: V8_MAX_SEMISPACE_SIZE=536870912
18:08:58  <mraleph>this is the wrongest part.
18:09:08  <piscisaureus>mraleph: so what should that be?
18:09:12  <mraleph>nothing
18:09:34  <mraleph>it should be left as it is
18:09:44  <mraleph>giving 500mb to semispace is a very strange choince
18:09:47  <piscisaureus>mraleph: well, tweet that.
18:09:53  <piscisaureus>mraleph: I will retweet it
18:09:54  <piscisaureus>:-)
18:10:01  <piscisaureus>damage control mode
18:10:04  <mraleph>we are on it in the comments
18:10:22  <piscisaureus>oh yeah if the article gets updated then that would be even better
18:12:32  * mikealquit (Quit: Leaving.)
18:14:52  * mikealjoined
18:18:05  <TooTallNate>does anybody have any objections to either of these tweaks?
18:18:06  <TooTallNate>https://github.com/TooTallNate/node/compare/configure-tweak
18:19:07  * mikealquit (Client Quit)
18:20:10  * mikealjoined
18:20:20  <TooTallNate>isaacs: piscisaureus: bnoordhuis: ^
18:21:19  <tjfontaine>the first is to support 2.5?
18:21:27  <tjfontaine>ah yes I see the message
18:21:27  <tjfontaine>ok
18:21:39  <tjfontaine>the first one has an awesome sha1
18:22:57  <isaacs>TooTallNate: lgtm
18:23:07  <isaacs>supporting python 2.5 is not a goal, though
18:23:10  <isaacs>if it's easy, sure.
18:23:42  <TooTallNate>isaacs: ok understood, it was easy in this case. i think gyp has some problems of it own though :D
18:23:47  <isaacs>yeah
18:23:57  <isaacs>python 2.5 will crash in many other places, i believe
18:24:03  * dshaw_joined
18:24:11  <isaacs>iirc scons and waf are boht either broken or weird with it
18:24:36  <TooTallNate>gyp actually seems to work fine, i just have to tweak the ./gyp-mac-tool file that gets generated to use "0666" instead of "0o666"
18:25:04  <CIA-99>node: Nathan Rajlich master * rfdeeabb / configure : configure: don't use "with" for Python 2.5 and older - http://git.io/Sr615Q
18:25:05  <CIA-99>node: Nathan Rajlich master * r9b7a6c5 / configure : configure: output a newline at the end of config.gypi - http://git.io/J-5Fow
18:29:00  <piscisaureus>TooTallNate: will look
18:29:11  * avalanche123quit (Ping timeout: 276 seconds)
18:29:15  <piscisaureus>bnoordhuis: the slab allocator seems broken on windows
18:30:01  <piscisaureus>bnoordhuis: https://gist.github.com/2361188
18:30:05  <piscisaureus>bnoordhuis: thoughts?
18:30:57  * avalanche123joined
18:40:08  * travis-cijoined
18:40:08  <travis-ci>[travis-ci] joyent/node#713 (master - 9b7a6c5 : Nathan Rajlich): The build is still failing.
18:40:08  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/e066074...9b7a6c5
18:40:08  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1068333
18:40:08  * travis-cipart
18:40:53  <TooTallNate>lol wtf
18:40:55  <TooTallNate>88 failures
18:41:49  <piscisaureus>Yeah the latest uv upgrade fucked it up sincerely
18:53:16  * bradleymeckjoined
18:56:05  <txdv_>damn
18:56:10  <txdv_>and I wanted to fetch master today
18:56:13  <txdv_>you make me cry
19:01:20  <isaacs>txdv_: you can just temporarily `git revert ec521e5` on your local checkout
19:02:33  * creationixmakes note to not pull in libuv changes in luv* projects today
19:02:49  <wankdanker>is there any documentation on the libeio which is included with node 0.7.7? eio_custom has an additional parameter `eio_channel *channel` which breaks my module.
19:03:12  <TooTallNate>wankdanker: you should be using uv_queue_work() instead
19:03:31  <creationix>wankdanker, I think eio_custom is deprecated in libuv...
19:03:34  <creationix>yeah what TooTallNate said
19:03:41  <wankdanker>TooTallNate: eeek. is that backwards compatible with 0.6?
19:03:51  <TooTallNate>wankdanker: it's part of libuv
19:03:54  <TooTallNate>wankdanker: so yes
19:04:08  <creationix>it was added sometime on 0.5.x right?
19:04:14  <piscisaureus>isaacs: I'd say, just revert the commit in libuv and upgrade again.
19:04:27  <TooTallNate>wankdanker: libuv calls eio_custom() on unix platforms, and does the proper Windows equivalent there
19:04:34  <piscisaureus>isaacs: I am trying to get the slab allocator fixed but if I cannot get it done the it is also going out
19:04:39  <isaacs>piscisaureus: ok.
19:04:45  * dshaw_quit (Quit: Leaving.)
19:04:51  <wankdanker>TooTallNate creationix: cool, thanks I'll get on that then.
19:04:53  <isaacs>piscisaureus: want me to push to libuv/master as well?
19:04:54  <piscisaureus>isaacs: btw - send bnoordhuis an email if you do :-)
19:05:18  <piscisaureus>isaacs: well I am mostly concerned about node - the current state of brokenness is not acceptable, not even in master
19:05:28  <isaacs>piscisaureus: yeah, going to. he'd said something about having to get up early today, i assume he's got some business he's attending to.
19:05:40  <piscisaureus>isaacs: I don't know
19:05:47  <isaacs>yep. this needs to be fixed now-ish.
19:09:11  <isaacs>piscisaureus: testing in master with the libuv reversion
19:12:55  * dylukes_joined
19:13:34  * dylukes_changed nick to dylukes
19:13:54  * txdv_quit (Ping timeout: 245 seconds)
19:14:30  * `3rdEdenjoined
19:18:10  <isaacs>piscisaureus: hm. this doesn't revert cleanly.
19:18:29  <piscisaureus>isaacs: you mean, in node?
19:18:37  <isaacs>piscisaureus: no, i mean in libuv.
19:18:49  <isaacs>piscisaureus: i can revert the libuv upgrade easily enough
19:18:51  * xaqquit (Remote host closed the connection)
19:18:52  <piscisaureus>isaacs: ok, I can take a look if you want
19:19:01  <piscisaureus>isaacs: the windows bustage is easy enough to fix
19:19:10  <isaacs>piscisaureus: but i'd rather not, if we can fix it a bit more surgically
19:20:55  * `3rdEdenquit (Quit: Zzzz)
19:21:29  <isaacs>piscisaureus: oh, i think i see what happened.
19:21:51  <isaacs>piscisaureus: unix/core.c had something added in v0.6, and something else added in master, so the reversion couldn't figure it out
19:21:59  <isaacs>piscisaureus: trying with a "keep both" approach now
19:22:06  <isaacs>nope
19:22:08  <isaacs>../deps/uv/src/unix/core.c:190: error: ‘uv_loop_t’ has no member named ‘endgame_handles’
19:22:08  <isaacs>../deps/uv/src/unix/core.c:191: error: ‘uv_loop_t’ has no member named ‘endgame_handles’
19:22:20  <isaacs>wait a minute, that makes no sense...
19:22:28  <piscisaureus>isaacs: ah that's the work ben has done for libuv-linux
19:22:44  <isaacs>right
19:22:56  <isaacs>i'm assuming that this works in linux.
19:22:59  <isaacs>but it's super busted in os x
19:24:17  <isaacs>yeah, ok, looks like ed395e0 was the first bad commit, but not the last one :)
19:27:49  <isaacs>piscisaureus: do you feel like poking around in there, or should i just roll back libuv?
19:28:02  <piscisaureus>isaacs: I will poke in there
19:29:23  <isaacs>k. i'm going to run an errand and get some lunch. i'll be back in a bit. feel free to revert node@0db4dc0 if you can't figure it out easily. that's why we upgrade our deps atomically :)
19:31:40  * toothrjoined
19:38:05  * dshaw_joined
19:40:47  <piscisaureus>igorzi: are you doing anything node related atm?
19:42:59  <piscisaureus>saghul: the test is passing for me
19:43:19  <piscisaureus>saghul: could be a mingw issue. could be your windows version. What windows are you using?
19:43:28  <saghul>Windows 7 (32 bit)
19:43:58  <saghul>using minnow, with gcc 4.6.2
19:44:12  <saghul>*mingw
19:44:46  <saghul>i'll test msvc in a while
19:44:50  <piscisaureus>saghul: can you get a backtrace out of gdb?
19:47:12  * dylukesquit (Quit: Computer has gone to sleep.)
19:51:54  <bnoordhuis>reverting the libuv upgrade is not a real solution, of course
19:52:58  <bnoordhuis>isaacs: re endgame_handles: i wager you have stale files somewhere
19:53:43  * dylukesjoined
19:53:48  * dylukesquit (Client Quit)
19:55:27  <CIA-99>node: Bert Belder reviewme * r39cc2a4 / (src/slab_allocator.cc src/stream_wrap.cc): Slab allocator: don't attempt to shrink a non-buffer - http://git.io/YsK6wQ
19:55:38  <piscisaureus>bnoordhuis: ^-- review. Fixes windows
19:56:52  * isaacs_mobilejoined
19:58:11  <saghul>piscisaureus I have msvc 2008 and it's missing student.h, I'll get the 2010 version and test
19:58:23  <bnoordhuis>piscisaureus: reviewed
19:59:13  <bnoordhuis>piscisaureus: i would move that buf.base != NULL check out of the nread < 0 branch
20:00:22  <piscisaureus>bnoordhuis: that would get awkward
20:00:28  <piscisaureus>bnoordhuis: because
20:00:59  <bnoordhuis>piscisaureus: okay. then change it to -> if (buf.base) slab_allocator.Shrink(wrap->object_, buf.base, 0)
20:01:54  <piscisaureus>*either*:
20:01:54  <piscisaureus>if (...) {
20:01:54  <piscisaureus> Local<Object> slab = ...
20:01:54  <piscisaureus>} // slab out of scope
20:01:54  <piscisaureus>*or*:
20:01:55  <piscisaureus>Local<Object> slab;
20:01:55  <piscisaureus>if (...) {
20:01:56  <piscisaureus> slab = ...
20:01:56  <piscisaureus>} // slab could be undefined
20:02:08  <piscisaureus>bnoordhuis: ^
20:03:00  <CIA-99>node: Bert Belder master * r3ec84a1 / (src/slab_allocator.cc src/stream_wrap.cc): Slab allocator: don't attempt to shrink a non-buffer - http://git.io/wPRoyQ
20:03:06  <bnoordhuis>piscisaureus: you'd find out soon enough - it'd crash :)
20:04:51  <bnoordhuis>piscisaureus: new commit lgtm but Local<Object> slab = slab_allocator.Shrink(wrap->object_, buf.base, nread) fits on one line
20:05:17  <piscisaureus>bnoordhuis: alright.
20:05:19  <bnoordhuis>anyway, doesn't matter
20:07:18  * isaacs_mobilequit (Remote host closed the connection)
20:08:26  <piscisaureus>bnoordhuis: so what about the endgame_handles crashes?
20:08:53  <piscisaureus>bnoordhuis: you said something about stray files but I am surprised that it would cause libuv to abort
20:09:29  <bnoordhuis>piscisaureus: crash or build failure?
20:09:34  <piscisaureus>bnoordhuis: crash
20:09:43  <bnoordhuis>what isaacs posted is a build failure
20:09:55  <bnoordhuis>i mean this: ../deps/uv/src/unix/core.c:191: error: ‘uv_loop_t’ has no member named ‘endgame_handles’
20:10:47  <tjfontaine>he was trying to revert inside libuv, I think he was saying it was larger than one commit
20:11:10  <piscisaureus>bnoordhuis: that's after a revert of one of your patches. The real problem is this: https://gist.github.com/2358108 - https://github.com/joyent/node/commit/0db4dc0024eaa538bf4913d6bf256a18126de2ba#commitcomment-1196660
20:11:11  <piscisaureus>saghul: it's cool that you can try with msvc - but if you can extract anything meaningful out of gdb (stack trace?) that's more helpful, since it would actually help us fix the issue :-)
20:11:12  <bnoordhuis>oh, that i don't doubt - it's been a while since the last upgrade
20:11:20  <bnoordhuis>the upgrade commit was rather massive
20:11:55  * dylukesjoined
20:12:20  <isaacs>bnoordhuis: yeah, of course, reverting the libuv upgrade is only a stopgap. we need to fix it properly.
20:12:34  <bnoordhuis>it's kind of odd that ed395e0 breaks node but not the tests
20:12:43  <isaacs>bnoordhuis: it's just that "fix it properly" is more than reverting one bad commit in libuv out of context
20:12:52  <isaacs>bnoordhuis: and yes, it would be nice if the libuv tests caught this :)
20:14:37  * brsonjoined
20:15:00  <bnoordhuis>isaacs: anyway, no worries, i'll fix it
20:15:41  <isaacs>bnoordhuis: awesome. if it's going to take a long time (ie, more than a day), please revert the libuv upgrade in the meantime.
20:15:45  <isaacs>thanks
20:15:55  * isaacsoff to put food in the neighbor's cat.
20:16:28  <bnoordhuis>better that than the other way around
20:16:37  <bnoordhuis>by which i mean put a cat in the neighbor's food
20:17:41  <saghul>piscisaureus gdb says nothing o_O I'll create a 2 line standalone test to see
20:18:16  <bnoordhuis>[02:00|% 100|+ 379|- 0]: Done <- who the man?
20:18:53  <mmalecki>bnoordhuis: ++
20:18:53  <kohai>bnoordhuis has 12 beers
20:19:15  <mmalecki>bah, only 12 beers Ben?
20:19:33  * travis-cijoined
20:19:33  <travis-ci>[travis-ci] joyent/node#714 (reviewme - 39cc2a4 : Bert Belder): The build is still failing.
20:19:33  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/commit/39cc2a4
20:19:33  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1069092
20:19:33  * travis-cipart
20:21:10  <bnoordhuis>mmalecki: i reset the counter hourly
20:21:58  <mmalecki>bnoordhuis: I think that counts as alcoholism!
20:27:10  * txdvjoined
20:30:51  <piscisaureus>bnoordhuis: where the commit, then?
20:31:29  <piscisaureus>bnoordhuis, I mean: [02:00|% 100|+ 478|- -99] <-- who the man now?
20:31:37  <bnoordhuis>piscisaureus: i'm trying to fix it properly
20:31:54  <bnoordhuis>the easy way is to remove if (activecnt < 0) abort(); from ev.
20:31:55  <bnoordhuis>*ev.c
20:32:10  <piscisaureus>bnoordhuis: wrong!
20:32:15  <isaacs>piscisaureus: -99 failures?
20:32:30  <piscisaureus>isaacs: awesome, innit?
20:32:44  <isaacs>piscisaureus: i didn't know you could pass `make test` that hard. i'm impressed.
20:32:49  * travis-cijoined
20:32:50  <travis-ci>[travis-ci] joyent/node#715 (master - 3ec84a1 : Bert Belder): The build is still failing.
20:32:50  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/9b7a6c5...3ec84a1
20:32:50  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1069145
20:32:50  * travis-cipart
20:35:53  * isaacschanged nick to isaacs_away
20:39:59  <igorzi>piscisaureus: hey
20:40:15  <piscisaureus>igorzi: hey
20:40:27  <igorzi>piscisaureus: i'm finally looking at why that send tcp connections patch doesn't work for andreasmadsen
20:40:39  <piscisaureus>igorzi: ah, ok
20:40:42  <piscisaureus>igorzi: does it for you?
20:41:04  <igorzi>piscisaureus: nope.. don't know why yet.. just started looking at it
20:41:19  <piscisaureus>igorzi: ah, ok
20:47:23  * c4milo_joined
20:49:02  * c4miloquit (Quit: me fui)
20:49:12  * c4milo_changed nick to c4milo
20:50:28  <saghul>piscisaureus got some gdb trace: https://gist.github.com/2362471
20:51:50  <piscisaureus>saghul: aha, thanks, very helpful
20:52:28  <saghul>piscisaureus any time :-)
20:54:59  <CIA-99>libuv: Bert Belder reviewme * r2e5e116 / (test/test-get-memory.c test/test-platform-output.c):
20:54:59  <CIA-99>libuv: Tests: don't use %zu placeholder in printf statements
20:54:59  <CIA-99>libuv: It's not supported by msvcrt. - http://git.io/sW3qyA
20:55:11  <piscisaureus>^-- igorzi bnoordhuis - anyone cares to review?
20:55:20  <bnoordhuis>piscisaureus: can you verify that this patch makes node's test suite pass? https://gist.github.com/bb78bfa02e5d14471619
20:55:40  <piscisaureus>bnoordhuis: you mean, on unix?
20:55:46  <bnoordhuis>piscisaureus: no, on windows
20:55:52  <piscisaureus>bnoordhuis: on windows it already passes
20:55:57  <bnoordhuis>oh, good
20:56:04  <bnoordhuis>btw, unsigned long long isn't available in c89 mode
20:56:12  <piscisaureus>sigh
20:56:24  <bnoordhuis>it will probably compile but with warnings
20:56:33  <piscisaureus>bnoordhuis: so what can we use instead
20:56:44  <piscisaureus>"long" is 32 bit on windows: -/
20:56:51  <igorzi>piscisaureus: lgtm
20:57:00  * travis-cijoined
20:57:00  <travis-ci>[travis-ci] joyent/libuv#185 (reviewme - 2e5e116 : Bert Belder): The build is still failing.
20:57:00  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/2e5e116
20:57:00  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1069632
20:57:00  * travis-cipart
20:57:01  * isaacs_mobilejoined
20:57:06  <bnoordhuis>piscisaureus: nothing. it's one of the great unsolved mysteries :/
20:57:21  <piscisaureus>OMG
20:57:22  <bnoordhuis>land it, i'll clean it up if need be
20:57:36  <piscisaureus>bnoordhuis: ok, as long as you don't resort to %zu :-)
20:57:48  <CIA-99>libuv: Bert Belder master * r2e5e116 / (test/test-get-memory.c test/test-platform-output.c):
20:57:48  <CIA-99>libuv: Tests: don't use %zu placeholder in printf statements
20:57:48  <CIA-99>libuv: It's not supported by msvcrt. - http://git.io/sW3qyA
20:58:01  * isaacs_mobilequit (Client Quit)
20:58:12  <piscisaureus>bnoordhuis: we can do something terrible like, cast to a double
20:58:17  * isaacs_mobilejoined
20:58:39  <bnoordhuis>piscisaureus: i would like to keep libuv as float free as possible
20:58:57  <piscisaureus>bnoordhuis: or
20:58:57  <piscisaureus>#define BI_P "%zu"
20:58:57  <piscisaureus>#define BI_T size_t
20:59:07  * piscisaureuskills a puppy
20:59:07  <bnoordhuis>yes, that's how most projects do it
20:59:21  * indutnyquit (Ping timeout: 252 seconds)
20:59:59  * travis-cijoined
20:59:59  <travis-ci>[travis-ci] joyent/libuv#186 (master - 2e5e116 : Bert Belder): The build is still failing.
20:59:59  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/42d3533...2e5e116
20:59:59  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1069655
20:59:59  * travis-cipart
21:00:33  <bnoordhuis>piscisaureus: might be worthwhile to test that patch i just posted
21:00:45  <piscisaureus>bnoordhuis: ok, if you want
21:00:49  <bnoordhuis>i'm pretty sure it's not a bug in node, not in libuv
21:01:03  <piscisaureus>bnoordhuis: so where is it?
21:01:04  <bnoordhuis>err, bug *in* node, *not* in libuv
21:01:07  <piscisaureus>bnoordhuis: the moon?
21:01:09  <piscisaureus>ah
21:03:22  <bnoordhuis>test/simple/test-http-get-pipeline-problem.js seems pretty broken on os x...
21:03:30  <piscisaureus>bnoordhuis: ok I am testing it
21:04:12  <bnoordhuis>oh, it tries to run ab
21:04:17  <bnoordhuis>bad test, no cookie
21:05:16  <txdv>have you got macs to test it on?
21:06:50  * isaacs_awaychanged nick to isaacs
21:08:32  * isaacs_mobilequit (Remote host closed the connection)
21:10:05  <bnoordhuis>txdv: yes. why?
21:10:27  <txdv>I wonder how many different OSes you are testing on
21:11:52  * perezdquit (Ping timeout: 246 seconds)
21:11:53  <bnoordhuis>linux, solaris, os x, windows, sometimes freebsd
21:12:07  <bnoordhuis>still working on the plan9 port
21:12:12  * indutnyjoined
21:12:26  <isaacs>plan9 is planed for version 9
21:12:36  <isaacs>along with multics
21:12:39  * perezdjoined
21:12:55  <txdv>support all the operating systems!
21:20:20  * txdvquit (Ping timeout: 250 seconds)
21:20:57  * perezd_joined
21:21:02  <piscisaureus>bnoordhuis: also on windows
21:21:21  <piscisaureus>bnoordhuis: btw - most tests pass with the timer reffing patch
21:22:11  <bnoordhuis>piscisaureus: right, thanks. now the small matter of fixing timer_wrap.cc
21:23:23  * perezdquit (Ping timeout: 276 seconds)
21:23:24  * perezd_changed nick to perezd
21:25:27  * bulatshakirzyanojoined
21:33:09  * bulatshakirzyanoquit (Quit: Computer has gone to sleep.)
21:36:51  * txdvjoined
21:38:24  * dylukesquit (Quit: Computer has gone to sleep.)
21:40:19  <creationix>piscisaureus, bnoordhuis which one of you is working on the uv_ref refactor?
21:40:38  <bnoordhuis>creationix: i am
21:40:42  <piscisaureus>creationix: ben
21:40:57  <bnoordhuis>if you want it done right, you need to do it yourself
21:41:15  <creationix>bnoordhuis, I need an API to know when a uv_handle_* is no longer holding the event loop open
21:41:27  <creationix>so I can release any GC reference to it at the VM layer
21:41:43  <creationix>and probably another API to know when it does have a pending callback or event
21:41:48  <bnoordhuis>creationix: you can keep track of that yourself, can't you?
21:41:57  <creationix>I can, but it's complicated
21:42:03  <creationix>and since libuv has to do that counting anyway
21:42:08  <creationix>why not reuse the logic
21:42:14  <bnoordhuis>once the refactor is done, handles will only ref the loop when active
21:42:28  <creationix>ok, what makes a handle active?
21:42:34  <bnoordhuis>depends on the handle type
21:42:42  <bnoordhuis>sockets, when they're reading or writing
21:42:50  <bnoordhuis>timers, when they're started
21:43:09  <creationix>ok, so then I want a way to register handle_on_active and handle_on_unactive
21:43:12  <creationix>or something like that
21:43:38  <bnoordhuis>i don't understand why
21:43:46  <bnoordhuis>you can check if a handle is active with uv_is_active()
21:44:10  <bnoordhuis>if you need something more / different, please explain why :)
21:44:14  <creationix>I'
21:44:24  <creationix>I'd rather not have to poll the object on every interaction
21:44:51  <creationix>s/object/struct/
21:45:11  <bnoordhuis>i still don't understand
21:45:28  <bnoordhuis>when you call e.g. uv_timer_start(), you *know* that the handle is active
21:45:38  <bnoordhuis>and when you call uv_timer_stop(), that it's inactive
21:45:50  <creationix>bnoordhuis, yes, but I don't want to have to know all that logic
21:45:54  <creationix>as you say, it depends on the type
21:46:09  <creationix>what about repeating timers
21:46:10  <bnoordhuis>okay, think of it like this
21:46:17  <bnoordhuis>when you create the handle, it's inactive
21:46:18  <creationix>what if you take a non-repeating timer and make it repeating
21:46:24  <bnoordhuis>as soon as it starts doing something, it becomes active
21:46:26  <bnoordhuis>until stopped or closed
21:46:51  * dylukesjoined
21:47:03  <bnoordhuis>that non-repeating timer that you turn into a repeating timer is doing something, hence it's active
21:47:16  <creationix>right, but my point is that it's complicated
21:47:18  <creationix>and that's just timers
21:47:28  <creationix>I'd rather just have a generic on_active and on_not_active
21:47:43  <creationix>since libuv has to do something already internally
21:47:54  <bnoordhuis>i really don't see the need
21:48:14  <creationix>I don't want to duplicate complex logic
21:48:42  <bnoordhuis>i also don't think it's complicated :)
21:48:47  <creationix>besides being more work, the duplicated logic has to be kept in sync or bugs appear
21:49:14  <creationix>is there a performance issue with allowing me to register a C callback?
21:49:23  <creationix>memory I guess
21:49:34  <creationix>it would mean two more function pointers on the struct
21:49:54  <bnoordhuis>yes, but it's not too worrisome
21:50:16  <bnoordhuis>it's just that i don't see a pressing need to add something that you can track yourself
21:50:22  <piscisaureus>creationix: I don't really understand
21:50:31  <piscisaureus>creationix: what is the problem you need to solve?
21:50:45  <creationix>I have been tracking it myself, but I'm constantly finding bugs because I assume things wrong about libuv internaly
21:51:03  <bnoordhuis>the idea behind the refactor is to make it simpler
21:51:08  <piscisaureus>yes
21:51:13  <bnoordhuis>because the reference counting scheme is kind of wtf-y now
21:51:36  <creationix>I want to leverage this simple and solid logic you're writing for the refactor, not duplicate it
21:51:44  <creationix>that way I know it's in sync
21:51:48  * mralephquit (Quit: Leaving.)
21:52:13  <piscisaureus>creationix: so what is the problem you need to solve?
21:52:24  <piscisaureus>creationix: e.g. you need to keep *what* in sync with libuv?
21:52:42  <creationix>I have to ref and unref objects from the GC's point of view
21:53:01  <piscisaureus>creationix: why?
21:53:16  <piscisaureus>creationix: you can't just GC a stopped object away
21:53:22  <creationix>ok, so suppose I have a timer object with a callback as a property
21:53:24  <piscisaureus>because you would need to uv_close it
21:53:32  <creationix>the timer object is actually the uv_timer_t
21:53:42  <creationix>it's in the lua vm heap
21:54:02  <creationix>it's possible that there is no reference to the object, but the callback is still pending
21:54:18  <creationix>if I don't insert an extra gc ref to the object then it will segfault when on_timer happens
21:54:55  <creationix>so basically I want to sync strong references in the scripting vm with the active state of the uv handle
21:55:12  <creationix>make them strong refs when active and weak refs when inactive
21:55:24  <piscisaureus>creationix: so does lua have this concept of weak refs?
21:55:33  <creationix>yes
21:55:36  <piscisaureus>creationix: or rather, weak ref callbacks
21:55:46  <bnoordhuis>creationix: make them strong refs when active and weak refs when inactive <- that won't work
21:55:57  <bnoordhuis>it's not safe to free the memory of a handle until it's closed
21:56:06  <piscisaureus>what ben said
21:56:09  <creationix>with candor, for example, there is no callback when the vm is about to collect something
21:56:36  <creationix>bnoordhuis, exactly, that's why it needs to be a strong ref while it's active
21:56:38  <piscisaureus>creationix: well, in that case you're screwed...
21:56:53  <creationix>but in candor I can make a ref strong or weak
21:56:54  <piscisaureus>creationix: yes, and that is why it *also* needs to be a strong ref when it's inactive
21:56:57  <bnoordhuis>creationix: it also needs to be a strong ref when it's inactive
21:57:02  <bnoordhuis>hah :)
21:57:03  <creationix>if I had an event from libuv to change this state, it would be safe
21:57:19  <bnoordhuis>no, it would not
21:57:20  <creationix>no, it doesn't need to be a strong ref when it's inactive
21:57:32  <bnoordhuis>let me repeat: you *cannot* free the memory until after uv_close
21:57:33  * mralephjoined
21:57:35  <creationix>if there is no natural ref to it, it might as well be dead
21:57:43  <creationix>I can call uv_close on gc
21:57:50  <creationix>just so it doesn't leak mem
21:58:13  <piscisaureus>creationix: but if candor doesn't give you a weak ref callback, how will you know when to call uv_close?
21:58:20  <isaacs>bnoordhuis: any eta on the fix in node? or anything i can do to help? i want to verify that this domains thing isn't making performance terrible or breaking things badly
21:58:27  <creationix>ok, I mispoke
21:58:36  <creationix>it does give a callback when it's about to be gced
21:58:42  <creationix>what it doesn't do it let you cancel the gc
21:58:47  <bnoordhuis>isaacs: if you want a quick fix, try this: https://gist.github.com/bb78bfa02e5d14471619
21:58:49  <piscisaureus>creationix: well, then you are also screwed
21:58:53  <creationix>so I can't check the active state and cancel the gc
21:59:11  <piscisaureus>creationix: because you need to keep the memory allocated until you make the close callback ...
21:59:33  <creationix>hmm, good point
21:59:42  <creationix>and libuv counts it as inactive during close?
21:59:50  <txdv>creationix: what VM are you talking about?
21:59:55  <piscisaureus>creationix: well the "limbo" state is kind of special
21:59:56  <creationix>candor, luajit and smjs
22:00:08  <piscisaureus>creationix: I don't know yet how we will count that. But it will reference the event loop for sure.
22:00:12  <creationix>txdv, candor is a new one
22:00:19  <piscisaureus>creationix: we have uv_is_closing() for that
22:00:48  <creationix>piscisaureus, right, so the same logic that counts as holding the event loop open is the exact same logic I want to toggle the references
22:00:59  <creationix>and it can be complicated and has edge cases
22:01:02  <txdv>this is madness
22:01:04  <creationix>so I don't want to repeat it
22:01:23  <TooTallNate>txdv == C3PO
22:01:38  * mralephquit (Client Quit)
22:01:41  <txdv>TooTallNate: ?
22:01:50  <isaacs>bnoordhuis: that seems somewhat like an incomplete fix. ;)
22:02:10  <piscisaureus>creationix: ok so I get the point.
22:02:10  <bnoordhuis>isaacs: yes, but it's enough to demonstrate that the bug is in node and not in libuv
22:02:14  <bnoordhuis>i'm working on tracking it down
22:02:22  <bnoordhuis>also, it makes the tests pass :)
22:02:25  <isaacs>bnoordhuis: ok, cool.
22:02:26  <isaacs>yes, it does
22:02:28  <isaacs>MUST BE GOOD
22:02:34  <isaacs>SHIP IT!
22:02:35  <bnoordhuis>damn right!
22:02:43  <TooTallNate>txdv: http://www.youtube.com/watch?v=ZFDaqCUfrwo&feature=player_detailpage#t=5s
22:02:44  <isaacs>that's test driven development, right?
22:03:18  <txdv>i named my windows computer c3po
22:03:22  <txdv>so i was a little bit confused
22:03:31  <TooTallNate>wow
22:04:01  <bnoordhuis>TooTallNate: `node-gyp configure build` doesn't work
22:04:08  <bnoordhuis>IOError: [Errno 21] Is a directory: 'build'
22:04:14  <TooTallNate>bnoordhuis: what version of node-gyp?
22:04:19  <bnoordhuis>what's in master
22:04:24  <txdv>I don't understand why the need for yet another virtual machine ... especially since it is just slimmed down javascript
22:04:26  <bnoordhuis>running configure and build separately does work btw
22:04:28  <piscisaureus>creationix: unfortunately the activity thing also won't fix your problem
22:04:32  <TooTallNate>bnoordhuis: ya, isaacs needs to update to v0.4.1
22:04:38  <creationix>piscisaureus, who not?
22:04:39  <TooTallNate>bnoordhuis: i just recently added that
22:04:44  <bnoordhuis>TooTallNate: oh, okay. nvm then :)
22:05:04  <piscisaureus>creationix: because the plan was that uv_write would not make the the handle itself active
22:05:25  * bulatshakirzyanojoined
22:05:33  <piscisaureus>creationix: (the existence of a pending write request would keep the loop alive by itself)
22:05:39  <creationix>piscisaureus, ok, so if there are more states than just "active" that holds the process open then I need all
22:05:46  <creationix>I don't care what it's called
22:05:57  <creationix>I just need to know if this handle is holding the event loop open or not
22:06:06  <creationix>and preferably be notified when it changes instead having to poll
22:06:15  <piscisaureus>creationix: no, that's not what you care about :-)
22:06:34  <piscisaureus>creationix: what you really care about is, "can a pointer to this object suddenly show up somewhere?"
22:07:21  <creationix>right, except I'll always have a reference via the vm for everything except the type of things that hold the event loop open
22:07:37  <creationix>so it will already be safe from the GC in all other cases
22:08:15  <creationix>if there is nothing holding the event loop open and nothing referencing it in the script, it's impossible to ever need the pointer
22:09:42  <creationix>hmm, but close is tricky
22:10:08  <piscisaureus>creationix: well, that depends on whether you expose the close callback + the object pointer to the user
22:10:20  <creationix>right
22:11:05  <creationix>in luvit, there is a lua callback that's a property on the cdata (which is the uv_timer_t as a lua object)
22:11:21  <creationix>lua can only access the wrapped struct if it's not GCed
22:11:27  <creationix>and lua can never access the C callback
22:11:56  <piscisaureus>creationix: I think you will have to "duplicate" the logic
22:12:21  <piscisaureus>creationix: (which is not really duplicate since the logic doesn't exist in libuv)
22:12:30  <creationix>is that because it's slightly different that what uv needs?
22:12:31  <piscisaureus>creationix: but the rules are quite simple
22:13:31  <piscisaureus>creationix: libuv is only concerned with "will anything happen or should we fall out of uv_run" and "is it safe to free the memory of handle xx"
22:14:15  <piscisaureus>creationix: you are concerned with "did the user forget to call uv_close, or is something still going on that might revive it" :-)
22:14:56  <piscisaureus>creationix: but the logic is not very difficult (I think timers in fact have the most edge cases)
22:15:41  <piscisaureus>creationix: there are two types of objects that you need to deal with:
22:15:41  <piscisaureus>* handles
22:15:41  <piscisaureus>* requests that operate on handles
22:16:31  * rendarquit (Quit: good night)
22:16:40  <creationix>how about libuv just document clearly what can hold the loop open?
22:16:51  <piscisaureus>creationix: that is the purpose of the refcount refactor
22:17:10  <piscisaureus>but it won't fix your problem
22:17:52  <creationix>does node leak memory if you forget to call close?
22:18:04  <piscisaureus>creationix: yes
22:18:09  * dylukesquit (Read error: Connection reset by peer)
22:18:09  <mjr_>bnoordhuis: I have a core file for you that shows the TLS hang.
22:18:14  <creationix>ahh, that's the easy way out
22:18:15  * dylukesjoined
22:18:27  <piscisaureus>creationix: although most of it is hidden in the internal api
22:18:57  <creationix>ideally I'd like it to not hang and auto-close if the handle it otherwise inactive and inaccessable
22:19:00  <piscisaureus>creationix: in that sense - we make sure that uv_close is called
22:19:20  <creationix>but I feel less bad if node didn't solve this problem
22:20:05  <piscisaureus>creationix: but in node you can easily leak:
22:20:05  <piscisaureus>net.createConnection(80, "this.server.never.hangs.up.com", function(){});
22:20:15  <piscisaureus>^-- creationix: easy leak :-)
22:20:36  <creationix>ok, I'll think more about it later
22:20:44  <creationix>I still think some sort of callback in libuv can help me
22:20:50  <creationix>time to go eat supper
22:20:57  <piscisaureus>super
22:21:14  <saghul>creationix hi there :-) for pyuv I call uv_close (in case nobody called it before) if the Python object is not held by anybody, so GCing an object causes uv_cloce
22:21:31  <creationix>saghul, right, that solved the forgot to gc issue
22:21:47  <creationix>but the harder issue is to hold the object safe in the gc just enough, but not too much
22:22:06  <saghul>also, when calling a callback in the Python world I increment the python refcount so the object is still alive when we get back to C
22:22:17  <creationix>everything I do seems to be either too string (never can be GCed automatically) or too weak (segfaults)
22:22:31  <creationix>right, so you implemented refcounts in your code
22:22:36  <creationix>I'd like to not have to do that
22:22:44  <creationix>*too strong
22:22:46  <saghul>well, you must, since it's Python :-)
22:22:50  <piscisaureus>creationix: node also kind of has that
22:22:57  <creationix>right, as do I
22:23:04  <creationix>but I think libuv can solve it once
22:23:28  <creationix>I'm more sensitive to this since I have multiple libuv binding projects
22:23:39  <piscisaureus>creationix: well, if you can come up with a solid proposal I'm probably fine with it
22:23:58  <creationix>ok, so two extra function pointers in uv_handle_t isn't unresonable?
22:24:02  <piscisaureus>creationix: but, to be honest, Ben and I will probably just shoot holes in your logic
22:24:13  <piscisaureus>creationix: depending on how big the problem is that it solves, no
22:24:14  <creationix>faulty logic needs holes in it
22:24:22  <creationix>:)
22:24:23  <bnoordhuis>mjr_: can you send it my way? i probably won't have time to look at it tonight though
22:24:46  <piscisaureus>creationix: I think you should go more for a double indirection scheme
22:25:00  <mjr_>bnoordhuis: sure, I'll start up another server on the machine, just wanted to do it when you were around so I could shut it down right away
22:25:23  <creationix>piscisaureus, I've already got like 5 levels of indirection to get at the struct in most Vms
22:25:39  <piscisaureus>creationix: well maybe you can repurpose one level then :-)
22:26:06  <saghul>is that the "Inception VM"? :-)
22:26:18  <creationix>lol, no
22:27:03  <creationix>maybe not 5, but more than 2 at least
22:27:04  <mjr_>bnoordhuis: (or anybody else who cares) http://prod-2131.voxer.com:3000/
22:27:40  * bnoordhuisstarts wget --mirror
22:27:55  <piscisaureus>creationix: so what you should probably do is keep track of the "active state" yourself, with the following rules
22:27:56  <piscisaureus>* expecting_callbacks = pending_reqs_on_handle || handle_is_active
22:28:27  <piscisaureus>if (!expecting_callbacks) make_weak(); else make_strong();
22:28:51  <creationix>right, I need to consider requests
22:28:58  <piscisaureus>creationix: yes
22:29:31  <piscisaureus>creationix: handles become active when you call read_start, read2_start, listen, timer_start
22:29:54  <piscisaureus>creationix: they become inactive when you call read_stop(*), uv_close
22:30:01  <creationix>so what is a request anyway, I'm not super clear on why some functions work on the handle directly and others need requests
22:30:37  <creationix>I know one use is things that need specific callbacks
22:30:46  <creationix>like uv_write callbacks
22:30:59  <piscisaureus>creationix: a handle is similar to EventEmitter (e.g. it could emit 0 to many events) and needs to be closed explicitly
22:31:14  <bnoordhuis>mjr_: yay, works!
22:31:31  <bnoordhuis>by which i mean that i now have an actual backtrace :)
22:31:32  <piscisaureus>creationix: a req is similar to an async function in node (like readFile) -> something that happens in the background and generates exactly one callback
22:31:45  <mjr_>bnoordhuis: our Solaris friends insist that we learn mdb for this kind of thing. It will also let us use dap's awesome jsstack work.
22:31:58  <mjr_>bnoordhuis: but I already know gdb, so I'm resistant.
22:32:04  <creationix>piscisaureus, ok, that's what I thought. I seem to remember cases not matching with that, but can't think of specifics right now
22:32:13  <creationix>anyway, I need to go, talk later
22:32:16  <bnoordhuis>mjr_: yeah... mdb feels like a step back when you're used to gdb
22:32:28  <piscisaureus>creationix: libuv guarantees that requests that operate on a handle always are flushed out before the handle itself makes its close callback
22:32:34  <bnoordhuis>though it's true that it'll let you do things that gdb won't
22:32:38  <piscisaureus>creationix: if you find any inconsistencies, please tell.
22:32:47  <creationix>ok
22:33:03  <piscisaureus>creationix: afaict only c-ares stuff is messy, but it;s going away
22:35:13  * mmaleckichanged nick to mmalecki[zzz]
22:40:46  * sj26quit (Ping timeout: 246 seconds)
22:42:54  * sj26joined
22:53:17  * bulatshakirzyanoquit (Quit: Computer has gone to sleep.)
22:57:14  <mjr_>bnoordhuis: you get those files?
22:58:22  <bnoordhuis>mjr_: yep
22:59:04  * perezdquit (Quit: perezd)
22:59:18  <bnoordhuis>okay, i'm going to revert the libuv upgrade
22:59:35  <bnoordhuis>don't want to spend hours on something that'll be thrown out a week or two anyway
22:59:47  * perezdjoined
23:01:00  <mjr_>bnoordhuis: did you also hear about our exciting dtrace discovery that TLS seems to be responsible for our memory growth on SmartOS?
23:05:35  <CIA-99>node: Ben Noordhuis master * re9dcfd4 / (41 files in 9 dirs):
23:05:35  <CIA-99>node: Revert "deps: upgrade libuv to 3c41597"
23:05:35  <CIA-99>node: This reverts commit 0db4dc0024eaa538bf4913d6bf256a18126de2ba.
23:05:35  <CIA-99>node: This commit makes a lot of tests fail due to reference counting errors. It's
23:05:35  <CIA-99>node: not worth it to debug because the reference counting scheme is due to change
23:05:35  <CIA-99>node: soon anyway. - http://git.io/McURDg
23:05:55  <bnoordhuis>TooTallNate: you may need to revert 70a5b53 again :/
23:06:10  <bnoordhuis>couldn't get the kqueue fix to apply to the old libuv
23:06:27  <bnoordhuis>mjr_: no. how/what did you find out?
23:06:42  <bnoordhuis>is this about the flame graph?
23:07:47  <bnoordhuis>piscisaureus: how's that openssl patch coming along?
23:07:59  <piscisaureus>bnoordhuis: I sent it :-/
23:08:20  <bnoordhuis>piscisaureus: send it again :)
23:09:03  <piscisaureus>bnoordhuis: looking it up again... I had to back off quite bit because the ui crap is all over the place
23:09:05  <piscisaureus>bnoordhuis: https://gist.github.com/2360332
23:09:43  <bnoordhuis>oh, the horror!
23:10:59  <piscisaureus>bnoordhuis: jsut fixed some style issues in the patch btw
23:11:16  <bnoordhuis>piscisaureus: it doesn't apply
23:11:17  <bnoordhuis>error: patch failed: deps/openssl/openssl.gyp:17
23:11:17  <bnoordhuis>error: deps/openssl/openssl.gyp: patch does not apply
23:11:42  <piscisaureus>bnoordhuis: huh it is based on top of your stuff
23:11:48  <bnoordhuis>oh wait, it does
23:11:54  <piscisaureus>bnoordhuis: try
23:11:54  <piscisaureus>curl https://raw.github.com/gist/2360332/b32671dde0e03062c7e870eceb88fbd94fd258de/0001-Disable-OpenSSL-UI.patch | git am -3
23:12:02  <bnoordhuis>nvm, fixed it :)
23:12:23  <piscisaureus>bnoordhuis: can we also enable OPENSSL_NO_ERR ?
23:12:32  <piscisaureus>bnoordhuis: or do we use error strings out of openssl in node?
23:12:42  <bnoordhuis>we use them
23:12:46  <piscisaureus>ok
23:13:26  <bnoordhuis>okay, rebuilding everything one last time...
23:13:38  <bnoordhuis>i'm buying a 16 core machine one of these days
23:13:53  <isaacs>bnoordhuis: what'd you find?
23:13:58  <isaacs>bnoordhuis: (saw the revert)
23:14:13  <piscisaureus>bnoordhuis: so your windows fix patch still includes WIN32_LEAN_AND_MEAN and MF1MF_BUILD (or whatever that was)
23:14:15  <piscisaureus>?
23:14:20  <bnoordhuis>piscisaureus: yes
23:14:24  <piscisaureus>good
23:14:27  <bnoordhuis>isaacs: that it's complicated :)
23:14:37  <piscisaureus>the winsock2 stuff can be letft out but not those
23:14:46  <bnoordhuis>and i didn't want to hack up half of node to fix it
23:14:53  <isaacs>kewl
23:15:05  <piscisaureus>bnoordhuis: so what's the issue?
23:15:22  <isaacs>bnoordhuis: can you write up an issue and attach it to the v0.8 milestone? or is it like a day or two thing?
23:15:25  <piscisaureus>bnoordhuis: must be an unix issue because on windows it passes :-)
23:15:37  <piscisaureus>bnoordhuis: or, do what isaacs says
23:15:59  <bnoordhuis>piscisaureus: it's kind of suspect. the loop refcount drops below zero and it's always a timer handle that causes it
23:16:28  <bnoordhuis>isaacs: will do. this problem should go away once the refcount refactor is done
23:16:32  <piscisaureus>bnoordhuis: doesn't happen on windows afaict
23:16:41  <bnoordhuis>of course that will introduce a slew of other bugs :)
23:16:52  <isaacs>sure
23:17:01  <bnoordhuis>piscisaureus: do you have a assert(loop->refcount >= 0) in there?
23:17:06  <piscisaureus>bnoordhuis: yes
23:17:20  <bnoordhuis>then it should be in src/unix/timer.c
23:17:47  <isaacs>bnoordhuis, piscisaureus: we've got the status call tomorrow. if you could take a few minutes to think of what is outstanding from v0.8 FC status in your opinion, that'd be helpful
23:17:48  <piscisaureus>bnoordhuis: I think uv_is_active for timers might be faulty, or you are overcompensating somewhere
23:18:05  <piscisaureus>isaacs: FC ?
23:18:10  <piscisaureus>RC>
23:18:10  <isaacs>feature complete
23:18:13  <piscisaureus>ah
23:18:32  <isaacs>i think we should aim for FC by May 1, release by June 1
23:19:15  <isaacs>we're close already
23:20:52  * travis-cijoined
23:20:53  <travis-ci>[travis-ci] joyent/node#716 (master - e9dcfd4 : Ben Noordhuis): The build is still failing.
23:20:53  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/3ec84a1...e9dcfd4
23:20:53  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1070634
23:20:53  * travis-cipart
23:25:21  <bnoordhuis>[02:04|% 100|+ 378|- 0]: Done <- huzzah!
23:25:28  <isaacs>bnoordhuis++
23:25:28  <kohai>bnoordhuis has 13 beers
23:25:30  <isaacs>thanks
23:25:54  <CIA-99>node: Bert Belder master * rc1f52a1 / (3 files in 2 dirs): Disable OpenSSL UI (+7 more commits...) - http://git.io/EIejrA
23:26:00  <bnoordhuis>start your compilers, gentlemen
23:26:08  <bnoordhuis>for some reason gyp insists on rebuilding the whole tree
23:26:34  <TooTallNate>bnoordhuis: you mean this patch? https://github.com/joyent/node/commit/2bb197c3f93f9d6682304c6cc4b2cdb2474885a5
23:27:02  <bnoordhuis>TooTallNate: no, 3c41597
23:27:21  <bnoordhuis>sorry, that's https://github.com/joyent/libuv/commit/3c41597
23:27:38  <TooTallNate>oh right
23:31:36  <piscisaureus>bnoordhuis: you forgot the windows fixes :-/
23:32:40  <bnoordhuis>piscisaureus: no, i merged those into ea55a9f
23:32:59  <piscisaureus>bnoordhuis: no they are not there
23:33:01  * mikealquit (Quit: Leaving.)
23:33:04  <bnoordhuis>wtf
23:33:17  <bnoordhuis>that's an old commit...
23:33:28  <piscisaureus>bnoordhuis: push it out!
23:33:44  <piscisaureus>bnoordhuis: there's also no need for TERMIOS no more I think btw
23:35:07  <bnoordhuis>force-push coming up
23:35:15  <bnoordhuis>i'll look into the TERMIOS thing later
23:35:52  <CIA-99>node: Bert Belder master * r1c88c3b / (3 files in 2 dirs): Disable OpenSSL UI (+7 more commits...) - http://git.io/pWgspA
23:36:08  <bnoordhuis>piscisaureus: 2639566 contains the windows changes
23:37:48  <isaacs>bnoordhuis: why does `make test` rebuild the whole tree now?
23:38:00  <isaacs>i just did `make distclean` and `make`, and then `make test` is rebuilding it yet again
23:39:00  * pfox___quit (Ping timeout: 252 seconds)
23:39:19  <bnoordhuis>isaacs: blame gyp
23:39:20  * travis-cijoined
23:39:21  <travis-ci>[travis-ci] joyent/node#717 (master - c1f52a1 : Bert Belder): The build is still failing.
23:39:21  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/e9dcfd4...c1f52a1
23:39:21  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1070809
23:39:21  * travis-cipart
23:39:29  <isaacs>wth
23:40:23  <bnoordhuis>there's a check on common.gypi in the makefile that makes it run configure
23:40:37  <bnoordhuis>that's what forcing the rebuild
23:41:27  <isaacs>are we touching config.gypi in the test?
23:41:30  <isaacs>that doesn't make sense
23:42:07  * paddybyersquit (Quit: paddybyers)
23:42:50  * dylukesquit (Quit: Pipes are broken. Sending packets via Fedex.)
23:42:52  <bnoordhuis>it probably seemed like a good idea at the time
23:43:17  * josephgjoined
23:45:17  * pfox___joined
23:54:09  * c4miloquit (Ping timeout: 250 seconds)