00:03:18  <TooTallNate>ok got it
00:03:22  <TooTallNate><(var)
00:03:27  <TooTallNate>not <(var>
00:03:29  <TooTallNate>:p
00:06:50  <DrPizza>yeah
00:09:45  <TooTallNate>fuck yeah!!!
00:09:51  <TooTallNate>node-gyp + windows :D
00:16:01  <piscisaureus_>nice
00:16:14  <piscisaureus_>TooTallNate: I will try it tomorrow. keep up the good work.
00:38:25  * lwillejoined
00:38:28  * lwillequit (Remote host closed the connection)
00:38:33  * lwillejoined
00:43:07  * lwillequit (Ping timeout: 240 seconds)
01:08:25  * isaacsquit (Remote host closed the connection)
01:09:09  * isaacsjoined
01:16:43  * isaacsquit (Ping timeout: 252 seconds)
01:26:32  * TooTallNatequit (Quit: Leaving...)
01:53:03  * TooTallNatejoined
02:00:54  * TooTallNatequit (Quit: Leaving...)
02:13:56  * bnoordhuisquit (Ping timeout: 240 seconds)
02:31:11  * brsonquit (Quit: leaving)
02:47:28  * isaacs_mobilejoined
02:48:40  * isaacs_m_joined
02:48:41  * isaacs_mobilequit (Read error: Connection reset by peer)
02:48:43  * isaacs_m_quit (Client Quit)
02:48:56  * isaacs_mobilejoined
02:53:52  * isaacsjoined
03:00:56  * isaacs_mobilequit (Remote host closed the connection)
03:05:45  * TooTallNatejoined
03:07:41  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
03:33:08  * TooTallNatequit (Quit: Leaving...)
03:37:36  * isaacsquit (Remote host closed the connection)
03:51:19  * theColejoined
04:02:21  * theColequit (Quit: theCole)
04:15:17  * TooTallNatejoined
04:16:28  * TooTallNatequit (Client Quit)
04:25:52  * isaacsjoined
04:34:14  * TooTallNatejoined
04:36:53  * TooTallNatequit (Client Quit)
05:00:55  * dshaw_joined
05:01:28  * isaacs_mobilejoined
05:14:09  * isaacs_mobilequit (Remote host closed the connection)
05:28:32  * lwillejoined
05:28:51  * lwillequit (Client Quit)
05:35:04  * sh1mmerquit (Quit: sh1mmer)
05:36:01  * sh1mmerjoined
06:07:14  * mraleph1joined
06:31:26  * orlandovftwjoined
06:34:11  * perezdquit (Quit: perezd)
06:41:53  * paddybyersjoined
07:06:45  * mraleph1quit (Quit: Leaving.)
08:14:50  * paddybyersquit (Quit: paddybyers)
08:28:34  * isaacsquit (Remote host closed the connection)
08:29:12  * isaacsjoined
08:29:58  * dshaw_quit (Quit: Leaving.)
08:34:15  * isaacsquit (Ping timeout: 248 seconds)
08:45:03  * paddybyersjoined
08:46:34  * paddybyers_joined
08:49:43  * paddybyersquit (Ping timeout: 248 seconds)
08:49:44  * paddybyers_changed nick to paddybyers
10:00:55  * lwillejoined
10:11:50  * orlandovftwquit (Ping timeout: 260 seconds)
10:46:30  * lwillequit (Remote host closed the connection)
11:10:08  * paddybyers_joined
11:10:08  * paddybyersquit (Read error: Connection reset by peer)
11:10:08  * paddybyers_changed nick to paddybyers
11:33:30  * toothrquit (*.net *.split)
11:35:16  * toothrjoined
11:35:25  * toothrquit (Max SendQ exceeded)
11:38:31  * toothrjoined
12:06:45  * AvianFluquit (Ping timeout: 255 seconds)
12:48:00  * AvianFlujoined
13:14:29  * piscisaureus_joined
13:20:55  * bnoordhuisjoined
13:40:37  <piscisaureus_>bnoordhuis: should we compile node with -fno-rtti -fno-exceptions?
13:41:00  <bnoordhuis>piscisaureus_: yes, and i think we already do
13:41:04  <bnoordhuis>in master anyway
13:41:08  <piscisaureus_>ok, kewl
13:41:20  <piscisaureus_>I'm kinda happy that I can develop on master again
13:41:31  <piscisaureus_>without worrying about everything being broken due to isolates
13:42:20  <bnoordhuis>piscisaureus_: talking about... https://github.com/bnoordhuis/node/commit/e0a8d82 <- review?
13:42:41  <piscisaureus_>damn
13:42:43  <piscisaureus_>that's a lot
13:43:43  <piscisaureus_>bnoordhuis: what about we leave Loop() in?
13:44:15  <piscisaureus_>(and make it inline-able)
13:44:29  <bnoordhuis>piscisaureus_: it's possible but why? also, it's a perl one-liner to put them back in later
13:44:37  <piscisaureus_>right
13:45:11  <piscisaureus_>bnoordhuis: well, because uv_default_loop() is a function call + pthread_once
13:45:25  <piscisaureus_>bnoordhuis: but since you can put it in later it's fine to remove it now.
13:45:42  <bnoordhuis>cool
13:45:48  <bnoordhuis>i suppose isaac should review it too
13:45:58  <bnoordhuis>but i want to land it, damnit
13:48:13  <piscisaureus_>bnoordhuis: did you do it manually?
13:48:22  <piscisaureus_>bnoordhuis: or did you just stack up reverts?
13:48:38  <bnoordhuis>piscisaureus_: the latter
13:48:44  <bnoordhuis>with a teeny bit of manual tweaking
13:48:47  <piscisaureus_>oh, I assume it's fine then
13:48:56  <piscisaureus_>wrapped_script_constructor <-- byebye
13:49:04  <bnoordhuis>it won't be missed :)
13:49:10  <piscisaureus_>indeed
13:49:18  <piscisaureus_>Looking at node.cc it looked kind of clean
13:49:33  <piscisaureus_>but all this NODE_VAR crap is good to get rid of
13:49:52  <bnoordhuis>agreed
13:50:57  <piscisaureus_>bnoordhuis: we are going to do it again. Maybe before that we should patch v8 so you can have symbols shared across isolates
13:51:24  <bnoordhuis>piscisaureus_: why would we try isolates again?
13:51:34  <piscisaureus_>bnoordhuis: because we're drunk?
13:52:06  <bnoordhuis>then i'll stay stone cold sober from now on
13:52:16  * bnoordhuisputs down the beer bottle
13:52:29  <piscisaureus_>putting down the beer bottle doesn't make you sober ben
13:53:10  <benvie>haha
13:53:22  <bnoordhuis>it will eventually
13:53:26  <bnoordhuis>but seriously, do you want to revisit isolates again?
13:54:00  <piscisaureus_>bnoordhuis: maybe, once
13:54:08  <piscisaureus_>I have to think about it very deeply first
13:54:15  <bnoordhuis>yes, please do :)
13:54:32  <indutny>hahaha
13:54:38  <indutny>I think we will
13:54:42  <bnoordhuis>i could imagine providing some kind of async vm.runInNewContext
13:55:00  <piscisaureus_>bnoordhuis: how could that be async?
13:55:04  <indutny>bnoordhuis: it won't work
13:55:12  <piscisaureus_>yes. bnoordhuis, shame
13:55:15  <indutny>bnoordhuis: at least you won't be able to put context
13:55:32  <indutny>only if you'll create isolate and context
13:55:37  <bnoordhuis>i stress the "some kind of"
13:55:53  <indutny>kk
13:56:13  <indutny>I think v8 may eventually support threading
13:56:20  <indutny>s/I think/I hope
13:56:34  <bnoordhuis>i wouldn't if i were them
13:56:47  <bnoordhuis>v8's main customer is chrome/chromium
13:57:04  <bnoordhuis>i don't think they (chrome/chromium) care about threading
13:57:07  <indutny>yeah, so that depends on browser needs
13:57:12  <indutny>it isn't ow
13:57:14  <indutny>s/ow/now
13:57:19  <indutny>but who knows
13:57:48  <bnoordhuis>which reminds me...
13:57:50  <bnoordhuis>mraleph: ping
13:59:25  <mraleph>pong
13:59:31  <mraleph>bnoordhuis: pong
14:01:01  <bnoordhuis>mraleph: hey. v8's preparser api, what performance gain should i expect to see?
14:01:16  <mraleph>who knows
14:01:24  <mraleph>I don't know :-)
14:01:29  <bnoordhuis>hah, too bad
14:01:33  <bnoordhuis>been toying around with it
14:01:37  <mraleph>faster parsing maybe sometimes if you are lucky.
14:01:42  <bnoordhuis>it compresses well so that's good
14:01:53  <bnoordhuis>but it doesn't really seem to improve script loading times
14:01:53  <mraleph>let me ask the author.
14:02:11  <bnoordhuis>thanks
14:03:21  <piscisaureus_>bnoordhuis: The patch looks good to me. I wasn't really that involved with isolates so I can't really tell if maybe you are forgetting some bits.
14:03:22  <indutny>bnoordhuis: hm :)
14:03:24  <indutny>interesting
14:03:28  <indutny>preparser-api
14:03:34  <piscisaureus_>bnoordhuis: you probably would have to get ryah to review ....
14:03:36  <indutny>I read that code few months ago
14:03:47  <indutny>brb
14:03:55  <bnoordhuis>piscisaureus_: why?
14:04:27  <piscisaureus_>bnoordhuis: he was more involved with isolates right?
14:04:34  <piscisaureus_>bnoordhuis: actually, just land it
14:04:44  <piscisaureus_>if it doesn't break anything, that is
14:04:46  <bnoordhuis>piscisaureus_: oh, like that. ryan's okay with it
14:04:53  <bnoordhuis>he had the same regrets about isolates i had
14:05:03  <piscisaureus_>bnoordhuis: he reviewed you patch?
14:05:23  <bnoordhuis>no, but we've talked about it
14:05:38  <bnoordhuis>okay, landing patch
14:08:31  <mraleph>bnoordhuis: so he says you need a huuuge script which mostly consists of non-executed lazyly compilable code to see the difference.
14:08:55  <mraleph>bnoordhuis: I think this does not hold for node.js
14:09:25  <bnoordhuis>mraleph: thanks. i suspected it was something like that :)
14:09:53  <bnoordhuis>we'll just have to write a boat load more javascript code
14:10:24  <mraleph>preferably it should be dead and never executed :-)
14:10:46  <mraleph>(consider commenting it out. parser is pretty effecient in parsing that).
14:17:10  <CIA-101>node: Ben Noordhuis master * rd4c4838 / (45 files in 5 dirs): (log message trimmed)
14:17:10  <CIA-101>node: Revert support for isolates.
14:17:10  <CIA-101>node: It was decided that the performance benefits that isolates offer (faster spin-up
14:17:10  <CIA-101>node: times for worker processes, faster inter-worker communication, possibly a lower
14:17:10  <CIA-101>node: memory footprint) are not actual bottlenecks for most people and do not outweigh
14:17:10  <CIA-101>node: the potential stability issues and intrusive changes to the code base that
14:17:11  <CIA-101>node: first-class support for isolates requires.
14:18:36  <CIA-101>libuv: Roman Shtylman v0.6 * r9fa2cf2 / (test/test-list.h uv.gyp test/test-udp-multicast-ttl.c): test: add multicast TTL test - http://git.io/6FJhjg
14:20:20  * travis-cijoined
14:20:20  <travis-ci>[travis-ci] joyent/libuv#79 (v0.6 - 9fa2cf2 : Roman Shtylman): The build is still failing.
14:20:20  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/443445a...9fa2cf2
14:20:20  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/633783
14:20:20  * travis-cipart
14:20:58  <bnoordhuis>indutny: https://github.com/joyent/libuv/pull/292 <- is that PR still relevant?
14:22:05  * mikealjoined
14:22:53  <mmalecki>bnoordhuis: so, pull requests!
14:23:40  <bnoordhuis>mmalecki: pull requests are heavily overrated
14:23:52  <bnoordhuis>i'm going down the marc lehmann path: you can look but you cannot touch
14:24:50  * mikealquit (Client Quit)
14:25:14  <mmalecki>bnoordhuis: lol
14:25:24  <mmalecki>bnoordhuis: BUT. these are *my* pull requests!
14:26:13  <bnoordhuis>mmalecki: okay, but i'm not doing anything today that touches child_process
14:26:34  <mmalecki>bnoordhuis: but...
14:27:05  * travis-cijoined
14:27:05  <travis-ci>[travis-ci] joyent/node#370 (master - d4c4838 : Ben Noordhuis): The build is still failing.
14:27:05  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/a9723df...d4c4838
14:27:05  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/633759
14:27:05  * travis-cipart
14:27:16  <mmalecki>oh well, I don't have time to nerdfight much anyway, we can do that tomorrow
14:28:06  <bnoordhuis>actually, it's that i have a hard time deciding what are good child_process changes...
14:28:32  <mmalecki>bnoordhuis: the ones which make API more consistent and better
14:28:48  <mmalecki>that's pretty much what node is about, I guess
14:32:42  <indutny>bnoordhuis: sorry, I was afk
14:32:42  <indutny>one sec
14:33:23  <indutny>bnoordhuis: no, closed
14:35:55  <CIA-101>libuv: Nathan Rajlich v0.6 * rd33ccb0 / include/uv.h : Add EXDEV to the errno map. - http://git.io/UEI8ug
14:37:35  * travis-cijoined
14:37:35  <travis-ci>[travis-ci] joyent/libuv#80 (v0.6 - d33ccb0 : Nathan Rajlich): The build is still failing.
14:37:35  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/9fa2cf2...d33ccb0
14:37:35  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/633840
14:37:35  * travis-cipart
14:42:21  <mmalecki>bnoordhuis: btw, moving out in 22 days :)
14:42:25  <piscisaureus_>bnoordhuis: src\process_wrap.cc(24): fatal error C1083: Cannot open include file: 'node_var
14:42:25  <piscisaureus_>s.h': No such file or directory [D:\node4\node.vcxproj]
14:44:42  <bnoordhuis>piscisaureus_: peculiar, gcc doesn't even complain it...
14:46:11  <bnoordhuis>okay, force-push coming up
14:46:33  <CIA-101>node: Ben Noordhuis master * r74a8215 / (45 files in 5 dirs): (log message trimmed)
14:46:33  <CIA-101>node: Revert support for isolates.
14:46:33  <CIA-101>node: It was decided that the performance benefits that isolates offer (faster spin-up
14:46:33  <CIA-101>node: times for worker processes, faster inter-worker communication, possibly a lower
14:46:33  <CIA-101>node: memory footprint) are not actual bottlenecks for most people and do not outweigh
14:46:34  <CIA-101>node: the potential stability issues and intrusive changes to the code base that
14:46:35  <CIA-101>node: first-class support for isolates requires.
14:47:58  <bnoordhuis>mmalecki: where are you moving to?
14:49:23  <mmalecki>bnoordhuis: just different place, here in Poznan. moving out from my parents :)
14:50:00  <bnoordhuis>congrats, let the years of partying begin
14:50:16  <mmalecki>yeah!
14:50:29  <mmalecki>place is pretty sweet, http://dom.gratka.pl/tresc/401-26818479-wielkopolskie-poznan-naramowice-karpia.html
14:51:16  <mmalecki>there's some silly text in there, but who gives a fuck about reading anyway. photos are awesome :)
14:59:48  <CIA-101>node: Bert Belder reviewme * r2e2df04 / common.gypi : Windows: disable RTTI and exceptions - http://git.io/mnhaCQ
14:59:49  <piscisaureus_>^-- bnoordhuis: review?
15:00:28  * travis-cijoined
15:00:28  <travis-ci>[travis-ci] joyent/node#371 (master - 74a8215 : Ben Noordhuis): The build is still failing.
15:00:28  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/d4c4838...74a8215
15:00:28  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/633880
15:00:28  * travis-cipart
15:00:56  <bnoordhuis>piscisaureus_: looks okay. does it compile, is it faster?
15:01:31  <piscisaureus_>bnoordhuis: it compiles. I couldn't notice any difference with http_simple but that is dominated by nt kernel performance
15:01:40  <piscisaureus_>bnoordhuis: the exe is a couple of 100 kb smaller
15:01:48  <bnoordhuis>that much? wow
15:01:55  <piscisaureus_>rtti is expensive
15:02:07  <piscisaureus_>in terms of compiled size
15:02:23  <CIA-101>node: Bert Belder master * r2e2df04 / common.gypi : Windows: disable RTTI and exceptions - http://git.io/mnhaCQ
15:04:46  <piscisaureus_>bnoordhuis: http://groups.google.com/group/nodejs/browse_thread/thread/3dfaa4756e8d2b7c
15:05:07  <piscisaureus_>bnoordhuis: I kinda like it. Looks like c++ works well as a high-level language
15:05:32  <bnoordhuis>piscisaureus_: c++11 is well-suited for it
15:05:40  <bnoordhuis>it'd be rather painful to work with in c++98
15:05:40  <indutny>but looks awkward
15:05:46  <indutny>:D
15:05:56  <piscisaureus_>it doesn't
15:06:01  <indutny>no it is
15:06:06  <indutny>:D
15:06:17  <piscisaureus_>server.listen("", 8080, [](request& req, response& res){
15:06:22  <piscisaureus_>^-- that's nice heh?
15:06:36  <bnoordhuis>the thing is... how many people have a c++11 compiler installed?
15:06:36  <indutny>piscisaureus_: nice in comparison to C++98
15:06:43  <piscisaureus_>I don't
15:06:50  <piscisaureus_>or - wait, does msvc support it?
15:07:08  <piscisaureus_>I heard some msft dude bragging about c++11 recently
15:07:15  <piscisaureus_>so it must be in msvc or?
15:07:31  <bnoordhuis>you ask questions i don't know the answer to
15:11:33  <piscisaureus_>bnoordhuis: do c++ inline functions - like [](foo* bar) { } - support closures?
15:11:54  <bnoordhuis>piscisaureus_: i don't see why not
15:12:24  <piscisaureus_>bnoordhuis: apparently one can just mix that with c-style function pointers
15:12:31  <piscisaureus_>bnoordhuis: so how does it do that?
15:12:46  <piscisaureus_>I mean, it has to store state somewhere
15:12:51  <bnoordhuis>piscisaureus_: [](foo* bar) { } <- that's not an inline function though, that's an anonymous function
15:13:01  <piscisaureus_>oh - that's what I mean
15:13:18  <piscisaureus_>does that support closure scope?
15:13:57  <bnoordhuis>i think the answer is 'yes with caveats'
15:14:04  <bnoordhuis>trying to find a good link that explains it
15:14:12  * indexzerojoined
15:14:36  * indexzeroquit (Client Quit)
15:14:41  * travis-cijoined
15:14:41  <travis-ci>[travis-ci] joyent/node#372 (reviewme - 2e2df04 : Bert Belder): The build was broken.
15:14:41  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/commit/2e2df04
15:14:41  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/633956
15:14:41  * travis-cipart
15:15:03  <bnoordhuis>meh
15:15:10  <piscisaureus_>bnoordhuis: It would have to allocate some memory for the captured data and probably copy a stub there
15:15:24  <bnoordhuis>piscisaureus_: [](foo* bar) captures nothing, i.e. it's not a closure
15:15:25  <piscisaureus_>but that won't work
15:15:29  <piscisaureus_>yeah ok
15:15:49  <piscisaureus_>so [](foo *bar) is compatible with (*)(foo*)
15:16:03  <bnoordhuis>yes
15:16:05  <piscisaureus_>but [a, b](foo* bar) isn't
15:16:29  <piscisaureus_>hmm
15:16:34  <piscisaureus_>this guy has some work to do then
15:18:32  * travis-cijoined
15:18:32  <travis-ci>[travis-ci] joyent/node#373 (master - 2e2df04 : Bert Belder): The build is still failing.
15:18:32  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/74a8215...2e2df04
15:18:32  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/633993
15:18:32  * travis-cipart
15:22:07  <bnoordhuis>piscisaureus_: i suppose you could make [a, b](foo* bar) compatible with (*)(foo*) with some clever stack trampolining
15:22:23  <bnoordhuis>kind of like gcc's function-local functions work
15:22:42  <bnoordhuis>*nested functions
15:23:24  <piscisaureus_>bnoordhuis: does that also work when the stack unwinds?
15:23:50  <piscisaureus_>bnoordhuis: I am very sceptical about it, that's mainly because I can't imagine how I would implement that myself :-)
15:23:52  <bnoordhuis>piscisaureus_: probably not. gcc only supports them in c mode :)
15:24:32  <piscisaureus_>bnoordhuis: one way could obviously to just allocate some memory
15:24:46  <piscisaureus_>fill that with a call trampoline and put the state after that
15:24:56  <piscisaureus_>and return a pointer to it
15:25:22  <piscisaureus_>the thing is, since there is no garbage collection it would be impossible to tell when that memory can be released again
15:26:29  <bnoordhuis>piscisaureus_: when the nested function goes out of scope? it could use the normal stack unwinding protocol
15:26:44  <bnoordhuis>in that case it'd be more of a functor, really
15:27:03  <piscisaureus_>bnoordhuis: that would make the function pointer invalid since its captured vars get cleaned up
15:27:16  <bnoordhuis>yes, that's the responsibility of the programmer
15:27:19  <piscisaureus_>bnoordhuis: when dealing with libuv, that would be really bad
15:27:30  <piscisaureus_>since we make sure the stack always unwinds before making a callback
15:38:44  <indutny>bnoordhuis: what [a,b](foo* bar) means?
15:39:01  <indutny>bnoordhuis: and how functions can access their scope in c++?
15:39:29  <bnoordhuis>indutny: it creates a lambda / closure and makes copies of a and b
15:39:44  <indutny>bnoordhuis: at runtime?
15:39:48  <bnoordhuis>indutny: yes
15:39:51  <indutny>oh
15:39:57  <indutny>interesting
15:40:02  <indutny>but how does it pass to function
15:40:09  <bnoordhuis>how does it pass what?
15:40:14  <indutny>copies
15:40:27  <bnoordhuis>it creates a functor-like object
15:40:48  <indutny>oooh
15:40:56  <indutny>interesting
15:41:08  <bnoordhuis>it's a short-hand syntax for what you can already do in c++98
15:41:16  <bnoordhuis>but short-hand in this case is rather convenient
15:42:14  <bnoordhuis>piscisaureus_: were we going to do symbol hiding? i think you already do on windows?
15:42:26  <piscisaureus_>bnoordhuis: it is enabled now
15:42:36  <piscisaureus_>bnoordhuis: we're not doing it on windows btw
15:42:52  <indutny>bnoordhuis: still it's interesting, how it works
15:42:52  <piscisaureus_>bnoordhuis: the problem is that we still rely on some internal functions to be exported
15:43:03  <indutny>bnoordhuis: going to disassembly a program
15:43:05  <piscisaureus_>bnoordhuis: uv_inet_pton and friends iirc
15:43:49  <piscisaureus_>bnoordhuis: I think symbol hiding is on on master for unix atm. TooTallNate reported that he had problems loading compiled extensions so he had to disable it again
15:44:19  <bnoordhuis>indutny: they're allocated on the stack. it essentially looks like `struct my_functor my_lambda(a, b);`
15:44:40  <bnoordhuis>piscisaureus_: yeah, we compile with -fvisibility=hidden if gcc >= 4
15:45:24  <piscisaureus_>bnoordhuis: we should really find a solution for ares_inet_pton
15:45:40  <piscisaureus_>it hurts every time I think about it
15:45:47  <bnoordhuis>piscisaureus_: https://github.com/bnoordhuis/libuv/commit/81fdf6a
15:46:15  <piscisaureus_>bnoordhuis: lgtm
15:46:30  <bnoordhuis>piscisaureus_: so why don't we wrap ares_inet_pton with uv_inet_pton?
15:46:58  <piscisaureus_>bnoordhuis: the problem is that cares doesn't export it from its headers
15:47:03  <indutny>bnoordhuis: ok, got it
15:47:04  <piscisaureus_>nor does it mark them as ARES_EXPORT
15:47:17  <piscisaureus_>bnoordhuis: so with symbol hiding, those function will be hidden :-)
15:47:30  <bnoordhuis>piscisaureus_: like that. easily fixed, right?
15:47:48  <piscisaureus_>bnoordhuis: if we are floating patches, yes
15:47:55  <piscisaureus_>bnoordhuis: we could also just copy them to libuv
15:47:56  <bnoordhuis>a minor nuisance when upgrading but manageable
15:48:00  <bnoordhuis>or that
15:48:08  <piscisaureus_>bnoordhuis: I prefer $that
15:48:18  <bnoordhuis>if you audit them :)
15:48:25  <piscisaureus_>sure
15:48:41  <bnoordhuis>okay, make it so
15:50:39  <piscisaureus_>bnoordhuis: the code body is rather large :-)
15:50:45  <piscisaureus_>bnoordhuis: I am also going to float http://comments.gmane.org/gmane.network.dns.c-ares/865
15:52:03  <bnoordhuis>piscisaureus_: hm. does left wrap around?
15:52:20  <piscisaureus_>bnoordhuis: no.
15:52:37  <piscisaureus_>bnoordhuis: the `long` part I don't agree with but it's rather harmless
15:53:08  <bnoordhuis>i don't see the buffer overrun :/
15:53:19  <bnoordhuis>is this korsakov catching up with me?
15:53:49  <bnoordhuis>anyway... sure, if you think it's okay
15:53:57  <piscisaureus_>I will take another look
16:02:41  <pquerna>wjw, didn't imagine isolates going away :-/
16:03:46  <piscisaureus_>pquerna: you feel sorry for them>
16:03:55  <pquerna>well, kinda.
16:04:19  <pquerna>i always imagined they were how we would beat nginx
16:05:05  <piscisaureus_>pquerna: how did you expect isolates to make the difference?
16:05:30  <pquerna>yes, at least on unix
16:06:01  <pquerna>one isolate per core, optimize the accept() path, no need for external process locking to prevent thundering heards
16:06:12  <pquerna>but doesn't matter that much really.
16:06:33  <pquerna>whats left to do in v0.8 then? https://groups.google.com/group/nodejs/browse_thread/thread/79504e62223f3bf0 gets pretty skim without isolates
16:07:23  * AndreasMadsenjoined
16:07:23  <piscisaureus_>pquerna: well, domains are ehm, not done
16:07:30  <piscisaureus_>pquerna: I got stuck trying to define them
16:07:37  <piscisaureus_>pquerna: and we have to make libuv better
16:07:51  <piscisaureus_>fix the refcount crap, merge stream types, make the interface more consistent
16:08:08  <AndreasMadsen>anyone who would care to review this small patch -> https://github.com/joyent/node/pull/2661
16:08:13  <pquerna>yeah, i was talking to ry a month ago about the stream types.
16:08:26  <piscisaureus_>pquerna: you have any specific ideas about that?
16:08:26  <pquerna>about making a vtable maybe; then you could make stream types not bundled in libuv too.
16:09:24  <piscisaureus_>pquerna: yeah ryan wanted vtables as well. but we would have to open up the callback dispatcher queue as well
16:10:00  <piscisaureus_>which is ehm, work, because linux and windows implement that very differently
16:13:35  <piscisaureus_>pquerna: we also want to write an experimental epoll backend for linux that uses EPOLLET
16:14:27  <piscisaureus_>that sentence was full of pleonasm's
16:28:14  <mmalecki>kernel noob, is this going to be faster?
16:30:01  <pquerna>edge triggered? in theory. i guess. its hard to prove really.
16:30:16  <pquerna>because most systems that are 'big' are so ingrained in level triggering
16:30:47  <pquerna>in the end though, it might all be a wash, but a fun experiment perhaps in libuv where its possible to do it
16:36:59  <piscisaureus_>pquerna: well bnoordhuis had some benchmarks that were dominated by epoll_ctl. With edge-triggered epoll it should be possible to make less epoll_ctl calls.
16:39:01  <bnoordhuis>mmalecki, piscisaureus_, pquerna: dominated by epoll_ctl with specific workloads (lots of active file descriptors, tiny reads/writes)
16:39:14  <bnoordhuis>still, that describes a lot of networked applications
16:40:23  <bnoordhuis>pquerna: side note, the thundering herd problem has been long solved on linux
16:41:19  <AndreasMadsen>isaacs: who is assigned to review cluster patches, ryan did it before?
16:41:47  <pquerna>bnoordhuis: so i should put 80 processes with a listening socket all call non-blocking accept at the same time?
16:42:24  <indutny>pquerna: I miss isolates too
16:42:26  <bnoordhuis>pquerna: yes. only one process should wake up
16:42:45  <bnoordhuis>eh well, non-blocking...
16:43:18  <bnoordhuis>epoll_wait has been kind of inconsistent in that respect
16:43:37  * bnoordhuismakes a note to check that again
16:43:44  <piscisaureus_>pquerna: well it was not as if isolates were going to fix the thundering herd problem
16:44:00  <piscisaureus_>bnoordhuis: well edge-triggered should definitely solve the thundering herd problem
16:44:32  <bnoordhuis>piscisaureus_: edge-triggered i/o is only relevant once you've accepted the connection
16:44:41  <bnoordhuis>piscisaureus_: pquerna is talking about the accept() call itself
16:44:56  <piscisaureus_>bnoordhuis: no, epoll_wait returning would remove the fd from the readable set
16:45:40  <bnoordhuis>yeah... that's what i mean with epoll_wait has not always been consistent in that respect
16:45:51  <piscisaureus_>bnoordhuis: with level-triggered the fd would stay in the readable set until the backlog has been cleared
16:46:00  <piscisaureus_>so it might wake up many threads
16:46:10  <bnoordhuis>i need to dig up an old kernel and try it
16:46:37  <piscisaureus_>hmm
16:46:55  * isaacsjoined
16:47:06  <piscisaureus_>actually that would also be bad. what if there are 2 pending connections? -> one process would have to accept both
16:47:14  <piscisaureus_>I guess only benchmarks can tell
16:48:30  <bnoordhuis>maybe we should pick a minimum supported kernel
16:48:46  <piscisaureus_>bnoordhuis: about that cares patch
16:48:51  <piscisaureus_>bnoordhuis: I don't see it either
16:48:55  <bnoordhuis>i've been supporting everything from 2.6.9 onwards and it shows :/
16:49:07  <piscisaureus_>bnoordhuis: the only thing I can think of is that it might overflow the ret buffer by 1 byte
16:49:29  <piscisaureus_>because it writes a trailing \0 after every entry
16:49:50  <bnoordhuis>piscisaureus_: i reckoned it was an underflow from 0 to (size_t) -1 since it's subtracting
16:50:23  <bnoordhuis>morning isaacs
16:50:55  * pieternjoined
16:51:17  <AndreasMadsen>isaacs: who is assigned to review cluster patches? - ryan did it before
16:51:23  <CIA-101>node: Ben Noordhuis master * r832efb1 / test/simple/test-isolates-parent-exit.js : test: remove deprecated isolates test - http://git.io/C6kswg
16:51:37  <bnoordhuis>i vote isaacs!
16:51:50  <mmalecki>lol
16:52:19  <mmalecki>nice democracy you guys have there :)
16:54:34  <AndreasMadsen>Hopefully I won't end up with a random guy who thinks they can have control wish worker there will get a specific client.
16:55:49  <AndreasMadsen>The number of people there have wrote me personally on mail is countless.
16:55:58  <bnoordhuis>AndreasMadsen: don't take this the wrong way but... wut?
16:56:17  <bnoordhuis>you're afraid of people trying to influence you?
16:56:41  <tjfontaine>I think s/wish/which/, and maybe he means which subchild gets a specific client?
16:56:50  <AndreasMadsen>bnoordhuis: influence what?
16:57:22  <bnoordhuis>ah, the language barrier...
16:57:28  <AndreasMadsen>tjfontaine: when talking about clusters I replace child with worker.
16:57:38  <bnoordhuis>AndreasMadsen: "Hopefully I won't end up with a random guy who thinks they can have control wish worker there will get a specific client." <- i don't understand what you mean
16:57:39  <tjfontaine>AndreasMadsen: I was trying to clarify for bnoordhuis
16:57:44  <isaacs>i can review cluster patches
16:58:00  <AndreasMadsen>^ https://github.com/joyent/node/pull/2661
16:58:05  <isaacs>thanks
16:58:08  * dapjoined
16:58:12  <bnoordhuis>tjfontaine: yes, that sounds plausible but i'd rather hear it from the horse's mouth :)
16:58:34  <bnoordhuis>AndreasMadsen: not that i'm comparing you to a horse
16:58:38  <bnoordhuis>i rather like horses
16:58:40  * bnoordhuisducks
16:59:53  <isaacs>AndreasMadsen: so, people ask to be able to have a specific child process handle a specific request, rather than have them automatically distributed?
17:00:22  <AndreasMadsen>isaacs: yes, a specific type of requests
17:01:04  <AndreasMadsen>isaacs: and workers should not run the same code.
17:01:19  <isaacs>oic, so you could have one type of worker for a TCP server, and another for a HTTP server or something.
17:01:27  <isaacs>that sounds complicated.
17:01:56  <AndreasMadsen>isaacs: no one worker to handle HTTPS certificate1 and one worker to handle HTTPS certificate2.
17:02:03  <isaacs>oh, jeez.
17:02:04  <isaacs>even worse.
17:02:12  <mmalecki>isaacs++
17:02:21  <indutny>that won't work :D
17:02:29  <indutny>you may not even expect it to work
17:02:45  <indutny>I suggest using different certificates on master
17:02:52  <indutny>and balance cleartext http
17:03:09  <mmalecki>indutny++
17:03:11  <AndreasMadsen>indutny: I do to
17:03:16  <AndreasMadsen>s/to/too
17:03:23  <mmalecki>node-http-proxy is pretty good at this stuff
17:03:26  <indutny>so what's the case?
17:03:38  <AndreasMadsen>But then: "the code running in workers ****must*** be different in each worker" - they never say why.
17:03:38  <indutny>ah
17:03:53  <indutny>it may be different
17:03:58  <indutny>it's cool
17:04:04  <piscisaureus_>it's dumb
17:04:09  <indutny>you can distribute things like hook.io does
17:04:19  <indutny>different processes will server different purposes
17:04:20  <piscisaureus_>people can just roll their own if they really need that
17:04:28  <piscisaureus_>or they can use the IPC channel directly
17:04:30  <mmalecki>AndreasMadsen: tell them to open an issue with explanation
17:04:35  <indutny>piscisaureus_: yeah
17:04:36  <isaacs>node is not every feature for every use case.
17:04:39  <indutny>that's what I meant
17:04:51  <indutny>users just should be able to do that
17:05:03  * travis-cijoined
17:05:03  <travis-ci>[travis-ci] joyent/node#374 (master - 832efb1 : Ben Noordhuis): The build is still failing.
17:05:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/2e2df04...832efb1
17:05:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/634400
17:05:03  * travis-cipart
17:05:03  <indutny>w/o copying code from core
17:05:06  <piscisaureus_>isaacs: that's what I thought when we removed listenFD >:-)
17:05:40  <isaacs>piscisaureus_: sure, we just didn't realize every place that was being used.
17:06:01  <isaacs>the cluster use-case was handled, but the sockets-across-sunos-zones wasn't.
17:08:02  <isaacs>anyway..
17:08:53  <isaacs>the point is, at this point, expanding the boundaries of node requires a lot of justification. child processes in cluster can all run the same code. it's fine.
17:09:12  <mmalecki>so, can anyone review my pull request, which is valid again (thanks to removing isolates)?
17:10:22  <mmalecki>https://github.com/joyent/node/pull/2454
17:11:12  <AndreasMadsen>mmalecki: It is not difficult to handle in userland, I it is something cluster clearly shouldn't handle that way. If they want to use cluster they should use filter the request in workers by cleartext and call a clientTypeHandler. This way they can balance there clients without complex code. But somehow that isn't good enough. If they can't explain it to me - nobody will understand it.
17:11:51  <bnoordhuis>mmalecki: it lgtm last time i reviewed it
17:12:12  <mmalecki>bnoordhuis: is it green for github or should I rebase?
17:12:37  <indutny>green green
17:12:47  <mmalecki>thanks, indutny :)
17:13:04  * TooTallNatejoined
17:13:22  <indutny>isaacs: I think we can introduce one useful criteria for getting new functionality in the core
17:13:45  <indutny>isaacs: like "It's impossible to do it in userland w/o copying parts of code from core"
17:13:59  <mmalecki>indutny++, great idea
17:14:18  <indutny>I seen a lot of that stuff
17:14:34  <indutny>that means our API is lacking extensibility
17:14:54  <mmalecki>actually, can we discuss spawn(..., {ipc: true}) idea before merging that?
17:14:57  <indutny>but that shouldn't be done prematurely
17:15:16  <mmalecki>it makes it more generic, and ihmo, better
17:16:35  <indutny>mmalecki: I wasn't talking about your code actually :D
17:16:45  <mmalecki>indutny: I know
17:16:52  <indutny>ok, just FYI
17:18:11  <isaacs>indutny: i dont' think that's a high enough bar.
17:18:25  <indutny>isaacs: that's just one criteria
17:18:37  <indutny>isaacs: there're others
17:18:43  <isaacs>indutny: sure, let's add lots of necessary conditions. :)
17:18:46  <indutny>like "it's too high-level for core"
17:18:53  <isaacs>just don't imply that any of them are sufficient
17:18:54  <indutny>hahaha ;)
17:19:02  <indutny>haven't said that
17:19:12  <isaacs>i'd say, "If it's possible to do in an addon, it doen'st belong in core"
17:19:14  <isaacs>for most things
17:20:11  <mmalecki>"if implementing in user space requires using some implementation detail" might be the next one
17:20:18  <indutny>I can ammend: "if it's possible to do it without copying code from core in addon, it doesn't belong in core"
17:20:39  <indutny>where "without copying code" applies only for features that are **really** needed
17:21:05  <indutny>or, in other words, highly requested by users
17:21:28  <indutny>we need to write naive-bayes classifier for PR texts
17:21:34  <indutny>like twss.js
17:21:55  <mmalecki>no, we'll actually just use twss.js
17:22:12  <mmalecki>then close it or automatically merge it, depending on the result
17:22:53  <isaacs>mmalecki, indutny: i think this discussion is not really necessary.
17:23:01  <isaacs>we're not going to make a bunch of "must-haves" public, probably.
17:23:10  <indutny>agreed
17:23:15  <indutny>k, gtg
17:23:19  <isaacs>just assume it *won't* go in core, and tell people to deal with it.
17:23:48  <piscisaureus_>I don't know. The API should just be small and flexible.
17:23:54  <isaacs>yeah
17:24:02  <isaacs>if we can deliver more value somehow, we might do it
17:24:21  * orlandovftwjoined
17:24:25  <isaacs>but like, major changes? adding features that can be done in userland? no way.
17:24:45  <piscisaureus_>yup
17:25:09  <piscisaureus_>isaacs: although, why do we have child_process.exec then? :_)
17:25:20  <mmalecki>yeah, so while we're here. https://github.com/joyent/node/pull/2454
17:25:29  <isaacs>we need to be very focused on helping existing programs run more reliably, and provide better tools for making them more stable.
17:26:11  <AndreasMadsen>piscisaureus_: ++
17:26:34  <benvie>js has gotten a long way by simply letting people change almost anything they wanted, even builtin stuff. Inheriting from core and tweaking some functionality/reproducing some code isn't a bridge too far. But being unable to override stuff without redoing it entirely is probably where something is wrong.
17:27:13  <benvie>people can be responsible for their monkeypatches
17:27:22  <tjfontaine>I'm fine with "what can be done in an addon" policy, so long as we can get some conditional/platform depends in npm :)
17:28:38  <isaacs>mmalecki: i think that the default for child_process.fork should be to share stdio with the parent, since that's fastest and usually going to be desired.
17:28:42  <piscisaureus_>tjfontaine: why would you need that? examples
17:29:05  <isaacs>mmalecki: but an option to do the dup dance would be fine, i think, if it doesn't impose too much complexity
17:29:15  <indutny>sorry people for starting that discussion :(
17:29:18  <indutny>really sorry
17:29:18  <mmalecki>isaacs: it's the default with this patch, but it's done with pipe
17:29:26  <mmalecki>isaacs: should I make it use customFds
17:29:27  <mmalecki>?
17:29:27  <tjfontaine>piscisaureus_: for instance I have a replacement dns stack, but to get platform information in windows I need to make native calls, I'd rather not ship an addon module that NOOPs on !win32
17:29:42  <bnoordhuis>anyone else want to review https://github.com/joyent/node/pull/2454 ?
17:29:45  <isaacs>indutny: it's ok :)(
17:30:25  <isaacs>bnoordhuis: i'm looking at it now
17:30:30  <piscisaureus_>tjfontaine: I don't really get it. If you leave out the dependency, then you are not fixing anything.
17:30:35  <piscisaureus_>It just won't work on windows
17:30:57  <tjfontaine>piscisaureus_: well, I want to be able to support windows, but with just an additoinal dependency for that platform
17:31:04  <indutny>so... https://github.com/joyent/node/pull/2454/files
17:31:05  <benvie>I think he's saying he wants support from the npm end for packaging that stuff
17:31:15  <tjfontaine>yes
17:31:17  <indutny>mmalecki: it's just piping info to parent?
17:31:21  <mmalecki>indutny: yes
17:31:25  <isaacs>mmalecki: yes, it should use customFds
17:31:28  <indutny>looks harmless if it works
17:31:39  <isaacs>mmalecki: otherwise we're pumping the bytes through userland
17:31:45  <isaacs>(er, js-land)
17:31:47  <indutny>isaacs: ++
17:31:53  <indutny>wonder-land
17:32:06  <piscisaureus_>mmalecki: yes just set customFDs to [-1, 1, 2]
17:32:07  * bnoordhuisis off to dinner
17:32:10  <mmalecki>isaacs: ok, let me think about a graceful way to handle this
17:32:23  <isaacs>mmalecki: but don't we already do that...? it looks like the line you removed in that patch does exactly that.
17:32:28  <mmalecki>piscisaureus_: it won't have .stdout and .stderr then, would it?
17:32:35  <isaacs>mmalecki: that's correct.
17:32:44  <piscisaureus_>aah, right
17:32:56  <isaacs>mmalecki: so, it sounds like what you want is to dump stdio to the parent's stdio, but *also* grab the bytes in your parent program?
17:32:58  <indutny>oooh
17:32:59  <piscisaureus_>you mean the ChildProcess object needs stdout and stderr streams attached
17:33:08  <mmalecki>isaacs: yeah
17:33:20  <indutny>so commit is not about .silent
17:33:26  <indutny>surprisingly
17:33:30  <indutny>:D
17:33:31  <isaacs>mmalecki: then why not just pass silent:true and do the Stream.pipe yourself/
17:33:56  <indutny>isaacs: if .customFDs is present - pipes won't be created
17:34:06  <indutny>https://github.com/mmalecki/node/blob/ae2a4ee39019542e216919b5691a73fa687be80c/lib/child_process.js#L414
17:34:42  <isaacs>indutny: https://github.com/mmalecki/node/blob/ae2a4ee39019542e216919b5691a73fa687be80c/lib/child_process.js#L416
17:34:42  <piscisaureus_>indutny: no
17:34:49  <isaacs>indutny: if they're set to -1 it will be
17:34:57  <piscisaureus_>indutny: ^- that
17:35:04  <indutny>oh, right
17:35:12  <isaacs>[-1,-1,-1] is the default
17:35:26  <piscisaureus_>people will still be surprised that there is no stdin
17:35:34  <bnoordhuis>customFds is kind of deprecated though, innit?
17:35:42  <piscisaureus_>bnoordhuis: yes and no
17:35:46  <isaacs>bnoordhuis: yeah..
17:35:54  <isaacs>it's not deprecated, it's just hideous
17:36:00  <piscisaureus_>exactly
17:36:22  <piscisaureus_>the problem is not so much that we don't want to support this use case
17:36:22  <bnoordhuis>isaacs: doc/api/child_processes.markdown:There is a deprecated option called `customFds` which allows one to specify
17:36:31  <isaacs>it'd be nice to have something like "silent" or something
17:36:37  <isaacs>bnoordhuis: indeed.
17:37:02  <piscisaureus_>but { customFds: [42, 43, 44] } or { customFds: [server.socket.fd, 1, 2] }
17:37:10  <benvie>it seems to be the only way to accomplish a number of tasks which I assume is why it's in a state of schrodenger cat deprecation
17:37:11  <piscisaureus_>^-- that's the kind of stuff we don't want
17:37:41  <piscisaureus_>people should have the option to:
17:37:45  <piscisaureus_>- use a pipe
17:37:59  <piscisaureus_>- inherit the stdio handle from the parent
17:38:09  <isaacs>piscisaureus_: there's already no support for that, i thought
17:38:11  <piscisaureus_>- (maybe: redirect stderr to stdout or vice versa)
17:38:19  <isaacs>piscisaureus_: customFds must be eiter 0,1,2 or -1
17:38:22  <piscisaureus_>isaacs: yes
17:38:54  <piscisaureus_>isaacs: now we need to make it less hideous
17:38:56  * bbbbjoined
17:38:57  <isaacs>the option should be, for each stdio stream, do you want to inherit the parent's, or expose a Stream object.
17:39:04  <isaacs>anything fancy can be done in JS
17:39:08  <bbbb>indutny, ping?
17:39:12  <indutny>bbbb: pong
17:39:54  <bbbb>indutny, do you know if the rest api for v8's debugger matches the sendmessage stuff used right now?
17:39:58  <piscisaureus_>isaacs: there are two more options I can think of that we may or may not want. Stdio could be a black hole, or people might want to redirect stdout to the parent's stderr
17:40:15  <CIA-101>node: koichik master * rc2dc673 / (lib/http.js test/simple/test-http-after-connect.js):
17:40:15  <CIA-101>node: http: fix http-parser is freed twice
17:40:15  <CIA-101>node: after response to CONNECT/Upgrade request.
17:40:15  <CIA-101>node: Fixes #2704. - http://git.io/npq1Cw
17:40:34  <indutny>bbbb: huh, you mean message formatting, right?
17:41:17  <indutny>bbbb: ah
17:41:31  <bbbb>indutny, i guess, i mean if i were to pipe the rest command directly ie. 'content-length: x\r\n\r\n{...}' to sendmessage would it act the same
17:41:49  <isaacs>piscisaureus_: i think redirecting stdout<->stderr is probably fancy enough to just do in js
17:41:59  <piscisaureus_>isaacs: yes
17:42:03  <indutny>bbbb: sorry, I don't know much about it
17:42:09  <isaacs>piscisaureus_: black hole would be nice, though
17:42:12  <mmalecki>or we could support customFds for fork
17:42:16  <piscisaureus_>isaacs: so have these options
17:42:19  <isaacs>piscisaureus_: i mean, that'd be the fastest, probably
17:42:27  * igorzijoined
17:42:35  <indutny>bbbb: and I naively thought that we'll left socket connections and debugger agent of v8, when isolates will come in
17:43:02  <bbbb>indutny, i thought isolates we on the way out?
17:43:17  <indutny>bbbb: yes, they're already out
17:44:02  <indutny>I think I may try using pipes instead of net connections
17:44:10  <piscisaureus_>{ stdin: 'stream', // 'null', 'stream', 'inherit'.
17:44:10  <piscisaureus_> stdout: 'stream',
17:44:10  <piscisaureus_> stderr: 'stream' }
17:44:18  <piscisaureus_>simple really
17:44:35  <isaacs>piscisaureus_: yeah, that'd be kind of nice.
17:44:44  <isaacs>piscisaureus_: it'd be nice to maybe be able to set them all at once, too.
17:44:51  <isaacs>{ stdio: 'null' }
17:44:57  <piscisaureus_>isaacs: yeah
17:45:09  <mmalecki>that belongs to .spawn, not fork, right?
17:45:10  <isaacs>so stdio could be one of those options, or an object of in/out/er
17:45:15  <piscisaureus_>isaacs: but then we have to do domination rules
17:45:29  <isaacs>also: it'd be nice to have fork and spawn do the same behavior here, as well.
17:45:33  <piscisaureus_>isaacs: { stdio: 'null', stderr: 'inherit' } <-- ?
17:45:44  <isaacs>piscisaureus_: nonono
17:45:52  <mmalecki>piscisaureus_: stderr wins, it's more specific. or throw :)
17:45:55  <isaacs>piscisaureus_: { stdio: { in: 'stream', out:'inherit' } }
17:46:07  <indutny>isaacs: ++
17:46:09  <isaacs>piscisaureus_: or just { stdio: 'stream' }
17:46:09  <mmalecki>isaacs: ++
17:46:11  <indutny>looks good
17:46:14  <piscisaureus_>isaacs++
17:46:22  <isaacs>so the top level option is just 'stdio', period
17:46:34  <mmalecki>so, shall I pull request?
17:46:35  <isaacs>man, removing isolates really makes this much simpler.
17:46:45  * alex_rjoined
17:47:05  <mmalecki>isaacs: you should've seen Charlie after I told him isolates are going away :)
17:47:12  <isaacs>oh?
17:47:29  <AndreasMadsen>mmalecki: :D
17:47:33  <mmalecki>isaacs: I think it was 'I <3 isaacs!' :D
17:47:39  <indutny>hahahaha
17:48:17  <indutny>personally, I think that was a vain try from it's start
17:48:32  <indutny>only one thing I really liked about isolates is debugger
17:48:35  <isaacs>yeah
17:48:46  <isaacs>i don't think it was a vain try. there was a lot of reason to think it'd be good.
17:49:01  <isaacs>if we already knew everything we wouldn't have to try things to find out :)
17:49:05  <indutny>haha :)
17:49:07  <indutny>righto
17:50:00  <indutny>but threads w/o shared data are ... odd
17:50:11  <indutny>shared buffers and addon data doesn't counts
17:50:21  <alex_r>hey all, is there a specific channel more appropriate for n00b libuv questions?
17:50:30  <indutny>alex_r: shoot
17:50:41  <piscisaureus_>yes, #libuv-noob-questions
17:50:44  <isaacs>alex_r: if they're noob libuv questions, then this is the place. noob nodejs questions go in #Node.js
17:51:05  * indutnychanged nick to uvn00b
17:51:21  <uvn00b>oops, wrong room
17:51:28  <mmalecki>lol
17:51:30  * uvn00bchanged nick to indutny
17:51:41  <mmalecki>isaacs: so, should I pull request this stuff?
17:52:02  * piscisaureus_changed nick to noden00b
17:52:12  <isaacs>mmalecki: i'm writing up the plan now, and i'll close this existing one.
17:52:25  <isaacs>mmalecki: but yeah, go ahead and feel free to code it. i think we've got a plan.
17:52:35  <mmalecki>isaacs: sounds good!
17:52:42  <noden00b>isaacs: so will fork() take anything for stdin?
17:52:59  <mmalecki>it shouldn't, imo
17:53:14  <noden00b>isaacs: actually we could have a 'ipc' type as well
17:53:16  * indutnychanged nick to piscisaureus_
17:53:20  <piscisaureus_>hey guys
17:53:26  <piscisaureus_>where can I ask a n00b question?
17:53:31  <alex_r>for now, this is definitely a libuv question: Can libuv listen to a fd/connection that was established by another lib?
17:53:31  * piscisaureus_changed nick to indunty
17:53:31  <noden00b>ask me
17:53:50  <noden00b>piscisaureus_: you wanted me to question me?
17:54:01  <indunty>infinite loop
17:54:09  <mmalecki>I don't think I even
17:54:16  * travis-cijoined
17:54:16  <travis-ci>[travis-ci] joyent/node#375 (master - c2dc673 : koichik): The build is still failing.
17:54:16  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/832efb1...c2dc673
17:54:16  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/634550
17:54:16  * travis-cipart
17:54:34  <indunty>alex_r: I think yes, but noden00b knows better
17:54:58  <noden00b>alex_r: you can
17:55:09  <tjfontaine>alex_r: it's allowed, but I would advise you let only one thing have the responsibility for it
17:55:57  * isaacsso confused
17:56:00  <isaacs>https://github.com/joyent/node/pull/2454#issuecomment-3833276
17:56:07  <noden00b>alex_r: https://github.com/joyent/libuv/blob/master/include/uv.h#L871
17:56:10  <TooTallNate>noden00b: you you bert?
17:56:34  <noden00b>alex_r: actually, that was wrong, sorry
17:56:40  <AndreasMadsen>isaacs: please remember my cluster patch
17:56:58  <noden00b>alex_r: the answer is, you can't :-/. We want to support this though.
17:56:59  <isaacs>piscisaureus, mmalecki: I don't know that we need a ipc option there, because oyu just use fork if you want fancy pants ipc, and set up the stdio however you want it.
17:57:03  <alex_r>gotcha. I am interested in building an erlang c-node that uses libuv for non-blocking communications. The docs for erlang c-nodes show only blocking calls and don't really go into any detail about how to support multiple connections.
17:57:34  <noden00b>alex_r: we want to support this though
17:57:47  <alex_r>There might be a way to initiate the connection from uv, assuming that uv_listen isn't doing anything other than handing the new socket off to on_connect?
17:57:47  <isaacs>AndreasMadsen: yes, that is next on my agenda after getting some coffee :)
17:57:59  <AndreasMadsen>isaacs: thanks
17:58:08  <mmalecki>I know I was forgetting something :/
17:58:09  <isaacs>AndreasMadsen: i'm a bit behind on cluster stuff, so i'll have to spend some time in quiet mode to review everything that's gone on there.
17:58:11  <mmalecki>thanks isaacs!
17:58:38  <indunty>alex_r: I think erlang is spawning thread for each incoming connection
17:58:53  <indunty>alex_r: I mean, this is a usual way to do it in erlang
17:58:57  <AndreasMadsen>isaacs: I will allow it
17:59:08  <noden00b>alex_r: actually the on_connect doesn't receive anything. But it can pick up an incoming connection as a uv_stream_t
17:59:16  * noden00bchanged nick to piscisaureus
17:59:29  <piscisaureus>TooTallNate: what's up?
18:00:01  <TooTallNate>piscisaureus: gonna say that this bad boy should be ready now: https://github.com/joyent/node/pull/2685
18:00:10  <TooTallNate>the $() syntax works very well
18:00:12  <TooTallNate>thanks!
18:00:38  <AndreasMadsen>isaacs: will first begin the next cluster patch on Thursday (or perhaps later) so take your time.
18:01:20  <piscisaureus>TooTallNate: ok, will land
18:01:47  <alex_r>indunty: unless they've made updates to the libs, erl_accept and ei_accept don't spin new threads to handle the incoming connections.
18:02:43  <isaacs>TooTallNate: for a second i thought you were talking about putting jquery syntax somewhere in node.
18:02:54  <tjfontaine>heh
18:03:03  <indunty>alex_r: they do not
18:03:03  <TooTallNate>isaacs: haha
18:03:06  <indunty>alex_r: users do
18:03:13  <CIA-101>node: Nathan Rajlich master * r5e1471c / (tools/addon.gypi tools/gyp_addon):
18:03:13  <CIA-101>node: gyp_addon: link with node.lib on Windows
18:03:13  <CIA-101>node: Closes GH-2685 - http://git.io/9i62FA
18:03:29  <indunty>isaacs: no words
18:03:32  <TooTallNate>piscisaureus: thanks
18:03:34  <isaacs>$(filename).open("r").data(function (chunk) { ... })....
18:03:38  <piscisaureus>TooTallNate: thanks
18:03:42  <isaacs>it'd be kind of cool
18:03:46  <indunty>nooooo
18:03:49  <isaacs>hahah
18:03:58  <isaacs>fsQuery
18:04:07  <isaacs>maybe use CSS selectors to find files
18:04:14  <isaacs>or i guess globs would be more appropriate
18:04:17  <piscisaureus>$(80).listen(function(req, res) {
18:04:21  <isaacs>$("*.js").each(...)
18:04:46  <isaacs>nice
18:04:52  <piscisaureus>$('').listen(
18:04:54  <alex_r>indunty: ah, right. My desire to write/maintain a threaded erlang c-node is low. Eventually, I'd like to be able to take a libuv based c-node and port that to a V8/node.js extension. Am I going about it the worst way?
18:05:52  <piscisaureus>alex_r: c-node, what is that?
18:06:04  <indunty>piscisaureus: some C extensions that can receive ! msgs
18:06:08  <indunty>piscisaureus: http://www.erlang.org/doc/tutorial/cnode.html
18:06:43  <indunty>and send messages of course
18:06:47  <isaacs>alex_r: so.. you'd be able to talk to erlang directly from a node/libuv program?
18:07:01  <isaacs>that'd be kind of awesome.
18:07:03  <alex_r>isaacs: exactly.
18:07:35  <indunty>isaacs: what is awesome about it?
18:07:38  <alex_r>isaacs: the amqp lib is a bit slow when you start pushing a lot of traffic
18:07:49  * dshaw_joined
18:07:53  <alex_r>isaacs: otherwise, I'd just use rabbit and be done with it.
18:07:55  <piscisaureus>alex_r: I think you will have to use erl_receive_msg and friends
18:08:03  <piscisaureus>alex_r: so basically libuv won't help you
18:08:23  <indunty>piscisaureus: I think alex_r wants to pass fds from node to erlang and back
18:08:41  <indunty>piscisaureus: and do some other stuff with node
18:08:52  <indunty>alex_r: correct me if I'm wrong
18:08:57  <piscisaureus>hmm.
18:09:07  <piscisaureus>I may be dumb, sorry
18:09:15  <alex_r>indunty: really I want erlang to see a node.js service as an erlang process.
18:09:26  <indunty>oh, even better
18:09:34  <alex_r>indunty: end game is simple, low latency messaging between the two.
18:09:41  <indunty>yeah
18:09:50  <indunty>looks interesting
18:10:04  <alex_r>indunty: am I the ideal person to build it? Nope : ) But it's something I need.
18:10:16  <indunty>haha
18:10:52  <indunty>I don't know much about c-nodes
18:11:11  <indunty>so I have the dubious assistance in that question
18:11:27  <alex_r>indunty: there's not a ton of documentation about them, honestly. I haven't really seen a decent reference implementation anywhere : \
18:11:59  <indunty>isaacs: so basically you should choose
18:12:02  <indunty>oops
18:12:04  <indunty>sorry isaacs
18:12:22  <indunty>alex_r: so basically you should choose, either you want to start node from erlang, or erlang from node
18:12:27  <indunty>or do IPC
18:12:42  <indunty>IPC seems to be most simple
18:12:56  <indunty>but I think you don't even need c-nodes for that
18:12:59  <alex_r>indunty: end of the day, starting node from erlang is the end-game. Erlang has supervisor trees that would let me control node apps...
18:13:07  <alex_r>indunty: sorry, IPC?
18:13:15  <alex_r>interprocess communication?
18:13:25  <indunty>alex_r: http://en.wikipedia.org/wiki/Inter-process_communication
18:13:26  <indunty>yes
18:13:36  <indunty>alex_r: so erlang can spawn node processes
18:13:38  <alex_r>indunty: doesn't that assume the same box?
18:13:46  <indunty>aah
18:13:59  <indunty>yes it does
18:14:05  <indunty>but you can have erlang nodes on each box
18:14:19  <indunty>each will wrap node process
18:14:24  * mraleph1joined
18:14:30  <indunty>and handle IPC with it
18:14:41  <alex_r>interesting
18:15:10  <isaacs>alex_r: or you could more easily swap out the spidermonkey implementation in couchdb with node.js
18:15:19  <indunty>isaacs: someone did that
18:15:33  <isaacs>yeah, but i keep not seeing it in real life :)
18:15:46  <indunty>me too :)
18:15:55  <indunty>fck couchdb, use bptree :D
18:15:56  <indunty>haha
18:16:00  <alex_r>isaacs: you just lost me a little ; )
18:16:45  <indunty>brb
18:17:07  * travis-cijoined
18:17:07  <travis-ci>[travis-ci] joyent/node#376 (master - 5e1471c : Nathan Rajlich): The build is still failing.
18:17:07  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/c2dc673...5e1471c
18:17:07  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/634609
18:17:07  * travis-cipart
18:19:31  <alex_r>isaacs: were you saying that couchdb has already figured this problem out? I guess I could source dive it and find out for myself : )
18:20:06  <isaacs>alex_r: not official couchdb. afaik, they talk to sm over stdio
18:20:08  <isaacs>sm = spidermonkey
18:20:19  <isaacs>but that might be out of date info
18:20:31  <isaacs>could be talking to spidermonkey C api these days, i dunno
18:20:41  <alex_r>isaacs: thanks, still good to know. I may reach out to some couch people then : )
18:20:56  <isaacs>someone did writing a thing where you could swap that out with node.js, but besides people talking about it at conferences, i've never seen it in action
18:21:16  <indunty>isaacs: team.fm is using it
18:21:20  <indunty>AFAIK
18:21:23  <isaacs>oh, neat
18:21:34  <indunty>I've worked with them in 2011
18:22:22  <indunty>and they're also implemented their own auth for couchdb, based on LDAP :P
18:22:25  <indunty>that was awful
18:22:34  <indunty>but team was nice
18:22:47  <alex_r>LDAP makes me sad
18:23:08  <alex_r>thanks very much all, this has been very helpful. Sounds like I was probably over-thinking things : )
18:25:58  * bbbbquit (Ping timeout: 252 seconds)
18:26:48  <toothr>is it possible to to integrate libuv with another event loop? eg within a GUI app? i see there's uv_run_once, is that what I should be using?
18:28:36  <TooTallNate>toothr: i'm in the same boat, so i don't think there's an elegant way to do it
18:29:12  <TooTallNate>uv_run_once kinda works, but it's also like an endless loop since you're bouncing back and forth between loops constantly
18:29:17  <TooTallNate>eating up cpu
18:30:31  <toothr>i was mostly interested in filesystem events
18:31:31  <toothr>i'll worry about this later, thanks for the input
18:33:09  * dshaw_1joined
18:34:16  * dshaw_quit (Ping timeout: 244 seconds)
18:50:06  <TooTallNate>piscisaureus: what does the /m flag do to msbuild?
18:50:17  <TooTallNate>you guys use it in the vcbuild.bat
18:50:58  <piscisaureus>TooTallNate: set the number of cpus to use
18:50:59  <piscisaureus>I am off
18:51:00  <piscisaureus>bye
18:52:46  * brsonjoined
18:55:45  * piscisaureusquit (Ping timeout: 256 seconds)
19:02:20  * DrPizzaquit (*.net *.split)
19:02:36  * DrPizzajoined
19:05:12  * `3rdEdenjoined
19:14:07  <benvie>aye event loop
19:14:18  <benvie>need to get some webkit/chrome up in here
19:15:19  * bbbbjoined
19:19:30  * mikealjoined
19:32:07  * dshaw_1quit (Ping timeout: 240 seconds)
19:33:00  * dshaw_joined
19:37:19  <CIA-101>libuv: Ben Noordhuis master * re53302f / include/uv.h :
19:37:19  <CIA-101>libuv: Explicitly export libuv symbols if gcc >= 4.
19:37:19  <CIA-101>libuv: Only export symbols that are part of the libuv API, hide everything else.
19:37:19  <CIA-101>libuv: Prevents symbol clashes in applications and libraries that depend on libuv and
19:37:19  <CIA-101>libuv: speeds up link times to boot. - http://git.io/zUlayw
19:37:19  <CIA-101>libuv: Ben Noordhuis master * r4a5f3bb / (src/unix/eio/config_linux.h src/unix/eio/eio.c):
19:37:19  <CIA-101>libuv: eio: don't use futimes() on linux
19:37:20  <CIA-101>libuv: uclibc does not provide the syscall wrapper. Translate it into a direct utimesat
19:37:20  <CIA-101>libuv: syscall if available, else fail with ENOSYS. - http://git.io/VemW0w
19:39:18  * travis-cijoined
19:39:19  <travis-ci>[travis-ci] joyent/libuv#81 (master - 4a5f3bb : Ben Noordhuis): The build is still failing.
19:39:19  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/65bbf02...4a5f3bb
19:39:19  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/634877
19:39:19  * travis-cipart
19:40:36  <bnoordhuis>brson: do you need a hand or some pointers on how to integrate libuv?
19:48:38  <tjfontaine>also if uv_run_once is causing a lot of cpu time, then you're probably calling it too often :)
19:51:23  * bbbbchanged nick to bmeck
19:51:30  * bmeckchanged nick to bradleymeck
20:03:11  * isaacsquit (Remote host closed the connection)
20:10:17  * isaacs_mobilejoined
20:10:30  * mikealquit (Quit: Leaving.)
20:13:33  <indunty>oh, __attribute__ black magic
20:18:03  * `3rdEdenquit (Quit: Leaving...)
20:26:19  * pieternquit (Quit: pietern)
20:30:18  * `3rdEdenjoined
20:31:51  * creationixjoined
20:33:04  <CIA-101>libuv: Nathan Rajlich v0.6 * rdbc046c / (include/uv.h src/unix/error.c): Add EXDEV to the errno map. - http://git.io/FGtmgw
20:34:45  * travis-cijoined
20:34:45  <travis-ci>[travis-ci] joyent/libuv#82 (v0.6 - dbc046c : Nathan Rajlich): The build is still failing.
20:34:45  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/d33ccb0...dbc046c
20:34:45  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/635115
20:34:45  * travis-cipart
20:34:49  <brson>bnoorduis: I would welcome any suggestions. If you are concerned about our current mess, then I want to assure you that I know we are doing some dumb things :)
20:36:12  <brson>*bnoordhuis
21:03:47  * mraleph1quit (Quit: Leaving.)
21:05:10  * isaacs_mobilequit (Remote host closed the connection)
21:10:51  * `3rdEdenquit (Quit: Leaving...)
21:13:26  * pieternjoined
21:15:58  * isaacsjoined
21:24:12  <isaacs>AndreasMadsen: the new cluster stuff is pretty awesome. i hadn't really been paying much attention to it for a while, but this is really nie.
21:24:13  <isaacs>*nice
21:24:22  <AndreasMadsen>hi
21:24:39  <isaacs>reviewing that pull req now, but first had to get caught up on how it all actually works :)
21:25:04  <AndreasMadsen>isaacs: that's cool :)
21:25:37  <AndreasMadsen>going to bed
21:26:25  * AndreasMadsenquit (Remote host closed the connection)
21:29:23  * mikealjoined
21:31:58  * paddybyersquit (Quit: paddybyers)
21:32:13  * mikealquit (Client Quit)
21:32:38  * paddybyersjoined
21:38:28  * theColejoined
22:06:23  * bradleymeckquit (Quit: Leaving)
22:13:04  * dannycoatesjoined
22:16:00  <isaacs>bnoordhuis: still around?
22:16:05  <bnoordhuis>isaacs: yes
22:16:16  <isaacs>bnoordhuis: anything else left to do to remove isolates?
22:16:30  <bnoordhuis>isaacs: no. it's dead, jim
22:16:46  <isaacs>i see the big patch there, but just want to make sure that indutny and andreasmadsen had a chance to make sure the parts that touched their things looks ok
22:17:00  <bnoordhuis>yep, it's been reviewed in-depth
22:17:30  <isaacs>i'm going to cut 0.7.3 tomorrow.
22:17:30  <isaacs>sweet.
22:17:34  <isaacs>thank you very much.
22:17:55  <bnoordhuis>i can honestly and with a straight face say that the pleasure is all mine :)
22:28:41  <dap>hi mraleph
22:34:09  * mraleph1joined
22:42:48  * mraleph1quit (Quit: Leaving.)
22:49:18  * piscisaureusjoined
22:49:35  * piscisaureuschanged nick to piscisaureus_
22:53:18  * mikealjoined
22:57:42  <isaacs>bnoordhuis: you know what this is about?
22:57:44  <isaacs>Assertion failed: (handle->InternalFieldCount() > 0), function Unwrap, file ../src/node_object_wrap.h, line 52.
22:57:45  <isaacs>Command: out/Release/node /Users/isaacs/dev/js/node-master/test/simple/test-script-new.js
22:58:43  <bnoordhuis>isaacs: yes. i suspect something in v8 has changed because none of the relevant code in node has
22:58:57  <isaacs>interesting
22:58:59  <bnoordhuis>it's not caused by the isolates back-out if that's what you're wondering
22:59:21  <isaacs>well, even if it was, the total number of tests passing went up considerably :)
22:59:28  <isaacs>breaking one is worth passing an extra 10 or so
22:59:29  <bnoordhuis>heh, net win
22:59:31  <isaacs>exactly
22:59:43  <isaacs>but assertion errors are always kind of scary to me.
22:59:54  <isaacs>since they're fundamentally un-handle-able in node programs
23:00:18  <bnoordhuis>true, but this particular case boils down to -> node -e '(new (require("vm").Script)("")).runInNewContext.call("")'
23:00:21  <bnoordhuis>should be pretty rare
23:03:26  * theColequit (Ping timeout: 240 seconds)
23:13:40  * mikealquit (Quit: Leaving.)
23:14:35  <isaacs>bnoordhuis: +/- update to v8 3.9? we're still in an unstable branch, but it seems kind of nice to lock our 07/08 to v8 v3.8
23:15:09  <bnoordhuis>isaacs: uhm, let me check the feature list
23:15:11  * paddybyersquit (Quit: paddybyers)
23:15:49  <isaacs>their changelog sounds like all good things. i'm sure they would have mentioned any new bugs they put in ;)
23:17:16  <bnoordhuis>isaacs: seems there are no shocking new features in 3.9 so far
23:17:37  <isaacs>i'll try it out, see if it breaks anything significant.
23:17:40  <isaacs>thanks
23:19:05  <bnoordhuis>isaacs: v8 uses wrap-around versioning, right? as in 3.9.0 is really 3.8.10
23:19:19  <isaacs>oh, i think it's worse than that
23:19:25  <isaacs>they use weekly-release versioning
23:19:38  <bnoordhuis>right
23:19:55  <bnoordhuis>so just stay six weeks behind to give the v8 guys time to iron out the bugs
23:19:55  <isaacs>and when they start 3.9, they start doing,, etc
23:20:21  <isaacs>so, bleeding-edge and trunk are just two separate trains
23:20:40  <isaacs>but it's not wraparound, exactly
23:20:59  <isaacs>node 0.6 is on right now
23:21:20  <isaacs>er.. it was last time, before i updated it :0
23:21:21  <isaacs>:)
23:21:24  <bnoordhuis>:)
23:22:02  <bnoordhuis>seems like a lot of effort to back-port all those fixes, i don't think
23:22:38  <bnoordhuis>mraleph: why?
23:24:06  * benviequit
23:24:45  * benviejoined
23:27:03  * piscisaureus_quit (Ping timeout: 265 seconds)
23:29:12  * piscisaureus_joined
23:31:44  <isaacs>doens't break any tests that weren't already broken.
23:32:30  <isaacs>ok, landing it.
23:35:17  <bnoordhuis>brson: let me read up on the code. the main thing you could benefit from is having c code call rust functions but i see on the ML that you're aware of that :)
23:36:08  <isaacs>ok, v0.7.3 branch created. we're getting closer to 1-day feature lock. I'll branch 0.6.11 tomorrow.
23:36:31  <brson>bnoorduis: yeah, the main reason we have made so little progress is due to deficiencies in our FFI. Hopefully in the next month or so we will have the last two pieces of the FFI puzzle
23:36:33  <mmalecki>what's 1-day feature lock?
23:37:02  <mmalecki>no new features in release day?
23:37:10  <mmalecki>s/in/on/
23:38:46  * skabbesjoined
23:40:25  <bnoordhuis>mmalecki: yes
23:41:00  <mmalecki>damn. not sure if I can write this stdio stuff today
23:41:38  <mmalecki>I'll try tho, I have some energy drinks lying around
23:42:11  <mmalecki>s/lying/laying/
23:42:21  <bnoordhuis>mmalecki: there's always next week
23:42:31  <mmalecki>I think?
23:42:46  <mmalecki>it's laying or lying around?
23:42:48  * mmaleckigoogles
23:45:00  <isaacs>hm... what happened to CIA?
23:45:58  <mmalecki>it's not safe to ask such questions here, sir.
23:46:30  <mmalecki>it's lying around in this case
23:46:48  <CIA-101>node: Andreas Madsen master * r23514fc / doc/api/cluster.markdown : [doc] cluster: remove part about autoFork since this do not exist - http://git.io/ijgkLQ
23:46:50  <CIA-101>node: Andreas Madsen master * r1595a6e / lib/cluster.js :
23:46:50  <CIA-101>node: cluster: use process.disconnect method
23:46:50  <CIA-101>node: After adding a .disconect method and connected flag in child_process
23:46:50  <CIA-101>node: we should no longer use the process._channel object. - http://git.io/7ESKng
23:46:51  <CIA-101>node: Andreas Madsen master * ra208720 / lib/cluster.js :
23:46:51  <CIA-101>node: cluster: simplify process event handling
23:46:52  <CIA-101>node: This simplify the internalMessage and exit event handling
23:46:52  <CIA-101>node: And simply relay message and error event to the worker object
23:46:53  <CIA-101>node: Note that the error event was not relayed before - http://git.io/BKp0xg
23:47:24  <isaacs>ahh, there it is
23:47:29  <isaacs>wow, quite a lag
23:49:49  <TooTallNate>isaacs: github is acting weird right now :\
23:50:01  <isaacs>ah
23:50:01  <isaacs>ok
23:50:12  <isaacs>TooTallNate: btw, that glob stuff..
23:50:21  <isaacs>** is really a huge pita
23:50:28  <isaacs>kind of wish that'd never been invented... :)
23:50:54  <TooTallNate>haha, where did i mention that?
23:51:02  <TooTallNate>oh you mean in the node-gyp source?
23:51:11  <isaacs>oh, i thought you'd commented on the bug
23:51:17  <isaacs>about it not working quite right on windows
23:51:23  <isaacs>the absolute/relative stuff
23:51:40  <TooTallNate>just like "C:\something" doesn't work
23:51:45  <TooTallNate>anything absolute
23:51:47  <isaacs>right
23:52:06  <isaacs>so, part of the problem is the clever way that i approached handling **
23:52:12  <TooTallNate>not a huge deal, i don't *need* it
23:52:16  <isaacs>heh
23:52:22  * isaacsis obsessive. it must be correct.
23:52:38  <TooTallNate>haha, i fell ya
23:52:46  <TooTallNate>node-gyp is pretty sweet now too
23:52:53  * piscisaureus_quit (Read error: Connection reset by peer)
23:52:54  <isaacs>yeah, i'm really excited about the progress here.
23:52:59  <TooTallNate>detect's msbuild automatically on windows now
23:53:14  <TooTallNate>so you can run it in any kind of command prompt, like git-bash
23:53:19  <isaacs>we've talked about doing basically exactly what you're doing for... i think about as long as i can remember, actually.
23:53:34  <isaacs>but it's so full of sadness and despair.
23:53:38  <isaacs>you are a hero, going there.
23:54:00  <TooTallNate>:) well i wanted the recognition honestly
23:54:12  <TooTallNate>so contributing something valuable helps
23:54:15  <isaacs>yeah, recognition is sweet :)
23:54:31  <isaacs>it's a good motivator, too, because it usually means you're doing something valuable.
23:54:32  <TooTallNate>i want more adoption though! we gotta start pushing for gyp
23:54:38  <isaacs>yeah
23:54:41  <isaacs>there's a ton of inertia.
23:54:52  <mmalecki>well, I hate people begging me for autographs everyday I leave
23:54:54  <isaacs>to get people to use package.json, i sent pull request after pull request.
23:55:08  <TooTallNate>haha, ya i remember that
23:55:12  <TooTallNate>mmalecki: lol
23:55:30  <TooTallNate>isaacs: one outstanding problem though is bundled deps that need to be statically compiled
23:55:51  <TooTallNate>i.e. node-ffi depends on having it's deps/libffi statically compiled before the module is compiled
23:56:04  <isaacs>TooTallNate: right
23:56:14  <TooTallNate>the best solution is to gyp-ize the lib, but that's not always possible
23:56:15  <isaacs>TooTallNate: a good place to start would be with this list: http://isaacs.iriscouch.com/registry/_design/app/_list/needBuild/needBuild
23:56:40  <TooTallNate>isaacs: oh nice list :D
23:56:53  <isaacs>that's every node module that has a pre/post/install script
23:57:13  <TooTallNate>isaacs: but i'm thinking of running "configure", "build" and "clean" hooks, which could be JS files specified in the package.json
23:57:31  <isaacs>oh, actually, this one is better: http://registry.npmjs.org/-/scripts?script=install,preinstall,postinstall
23:57:36  <TooTallNate>isaacs: they could run module-specific build tasks
23:57:45  <isaacs>oh, wait... no, that one doesn't seem to be respecting the "script" argument...
23:58:05  <TooTallNate>is that last one *all* packages?
23:58:19  <isaacs>ahh, it's scriptS: http://registry.npmjs.org/-/scripts?scripts=install,preinstall,postinstall
23:59:05  <isaacs>the goal should be to reduce the surface area.
23:59:24  <isaacs>the problem we're facing is that packages shell out and do all manner of crazy bullshit stuff
23:59:29  <isaacs>that needs to be brought in line
23:59:46  <isaacs>like, we'll execute "node-gyp" if there's a gypfile, and the gypfile can specify X, Y, and Z.