00:04:58  * piscisaureus__off
00:17:56  * paddybyersquit (Quit: paddybyers)
00:20:11  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:20:34  * ErikCorry2quit (Quit: Page closed)
00:24:07  * mikealjoined
00:32:57  * `3rdEdenquit (Quit: ZZZZzzzzzz)
00:39:35  <mmalecki>any word on the release?
00:39:38  <mmalecki>ryah: ^ ?
00:47:36  <mmalecki>ok, I'm off for today. we'll upgrade workers tomorrow.
01:16:29  <CIA-115>node: Ben Noordhuis master * r97e4b3a / (src/node_isolate.cc test/simple/test-isolates-ping-pong.js): isolates: drain message queue completely - http://git.io/kHus1w
01:28:09  * travis-cijoined
01:28:09  <travis-ci>[travis-ci] joyent/node#212 (master - 97e4b3a : Ben Noordhuis): The build is still failing.
01:28:09  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/787f62d...97e4b3a
01:28:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/499982
01:28:09  * travis-cipart
01:30:36  <CIA-115>node: Fedor Indutny master * ra5f74b4 / (src/node_script.cc src/node_vars.h): added isolates support - http://git.io/GLGJbg
01:30:37  <CIA-115>node: Fedor Indutny master * r44e7033 / (src/node.cc src/node_vars.h): fixed debugger segfaults - http://git.io/11velw
01:30:37  <CIA-115>node: Fedor Indutny master * r99679c6 / (5 files in 2 dirs): IsolateDebugger C++ - http://git.io/pFnUzw
01:30:37  <CIA-115>node: Fedor Indutny master * r6b2091b / (lib/_debugger.js lib/child_process.js): debug threads - http://git.io/3W2b3Q
01:32:14  * dap1quit (Quit: Leaving.)
01:32:25  * sh1mmerquit (Quit: sh1mmer)
01:43:19  * travis-cijoined
01:43:19  <travis-ci>[travis-ci] joyent/node#213 (master - 6b2091b : Fedor Indutny): The build is still failing.
01:43:19  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/97e4b3a...6b2091b
01:43:19  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/499994
01:43:19  * travis-cipart
01:49:54  * mikealquit (Quit: Leaving.)
01:52:53  * dshaw_quit (Ping timeout: 252 seconds)
01:56:21  * mikealjoined
02:02:24  * mikealquit (Quit: Leaving.)
02:13:33  <ryah>bnoordhuis: thanks
02:13:41  <ryah>mmalecki: probably wont happen today
02:13:53  <ryah>mmalecki: why you interested btw?
02:16:01  * mikealjoined
02:23:16  * pieternquit (Quit: pietern)
02:25:35  * sh1mmerjoined
02:39:19  * mikealquit (Quit: Leaving.)
02:40:10  * sh1mmerquit (Quit: sh1mmer)
02:49:22  * brsonquit (Quit: leaving)
02:52:20  * isaacsquit (Quit: isaacs)
02:53:41  * isaacsjoined
02:54:27  * bnoordhuisquit (Read error: Operation timed out)
02:59:41  <TooTallNate>how come uv_run_once() uses EVRUN_NOWAIT instead of EVRUN_ONCE?
02:59:48  * TooTallNatehas no idea what the differences are
03:03:17  * isaacsquit (Quit: isaacs)
03:54:12  * dshaw_joined
03:55:24  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
04:19:54  * sh1mmerjoined
04:31:04  * sh1mmerquit (Quit: sh1mmer)
04:38:11  * mikealjoined
04:40:29  * mikealquit (Client Quit)
04:43:46  <indutny>morning everyone
05:00:05  * mikealjoined
05:24:44  * sh1mmerjoined
05:37:48  * mikealquit (Quit: Leaving.)
05:48:26  * mikealjoined
05:49:22  * mikealquit (Client Quit)
05:55:03  * mjr_joined
06:18:35  * perezdquit (Quit: perezd)
06:33:40  * slaskisjoined
07:01:41  * paddybyersjoined
07:13:32  * mikealjoined
07:24:13  * mjr_quit (Quit: mjr_)
07:28:22  * kuebkjoined
07:44:34  * kuebk1joined
07:48:51  * kuebkquit (Ping timeout: 276 seconds)
07:50:45  * kuebk1quit (Ping timeout: 252 seconds)
07:52:55  * kuebkjoined
07:59:21  * slaskisquit (Quit: slaskis)
08:03:49  * vodotikigodquit (Ping timeout: 240 seconds)
08:35:47  <mmalecki>ryah: I wanted to deploy node v0.7 to nodejs workers on Travis so that people can start testing their stuff out
08:36:27  <mmalecki>but anyway, I'll wait :)
08:36:30  <mmalecki>indutny: hi!
08:36:49  <mmalecki>damn, I have to to school. ttyl
08:37:31  <indutny>mmalecki: hi!
08:44:04  * mikealquit (Quit: Leaving.)
08:50:02  * slaskisjoined
09:03:45  * voodootikigod_joined
09:28:47  * ErikCorryV8joined
09:35:38  * mikealjoined
12:00:46  <mrb_bk>good morning
12:07:11  <ErikCorryV8>The 3.6 string hash seeding backport landed.
12:07:38  <ErikCorryV8>It was modified a little in review, so it does not correspond exactly to the version that went out in V8.
12:08:11  <ErikCorryV8>The main thing is that it got 10362 merged back from bleeding edge too.
12:08:56  <ErikCorryV8>argh, I forgot to update version.cc :-(
12:14:45  <ErikCorryV8>Fedor is putting the finishing touches to the numeric hash seeding patch. That will need to be back ported too if it sticks.
12:25:19  * piscisaureus_joined
13:11:42  <indutny>release?
13:11:44  <indutny>0.7.0
13:15:18  <indutny>piscisaureus_: https://github.com/v8/v8/commit/2ee154a5b3d09b7ed0a17a108aec40a2174acee0
13:18:13  <ErikCorryV8>Now someone just needs to back port...
13:18:18  <ErikCorryV8>To 3.6
14:03:55  * bnoordhuisjoined
14:12:14  <indutny>what's blocking release?
14:12:17  <indutny>bnoordhuis: ^
14:15:19  * benviejoined
14:18:29  * kuebkpart
14:19:30  * voodootikigod_changed nick to voodootikigod
14:26:37  <bnoordhuis>indutny: i think it's the potential fix for a segfault in the slab allocator that's being tested by the voxer guys
14:26:52  * voodootikigodquit (Quit: Write failed: Broken pipe)
14:27:49  <indutny>bnoordhuis: aah
14:27:52  <indutny>I seen it
14:34:37  <indutny>bnoordhuis: haven't we fixed problem with uv_ref and process.stdin?
14:35:01  <indutny>bnoordhuis: looks like it's refed by default
14:35:09  <indutny>bnoordhuis: and unrefed only on .pause method
14:35:38  <bnoordhuis>indutny: uhm, probably
14:35:58  <indutny>bnoordhuis: that's wrong
14:40:06  * mrb_bkquit (Ping timeout: 240 seconds)
14:42:40  * Casanjoined
14:49:04  * mrb_bkjoined
14:50:35  <indutny>bnoordhuis: https://github.com/joyent/node/pull/2500
14:50:53  <indutny>bnoordhuis: read tty stream should not ref by default
14:51:10  <bnoordhuis>indutny: maybe not but does it pass all tests?
14:51:44  <indutny>bnoordhuis: lets see
14:54:54  <indutny>bnoordhuis: yes
14:55:05  <indutny>bnoordhuis: btw, looks like debugger-repl test needs to be fixed
14:58:15  <indutny>bnoordhuis: https://github.com/joyent/node/pull/2501
14:59:38  <bnoordhuis>indutny: can you prefix your commit logs with 'foo:' instead of '[foo]'? `git am` strips off the latter
15:00:19  <indutny>bnoordhuis: ok
15:00:22  <indutny>bnoordhuis: next time
15:01:49  * mjr_joined
15:04:00  * indutnytopic: welcome to the void
15:04:19  <indutny>bnoordhuis: but initializing tty's readstream is referncing loop
15:04:34  <indutny>bnoordhuis: that should be a fix for v0.6 too
15:04:45  <bnoordhuis>indutny: i don't know
15:05:28  <bnoordhuis>calling process.stdin.pause() fixes it
15:06:25  <indutny>bnoordhuis: yes
15:06:52  <indutny>bnoordhuis: so you propose calling .pause instead of directly unrefing?
15:07:19  <bnoordhuis>yes
15:07:40  <bnoordhuis>unref'ing the stdin handle unconditionally means that process.stdin.on('foo', ...) stops working
15:07:42  <indutny>bnoordhuis: I think there was .pause some time ago
15:08:02  <indutny>bnoordhuis: I don't understand
15:08:07  <indutny>bnoordhuis: .pause will do same thing
15:08:12  <indutny>aaah
15:08:13  <indutny>got it
15:11:19  <indutny>bnoordhuis: is that better ? https://github.com/joyent/node/pull/2500/files
15:12:12  <bnoordhuis>indutny: i don't think this is something that needs fixing
15:12:28  <indutny>bnoordhuis: really? say that to every cli script
15:12:37  <bnoordhuis>if you use process.stdin, you should be aware that it refs the event loop and that you need to .pause() it if you're done with it
15:12:48  <indutny>bnoordhuis: you don't understand
15:13:06  <bnoordhuis>i think i understand, i just don't see the problem
15:13:07  <indutny>bnoordhuis: if I just invoke process.stdin getter, loop will never finish
15:13:31  <indutny>bnoordhuis: I'm not calling anything, neither doing anything indirectly
15:13:47  <indutny>bnoordhuis: just put 'process.stdin;' line in any cli script and it won't exit
15:13:51  * mjr_quit (Quit: mjr_)
15:14:06  <bnoordhuis>i know that, read my comment above
15:14:42  <indutny>bnoordhuis: problem? unobvious behaviour? API inconsistency?
15:14:52  <indutny>this is really obscure problem
15:15:16  <indutny>and many people will spend hours finding what causes their scripts to not exit
15:15:43  <indutny>bnoordhuis: so I think if want to leave it as it is
15:15:51  <indutny>bnoordhuis: we should init process.stdin by default
15:20:37  <indutny>bnoordhuis: I don't understand why referencing is good
15:20:50  <indutny>bnoordhuis: while fix won't hurt performance impact
15:20:58  <indutny>bnoordhuis: and will save API compatibility
15:22:13  <bnoordhuis>well... maybe
15:22:20  <bnoordhuis>since you need to call .resume() anyway
15:23:02  <bnoordhuis>the thing is, i know it was discussed a while ago and there was a reason to do it like this
15:23:29  <indutny>bnoordhuis: lets find a commit
15:24:08  <bnoordhuis>indutny: cf20b6bf65bd037193d6e8b1b671c4659897861f
15:25:32  <indutny>bnoordhuis: ok, so if I'll call resume on it loop will be refed two times instead of one?
15:26:14  <indutny>bnoordhuis: and probably I'm missing point, but it looks like isaacs just forgot to .pause it
15:26:55  <bnoordhuis>indutny: ask isaacs when he's online
15:27:37  <indutny>k
15:27:56  <bnoordhuis>indutny: is there a better way to do #2501?
15:28:19  * pieternjoined
15:28:20  <bnoordhuis>i mean without doing a `if (process.features.isolates)` branch?
15:32:13  <indutny>bnoordhuis: nope
15:32:18  <indutny>bnoordhuis: debugger has different outputs
15:33:29  <mmalecki>so, hey. can we stop nerdfighting in https://github.com/joyent/node/pull/2454 and actually try coming up with some API?
15:36:41  <mmalecki>please?
15:37:27  <mmalecki>I'd propose spawn(..., { ipc: true }) for just spawning a process with IPC channel and `fork` which could do rocket science with isolates and whatever.
15:37:41  <mmalecki>pretty similar to what indexzero proposed.
15:39:53  <mmalecki>anyone has any opinion on that?
15:43:19  <mmalecki>I see :/
15:47:36  <CIA-115>node: Ben Noordhuis master * r7cee968 / (src/node_isolate.cc src/node_isolate.h): isolates: add process-global list of isolates - http://git.io/sgAm9w
15:48:40  <indutny>bnoordhuis: what about socket sharing between isolates?
15:48:46  <indutny>bnoordhuis: do we have it?
15:49:06  <indutny>bnoordhuis: I mean fd sharing, actually
15:49:21  <bnoordhuis>indutny: not yet
15:49:30  <indutny>bnoordhuis: k, just curious
15:50:32  <CIA-115>node: Fedor Indutny master * r4cbcdb4 / (2 files): test: make debugger-repl tests work with isolates - http://git.io/4V4fuQ
15:51:07  <bnoordhuis>Program terminated with signal 11, Segmentation fault.
15:51:07  <bnoordhuis>#0 0x0000000000943f3b in v8::internal::CallIC_Miss(v8::internal::Arguments, v8::internal::Isolate*) () <- not good
15:51:18  * isaacsjoined
15:51:26  <isaacs>indutny: what's up?
15:52:35  <indutny>isaacs: cf20b6bf65bd037193d6e8b1b671c4659897861f
15:52:37  <indutny>hi
15:52:48  <indutny>https://github.com/joyent/node/commits/cf20b6bf65bd037193d6e8b1b671c4659897861f
15:53:00  <indutny>oops, wrong url
15:53:01  <indutny>https://github.com/joyent/node/commit/cf20b6bf65bd037193d6e8b1b671c4659897861f
15:53:43  <indutny>isaacs: we was discussing with bnoordhuis a behaviour of process.stdin
15:54:12  <bnoordhuis>^ indutny talks so street
15:54:22  <indutny>isaacs: is that was made with some purpose? ./node -e 'process.stdin' <- will never exit
15:54:34  <indutny>bnoordhuis: :)
15:54:39  <indutny>bnoordhuis: just adding context to my words
15:55:27  <mmalecki>can I have some feedback for https://github.com/joyent/node/pull/2454#issuecomment-3431711 ?
15:55:29  <isaacs>indutny: i don't love having process.stdin be a getter.
15:55:31  <indutny>isaacs: I thought process.stdin should be paused immediately after creation, and your commit was intended to fix that problem
15:55:50  <indutny>isaacs: that's another question
15:55:54  <indutny>isaacs: and problem
15:56:07  <indutny>isaacs: but should we unref it by default?
15:56:20  <indutny>isaacs: is that what your commit was intended to fix?
15:56:25  <isaacs>indutny: the problem was that there was no way to close it except to completely destroy it.
15:56:35  <isaacs>which meant it couldn't be read from again
15:56:50  <isaacs>so, .resume() has to ref it, and .pause() has to unref it
15:56:56  <indutny>isaacs: ah, so you're ok with process.stdin blocking process
15:57:03  <indutny>and breaking backwards compatibility
15:57:09  <isaacs>but, the real question is, should the process.stdin be a getter that calls process.openStdin()
15:57:28  <indutny>isaacs: if not - what should it be?
15:57:35  <isaacs>or should you have to call process.stdin.resume() once to "open" it
15:57:43  <isaacs>which is how it was pre-0.4
15:57:58  <indutny>isaacs: yes, that's it
15:58:17  <indutny>isaacs: I think previous semantics were better
15:58:39  <isaacs>really, this change you reference is a step towards the 0.4 semantics. i think we're mostly in agreement here about how it should be.
15:58:44  <isaacs>but, here's the rub:
15:58:54  <isaacs>people do `process.stdin.on("data", blah blah blah)`, right?
15:59:00  <indutny>right
15:59:04  <isaacs>and they expect that to work
15:59:10  <indutny>and it'll work
15:59:14  <indutny>if they'll resume stream
15:59:22  <indutny>it should be paused by default
15:59:40  <indutny>if you won't call function to receive data from stdin in C++
15:59:48  <indutny>app will just exit
15:59:53  * travis-cijoined
15:59:54  <travis-ci>[travis-ci] joyent/node#214 (master - 7cee968 : Ben Noordhuis): The build is still failing.
15:59:54  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/6b2091b...7cee968
15:59:54  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/502558
15:59:54  * travis-cipart
16:00:00  <indutny>so you need to explicitly read it
16:00:02  <isaacs>well… we could magic up the .on function on the stdin stream
16:00:09  <isaacs>i'd rather do that than have a magic getter
16:00:27  <indutny>getter is a voodoo magic now, agreed
16:00:28  * pieternquit (Ping timeout: 255 seconds)
16:00:47  <indutny>but I think explicit process.stdin.resume() is good
16:00:57  <isaacs>what i'd like to maybe do is if you call on("data") or on("end"), it'll resume it.
16:00:58  <indutny>it's like fgets
16:01:10  <indutny>isaacs: that's obscure
16:01:12  <isaacs>yeah, but really, the metaphor should be to ruby and python here, i think, not to C
16:01:23  <indutny>isaacs: and how do they do that?
16:01:35  <indutny>isaacs: they're both blocking (by default)
16:01:36  <isaacs>i'm not sure, exactly. not with nonblocking io ;)
16:01:45  <indutny>isaacs: yes, that's the case
16:01:47  * pieternjoined
16:01:49  <bnoordhuis>isaacs: i don't think process.stdin.on('data', ...) works right now, you have to .resume() it first
16:02:06  <indutny>even better! :)
16:02:32  <isaacs>bnoordhuis: i thought it opened automatically when you reference it
16:02:41  * travis-cijoined
16:02:41  <travis-ci>[travis-ci] joyent/node#215 (master - 4cbcdb4 : Fedor Indutny): The build is still failing.
16:02:41  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/7cee968...4cbcdb4
16:02:41  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/502579
16:02:41  * travis-cipart
16:02:58  <bnoordhuis>isaacs: try this: node -e 'process.stdin.on("data", console.error)'
16:03:04  <bnoordhuis>vs. node -e 'process.stdin.resume(); process.stdin.on("data", console.error)'
16:03:17  <isaacs>oh, right
16:03:22  <isaacs>ok, that's a bug, then
16:03:33  <isaacs>we should probably not ref on the getter
16:03:41  <indutny>yes!!!
16:03:42  <indutny>:D
16:04:02  <isaacs>and instead only ref on resume, and then decide explicitly where and if we want to automatically call .resume() to make users not surprised.
16:04:07  <mmalecki>will isolates share a global context or module cache?
16:04:15  <bnoordhuis>mmalecki: no
16:04:39  <indutny>mmalecki: they're isolates, they're isolates from each other (mostly)
16:05:08  <mmalecki>indutny: and fork is called fork, but it isn't fork at all :). wanted to make sure.
16:05:09  <indutny>mmalecki: and supposed to contact each other only through messaging channel
16:05:16  <indutny>mmalecki: hahaha :)
16:05:18  <indutny>righto
16:06:13  <paddybyers>bnoordhuis: a quick (probably dumb) question:
16:06:31  <paddybyers>why is minizip in the tree, but nothing uses it?
16:06:42  <bnoordhuis>paddybyers: because it's part of zlib
16:07:05  <paddybyers>there's no plan for a js binding for it?
16:07:29  <bnoordhuis>paddybyers: no. but i could imagine taking a patch for that
16:08:10  <paddybyers>ok I did a quick port of https://github.com/springmeyer/node-zipfile to use minizip instead
16:08:13  <bnoordhuis>the problem is... give the unwashed masses a zip binding and they'll start clamoring for tar support, bzip2, etc
16:08:43  <paddybyers>of course
16:08:54  <isaacs>i'm not sure that zip qualifies as a core internet protocol.
16:08:58  <isaacs>gzip? absolutely.
16:09:14  <isaacs>you cannot reasonably run a web server or client in an optimum way on the modern internet without gzip.
16:09:20  <bnoordhuis>i kind of agree with that
16:09:22  <isaacs>but zip? meh.
16:09:29  <bnoordhuis>and there are already good zip modules out there
16:09:54  <isaacs>node is not about providing a binding to every library it bundles. there are huge bits of openssl that we don't expose, either.
16:10:07  <paddybyers>bnoordhuis: only ones that spawn zip, or use zip.h, and I've got neither on Android
16:10:21  <indutny>bnoordhuis: btw, are we build openssl with zlib?
16:10:34  <isaacs>bnoordhuis: yeah, i dont' think there are many good zip modules out there.
16:10:41  <paddybyers>it's ok, it's fine to keep it as a separate addon
16:10:44  <isaacs>paddybyers: kriszyp's module just does it in js
16:10:54  <bnoordhuis>^ that's the one i mean
16:11:03  <bnoordhuis>indutny: yes
16:11:04  <isaacs>bnoordhuis: but it's not fast.
16:11:09  <isaacs>(last i checked)
16:11:31  <bnoordhuis>it's a good incentive for the v8 guys to get off their backs
16:11:46  <mmalecki>isaacs: what do you think? https://github.com/joyent/node/pull/2454#issuecomment-3431711
16:12:53  * bnoordhuisis off to dinner
16:13:40  <paddybyers>https://github.com/paddybyers/node-zipfile/tree/master-minizip if anyone's interested
16:13:56  <isaacs>mmalecki: i think this is probably not going to change.
16:14:17  <mmalecki>isaacs: why?
16:14:29  <isaacs>mmalecki: because that adds complexity to the api unnecessarily.
16:14:32  <pquerna>minizip is pretty easy to embed and such. use it in our lua stuff.
16:14:55  <mmalecki>isaacs: no, it actually reduces complexity - things become more generice
16:14:59  <mmalecki>*generic
16:15:29  <isaacs>mmalecki: it adds an option, for the ostensible purpose of making fork() able to run non-javascript programs
16:15:43  <isaacs>mmalecki: generic does not always mean lower complexity.
16:15:51  <isaacs>orthogonal concerns.
16:16:54  <mmalecki>isaacs: I don't want changes to fork(), I want spawn to support ipc
16:17:33  <isaacs>mmalecki: then that's even more complexity added, becasue now we are exposing something that we explicitly want to be able to change in the near future.
16:17:38  <isaacs>exposing an api locks it in place.
16:17:59  <mmalecki>isaacs: hm, you want to change spawn API?
16:18:11  <isaacs>mmalecki: not the api, no, but the implementation.
16:18:30  <isaacs>if we expose the ipc functionality like your'e suggesting, then we're locked into a specific set of semantics that we're still experimenting with.
16:18:33  <mmalecki>isaacs: you want spawn to be able to spawn node processes only?
16:18:36  <isaacs>because then it becomes api
16:18:51  <isaacs>mmalecki: i want a way to say "Run another node program and set up a communication channel with it".
16:19:04  <mmalecki>isaacs: so do I.
16:19:14  <mmalecki>isaacs: I just want it to be configurable.
16:19:17  <isaacs>if you want that program to be a coffee-script loader, then write "require("coffee-script"); require(process.argv[2])" in app.js, and do fork("app.js foo.coffee")
16:19:40  <isaacs>"configurable" == "more complicated"
16:19:44  <isaacs>in almost every case.
16:20:23  <mmalecki>isaacs: making things easier for userland is good.
16:20:36  <isaacs>i fail to see how this is making things much harder for userland.
16:20:46  <mmalecki>isaacs: if you disagree, please remove http module. it can be implemented with net module.
16:20:54  <isaacs>"use javascript with child_process.fork()" is not the end of the world.
16:20:57  <isaacs>it takes 2 lines to work around it.
16:21:10  <isaacs>mmalecki: that's a reduction to absurdity. there is a line, you know that.
16:21:20  * dshaw_quit (Quit: Leaving.)
16:21:20  <mmalecki>isaacs: "workaround" is the keyword here.
16:21:31  <isaacs>mmalecki: it's not a use case that fork() is designed to address.
16:21:43  <mmalecki>isaacs: but spawn is
16:21:49  <isaacs>mmalecki: ok
16:23:20  <isaacs>so use spawn :)
16:23:27  <isaacs>communicate over stdio
16:23:48  <mmalecki>isaacs: so reimplement core functionality?
16:24:05  <isaacs>mmalecki: no, you're talking about implementing *different* functionality. that's the whole point.
16:24:31  <isaacs>but i mean, we could have the same conversation about chroot, or memmap, or a bunch of other things.
16:25:24  <mmalecki>isaacs: I just want core API to not suck.
16:25:34  <isaacs>mmalecki: what yoer' talking about is making the core api bigger.
16:25:44  <mmalecki>I'm not even asking for a new API, really. I'm asking for making old API more generic.
16:26:08  <mmalecki>isaacs: ok, so can we do that if it doesn't add any code?
16:26:09  <isaacs>…by adding a new option to it
16:26:25  <isaacs>mmalecki: "doesn't add any code"?
16:26:37  <mmalecki>lines added - lines removed < 0
16:26:41  <isaacs>mmalecki: oh, no.
16:26:50  <isaacs>we can do it if it doesn't change the api at all.
16:26:57  <isaacs>;)
16:27:24  <mmalecki>isaacs: is that a way of saying 'fuck you, go and reimplement it?'
16:27:29  <isaacs>we have to be very careful about changing the api surface.
16:27:35  <isaacs>minus the "fuck you, "
16:28:35  <isaacs>mmalecki: in my opinion, adding .fork() in the first place was extremely regrettable. however, the spawn() api is not suitable for running isolates, and there was a lot of call for that.
16:28:50  * slaskisquit (Quit: slaskis)
16:28:52  <isaacs>mmalecki: but why can't you just spawn() a process, and send json over stdio now?
16:29:04  <isaacs>i mean, you don't even have to write any C++ to make this happen.
16:29:55  <indutny>bnoordhuis: openssl is building w/o zlib
16:30:04  <mmalecki>isaacs: I'm going to. but I'd have to set some fd's to non-blocking mode, no?
16:30:07  <indutny>bnoordhuis: just added random stuff to zlib compressor's file
16:30:11  <isaacs>or you could just say that forever doens't support coffeescript, and tell people to speak through a js file.
16:30:12  <indutny>bnoordhuis: compiler never gets in
16:30:34  <isaacs>mmalecki: and they could write the two-line js loader shim themselves.
16:30:40  <isaacs>mmalecki: or they can compile their cs to js
16:30:53  <isaacs>mmalecki: it's not as if there aren't already easy ways around the alleged problem here.
16:30:54  <mmalecki>isaacs: we have to be careful with changing the api surface.
16:31:16  <isaacs>mmalecki: there are far more people using node than using forever.
16:32:09  <mmalecki>isaacs: just messing with you :)
16:32:30  <isaacs>i don't want to dull your enthusiasm.
16:32:59  <isaacs>but we have to stay focused.
16:33:09  <mmalecki>isaacs: this issue doesn't make me enthustiastic about contributing to core at all, unfortunately
16:33:26  <isaacs>mmalecki: i think it would help to make the roadmap more public.
16:33:27  <isaacs>working on that.
16:33:31  <mmalecki>but well, I have a war to win!
16:34:05  <isaacs>"you can do that in 2 lines of JS" is a very compelling argument to say "no" to any proposed api change.
16:34:52  <isaacs>in fact, in forever, you can even choose to add some shim yourself that does this.
16:35:07  <isaacs>and your users can see the same surface as if you got your core proposal.
16:35:23  <mmalecki>isaacs: I'm going to reimplement fork in more generic way.
16:35:32  <isaacs>that sounds like more work than necessary.
16:35:44  <isaacs>and it sounds like unnecessarily adding a compilation step to your module.
16:35:46  <mmalecki>isaacs: that sounds generic :)
16:36:06  <isaacs>unnecessary compilation is like unnecessary surgery.
16:36:58  <isaacs>why not just detect coffeescript and add a js shim for that?
16:37:01  <isaacs>or tell your users to?
16:37:12  <mmalecki>isaacs: I only need it for setting fds to non-blocking mode, no?
16:39:22  <mmalecki>anyway, is 0.7 release expected to happen today?
16:40:35  <isaacs>mmalecki: oh, actually, it looks like fork is all-js anyway
16:40:57  <piscisaureus_>indutny++ (re number hash fix)
16:40:58  <kohai>indutny has 2 beers
16:41:39  <indutny>piscisaureus_: that was easy, you and ErikCorryV8 done most of job
16:41:40  <isaacs>mmalecki: yeah, i haven't looked at this in a while. looks like all the c++ bits moved to libuv.
16:41:47  <isaacs>mmalecki: what node has is just js
16:41:55  <piscisaureus_>ok ErikCorryV8++ then :-)
16:42:03  <isaacs>mmalecki: but, 100 lines of js vs a 2 line shim? i think the simpler path is obvious.
16:42:32  <mmalecki>isaacs: no, we also need stdout and stderr
16:42:36  <indutny>piscisaureus_: :)
16:42:44  <isaacs>mmalecki: you'd get that with a js shim
16:42:58  <isaacs>mmalecki: you fork to a js file that require()s the coffee-script file.
16:43:11  <mmalecki>isaacs: hm, no? fork has no .stdout or .stderr.
16:43:15  <indutny>piscisaureus_: have you worked with openssl compression?
16:43:20  <isaacs>mmalecki: oh, i see.
16:43:22  <indutny>piscisaureus_: how may I choose one?
16:43:28  <isaacs>you need stdout and stderr to not be shared with the parent?
16:43:52  <mmalecki>isaacs: yes. and to be actually accessible.
16:43:57  <isaacs>mmalecki: same thing
16:43:57  <mmalecki>we have logging based on that
16:44:23  <isaacs>mmalecki: ok, so what you really want then, is a spawn() that lets you do logging through a fd=4 channel?
16:44:35  * AndreasMadsenjoined
16:44:36  <isaacs>er, 3
16:45:06  * ErikCorryV8quit (Ping timeout: 258 seconds)
16:45:37  <mmalecki>isaacs: and fd=3 is? what I really want spawn which can pass messages around.
16:46:23  <isaacs>mmalecki: check out the createChannel function in lib/child_process.js
16:46:43  <isaacs>er, setupChannel function, i mean
16:47:04  <isaacs>you can also have the child process connect to a socket.
16:47:30  <mmalecki>isaacs: it's a private API, no?
16:47:50  <indutny>ryah: yt?
16:47:53  <isaacs>mmalecki: yeah. so you'll have to reimplement a lot of it.
16:48:02  <isaacs>mmalecki: but really, i think this is a bad path to head down.
16:48:07  <isaacs>i don't think you really need this thing you think you need.
16:48:19  <indutny>oh, not ryah
16:48:20  <indutny>sorry
16:49:05  <indutny>or not!
16:49:06  <indutny>ryah: https://github.com/joyent/node/commit/e83c6959
16:49:12  <indutny>defend! :)
16:49:33  <indutny>bnoordhuis: probably you can help too https://github.com/joyent/node/commit/e83c6959
16:49:45  <mmalecki>isaacs: I'm intelligent enough to know what me and my users need.
16:50:19  <isaacs>mmalecki: if it only took intelligence, i'd agree with you.
16:50:24  <isaacs>mmalecki: but that's not the point.
16:50:33  <isaacs>or rather, that's a much more general point.
16:50:58  <piscisaureus_>indutny: ryah's defense: http://journal.paul.querna.org/articles/2011/04/05/openssl-memory-use/
16:51:52  <mmalecki>isaacs: right, experience and stuff. whatever, I will implement it anyway.
16:52:04  <isaacs>k
16:52:32  <isaacs>i think you've fully asked 2 why's. you need 3 more.
16:52:54  <indutny>piscisaureus_: do we have latest openssl?
16:53:11  <piscisaureus_>indutny: I think by the time we were using system openssl
16:53:16  <indutny>piscisaureus_: I can't grep SSL_OP_NO_COMPRESSION
16:53:18  <indutny>piscisaureus_: nope
16:53:27  <indutny>piscisaureus_: ah, by the time of article?
16:53:36  <piscisaureus_>indutny: on master we has static openssl I think
16:53:45  <mmalecki>isaacs: sorry? I don't think I follow.
16:53:58  <piscisaureus_>indutny: that patch is almost a year ago :-)
16:54:18  <indutny>piscisaureus_: may be it's time to review it :)
16:54:35  <isaacs>mmalecki: http://en.wikipedia.org/wiki/5_Whys
16:55:10  <indutny>piscisaureus_: SSL_MODE_RELEASE_BUFFERS
16:55:29  <indutny>piscisaureus_: ah, that's not related
16:55:49  <indutny>piscisaureus_: well at least we can build openssl with zlib
16:56:05  <indutny>piscisaureus_: otherwise users won't be able to use it
16:56:24  <isaacs>in practice, sometimes it takes more than 5.
16:56:37  <isaacs>but 5 is a good number to shoot for, since most people stop at 1, and most smart people stop at 2 or 3
16:58:11  * dapjoined
16:58:35  <mmalecki>isaacs: I see. I don't think I have any question to ask now, tho.
16:59:04  <piscisaureus_>indutny: it is outside of my area of expertise. I think you should talk to rya
16:59:14  <piscisaureus_>... to ryah or pquerna about this
16:59:29  <mmalecki>isaacs: answer will be 'no' anyway. let's just stop waisting your time and go waste my time instead.
17:00:08  <indutny>ryah: pquerna: ping :)
17:01:51  <mmalecki>isaacs: it's not a car breakage or even a proper bug. it's your design problem. it's not that easy to diagnose because it happens in your mind.
17:02:59  <isaacs>mmalecki: ok
17:04:51  <indutny>piscisaureus_: ok, confirm memory leaking with compressors on is true on latest node too
17:04:56  <indutny>200 mb in 30 seconds
17:08:21  <indutny>piscisaureus_: oh, it's leaking memory even w/o compressors
17:09:59  * perezdjoined
17:09:59  * perezdquit (Excess Flood)
17:10:10  * paddybyerspart
17:10:29  * paddybyersjoined
17:12:29  <indutny>or my spdy server is leaking...
17:12:31  <indutny>hm...
17:26:04  * dshaw_joined
17:28:37  <indutny>isaacs: zlib is leaking
17:28:43  <isaacs>indutny: oh?
17:28:51  <indutny>isaacs: opening bug
17:28:58  <isaacs>can you reproduce?
17:29:05  <isaacs>and is it actually leaking, or just using a bunch of memory?
17:29:46  <piscisaureus_>indutny: In your test case you should check whether GCs are triggered
17:29:57  <indutny>piscisaureus_: isaacs https://github.com/joyent/node/issues/2504
17:30:10  <indutny>piscisaureus_: if I won't trigger it, node will crash in seconds
17:30:15  <indutny>piscisaureus_: because malloc will fial
17:30:18  <indutny>s/fial/fail
17:30:38  <isaacs>indutny: what do you expect from that?
17:30:51  <indutny>isaacs: to not leak memory :)
17:31:01  <piscisaureus_>indutny: well it leaks here
17:31:05  <piscisaureus_>although it takes a while to crash
17:31:10  <indutny>piscisaureus_: yes
17:31:13  <piscisaureus_>it's leaking about 20mb per second
17:31:14  <indutny>piscisaureus_: but that is a bug
17:31:24  <indutny>piscisaureus_: because streams are getting gc
17:31:41  <indutny>piscisaureus_: and using zlib is critical for spdy
17:31:51  <piscisaureus_>indutny: I think it could be due to the close() callback being deferred
17:32:01  <piscisaureus_>indutny: what if you run it in a nextTick loop?
17:32:15  <indutny>piscisaureus_: one sec
17:32:58  <piscisaureus_>indutny oh wait
17:33:04  <piscisaureus_>indutny: you are never releasing the stream :-/
17:33:13  <indutny>piscisaureus_: how should I do that?
17:33:43  <piscisaureus_>indutny: stream.end / destroy ?!
17:33:47  <isaacs>piscisaureus_: setting p to some new value should release it
17:34:02  <isaacs>piscisaureus_: it should get cleaned up if the reference is gc'ed
17:34:03  <indutny>piscisaureus_: I'll do destroy
17:34:09  <indutny>piscisaureus_: but actually nextTick trick helps
17:35:47  <piscisaureus_>indutny: well it actually still leaks for me but much slower
17:35:53  <indutny>piscisaureus_: yes
17:35:55  <indutny>much slower
17:36:32  * Casanquit (Quit: Leaving)
17:36:51  <isaacs>indutny: no .destroy() on zlib streams
17:36:57  <isaacs>indutny: it's all handled in .end()
17:37:25  <indutny>isaacs: nothing is really handled here :)
17:37:38  <indutny>but looks like this is not an issue that I'm experiencing with node-spdy
17:37:44  <indutny>something else is leakig
17:37:50  <indutny>s/leakig/leaking
17:37:50  <isaacs>gotta run to a meeting. i'll investigate in a bit.
17:38:02  <indutny>isaacs: k thank you
17:38:05  * isaacsquit (Quit: isaacs)
17:41:38  <piscisaureus_>node_zlib.cc has some style issues
17:43:10  <indutny>piscisaureus_: yes, but that's not an issue
17:43:48  <piscisaureus_>indutny: I wonder how we ensure that the ZCtx object is not cleaned up before the thread pool action returns
17:44:00  <indutny>piscisaureus_: ooh
17:44:09  <indutny>piscisaureus_: that applies for many other things too
17:44:15  <piscisaureus_>it looks like some bits are missing here
17:44:22  <piscisaureus_>no
17:44:36  <piscisaureus_>indutny: libuv usually takes care of that
17:44:45  <piscisaureus_>indutny: and libuv streams are not affected by GC anyway
17:46:30  <ryah>hello
17:46:34  <indutny>ryah: hi!
17:48:16  <piscisaureus_>aaaah
17:48:19  <ryah>indutny: how's the numeric hash key thing going?
17:48:20  <piscisaureus_>indutny: gotcha
17:48:32  <piscisaureus_>indutny: we are leaking uv_work_t objects
17:48:41  <indutny>piscisaureus_: where?
17:48:52  * TooTallNatejoined
17:49:07  <piscisaureus_>indutny: WorkReqWrap and uv_work_t objects are allocated in Write
17:49:17  <indutny>piscisaureus_: ah
17:49:19  <piscisaureus_>indutny: but only the WorkReqWrap object is freed in After()
17:49:26  <piscisaureus_>indutny: but this is also no-good style
17:49:32  <indutny>piscisaureus_: I'm encountering strange issue
17:49:36  <indutny>piscisaureus_: running a tls server
17:49:39  <piscisaureus_>indutny: the uv_work_t should be embedded in the WorkReqWrap
17:49:46  <indutny>piscisaureus_: and it's leaking on connections
17:50:22  <indutny>piscisaureus_: oh, it's getting to 90mb limit and then lowering
17:50:27  <indutny>ah, nope
17:50:28  <indutny>99mb
17:51:48  <indutny>brb
17:53:03  * isaacsjoined
17:54:49  <piscisaureus_>indutny: this should probably do it: https://gist.github.com/1590237
17:55:16  * isaacsquit (Client Quit)
17:55:28  * isaacsjoined
17:55:31  <indutny>piscisaureus_: one second
17:55:33  <indutny>I'll test it
17:55:45  <piscisaureus_>indutny: I think it can be made better, since we never do more than one write request at a time I guess we could just embed the uv_work_t inside the ZCtx object and we would not have to malloc at all
17:56:35  <indutny>let me test it first
17:57:47  <indutny>sorry gtg
17:57:51  <indutny>be back in 20 minutes
17:59:40  * dshaw_quit (Quit: Leaving.)
17:59:49  <piscisaureus_>@jasonh: @twericb @joyent @basho @voxer @nodejs makes the old initial days of twitter look like a little speed bump
18:00:01  <piscisaureus_>what does Jason mean with that?
18:00:41  * dshaw_joined
18:02:45  <bnoordhuis>indutny: you mean deflate compression of tls streams? that's disabled
18:02:53  <bnoordhuis>but i think piscisaureus_ already pointed out why
18:08:24  <isaacs>piscisaureus_: twitter was first hosted at joyent
18:08:39  <indutny>bnoordhuis: yes
18:08:43  <isaacs>piscisaureus_: and they did a lot of performance analysis with them.
18:08:47  <indutny>bnoordhuis: piscisaureus_ pointed it out for me
18:08:50  <indutny>bnoordhuis: sorry for bothering
18:09:04  <isaacs>piscisaureus_: voxer is blowing up way more than twitter was then, and using much faster technology, and we have much better introspection into it now.
18:09:11  <rmustacc>And they mostly ignored it...
18:09:13  <piscisaureus_>isaacs: ah that explains, thnx
18:09:23  <piscisaureus_>isaacs: so another question
18:09:27  <rmustacc>protip: Don't throw and catch an exception one stack frame away when you have 500 frame stacks.
18:09:42  <bnoordhuis>indutny: np
18:09:52  <piscisaureus_>isaacs: how are we making sure in node_zlib that the ZLib context is not being GCed before the thread pool is done
18:10:06  <isaacs>piscisaureus_: lemme take a look at that.
18:10:11  * `3rdEdenjoined
18:10:29  <indutny>rmustacc: protip: throw primitives in such cases :)
18:11:27  <rmustacc>That's what the twitter folks were doing and that's what was causing horrible latency.
18:11:53  <isaacs>rmustacc: you sure? because i heard that solaris was to blame.
18:12:06  * brsonjoined
18:12:46  <isaacs>rmustacc: after all, they didn't see those problems on linux.
18:13:14  <rmustacc>isaacs: Oh right, my mistake. We are talking about slowlaris.
18:17:48  <isaacs>piscisaureus_: it looks like the ReqWrap object has a reference to ctx, and its object gets passed to the js layer.
18:17:55  <isaacs>piscisaureus_: i'm not sure when it gets gc'ed.
18:22:29  <isaacs>piscisaureus_: doesn't ReqWrap clean up its stuff when it gc's the ->object_ handle?
18:22:55  <piscisaureus_>isaacs: ReqWrap doesn't do anything magically
18:23:04  * bradleymeckjoined
18:23:18  <isaacs> ~ReqWrap() {
18:23:18  <isaacs> // Assert that someone has called Dispatched()
18:23:18  <isaacs> assert(req_.data == this);
18:23:18  <isaacs> assert(!object_.IsEmpty());
18:23:19  <isaacs> object_.Dispose();
18:23:19  <isaacs> object_.Clear();
18:23:19  <isaacs> }
18:23:33  <piscisaureus_>isaacs: hmm oh wait like that
18:23:54  <bradleymeck>anyone know if there is anything to look out for when using DLL injection and LD_PRELOAD in libuv?
18:23:57  <isaacs>oh, i guess that's the other way around
18:24:00  <indutny>isaacs: I'm often .flush() my zlib streams, is that ok?
18:24:08  <isaacs>indutny: it's unnecessary and costly.
18:24:14  <piscisaureus_>isaacs: basically when someone destroys the ReqWrap from C++ then it makes the JS object GC-able
18:24:17  <isaacs>indutny: don't do it unless there is no question.
18:24:23  <isaacs>piscisaureus_: ok.
18:24:24  <indutny>isaacs: there's no other option
18:24:26  <isaacs>right
18:24:29  <isaacs>indutny: then do it.
18:24:39  <piscisaureus_>isaacs: also https://gist.github.com/1590237
18:24:46  <isaacs>indutny: it can dramatically reduce compression
18:25:11  <piscisaureus_>isaacs: basically you allocate both a ReqWrap and a uv_work_t but you free only the ReqWrap
18:25:16  <indutny>piscisaureus_: aaah, problem found!!!!!
18:25:25  <indutny>piscisaureus_: probably
18:25:28  <isaacs>ahhh
18:25:30  <isaacs>that makes sense.
18:25:37  * dapquit (Quit: Leaving.)
18:25:53  <piscisaureus_>isaacs: fortunately you don't need to allocate an uv_wrap_t at all, because ReqWrap<uv_work_t> has an embedded uv_work_t
18:25:57  <isaacs>and the ReqWrap is a WorkReqWrap anyway, right?
18:25:59  <isaacs>ok.
18:26:05  <isaacs>awesome. ok, you found the issue, then
18:26:11  <indutny>piscisaureus_: event-loop is very busy
18:26:28  <indutny>piscisaureus_: setInterval(fun(), 50) fires function once every 4-5 seconds
18:26:34  <isaacs>indutny: does that patch fix the issue you're seeing?
18:26:52  <indutny>isaacs: nope, and I'm not sure that zlib is related to my issue
18:26:56  <isaacs>indutny: the argument to setInterval/setTimeout is a minimum, not a maximum.
18:27:03  <indutny>isaacs: I understand
18:27:13  <indutny>isaacs: or probably not
18:27:26  <indutny>isaacs: so it may be moved inside event-loop queue?
18:27:39  <isaacs>indutny: setTimeout is, yes.
18:27:42  <indutny>ah
18:27:46  <indutny>so that's not issue then
18:27:46  <indutny>:D
18:27:52  <isaacs>setTimeout(fn, 0) can be called literally at any time in the future.
18:28:02  <isaacs>setTimeout(fn, 1000) will be called no sooner than 1 second in the future.
18:28:02  <isaacs>etc
18:28:18  <bnoordhuis>re setTimeout
18:28:20  <isaacs>most of the time, it's called very close to the specified timeout
18:28:35  <bnoordhuis>do we have conclusive benchmarks that timer lists are faster than standalone timer objects?
18:28:43  <indutny>isaacs: anyway process.nextTick is called with 4-5 seconds delay
18:28:47  <bnoordhuis>i'm not seeing much of a difference
18:28:48  <piscisaureus_>bnoordhuis: I have not
18:28:58  <isaacs>indutny: then that would mean that youer' doing a *lot* of stuff in that tick
18:29:12  <indutny>isaacs: or I'm doing a lot of ticks
18:29:17  <indutny>isaacs: and they're not well ordered
18:29:40  <isaacs>indutny: last i checked, nextTick is pushed into an array, and they're all run at the end of the current tick, before going to the event loop.
18:29:47  <piscisaureus_>bnoordhuis: Ryah is very much much in love with the timer linked list so you should talk to him about it.
18:30:00  <bnoordhuis>piscisaureus_: thanks, i will
18:30:05  <indutny>actually recursive process.nextTick should run every odd tick?
18:30:07  <indutny>isn't it?
18:30:14  <indutny>prob, not real tick
18:30:18  <piscisaureus_>no that's not how it works
18:30:24  <indutny>if there're many of them
18:30:33  <isaacs>piscisaureus_: that's changed?
18:30:43  <isaacs>piscisaureus_: when are nextTicks run?
18:30:55  <piscisaureus_>isaacs: from a Prepare or Check watcher
18:31:17  <isaacs>ohh. right, i remember, there was an issue with recursive nextTick'ing never letting go.
18:31:50  * isaacshasn't seen that code since 0.3 days or thereabouts
18:32:02  <piscisaureus_>the code is also a mess TBH
18:32:09  <indutny>:)
18:32:43  <bnoordhuis>it's also quite slow, it could be optimized a great deal
18:33:09  * mikealquit (Quit: Leaving.)
18:33:46  <indutny>still I'm trying to find what's leaking
18:33:54  <indutny>anyone knows methods?
18:34:37  <rmustacc>indutny: What platform are you on?
18:34:44  <indutny>rmustacc: osx
18:34:48  <indutny>dtrace
18:34:53  <indutny>how to use it?
18:35:00  <rmustacc>I probably wouldn't use it here.
18:35:07  <rmustacc>I was going to suggest using libumem and ::findleaks.
18:35:18  <rmustacc>But that's not on OS X.
18:35:40  <bnoordhuis>indutny: welcome to the force, fedor :)
18:35:59  <indutny>bnoordhuis: yahoo!! :)
18:36:14  <rmustacc>I think valgrind can do some of that stuff, but it's been years since I used it and it was never on anything meaningful.
18:36:42  <TooTallNate>does anyone know why "cflags" doesn't seem to work with gyp?
18:36:55  <ryah>dannycoates: any crashes?
18:36:55  <bnoordhuis>TooTallNate: because it's CFLAGS
18:37:15  <piscisaureus_>indutny: congrats :-)
18:37:56  <TooTallNate>bnoordhuis: idk i still don't see em on in the g++ command
18:37:57  <indutny>piscisaureus_: thanks
18:38:23  <bnoordhuis>TooTallNate: use CXXFLAGS for c++ code
18:39:27  <isaacs>piscisaureus_: that patch lgtm.
18:39:46  <TooTallNate>:\ it's just not working for me... "cxxflags", "CXXFLAGS"... seems like its broken in gyp or i'm going crazy
18:40:03  <ryah>dannycoates: oh shit you're getting techcrunched
18:40:06  <isaacs>https://gist.github.com/1590237
18:40:11  <ryah>http://techcrunch.com/2012/01/10/popular-like-voxer/
18:40:18  <dannycoates>ryah: no, but we haven't had any segfaults on other machines either since we fixed our code
18:40:36  <dannycoates>ryah: crunch cool :)
18:41:08  <ryah>dannycoates: please let me know when you are satisfied that the bug is fixed
18:41:24  <TooTallNate>indutny: congrats!
18:41:29  <piscisaureus_>isaacs: but I still like to know how we make sure a ZCtx object is not garbage collected before the uv_work_t finishes in the thread pool
18:41:36  <indutny>TooTallNate: thanks
18:41:47  <TooTallNate>indutny: you still with nodejitsu then?
18:42:04  <indutny>TooTallNate: yes
18:42:12  <TooTallNate>nice
18:42:23  <isaacs>piscisaureus_: oh, i think that's because the js layer keeps a ref to it
18:43:07  <isaacs>piscisaureus_: i mean, if you drop the ref to the js object, then it could be.
18:43:31  <bnoordhuis>piscisaureus_: maybe use container_of() instead of reinterpret_cast<WorkReqWrap*>(work_req->data);
18:43:37  <bnoordhuis>makes it clear that it's embedded
18:43:52  <piscisaureus_>isaacs: by dropping the reference to the Deflate object?
18:44:01  <piscisaureus_>isaacs: I am afraid I cannot approve that :-)
18:44:28  <bnoordhuis>TooTallNate: what are you doing exactly?
18:44:29  <indutny>bnoordhuis: container_of = love
18:44:33  <bnoordhuis>:)
18:44:54  * mikealjoined
18:44:57  <TooTallNate>bnoordhuis: https://gist.github.com/1590458
18:45:08  <TooTallNate>the new section at the bottom, for "mac"
18:45:13  <isaacs>piscisaureus_: what happens if it gets lost and gc'ed before the thread pool returns?
18:45:30  <TooTallNate>the -lobjc flag is added during link, but the cxxflags are not applied every
18:45:32  <dannycoates>ryah: looks good to me
18:45:32  <bnoordhuis>TooTallNate: oh, like that. sorry, i thought you meant passing extra cflags to make
18:45:33  <TooTallNate>*ever
18:45:46  <TooTallNate>ahh
18:45:47  <TooTallNate>lol
18:45:54  <TooTallNate>so is gyp busted then?
18:46:16  <bnoordhuis>no - at least, it shouldn't be
18:46:31  <bnoordhuis>'cflags' was right
18:47:07  <ryah>dannycoates: just to be clear - we're talking about https://github.com/joyent/node/issues/2473 this one right?
18:47:16  <isaacs>piscisaureus_: indutny's test at https://github.com/joyent/node/issues/2504 is going to do exactly that.
18:47:37  <dannycoates>ryah: yes 2473
18:47:44  <ryah>dannycoates: okay landing
18:50:42  <CIA-115>node: Ryan Dahl v0.6 * re6a30bd / (src/node_buffer.h src/stream_wrap.cc):
18:50:42  <CIA-115>node: Fix #2473
18:50:42  <CIA-115>node: Tested in production.
18:50:42  <CIA-115>node: See also http://code.google.com/p/v8/issues/detail?id=1889 - http://git.io/6Bn4eA
18:54:36  <ryah>once we fix the numeric hash key problem - we'll release v0.6.8
18:55:48  <indutny>ryah: it's fixed, but needs to be backported to 3.6
18:55:59  <ryah>indutny: ok
18:56:10  <indutny>ryah: https://github.com/v8/v8/commit/2ee154a5b3d09b7ed0a17a108aec40a2174acee0
18:56:27  <ryah>im going to wait for it to land in the 3.6 branch
18:56:57  <indutny>of course
18:56:59  <indutny>just FYI
18:58:38  * travis-cijoined
18:58:38  <travis-ci>[travis-ci] joyent/node#216 (v0.6 - e6a30bd : Ryan Dahl): The build passed.
18:58:38  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/b07acb3...e6a30bd
18:58:38  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/503360
18:58:38  * travis-cipart
19:01:31  <TooTallNate>bnoordhuis: additionally, the cflags defined in node/common.gypi don't end up in the compilation either
19:01:35  <ryah>bnoordhuis, piscisaureus_: want to jump on skype?
19:01:39  <TooTallNate>really seems like gyp is busted to me
19:02:04  <ryah>TooTallNate: what's it going?
19:02:09  <piscisaureus_>ryah: yeah I am on
19:02:11  <bnoordhuis>ryah: yep
19:02:23  <TooTallNate> g++ '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' '-DDEBUG' '-D_DEBUG' -I../node/src -I../node/deps/uv/include -I../node/deps/v8/include -Ideps/libffi/include -Os -gdwarf-2 -Wnewline-eof -mmacosx-version-min=10.4 -fno-strict-aliasing -Wall -Wendif-labels -W -Wno-unused-parameter -fno-rtti -fno-exceptions -fno-threadsafe-statics -MMD -MF out/Debug/.deps/out/Debug/obj.target/ffi_bindings/src/ffi.o.d.raw -c -o out/Debug/obj.target
19:02:33  <TooTallNate>there's one compilation unit
19:02:43  <TooTallNate>but the cflags defined in node/common.gypi aren't included
19:02:55  <TooTallNate>nor are the ones defined in my gyp file
19:03:18  <TooTallNate>AndreasMadsen: didn't you run into something similar with the cflags param in gyp?
19:03:19  <bnoordhuis>TooTallNate: when trying to build an add-on?
19:03:23  <TooTallNate>bnoordhuis: ya
19:03:27  <AndreasMadsen>hi
19:03:52  <bnoordhuis>TooTallNate: one moment please, back in a flash
19:04:00  <TooTallNate>ok thanks
19:04:09  <AndreasMadsen>TooTallNate: nop
19:05:20  <TooTallNate>AndreasMadsen: weren't you the one who tried writing the first node-gyp script?
19:05:46  <AndreasMadsen>TooTallNate: no
19:05:51  <TooTallNate>oh, haha
19:05:57  <TooTallNate>here it is
19:05:57  <TooTallNate>https://github.com/joyent/node/pull/2337
19:06:02  <TooTallNate>same first name, DOH!
19:06:32  <AndreasMadsen>hehe
19:06:44  <TooTallNate>anyways, looks like he found the same thing as me
19:06:45  <TooTallNate>https://github.com/andreasbotsikas/node/blob/9888507786cae055bd5d3f1fc960f4519fa355e0/tools/node_module.gypi#L54-60
19:07:20  <TooTallNate>err, i guess it's a little different
19:07:34  <TooTallNate>he's trying to use ldflags, i'm trying to use cflags :\
19:10:15  * kuebkjoined
19:13:19  <bnoordhuis>piscisaureus_: https://gist.github.com/0b3bd8138068d9b884d7
19:14:39  <piscisaureus_>bnoordhuis: lgtm
19:15:55  * mikealquit (Quit: Leaving.)
19:18:27  <indutny>ok, going to sleep
19:18:31  <indutny>thank you all!
19:18:32  <indutny>ttyl
19:18:34  <indutny>:)
19:19:20  * dapjoined
19:24:47  <mmalecki>indutny: night!
19:25:42  * perezdjoined
19:26:49  * kuebkquit (Ping timeout: 240 seconds)
19:29:30  * kuebkjoined
19:31:52  <TooTallNate>bnoordhuis: https://gist.github.com/1590684
19:41:05  * slaskisjoined
19:43:12  <bnoordhuis>TooTallNate: wfm
19:43:20  <bnoordhuis> cc -ObjC -MMD -MF out/Default/.deps/out/Default/obj.target/hello/hello.o.d.raw -c -o out/Default/obj.target/hello/hello.o hello.c
19:43:21  <bnoordhuis>cc1: error: invalid option argument ‘-ObjC’
19:43:21  <bnoordhuis>make: *** [out/Default/obj.target/hello/hello.o] Error 1
19:44:37  <TooTallNate>bnoordhuis: that's messed up
19:44:41  <TooTallNate>you on linux?
19:45:02  <bnoordhuis>yes
19:45:17  <TooTallNate>hmmm, maybe it's broken in OS X
19:45:27  <TooTallNate>can someone else on OSX please try my gist above?
19:49:17  <ryah>yes one sec
19:49:23  * mjr_joined
19:50:16  <CIA-115>node: Ryan Dahl master * rd4ee61f / (5 files): Add failing test-isolates2.js - http://git.io/NJpx8g
19:52:26  <paddybyers>TooTallNate: I get the same result as you on OSX
19:52:32  <TooTallNate>here's a second confirmation: https://gist.github.com/1590800
19:52:35  <TooTallNate>paddybyers: 3rd
19:52:36  <paddybyers>also with xcode as well as make
19:52:38  <TooTallNate>geez
19:52:42  <ryah>TooTallNate: email evmar
19:52:47  <ryah>cc me
19:52:51  <TooTallNate>ok will do
19:53:09  <ryah>bnoordhuis: heres another failing isolate test
19:53:32  <mmalecki>ryah: o hai
19:53:46  <mmalecki>ryah: is the 0.7 release going to happen today?
19:54:01  <mmalecki>sorry for bothering you, I want to deploy it to travis asap
19:54:11  <mmalecki>so that people can start testing their stuff out :)
19:54:36  <TooTallNate>mmalecki++
19:54:36  <kohai>mmalecki has 41 beers
19:54:56  <TooTallNate>i'm gonna have to start deploying prebuilt binaries to travis :)
19:55:08  <TooTallNate>they don't have libffi installed for example, so node-ffi can't build
19:55:17  <TooTallNate>but thats the benefit of bundling :)
19:55:54  <mmalecki>TooTallNate: we can totally install it
19:56:08  <TooTallNate>ryah: is evan @chromium.com or @google.com?
19:56:09  <TooTallNate>his email
19:56:20  <TooTallNate>I have both in my history for some reason
19:56:30  <mmalecki>TooTallNate: is it in ubuntu repos?
19:56:36  <TooTallNate>mmalecki: that would make the 0.4.x branch build, but really it's not necessary
19:56:43  <TooTallNate>mmalecki: yes it's in the ubuntu repo
19:56:50  <mmalecki>TooTallNate: all right!
19:56:52  <TooTallNate>libffi-dev I'm guessing
19:57:00  <TooTallNate>mmalecki: cool thanks!
19:57:02  <ryah>TooTallNate: *shrug*
19:57:07  <TooTallNate>lol ok
19:57:09  <ryah>TooTallNate: @google.com i guess
19:57:10  <mmalecki>TooTallNate: my pleasure :)
19:57:21  <ryah>TooTallNate: he's also on irc sometimes
19:59:17  <TooTallNate>ryah: now or no?
19:59:45  <ryah>TooTallNate: *shrug*
20:01:11  * mikealjoined
20:02:09  <CIA-115>node: Ben Noordhuis v0.6 * r0ad2717 / src/node_zlib.cc : Make sure that zlib contexts are not garbage collected when busy - http://git.io/FTSzBw
20:02:11  <CIA-115>node: Bert Belder v0.6 * r2d8af39 / src/node_zlib.cc : Fix memory leak in node_zlib - http://git.io/NylRnQ
20:02:50  * travis-cijoined
20:02:50  <travis-ci>[travis-ci] joyent/node#217 (master - d4ee61f : Ryan Dahl): The build is still failing.
20:02:50  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/4cbcdb4...d4ee61f
20:02:50  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/503595
20:02:50  * travis-cipart
20:05:06  <CIA-115>node: Ryan Dahl master * re1b829d / (2 files): Add broken test-isolates3.js - http://git.io/gCGb6w
20:10:09  * travis-cijoined
20:10:10  <travis-ci>[travis-ci] joyent/node#218 (v0.6 - 0ad2717 : Ben Noordhuis): The build was broken.
20:10:10  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/e6a30bd...0ad2717
20:10:10  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/503714
20:10:10  * travis-cipart
20:13:53  * piscisaureus_topic: libuv
20:13:55  * piscisaureus_topic: welcome to the void
20:15:11  * pieternquit (Quit: pietern)
20:15:12  <isaacs>ryah, piscisaureus_, bnoordhuis: if i reuse the workreqwrap, where should i delete the object? does the ~ZCtx function get called when the wrapped object dies?
20:15:40  <ryah>isaacs: it should just be part of the class - it doesn't need to be deleted
20:15:42  <bnoordhuis>isaacs: if you embed it, you don't have to delete it
20:16:00  <isaacs>oh, ok, so don't make it a pointer that gets new'ed.
20:16:06  <isaacs>that makes sense.
20:16:52  * travis-cijoined
20:16:52  <travis-ci>[travis-ci] joyent/node#219 (master - e1b829d : Ryan Dahl): The build is still failing.
20:16:52  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/d4ee61f...e1b829d
20:16:52  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/503724
20:16:52  * travis-cipart
20:17:04  <piscisaureus_>isaacs: I don't think you really need to use WorkReqWrap at all - just embed uv_work_t
20:19:12  <isaacs>piscisaureus_: review? https://gist.github.com/1590952
20:19:39  <isaacs>piscisaureus_: ryah seemed to think it was important to use the ReqWrap approach when i was first doing this.
20:20:10  <igorzi>piscisaureus_: so i was wrong about 3 syscalls for stat.. that's because our current implementation of uv_fs_stat does open+fstat+close (so that we could support long paths)
20:20:30  <igorzi>piscisaureus_: if i go back to using CRT stat (with FindFirstFileEx) - it's 1 syscall
20:20:51  <ryah>piscisaureus_: we'll want that added to your domains handle list
20:20:55  <igorzi>piscisaureus_: i'm going to implement stat in libuv (with FindFirstFileEx), which supports long paths
20:21:01  * slaskisquit (Quit: slaskis)
20:21:34  <ryah>piscisaureus_: or maybe just the zlib object itself
20:21:49  <ryah>seems janky to have the WorkReqWrap in there
20:22:04  <piscisaureus_>ryah: yeah and actually you do want to have the constructor and destructor called
20:22:11  <piscisaureus_>ryah: unless they are no-ops
20:23:07  <piscisaureus_>still I think you should just embed uv_work_t inside the zlib context
20:23:15  <ryah>agreed
20:24:11  <piscisaureus_>isaacs: ^ so get rid of WorkReqWrap
20:24:20  <piscisaureus_>igorzi: does FindFirstFile give you enough information
20:24:55  <igorzi>piscisaureus_: yeah, i think so
20:26:18  <piscisaureus_>igorzi: I think under some rare circumstances you might need to do the open-fstat-close trick (e.g for symlinks)
20:26:34  <piscisaureus_>igorzi: but for normal files this works efficiently yeah
20:26:49  * kuebzkyjoined
20:28:49  * kuebkquit (Ping timeout: 240 seconds)
20:31:30  <piscisaureus_>bbl
20:34:39  <isaacs>but doesn't the ReqWrap give me the persistent object handle that gets cleaned up in its destructor?
20:34:47  <isaacs>ryah, piscisaureus_ ^
20:35:32  * piscisaureus_quit (Ping timeout: 240 seconds)
20:35:34  <bnoordhuis>isaacs: you don't need it, ZCtx is itself a persistent object
20:35:35  <isaacs>then we do this with it:
20:35:36  <isaacs> req.buffer = chunk;
20:35:36  <isaacs> req.callback = callback;
20:35:36  <isaacs> this._processing = req;
20:35:50  <isaacs>so you're saying, just hang all that on hte ZCtx itself, and return this->object_?
20:35:58  <isaacs>er, ctx->handle_ rather
20:36:07  <bnoordhuis>isaacs: yes
20:36:39  <bnoordhuis>you can return Undefined() from Write(), you already have a reference to the object in JS land
20:36:42  <isaacs>ok, that seems pretty sane.
20:36:54  <isaacs>right, no need to keep the other one. can just set processing = true
20:37:20  <isaacs>otherwise it's just an extra object hanging around
20:49:08  <TooTallNate>ryah: also, with a gyp build, `process.platform === 'mac'`
20:49:11  <TooTallNate>is that permenant?
20:50:29  <isaacs>ryah, bnoordhuis: https://gist.github.com/1591104
20:50:53  <isaacs>TooTallNate, ryah: that looks like a bug. should be "darwin", no?
20:51:00  <TooTallNate>isaacs: ya, should be
20:53:07  <bnoordhuis>isaacs: don't use work_req->data, use container_of()
20:53:16  <isaacs>bnoordhuis: what's container_of()?
20:55:01  <bnoordhuis>isaacs: the best thing since sliced bread
20:55:08  * mikealquit (Quit: Leaving.)
20:55:15  <isaacs>besides that :)
20:55:27  <isaacs>what does it actually mean? blah->pointer i get.
20:55:28  <bnoordhuis>it returns a pointer to a struct that's embedded in another struct / class
20:55:34  <isaacs>oh, ok
20:56:26  <bnoordhuis>there are a couple of advantages but the main one is that it makes it clear that you're looking up an embedded struct
20:57:10  <isaacs>ok
20:59:06  <isaacs>bnoordhuis: so, something like this?
20:59:07  <isaacs> ZCtx<mode> *ctx = container_of(work_req, uv_work_t, work_req_);
20:59:32  <isaacs>assuming that &(ctx->work_req_) === work_req
20:59:38  <TooTallNate>mmalecki: woah you got libffi installed that fast, nice ;)
20:59:41  <bnoordhuis>isaacs: yes
20:59:46  <isaacs>kewl
21:00:10  <bnoordhuis>oh, another thing, you don't need parens in &ctx->work_req_
21:00:20  <bnoordhuis>they don't hurt either of course
21:00:25  <mmalecki>TooTallNate: oh? I didn't... I wanted to wait for antares, but well... XD
21:00:48  <TooTallNate>oh. lol well it looks like it's there :p
21:01:02  <mmalecki>TooTallNate: hm, can you link me to the build with and without it?
21:01:03  <isaacs>bnoordhuis: i like them. they're pretty.
21:01:54  <isaacs>bnoordhuis: my internal parser is mostly javascript. anything to make the C easier for it to grok is good :)
21:02:28  <TooTallNate>mmalecki: with: http://travis-ci.org/#!/rbranson/node-ffi/jobs/504116
21:02:32  <isaacs>& and -> are both foreign words, so their precedence is a bit easeir to read with the parens.
21:02:33  <TooTallNate>without: http://travis-ci.org/#!/rbranson/node-ffi/jobs/475890
21:03:23  <mmalecki>TooTallNate: they ended up on different workers, maybe one of them has it installed? that'd be weird tho
21:03:36  <TooTallNate>hmmm, not sure
21:03:39  <mmalecki>TooTallNate: I'll check it
21:10:20  <isaacs>bnoordhuis: https://gist.github.com/1591225 <-- fourth commit added
21:10:50  <isaacs>https://gist.github.com/1591225#file_0004_zlib_use_container_of_instead_of_data.patch
21:11:14  * piscisaureus_joined
21:11:17  <bnoordhuis>isaacs: ZCtx<mode> *ctx = container_of(work_req, ZCtx, work_req_); -> ZCtx<mode> *ctx = container_of(work_req, ZCtx<mode>, work_req_); ?
21:11:34  <isaacs>oh… hrm. i wonder why that works.
21:12:11  <isaacs>seems like it shouldn't compile without the <mode>
21:12:20  <isaacs>but it does, and passes tests. works by accident, maybe?
21:12:29  <bnoordhuis>Process() is part of ZCtx?
21:12:33  <isaacs>yes.
21:12:44  <bnoordhuis>in that case the compiler knows that ZCtx is really ZCtx<mode>
21:13:07  <isaacs>oh, ok
21:13:45  * pieternjoined
21:13:55  <isaacs>https://gist.github.com/1591238 anyway
21:13:59  <isaacs>better to be explicit there.
21:14:48  * isaacschanged nick to isaacs_lunch
21:15:07  * kuebzkyquit
21:18:22  <bnoordhuis>isaacs_lunch: lgtm
21:27:00  * piscisaureus__joined
21:28:11  * piscisaureus_quit (Read error: Connection reset by peer)
21:38:49  * brsonquit (Ping timeout: 240 seconds)
21:44:56  <indutny>isaacs_lunch: yt?
21:45:04  <indutny>oh
21:45:09  <indutny>nick says for itself
21:45:10  <indutny>:D
21:45:14  <indutny>bnoordhuis: yt?
21:45:23  <bnoordhuis>indutny: yes
21:46:18  <indutny>bnoordhuis: I think I found the source of problem
21:46:25  <bnoordhuis>of what problem?
21:46:28  <indutny>bnoordhuis: I added logging to ~ZCtx
21:46:37  <indutny>bnoordhuis: memory leak within node-spdy
21:46:50  <indutny>bnoordhuis: so I'm creating two zlib streams per connection
21:47:15  <indutny>bnoordhuis: and destructor never gets fired
21:47:26  <bnoordhuis>indutny: remember, never cross the streams
21:48:12  <bnoordhuis>indutny: a couple of patches were just landed / are in progress, you might want to check those
21:48:52  <indutny>bnoordhuis: ok
21:49:00  <indutny>bnoordhuis: probably I'll create stream pool
21:49:11  <indutny>bnoordhuis: but .reset() method needs to be landed first
21:49:47  <indutny>what do you think?
21:50:58  <bnoordhuis>i think it's odd that you don't see the destructor getting called
21:51:19  <indutny>bnoordhuis: it's called
21:51:31  <indutny>bnoordhuis: but 2 times
21:52:10  <indutny>bnoordhuis: while I'm receiving 3k connections
21:52:40  <bnoordhuis>indutny: sanity check, you do see 3k constructor calls?
21:52:47  <indutny>bnoordhuis: one sec
21:56:16  <indutny>bnoordhuis: yes
21:56:58  <bnoordhuis>indutny: are you 100% confident that your code is not holding onto handles?
21:58:02  <indutny>bnoordhuis: nope, but I'm storing everything within connection
21:59:18  <indutny>bnoordhuis: I'll add .reset() method for zlib stream
21:59:39  <bnoordhuis>indutny: try to reduce it to a minimal test case
21:59:42  <indutny>bnoordhuis: creating two zlib contexts per connection is anyway not a good idea
21:59:55  <indutny>bnoordhuis: ok, one second
22:00:03  * pietern_joined
22:00:27  <bnoordhuis>but i'm not going to look at it tonight, i have to get up early tomorrow :)
22:00:27  * pieternquit (Read error: Connection reset by peer)
22:00:27  * pietern_changed nick to pietern
22:00:43  <indutny>bnoordhuis: :)
22:02:52  <indutny>ok, tomorrow then
22:04:44  * rphillipsjoined
22:05:02  <rphillips>anybody see this assertion before on windows ? http://skitch.com/trolocsis/gaij8/screen-shot-2012-01-10-at-4.02.26-pm
22:05:15  <rphillips>line 1277 src\win\pipe.c
22:08:08  <igorzi>rphillips: are you using libuv from v0.6 branch?
22:08:38  <rphillips>yes
22:09:04  <igorzi>rphillips: what's the last commit?
22:09:36  <rphillips>5cc6090fdf738c7ae6677627f9f151c9bc16b43f
22:09:43  <mmalecki>https://github.com/joyent/node/pull/2505 <- just sayin'
22:10:21  <AvianFlu>damn it mmalecki that was supposed to be `infernal` not `internal`!
22:10:22  <AvianFlu>XD
22:10:39  <mmalecki>lol
22:12:44  <igorzi>rphillips: that's from master, not v0.6
22:13:07  <igorzi>rphillips: how do you reproduce it?
22:13:55  <rphillips>igorzi: https://github.com/luvit/luvit/blob/master/tests/runner.lua
22:14:00  <rphillips>trying to run this script on windows
22:14:06  <rphillips>using luvit
22:14:41  <mmalecki>(but no, really, release is coming, can anyone merge it now XD ?)
22:15:00  <mmalecki>bnoordhuis: poke poke poke ^
22:16:25  <rphillips>igorzi: happens on the latest master also
22:16:33  * AndreasMadsenquit (Remote host closed the connection)
22:16:56  <bnoordhuis>mmalecki: thanks maciej, merged
22:17:04  <CIA-115>node: Maciej Małecki master * r4d49469 / lib/child_process.js : child_process: fix typo in internal message event name - http://git.io/Egl18Q
22:17:28  <indutny>bnoordhuis: ready for my patch?
22:17:41  <indutny>bnoordhuis: I cleaned up node_zlib.cc a little, btw
22:17:46  <bnoordhuis>indutny: i'm off-duty
22:17:53  <indutny>bnoordhuis: np
22:17:57  <mmalecki>bnoordhuis: thanks! :)
22:18:42  * mmaleckigoes to http://github-high-scores.heroku.com/joyent/node/high_scores/ to check how many commits indutny is ahead
22:19:42  * piscisaureus__changed nick to piscisaureus_
22:19:50  <igorzi>rphillips: one possibility is that you're passed ipc=1 to uv_pipe_init on one end, and passed ipc=0 on another end of the pipe
22:20:28  <rphillips>i'll check that out. thanks
22:27:02  <CIA-115>node: Ryan Dahl v0.6 * r290bc0c / (5 files in 2 dirs):
22:27:03  <CIA-115>node: Use .jpg instead of .bmp for .msi
22:27:03  <CIA-115>node: smaller. - http://git.io/EHjFhg
22:32:24  * travis-cijoined
22:32:25  <travis-ci>[travis-ci] joyent/node#220 (master - 4d49469 : Maciej Małecki): The build is still failing.
22:32:25  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/e1b829d...4d49469
22:32:25  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/504480
22:32:25  * travis-cipart
22:32:41  * pieternquit (Remote host closed the connection)
22:32:53  * pieternjoined
22:34:44  * mjr_quit (Quit: mjr_)
22:35:02  * travis-cijoined
22:35:03  <travis-ci>[travis-ci] joyent/node#221 (v0.6 - 290bc0c : Ryan Dahl): The build is still failing.
22:35:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/0ad2717...290bc0c
22:35:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/504503
22:35:03  * travis-cipart
22:36:40  <piscisaureus_>rphillips: Are you using the luvit ports branch or are you just using master?
22:38:52  <txdv>ev has a readwatcher, it just notifies the user if there is something to read, will libuv have a read watcher too?
22:39:04  <rphillips>piscisaureus_: master
22:40:22  <piscisaureus_>rphillips: I did some windows work early december but I don't think it ever got merged, it still lives in the ports branch
22:40:26  <piscisaureus_>rphillips: anyhow
22:40:47  * paddybyersquit (Quit: paddybyers)
22:40:55  <piscisaureus_>rphillips: you should not use IPC pipes unless you're doing something similar to child_process.fork() in node
22:42:03  <piscisaureus_>rphillips: it basically turns uv_pipe_t from a raw binary stream into a packetized stream that allows handle sharing (so we can do FD passing on windows)
22:42:25  <piscisaureus_>but it only works if both ends of the pipe are libuv-based programs
22:43:54  <rphillips>luvit is passing 0 to the ipc flag in uv_pipe_init
22:46:24  <piscisaureus_>rphillips: hmm maybe the uv_pipe_t handle's memory got clobbered then
22:46:32  * mjr_joined
22:46:52  <rphillips>i'll debug it some more and report back
22:47:20  * mjr_quit (Client Quit)
22:47:28  <piscisaureus_>rphillips: but https://github.com/luvit/luvit/blob/master/lib/luvit.lua#L107-111 <-- this doesn't work on windows
22:47:44  <piscisaureus_>if you redirect stdio to a file or pipe then it will break in unexpected ways anyway
22:48:27  <rphillips>ah I see
22:50:40  * bradleymeckquit (Read error: Operation timed out)
22:56:22  * bnoordhuisquit (Ping timeout: 252 seconds)
23:10:05  * isaacs_limechatjoined
23:11:32  * mjr_joined
23:12:43  * mjr_quit (Client Quit)
23:13:35  * mjr_joined
23:13:58  * mjr_quit (Client Quit)
23:18:47  * isaacs_lunchchanged nick to isaacs
23:19:40  <indutny>isaacs: heya
23:19:45  <isaacs>yo
23:20:11  <indutny>isaacs: I'm very close to the source of my problems with zlib
23:20:34  <isaacs>indutny: nice!
23:20:35  <isaacs>what'd you find?
23:20:36  <indutny>isaacs: looks like flush's callback is sometimes gets into queu's end
23:20:47  <indutny>isaacs: so I'm receiving a ton of requests
23:20:51  <isaacs>oh, right, yeah, that cb-on-write thing is kind of weird.
23:21:02  * isaacsadds "Clean up streams" to the growing node todo list.
23:21:26  <indutny>isaacs: yes, looks like eio has a lot of callbacks in queue
23:21:31  <indutny>isaacs: and flush is always in end
23:21:47  <indutny>isaacs: so once I'll close all that connections
23:21:55  <indutny>isaacs: after some time, all callbacks will be fired
23:22:03  <isaacs>indutny: why do you need to call flush()?
23:22:33  <indutny>isaacs: because I
23:22:57  <indutny>isaacs: because I need to parse SPDY headers before doing everything else
23:23:18  <indutny>isaacs: should I use write callback instead?
23:23:42  <isaacs>hm.
23:24:03  <isaacs>indutny: well, so… the thing is, flush doesn't mean "block until everything is sent"
23:24:11  <isaacs>it means "tell zlib to send everything as fast as possible"
23:24:40  <isaacs>if you want to knwo that a write is complete, the best way is to check the return value, and if it's false, then attach a drain handler.
23:25:26  <isaacs>calling flush a lot is really not good. there are a few use cases where you do actually need to put a break in the zlib stream, and have it flush whatever it has, and obviously you have to do that at the end.
23:26:04  <indutny>isaacs: I'm doing that at the end of compressed data
23:27:02  <indutny>isaacs: looks like requests are coming faster than node can process
23:27:07  <isaacs>indutny: then why not call .end()? are you needing to re-use the stream object?
23:27:28  <indutny>isaacs: I think creating it would have bigger performance impact
23:27:42  <indutny>isaacs: than reusing
23:27:42  <isaacs>yeah, probably
23:27:48  <indutny>isaacs: btw, added reset method
23:27:50  <indutny>isaacs: locally
23:27:55  <isaacs>what's reset do?
23:28:06  <indutny>isaacs: reset's dictionary and everything
23:28:17  <indutny>isaacs: inflateReset and deflateReset
23:28:21  <indutny>isaacs: let me show you
23:28:34  <isaacs>oh, right, those are supplied by zlib.h, right?
23:29:01  <indutny>isaacs: yes
23:31:08  <indutny>isaacs: https://github.com/joyent/node/pull/2506
23:33:57  <indutny>oh, 6am is definitely a time to get sleeping :D
23:34:00  <indutny>sorry
23:34:01  <indutny>ttyl
23:35:18  <isaacs>g'nite!
23:36:16  * isaacsquit (Disconnected by services)
23:36:21  * isaacs_limechatchanged nick to isaacs
23:42:26  * isaacsquit (Remote host closed the connection)
23:42:43  * isaacs_limechatjoined
23:42:53  * isaacs_limechatchanged nick to isaacs
23:44:16  * isaacsquit (Remote host closed the connection)
23:44:28  * isaacsjoined
23:48:32  * isaacsquit (Remote host closed the connection)
23:49:18  * isaacsjoined
23:51:22  * isaacsquit (Remote host closed the connection)
23:51:37  * isaacsjoined
23:53:52  * isaacsquit (Remote host closed the connection)
23:54:07  * isaacsjoined
23:54:31  * isaacsquit (Remote host closed the connection)
23:55:11  * isaacsjoined
23:55:38  * isaacsquit (Remote host closed the connection)
23:56:16  * isaacsjoined
23:56:39  * isaacsquit (Remote host closed the connection)
23:57:22  * isaacsjoined
23:57:34  * pieternquit (Quit: pietern)
23:57:50  * mjr_joined