00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:07  * ircretaryjoined
00:00:34  * loladiroquit (Ping timeout: 272 seconds)
00:03:12  * TheJHquit (Ping timeout: 264 seconds)
00:06:12  * stagas_joined
00:06:37  * stagasquit (Ping timeout: 246 seconds)
00:06:43  * stagas_changed nick to stagas
00:27:25  * pooyajoined
00:32:39  * mjr_joined
00:37:42  * benoitcquit (Excess Flood)
00:44:14  * benoitcjoined
00:53:36  * indexzeroquit (Quit: indexzero)
01:01:36  * warzpart
01:10:16  * pooya_joined
01:10:49  * felixge_quit (Ping timeout: 244 seconds)
01:14:00  * pooyaquit (Ping timeout: 264 seconds)
01:14:00  * pooya_changed nick to pooya
01:16:36  * EhevuTovquit (Quit: This computer has gone to sleep)
01:19:44  * bnoordhuisquit (Ping timeout: 272 seconds)
01:24:45  * indexzerojoined
01:29:40  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:36:57  * jmar777joined
01:38:59  * EhevuTovjoined
01:47:10  * jmar777quit (Remote host closed the connection)
01:47:49  * jmar777joined
01:52:54  * jmar777quit (Ping timeout: 276 seconds)
01:59:45  * pooyaquit (Quit: pooya)
02:03:48  * loladirojoined
02:23:43  * loladiro_joined
02:24:34  * loladiroquit (Read error: Connection reset by peer)
02:24:34  * loladiro_changed nick to loladiro
02:46:56  * stagasquit (Ping timeout: 252 seconds)
02:47:37  * mikealquit (Quit: Leaving.)
02:52:57  * mikealjoined
02:53:51  * mikealquit (Client Quit)
03:06:46  * mjr_quit (Quit: mjr_)
03:13:52  * paddybyersquit (Ping timeout: 246 seconds)
03:24:00  * mikealjoined
03:46:00  * brsonquit (Ping timeout: 276 seconds)
04:42:34  * wolfeida_quit (Read error: Connection reset by peer)
04:42:48  * wolfeidaujoined
04:53:20  * brsonjoined
05:01:05  * EhevuTovquit (Quit: This computer has gone to sleep)
05:38:25  * TheJHjoined
05:51:00  * TheJHquit (Ping timeout: 252 seconds)
06:06:46  * indexzeroquit (Quit: indexzero)
06:24:05  * karupaneruraquit (Excess Flood)
06:26:36  * karupanerurajoined
06:28:50  * indexzerojoined
06:38:03  * wolfeidauquit (Remote host closed the connection)
06:51:20  * stagasjoined
06:52:32  * mikealquit (Quit: Leaving.)
06:54:06  * mikealjoined
07:10:24  * paddybyersjoined
07:18:16  * mikealquit (Quit: Leaving.)
07:20:04  * benoitcquit (Excess Flood)
07:22:45  * benoitcjoined
07:24:30  * paddybyersquit (Ping timeout: 252 seconds)
07:25:22  * pooyajoined
07:30:42  * paddybyersjoined
07:39:17  * rendarjoined
07:41:04  * mikealjoined
07:53:58  * Raltjoined
08:03:10  * paddybyersquit (Ping timeout: 256 seconds)
08:03:28  * indexzeroquit (Quit: indexzero)
08:03:57  * indexzerojoined
08:10:01  * felixgejoined
08:10:02  * felixgequit (Changing host)
08:10:02  * felixgejoined
08:29:07  * EhevuTovjoined
08:30:18  * loladiroquit (Quit: loladiro)
08:42:04  * paddybyersjoined
08:47:29  * brsonquit (Ping timeout: 252 seconds)
08:56:03  * loladirojoined
09:00:22  * felixgequit (Ping timeout: 246 seconds)
09:01:07  * felixgejoined
09:01:07  * felixgequit (Changing host)
09:01:07  * felixgejoined
09:08:19  * indutnyquit
09:12:07  * loladiroquit (Quit: loladiro)
09:20:32  * indutnyjoined
09:20:37  <indutny>hoya
09:20:53  <indutny>Hangar
09:20:55  <indutny>great
09:21:00  <indutny>now I can write from both mobile and desktop
09:22:04  * pooyaquit (Quit: pooya)
09:27:18  * indexzeroquit (Quit: indexzero)
09:32:34  * `3rdEdenjoined
09:35:43  * felixgequit (Quit: felixge)
09:35:55  * AvianFluquit (Remote host closed the connection)
09:42:39  * felixgejoined
09:42:39  * felixgequit (Changing host)
09:42:39  * felixgejoined
09:51:46  * bnoordhuisjoined
09:57:30  <indutny>bnoordhuis
09:57:32  <indutny>oops
09:57:36  <indutny>bnoordhuis: hey man
09:57:43  <indutny>bnoordhuis: so what have you figured out yesterday?
09:57:47  <indutny>was it slab allocator?
09:58:06  <bnoordhuis>indutny: that it's weak interaction at a distance
09:58:11  <bnoordhuis>iow, not sure yet
09:58:19  <indutny>iow?
09:58:21  <indutny>are you kidding
09:58:34  <bnoordhuis>do i ever jest?
09:58:57  <indutny>yes?
09:58:59  <indutny>:)
09:59:20  <indutny>interesting thing
09:59:27  <indutny>I see some memory leak in master
09:59:41  <indutny>it leaks like a hell
09:59:51  <indutny>bnoordhuis: wanna take a look?
10:00:12  <indutny>https://gist.github.com/79b5268e416d3c170ad8
10:00:16  <indutny>./node 1.js
10:00:25  <indutny>and then
10:00:33  <indutny>ab -c 100 -n 100000 http://localhost:8080/
10:00:39  <indutny>master process is now 680 mb RSS for me
10:00:59  <bnoordhuis>indutny: try --trace-gc
10:01:10  <indutny>good point
10:01:15  <indutny>actually, I was going to make heap dump
10:01:24  <bnoordhuis>or that :)
10:15:58  * felixgequit (Quit: http://www.debuggable.com/)
10:24:41  <indutny>bnoordhuis
10:24:51  <indutny>bnoordhuis: which tool I can use to analyze heap dumps?
10:25:01  <bnoordhuis>indutny: the chrome inspector
10:25:06  <indutny>ah
10:25:07  <indutny>right
10:28:03  <indutny>and how can I do it?
10:28:19  <indutny>nvm
10:32:22  <indutny>erm
10:32:41  * tdb2joined
10:33:18  <indutny>bnoordhuis: https://github.com/joyent/node/blob/master/lib/child_process.js#L157-L189
10:33:23  <indutny>so this .list is populated
10:33:40  <MI6>joyent/libuv: Ben Noordhuis master * c931e31 : unix: make assertion message more descriptive - http://git.io/lSET-w
10:35:06  <indutny>and never cleaned
10:35:07  <indutny>well
10:35:13  <indutny>it's cleaned when server is closed
10:35:17  <indutny>but not before that
10:35:34  <indutny>ah
10:36:05  * travis-cijoined
10:36:05  <travis-ci>[travis-ci] joyent/libuv#1019 (master - c931e31 : Ben Noordhuis): The build is still failing.
10:36:05  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/8e3e60ffbf20...c931e317465b
10:36:05  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/4138841
10:36:05  * travis-cipart
10:36:56  <indutny>no, it's cleaned
10:37:55  <bnoordhuis>is that code in child_process.js new? i don't remember that
10:38:37  <indutny>I don't remember it either
10:38:40  <indutny>but yeah, it's new
10:38:57  <indutny>hm...
10:39:00  <indutny>interesting
10:39:02  <indutny>so
10:39:04  <bnoordhuis>CommitDate: Mon May 14 07:47:52 2012 -0700
10:39:12  <bnoordhuis>not really new. new-ish then
10:39:21  <indutny>this .list seems to have very small lenght
10:39:37  <bnoordhuis>yes, but socket objects can be pretty big
10:39:45  <bnoordhuis>what does it look like in the inspector?
10:40:17  <indutny>it looks like there're a lot of sockets in this list
10:40:29  <indutny>which is odd
10:40:47  <indutny>probably array elements are retained after splice
10:41:08  <indutny>well, really
10:41:11  <indutny>it's 1-2 in length
10:41:14  <indutny>almost every time
10:42:04  <bnoordhuis>indutny: run with --expose-gc and add this: setTimeout(gc, 1000)
10:42:17  <indutny>one sec
10:42:18  <bnoordhuis>or -> if (typeof gc === 'function') setTimeout(gc, 1000);
10:42:21  <indutny>I'll do another heap dump
10:42:30  <indutny>ah, I see your point
10:42:38  <bnoordhuis>oh, if you're doing heap dumps
10:42:48  <bnoordhuis>a full gc is done just before taking the snapshot
10:42:57  <bnoordhuis>so no need in that case
10:43:16  <indutny>ah
10:43:16  <indutny>ok
10:43:47  * hzjoined
10:49:10  <indutny>bnoordhuis: yeah, still the same
10:49:16  <indutny>this.list retains all sockets passed to it
10:50:49  <bnoordhuis>why does console.trace('%j', {}) print '%j'...
10:51:34  <indutny>ahhaha
10:51:59  <indutny>and what should it do?
10:52:15  <indutny>I think console.trace doesn't support any escape sequences
10:52:18  <bnoordhuis>i would expect it to json-ify the argument
10:52:28  <bnoordhuis>yes, it's documented but it's silly if you ask me
10:52:44  <bnoordhuis>and unexpected - because i didn't expect it
10:53:03  <bnoordhuis>i'll open an issue. something for a rainy day
10:53:04  <indutny>aaah
10:53:05  <indutny>stupid me
10:53:13  <indutny>I was logging in a wrong place
10:53:17  <indutny>ok, it leaks like a hell
10:53:20  <indutny>and noone is clearing it
10:53:32  <indutny>shit
10:55:08  <indutny>I wonder why it should be retained
10:55:15  <indutny>and where is Andreas when we need him
10:55:16  <indutny>brb
10:55:20  <indutny>tea and banana
10:55:29  * EhevuTovquit (Quit: This computer has gone to sleep)
10:59:54  <indutny>isaacs committed 8 months ago
10:59:56  <indutny>https://github.com/joyent/node/commit/dceebbfa31a2b82bb534ba120ef9354a7d348f65
10:59:59  <indutny>oh isaacs
11:00:05  <indutny>if only you knew results of it
11:00:58  <indutny>bad news - it's in v0.8
11:19:19  * btraskjoined
11:21:10  * skebcioquit (Read error: Operation timed out)
11:23:06  * skebciojoined
11:35:43  <indutny>bnoordhuis: yt?
11:35:53  <indutny>bnoordhuis: I wanna discuss it with you
11:40:25  * stagas_joined
11:42:14  * stagasquit (Ping timeout: 255 seconds)
11:42:20  * stagas_changed nick to stagas
11:57:28  * AndreasMadsenjoined
11:57:45  <indutny>AndreasMadsen: hello
11:57:49  <AndreasMadsen>indutny: Yep, no problem
11:57:52  <bnoordhuis>indutny: discuss what?
11:57:55  <indutny>so SocketListSend populates list of sockets
11:58:02  <indutny>and never frees it
11:58:09  <indutny>well, it frees it only when server is closed
11:58:17  <indutny>I've removed that code
11:58:21  <indutny>and things are working properly
11:58:22  <indutny>so I wonder now
11:58:28  <indutny>why do you need to keep this list
11:58:39  <indutny>AndreasMadsen: ^
11:58:47  <indutny>bnoordhuis: (if you have any ideas) ^
11:58:58  <AndreasMadsen>Server.close() emits close when all sockets are closed.
11:59:22  <indutny>yes, I know
11:59:29  <indutny>but look at the code
11:59:43  <indutny>this list will have all sockets sent to another processes
11:59:47  <indutny>until server will be closed
12:00:11  <indutny>which eventually occupy all available memory
12:00:13  <AndreasMadsen>indutny: indutny, but sockets don't emit close on the master end, so in order to known when all sockets are closed the list is fetched when server.close is called.
12:00:32  <indutny>which is awkward
12:00:35  <indutny>so
12:00:41  <indutny>why do you need this list after all
12:02:04  <AndreasMadsen>indutny: I don't know how much the list is really needed, but it was made to avoid API differences between the "server as a master" and the "server as a server"
12:02:11  <AndreasMadsen>cases.
12:02:14  <indutny>erm
12:02:23  <indutny>explain
12:02:31  <indutny>I don't see where it is used at all
12:02:36  <indutny>it isn't exposed to any apis
12:02:57  <indutny>I suspect same can be applied to SocketListReceive
12:03:14  <AndreasMadsen>The API differences (there could have been) is in when server.on('close') is emitted.
12:05:04  <indutny>and?
12:05:26  <indutny>why do you need all sockets in lsit?
12:05:30  <indutny>s/lsit/list
12:06:50  <MI6>joyent/node: Ben Noordhuis master * e4598aa : gitignore: ignore perf data files - http://git.io/sqK43g
12:07:42  <indutny>AndreasMadsen: so can you please explain this API differencies in detail?
12:07:52  <AndreasMadsen>yep
12:15:30  <indutny>?
12:15:51  <AndreasMadsen>I'm here
12:16:04  <indutny>so
12:16:13  <indutny>I'm trying to figure out
12:17:06  * sgallaghjoined
12:17:18  <AndreasMadsen>In the normal case `server.on('close')` would be emitted when all sockets are closed. In the child.send case server.on('close') would be emitted instantaneously assuming that all sockets where send to another process.
12:20:04  <indutny>ok, I got it
12:20:09  <indutny>AndreasMadsen: thank you
12:20:13  <AndreasMadsen>indutny: cool
12:20:38  <AndreasMadsen>indutny: you should know that you where the one I originally discussed all this with ;)
12:20:53  <indutny>yeah, I remember it
12:20:59  <indutny>and remember not looking carefully into it
12:21:02  <indutny>my fault afterall
12:23:45  <AndreasMadsen>indutny: Personally I think that removing the SocketList would be the correct decision, after all its such a rare case and could be done in userland if truly needed.
12:24:59  <indutny>well, I think I'll either workaround it
12:25:10  <indutny>or just make behaviour a little bit different
12:25:44  <AndreasMadsen>Of cause finding a way to emit socket.on('close') in both master and worker would be the best solution.
12:26:19  <AndreasMadsen>indutny: cool, I will will keep an eye on you.
12:26:23  <indutny>haha
12:26:25  <indutny>deal
12:37:18  * qmx|awaychanged nick to qmx
12:46:14  * stagasquit (Ping timeout: 255 seconds)
13:43:48  * Gu_______joined
13:48:12  * hzquit (Ping timeout: 264 seconds)
13:48:25  * jmar777joined
13:50:47  * hzjoined
13:53:00  <tdb2>Are there plans to flatten-out the uv.h, for instance to use vanilla enums() instead of macros
13:56:17  <indutny>nothing I aware of
13:56:27  * piscisaureus_joined
13:56:34  <indutny>we already use enums where it's possible/needed
13:56:45  <indutny>tdb2: why do you need enums
13:56:51  <piscisaureus_>hey bnoordhuis, is it true that uv-unix asserts if you fail to read_stop when a socket errs?
13:57:10  <tdb2>I was experimenting with SWIG to build a wrapper, but it's very painful with macroed source
13:58:36  <indutny>piscisaureus_: yes
13:58:49  <indutny>piscisaureus_: if only you ain't trolling ben
13:58:54  <indutny>if you're - then no
13:58:59  <piscisaureus_>I am not
13:59:21  <piscisaureus_>So what is felix halim complaining about?
13:59:32  <indutny>well, it's asserting
13:59:36  <indutny>I was just kidding
13:59:45  <indutny>I suppose it's fixed now
13:59:52  <indutny>by emitting more informative assertion
14:00:06  <piscisaureus_>https://github.com/bnoordhuis/libuv/commit/c931e31
14:00:20  <piscisaureus_>on uv-win I just implicitly stop reading
14:01:04  <indutny>piscisaureus_: is it good?
14:01:19  <piscisaureus_>I don't like that libuv requires you to take a particular action
14:01:24  <indutny>piscisaureus_: I mean, repeating code is bad and everything. But at least people won't ignore this error
14:03:26  <indutny>which is what they should do
14:05:50  <piscisaureus_>well, is that so? :-)
14:06:05  <piscisaureus_>indutny: I mean, what if the person want's to call uv_close on a next tick?
14:08:58  <indutny>well
14:09:02  <indutny>I see your point
14:09:55  <indutny>ask ben
14:09:57  <indutny>anyway :)
14:10:12  <indutny>if that would be me behind this commit
14:10:17  <indutny>I'd probably change my mind now
14:10:21  <indutny>or
14:10:25  <indutny>pursue you
14:10:34  <indutny>because it should be consistent anyway
14:12:50  <saghul>I agree with piscisaureus_ here, I don't want to call uv_close early, I guess I could do read_stop, but I rather have libuv do it :-)
14:13:30  <piscisaureus_>yay!
14:13:58  <piscisaureus_>so indutny, I didn't quite got what you said -> do I need to convince you still?
14:14:05  <piscisaureus_>and bnoordhuis: --^ ?
14:14:30  <indutny>you lame guys
14:14:39  <indutny>I agree with you
14:21:09  <saghul>piscisaureus_, indutny now that bnoordhuis is not looking, can you add some input on this please? https://github.com/joyent/libuv/pull/676 :-)
14:27:36  <piscisaureus_>I get unicorn
14:29:23  <mmalecki>piscisaureus_: on my way to AMS
14:29:24  <mmalecki>bnoordhuis: ^
14:29:33  <saghul>stupid GitHub
14:32:19  <saghul>piscisaureus_ seems it's working again now
14:32:35  <piscisaureus_>not here no
14:33:10  <piscisaureus_>saghul: so what do you need the UV__LOOP_DEFAULT flag for?
14:33:58  <saghul>piscisaureus_ the unix loop had an unused flags field which i extended to windows and I thought I could add something useful there
14:34:29  <saghul>piscisaureus_ but that's a detail which I don't mind chaning anyway
14:37:16  <piscisaureus_>saghul: so what run modes do you plan adding after this?
14:37:35  <saghul>piscisaureus_ none
14:38:01  <saghul>this is meant to interrupt a run
14:38:08  <saghul>(the default mode, that is)
14:39:13  <piscisaureus_>I defined "run modes" broadly :-)
14:39:36  <piscisaureus_>I like the minimal principle where we don't have multiple ways to achieve the same thing
14:39:50  <piscisaureus_>but then it seems harmless and all that
14:40:20  <piscisaureus_>saghul: but the next PR that you are going to send is to hav uv_run_timed or uv_run_until_error and so forth ...
14:40:28  <saghul>The idea is that if one wants to run a loop, stop it at some undetermined point and then do whatever the user is forced to write some boilerplate
14:40:36  <piscisaureus_>uv_throw
14:40:40  <piscisaureus_>yes
14:40:42  <saghul>piscisaureus_ no i'm not :-)
14:40:52  * hzquit
14:41:19  <saghul>and the reason to add it would be to provide a nice API for a common/reasonable use case
14:46:35  * c4milojoined
14:49:15  <tdb2>saghul, for my 2c, I think uv_run_mode should be in the loop struct, then you modify that through uv_break(loop*)
14:50:17  <bnoordhuis>piscisaureus_: is it true that uv-unix asserts if you fail to read_stop when a socket errs? <- yes
14:50:21  <saghul>tdb2 that's an implementation detail
14:51:01  <tdb2>But I agree with the principle (thinking from a scripting language perspective)
14:51:42  <piscisaureus_>bnoordhuis: do you think that is more reasonable than implicitly read_stop'ing on EOF/error ?
14:51:46  <tdb2>while(foo->run_once) { last if $break; } will be horribly inefficient
14:52:00  <bnoordhuis>piscisaureus_: well, you need to close the handle anyway
14:52:42  <piscisaureus_>tdb2: why is that inefficient?
14:53:03  <tdb2>In Perl at least, perl -> c -> perl is the most expensive op you can do
14:54:34  <piscisaureus_>tdb2: so why don't you do it in C?
14:54:58  <saghul>bnoordhuis why close? is it not enough to stop it?
14:55:13  <bnoordhuis>saghul: i was just replying to you on the mailing list :)
14:55:28  <saghul>heh :-)
14:56:49  <Gu_______>hello i heard libuv is written in basic is this true
14:57:13  <saghul>piscisaureus_ I don't like to add things to pyuv that don't exist on libuv
14:57:24  <tdb2>piscisaureus_, it depends on the design goal of libuv - does libuv define the API or its bindings?
14:57:43  <bnoordhuis>Gu_______: no, logo. why do you ask?
14:58:05  <Gu_______>cause i want to make bindings for gw basic
14:58:26  <bnoordhuis>Gu_______: i hear good stories about gw basic
14:58:53  <Gu_______>omg i was scared, but logo has unit tests too
14:58:54  <bnoordhuis>saghul: Maybe transient network outages. <- very unlikely though
14:58:55  <Gu_______>http://www.calormen.com/logo/
15:00:38  <bnoordhuis>saghul: by the time the os tcp stack reports the error, the tcp session is effectively dead
15:01:28  <bnoordhuis>at least, with timeout errors. maybe ENETUNREACH
15:02:18  <saghul>bnoordhuis I see. What about doing the read_stop internally?
15:02:23  <saghul>like uv-win
15:02:56  <bnoordhuis>saghul: i could change that. but the assert() is a good reminder that you probably have a bug in your code
15:03:03  <bnoordhuis>which felix had
15:03:46  <saghul>bnoordhuis in pyuv if a handle is garbage collected I uv_close it
15:03:53  <saghul>but it may stay dead for a while
15:03:59  <saghul>I don't really care
15:04:09  <saghul>but a segfault is not very nice
15:04:43  <tdb2>Taking a parallel with lib-poppler - they have a private space which is wrapped by a C++ API. It would be preferred to have one API rather than variations for each language binding ... i.e. a C or C++ clean API
15:04:58  * piscisaureus_quit (Ping timeout: 272 seconds)
15:05:22  <bnoordhuis>saghul: fortunately it's a SIGABRT, not a SIGSEGV. but i see your point :)
15:06:15  <saghul>bnoordhuis I don't mind adding a uv_read_stop in pyuv, but IMHO it would be nice to have libuv take care ;-)
15:07:40  <bnoordhuis>saghul: i'll change it but i like that the assert() helps catch bugs
15:08:05  <bnoordhuis>maybe i'll replace it with some kind of debug tracing mechanism
15:08:21  * lohkeyjoined
15:08:42  <saghul>sounds good to me :-)
15:11:23  <tdb2>saghul, is all of that wrapper code in pyuv hand-crafted ?
15:12:05  * bradleymeckjoined
15:12:29  <saghul>tdb2 yes
15:12:39  <tdb2>(The Perl binding doesn't support uv_spawn - I'm pondering the complexity of adding it ...)
15:13:13  <bnoordhuis>tdb2: what's the issue?
15:13:28  <saghul>tdb2 it was not complicated, but it's tedious to convert Python sequences to char** with all that error checking
15:14:05  <tdb2>I'm pondering a rainy afternoon of either a) write a C wrapper API to bind using SWIG or b) write Perl XS code to wrap uv_spawn
15:14:07  <saghul>the only thing I don't like about uv_spawn is the fact that there is no init for it, like there is for other handles
15:14:33  <tjfontaine>a swig solution should only be used to bootstrap, after that you should be hands on anyway
15:15:38  <bradleymeck>@isaacs nm on pull request need to completely redo it. but I am still doing as suggested with a new uv_loop_t, but all the streams will have to be handled in C++
15:15:45  <tdb2>tjfontaine, depends how clean the structs are. A simple enough struct/procedure can be just named to wrap it
15:18:14  <tdb2>%extend uv_loop_t { int run() { return uv_run($self); } }
15:24:25  * AndreasMadsenquit (Remote host closed the connection)
15:37:20  <MI6>joyent/node: bnoordhuis created branch issue4586 - http://git.io/cvG-HQ
15:37:34  <bnoordhuis>^ review anyone? it's only a couple of lines
15:37:56  <bnoordhuis>really, it's a one-liner fix and 20 lines of comments + a test
15:41:35  * stagasjoined
15:47:38  * philips_quit (Excess Flood)
15:47:58  * AndreasMadsenjoined
15:52:17  * lohkeyquit (Quit: lohkey)
16:00:25  <indutny>hoya
16:00:34  * philips_joined
16:01:38  * qmxchanged nick to qmx|lunch
16:09:45  <bnoordhuis>indutny: ^ review
16:09:51  <bnoordhuis>plus question mark
16:09:55  <indutny>what?
16:09:56  <indutny>review
16:10:00  * mikealquit (Quit: Leaving.)
16:10:02  <bnoordhuis>indutny: http://git.io/cvG-HQ
16:10:17  <indutny>ircrelay killed history
16:10:24  <indutny>looking
16:11:57  * pooyajoined
16:13:04  * piscisaureus_joined
16:13:43  <indutny>bnoordhuis: lgtm
16:15:17  <bnoordhuis>thanks
16:15:26  <MI6>joyent/node: Ben Noordhuis master * c3642aa : http: fix "Cannot call method 'emit' of null" Fix the following exceptio - http://git.io/mYs5xw
16:15:32  * mikealjoined
16:17:19  <mmalecki>bnoordhuis: piscisaureus_ you guys in Amsterdam today?
16:17:32  <bnoordhuis>mmalecki: i'm not but bert is
16:17:36  <mmalecki>I might be up for some late beers, as in, midnight, 1 AM late
16:17:49  <bnoordhuis>you came at the right time. it just started snowing
16:18:14  <mmalecki>bnoordhuis: yeah, same here. snow in Amsterdam is fun, isn't it?
16:18:37  <mmalecki>also, I'm not there just yet. I'm waiting for my plane to Warsaw, then to Amsterdam
16:21:17  <bradleymeck>bnoordhuis: was it you who i was talking about execSync with?
16:21:53  <bnoordhuis>bradleymeck: if you mean if i was the guy that said "not execSync again", then yes
16:22:13  <bradleymeck>no someone was talking about impl it, grr backlog showing nothing in grep
16:23:27  <bradleymeck>on plus side i got a working copy, then found out that it is broken for large outputs so have to move all the streamwraps out to raw uv stream stuff and close the ones in JS manually, not terrible but more than I thought
16:23:49  * AvianFlujoined
16:23:55  <bradleymeck>piscisaureus_: was it you I talked to about execSync?
16:24:00  <bradleymeck>hail AvianFlu
16:24:52  * indexzerojoined
16:25:18  <indutny>all hail the daleks
16:26:27  <bnoordhuis>damnit, forgot to mention the issue # in that commit
16:26:43  <piscisaureus_>bradleymeck: possibly
16:27:01  <MI6>joyent/node: Ben Noordhuis master * 2dbd5a3 : http: fix "Cannot call method 'emit' of null" Fix the following exceptio - http://git.io/Al6WVA
16:27:49  <bradleymeck>piscisaureus_: talking about a separate uv_loop_t for the process, but it looks like all the stdio must be buffered after some tests with large output? does that make sense to you?
16:28:10  <piscisaureus_>bradleymeck: yes, that's unavoidable
16:28:24  <piscisaureus_>bradleymeck: it's also what I want :-). No synchronous callbacks please
16:29:21  <bradleymeck>piscisaureus_: clarify that last sentence
16:30:39  <piscisaureus_>bradleymeck: well you could imagine that execSync could block the event loop but still call callbacls when data comes in (but execSync itself would not return until the process exits)
16:30:44  <piscisaureus_>but I dislike it
16:31:54  <MI6>joyent/node: Ben Noordhuis v0.8 * f3e78bd : http: fix "Cannot call method 'emit' of null" Fix the following exceptio - http://git.io/x-X7jA
16:31:58  <bradleymeck>piscisaureus_: im using uv_run inside the execSync block. I tried using JS callbacks, but found some odd issues and am abandoning them
16:32:10  <piscisaureus_>bradleymeck: good!
16:32:33  <MI6>joyent/node: Ben Noordhuis master * e4598aa : gitignore: ignore perf data files - http://git.io/VJPcAw
16:32:38  <bradleymeck>makes it take much longer to write though
16:39:51  * AndreasMadsenquit (Remote host closed the connection)
16:41:09  * trevnorrisjoined
16:44:49  * dapjoined
16:44:54  * dapquit (Client Quit)
16:45:22  * dapjoined
16:45:44  * bradleymeckquit (Quit: bradleymeck)
16:48:02  * jmar777quit (Read error: Connection reset by peer)
16:48:34  * jmar777joined
16:52:47  * loladirojoined
16:55:42  * Benviejoined
16:57:03  * mmaleckichanged nick to mmalecki[fly]
16:57:40  * bradleymeckjoined
16:57:49  * sgallaghquit (Remote host closed the connection)
16:59:25  <indutny>bnoordhuis: Assertion failed: (fd_to_send >= 0), function uv__write, file ../deps/uv/src/unix/stream.c, line 724.
16:59:31  <indutny>I suppose some use after free, right?
17:00:06  <bnoordhuis>indutny: maybe
17:00:58  <indutny>ok
17:01:12  * bradleymeckquit (Read error: Connection reset by peer)
17:01:15  * bradleymeck_joined
17:01:36  <isaacs>bnoordhuis: have you seen that "cannot call method 'emit' of null" http error in 0.8?
17:02:00  <isaacs>bnoordhuis: wasn't the "make a copy of the listeners array" behavior added in 0.9?
17:02:17  * bradleymeck_quit (Client Quit)
17:05:16  * pooyaquit (Quit: pooya)
17:07:16  <indutny>bnoordhuis: https://github.com/joyent/node/issues/4592
17:07:20  * Gu_______quit (Quit: Computer has gone to sleep.)
17:09:06  * piscisaureus_quit (Ping timeout: 272 seconds)
17:11:07  <indutny>bnoordhuis: and this https://github.com/joyent/node/pull/4593
17:11:09  <indutny>isaacs: ^
17:11:25  <indutny>bnoordhuis: isaacs: would be good if you guys will check actual specification content
17:11:34  <indutny>since I might be missing sacred meaning of some parts of it
17:11:37  <indutny>due to my limited nature
17:11:42  * hzjoined
17:11:45  <indutny>and knowledge of your pretty popular language
17:12:43  * lohkeyjoined
17:13:52  <indutny>anyone?
17:21:12  <isaacs>hm. that language is pretty dense, but as i read it, that menas that the CN should not have wildcards in it.
17:21:20  <isaacs>however, i know for a fact that there are uses of * in the CN
17:21:24  <isaacs>so tha'ts strange.
17:21:54  <isaacs>indutny: chrome allows it, so i say we should, too
17:22:14  <indutny>ok
17:22:21  <indutny>pulling into master
17:22:47  <isaacs>yeah, pull req lgtm
17:23:24  <isaacs>bnoordhuis: we need to have a consistent story about throwing from async-callback-taking functions
17:25:04  * lohkeyquit (Ping timeout: 260 seconds)
17:25:56  <indutny>I think there're only way to fix it
17:25:58  <indutny>don't throw
17:27:49  <isaacs>indutny: fs.open({this:"is not a filename or even a string"}, callback)
17:27:57  <isaacs>indutny: note that the filename is not a string, and there's no mode specified
17:28:05  <isaacs>this is clearly a programmer error.
17:28:09  <isaacs>do we throw, or call the cb?
17:28:10  * qmx|lunchchanged nick to qmx
17:28:12  <indutny>cb
17:28:13  * mikealquit (Quit: Leaving.)
17:28:25  <indutny>it's programmer's error almost everytiem
17:28:27  <indutny>anyway
17:28:32  <isaacs>i'm inclined to agree. it's surprising when async functions throw
17:28:37  <isaacs>otoh, this is clearly an "incorrect" program
17:29:00  <indutny>definitely incorrect
17:29:11  <indutny>but the thing is
17:29:22  <indutny>that programs are made of different components intreconnected with each other
17:29:28  <isaacs>but i think a pretty good pattern is that we call the cb for public async API, throw for public sync api, and abort() or assert() for binding layer
17:29:29  <indutny>they should behave similarly
17:29:58  * lohkeyjoined
17:30:37  <MI6>joyent/node: Fedor Indutny master * 4dd70bb : tls: allow wildcards in common name see #4592 - http://git.io/P6ytEQ
17:30:49  * TheJHjoined
17:31:06  <isaacs>indutny: i am ok with this on v0.8 as well.
17:31:14  <indutny>another release?
17:31:17  <indutny>please, nooo
17:31:20  <isaacs>probably eventually :)
17:31:22  <indutny>:)
17:31:23  <isaacs>or not.
17:31:30  <isaacs>but you may as well land it there, in case we do one.
17:31:32  <isaacs>it's a bug
17:31:44  <indutny>now bnoordhuis will kill me
17:31:47  <isaacs>hahah
17:31:49  <MI6>joyent/node: Fedor Indutny v0.8 * 45024e7 : tls: allow wildcards in common name see #4592 - http://git.io/dKZApQ
17:31:51  <indutny>because he's going to feel pain again
17:31:55  <isaacs>orly?
17:31:56  <indutny>when merging v0.8 in master
17:31:57  <isaacs>how come?
17:32:05  <isaacs>oh, it'll be fine.
17:32:14  <isaacs>it's just the same change in both places. usually git can handle that.
17:32:23  <isaacs>what sucks is when you make a *different* change in both places.
17:36:24  <indutny>well
17:36:50  <isaacs>ugh. i'm seeing a bug in a pipe() in npm which i can't seem to reproduce outside of npm.
17:37:03  <isaacs>timing issue with git child proces.
17:40:30  * loladiroquit (Quit: loladiro)
17:41:32  <isaacs>it's so weird. if i do child.stdout.pipe(gzip, { end:false }) and then call end myself, it works fine.
17:41:38  <isaacs>but if i just do child.stdout.pipe(gzip) it doesn't
17:51:34  <isaacs>ahhh.. awesome. found it
17:53:01  <bnoordhuis>indutny: you should've landed that in v0.8 first
17:54:58  <bnoordhuis>isaacs: have you seen that "cannot call method 'emit' of null" http error in 0.8? <- yes
17:55:40  <isaacs>bnoordhuis: i believe indutny was hesitant to make changes to v0.8 because there will likely not be a v0.8.18
17:55:52  <bnoordhuis>why not?
17:55:53  <isaacs>but, we saw 0.6 releases afer v0.8 was out, so... probably there will be some bug fixes eventually
17:56:07  <isaacs>bnoordhuis: yeah, my thoughts also :)
17:56:16  * paddybyersquit (Ping timeout: 252 seconds)
17:56:35  <bnoordhuis>isaacs, indutny: re throw-vs-emit, it's clear-cut imo: throw an application bugs, emit runtime errors
17:56:39  <bnoordhuis>*on
17:56:56  <isaacs>bnoordhuis: but that's not actually what we do, and that line is not so clear-cut.
17:57:26  <bnoordhuis>isaacs: it's not what we do because of certain bleeding heart patches, that's true
17:58:15  <isaacs>bnoordhuis: potential throws need to be documented and then we're relying on people reading documentation.
17:58:26  <bnoordhuis>isaacs: or testing their code
17:58:33  <isaacs>against all potential input?
17:58:35  <isaacs>impossible.
17:59:02  <isaacs>what happens is that they DO test their code, then one day, get a bigger number that overflows the Uint32 limit, and their server crashes.
17:59:29  <bnoordhuis>and then they get a nice stacktrace that points to the offending location and fix their code
17:59:34  * piscisaureus_joined
17:59:46  <isaacs>well, no, not necessarily
17:59:48  <bnoordhuis>now, if you emit that error, all that contextual information is gone
17:59:50  * pooyajoined
18:00:02  <isaacs>you get exactly the same stack trace if you return the error in a cb
18:00:10  <isaacs>rather than throw it
18:00:13  <bnoordhuis>but you don't get the call site
18:00:26  <isaacs>true. butthe call site here is somewhere deep in the bowels of node.
18:00:33  <isaacs>remember, they're not actually calling crypto.getRandombytes
18:00:43  <isaacs>they're calling someModule.doSomeThing(reasonableLookingNumber)
18:00:55  <bnoordhuis>yes, and that will show up in the stacktrace as well
18:01:01  <isaacs>right, but the call site is not that useful
18:01:11  <bnoordhuis>of course it is
18:01:12  <isaacs>returning the error in a callback is better, because that's where their error handling code lives.
18:01:21  <bnoordhuis>if it happens in some module you don't control, you can at least report the bug
18:01:34  <isaacs>in other words, yes, the callsite is valuable, but not as valuable as being able to handle the error.
18:01:44  <bnoordhuis>strongly disagree
18:01:49  <isaacs>really?
18:02:05  <bnoordhuis>yes. matter of fact, that would be a breaking point for me
18:02:16  <isaacs>it's the difference between returning a 500 error to the user vs crashing the server.
18:07:58  * EhevuTovjoined
18:10:03  * loladirojoined
18:11:02  * hzquit
18:13:10  * mikealjoined
18:13:43  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:14:10  * piscisaureus_joined
18:16:39  * TooTallNatejoined
18:26:08  * EhevuTovquit (Quit: This computer has gone to sleep)
18:27:01  * EhevuTovjoined
18:27:03  * mikealquit (Quit: Leaving.)
18:27:24  * TheJHquit (Read error: No route to host)
18:27:55  * TheJHjoined
18:30:29  * stagasquit (Ping timeout: 252 seconds)
18:35:28  * mikealjoined
18:47:11  * sgallaghjoined
18:48:35  * TheJHquit (Ping timeout: 248 seconds)
18:50:34  * paddybyersjoined
18:57:39  * loladiroquit (Quit: loladiro)
18:58:04  * loladirojoined
19:00:46  * mikealquit (Quit: Leaving.)
19:00:54  * sblomjoined
19:00:57  * sblomquit (Client Quit)
19:02:42  * loladiroquit (Client Quit)
19:03:15  * loladirojoined
19:03:15  * loladiroquit (Client Quit)
19:08:00  * loladirojoined
19:10:06  * loladiroquit (Client Quit)
19:12:46  * jmar777quit (Remote host closed the connection)
19:13:22  * jmar777joined
19:13:58  * jmar777quit (Read error: Connection reset by peer)
19:14:27  * jmar777joined
19:15:56  * TheJHjoined
19:17:33  * brsonjoined
19:19:13  * roxlujoined
19:19:22  <roxlu>hi
19:21:36  * lohkeyquit (Quit: lohkey)
19:22:28  * lohkeyjoined
19:36:22  <indutny>hoho
19:36:37  <roxlu>everything good in libuv land?
19:36:59  * lohkeyquit (Quit: lohkey)
19:42:20  <roxlu>I was hoping someone /win 5
19:42:36  * paddybyersquit (Ping timeout: 252 seconds)
19:42:37  <roxlu>hehe well. .. not /win 5 :)
19:44:41  <roxlu>but, I was hoping someone in here could give me some advise on a threaded related subject. I'm writing a video encoder which has two related functions: addVideoFrame(void* data, size_t size) and addAudioFrame(void* data, size_t size);, in these function I copy the data to a std::vector (wrapped around a "Packet" object). In my threaded function I'm checking if there are new audio/video packets that I can process.. now I'm wondering what a good a
19:45:01  <tjfontaine>your client cut off at: "what a good a"
19:45:14  <roxlu>oh
19:45:40  <roxlu>now I'm wondering what a good approach is so the reading/writing from this queue of packets is not stalling my main thread ?
19:47:01  <indutny>isaacs: yt?
19:47:38  * loladirojoined
19:49:57  <isaacs>heading out to yoga practice. leave a message :)
19:50:08  <indutny>oh
19:50:11  <indutny>ok
19:50:13  <indutny>later then :)
19:50:20  <indutny>piscisaureus_: yt?
19:50:26  <piscisaureus_>indutny: in a meeting
19:50:57  <CoverSlide>aww
19:51:00  <CoverSlide>noone to play with
19:51:10  <roxlu>indutny: you miht have some advise on this threading thing maybe ?
19:51:15  <roxlu>yeah I'm here :)
19:51:34  <indutny>roxlu: what sort of advice you want?
19:51:56  <roxlu>what a good approach is to handle this threading
19:52:17  <indutny>what threading
19:52:22  <indutny>anyway
19:52:28  <indutny>the best approach to handle threading is to avoid it
19:52:32  <roxlu>indutny: did you see my post ^^
19:52:32  <roxlu>haha
19:52:38  <indutny>nope, I've missed it
19:52:41  <indutny>thanks to ircrelay
19:52:49  <roxlu>ah, I'll repaste
19:53:20  <roxlu>indutny: pasting here, because copy/paste adds some tabs: https://gist.github.com/72d5b40950610fac1bbd
19:54:28  <indutny>well, I'd a short look at it
19:54:36  <indutny>but I think you should just use two threads and semaphore
19:56:05  <roxlu>ok, how do you suggest these threads/semaphore work together? (<-- that's the thing I'm not experienced with)
20:00:06  <indutny>semaphore?
20:01:20  <roxlu>20:53 <@indutny> but I think you should just use two threads and semaphore
20:01:58  <indutny>no
20:02:02  <indutny>I mean just use semaphore
20:02:09  <indutny>do you know how it works?
20:02:25  <roxlu>indutny: isn't a semaphore like a mutex, but then very lightweight?
20:02:31  <indutny>not, really
20:02:35  <roxlu>ahh
20:02:38  <indutny>well, it can be implemented with mutexes
20:02:42  <indutny>but that's not the same thing
20:02:45  <indutny>so
20:02:51  <indutny>semaphore+shared queue+2 workers
20:02:56  <indutny>1 worker - producer
20:02:58  <indutny>1 worker - consumer
20:03:09  <indutny>producer places item in queue and triggers semaphore
20:03:25  <indutny>consumer waits for semaphore signal and takes item from the queue and process it
20:03:38  <roxlu>ah! thanks
20:03:58  <indutny>np
20:03:59  <indutny>you're welcome
20:04:00  <roxlu>I saw libuv has thread support.. can I use that to handle cross platform semaphores?
20:04:06  <indutny>btw, there're a good book around here
20:04:22  <roxlu>oh great, I'm really looking for a good book on this
20:04:26  <indutny>http://www.amazon.com/The-Multiprocessor-Programming-Maurice-Herlihy/dp/0123705916/ref=sr_1_3?ie=UTF8&qid=1358193860&sr=8-3&keywords=multithread
20:04:40  <roxlu>indutny: is that book also practical?
20:04:56  <roxlu>I mean does it describe APIs ?
20:05:30  * jmar777quit (Read error: Connection reset by peer)
20:05:48  <indutny>no, it's theoretical
20:05:52  * jmar777joined
20:05:57  <indutny>if you want APIs
20:06:03  <indutny>just search `man pthread` in google
20:06:08  <roxlu>:)
20:06:53  <indutny>ok, time to wash some dishes
20:07:02  <roxlu>hehe ok again thanks a lot!
20:08:11  * lohkeyjoined
20:09:07  <indutny>you're welcome
20:09:17  * jmar777quit (Remote host closed the connection)
20:09:32  <indutny>ryah: ohai man
20:09:35  <indutny>how are you doing?
20:09:52  * jmar777joined
20:13:08  <indutny>ryah: are you going to visit nodeconf this year?
20:13:22  <CoverSlide>he's alive!
20:14:14  * jmar777quit (Ping timeout: 260 seconds)
20:15:09  <indutny>CoverSlide: calm down, kiddo
20:15:10  <indutny>:)
20:25:59  * `3rdEdenquit (Quit: I shall swap.. devices)
20:29:44  * indexzeroquit (Quit: indexzero)
20:34:17  * jmar777joined
20:42:38  * lohkeyquit (Quit: lohkey)
20:42:47  * lohkeyjoined
20:46:31  * hzjoined
20:55:51  <ryah>indutny: no
20:56:41  <bnoordhuis>all the cool kids don't go to nodeconf
21:00:38  <piscisaureus_>I am going to nodeconf
21:03:19  <TooTallNate>piscisaureus_: summer camp?
21:04:33  * `3rdEdenjoined
21:06:28  <piscisaureus_>TooTallNate: the thing @ end of june
21:06:42  <indutny>ryah: oh, ok
21:06:56  <indutny>piscisaureus_: you're either not cool
21:06:58  <indutny>or not kid
21:06:59  <TooTallNate>piscisaureus_: ya, that's the one
21:07:00  <piscisaureus_>bnoordhuis: https://github.com/strongloop/node/commit/5c94ae11a20a5192e73239e50e5edbbb33e1dc80 <-- Made memory usage a lot more palatable for that customer of ours that shall not be named. Objections to landing it?
21:07:41  <indutny>micro-optimization
21:07:42  <indutny>nice
21:07:47  <indutny>piscisaureus_: lgtm
21:10:05  <saghul>bnoordhuis does that thing with not stoping a stream in case of error happen also for udp? (though I don't know what error taht could be)
21:13:08  * lohkeyquit (Ping timeout: 248 seconds)
21:13:16  * lohkeyjoined
21:14:34  * lohkeyquit (Client Quit)
21:18:36  <piscisaureus_>indutny: since you are a committer too, I'll happily take your thumbsup :-)
21:19:41  <MI6>joyent/node: Bert Belder master * e501ce4 : buffer: zero-length buffers shouldn't be slab-backed - http://git.io/zYZf3Q
21:20:19  <indutny>ahhaha
21:20:21  <indutny>ok
21:20:25  <indutny>it really loooks gooood to me
21:20:36  <MI6>joyent/node: Bert Belder v0.8 * a6b8f63 : buffer: zero-length buffers shouldn't be slab-backed - http://git.io/Sn3LDQ
21:20:39  <piscisaureus_>it makes a lot of difference with http-proxy
21:20:45  <piscisaureus_>since 0-length buffers happen a lot there
21:21:45  * hzquit
21:21:59  <tjfontaine>ya it makes sense
21:22:15  <indutny>good
21:22:31  <indutny>piscisaureus_ so you boy going to visit SF this year
21:22:45  * jmar777quit (Remote host closed the connection)
21:22:49  <piscisaureus_>indutny: yes, I think somewhere in february even
21:23:18  * jmar777joined
21:27:40  * jmar777quit (Ping timeout: 256 seconds)
21:27:47  * TheJHquit (Ping timeout: 255 seconds)
21:29:39  <trevnorris>piscisaureus_: was talking to a friend at apple about the memory fragmentation problem with pooled buffers and he gave me the idea of implementing simple memory compaction.
21:30:13  * paddybyersjoined
21:30:30  <trevnorris>couldn't we just piggy back on v8's gc and run a quick analysis of whether a pool should be compacted and shrunk?
21:31:48  <piscisaureus_>trevnorris: possibly. How?
21:32:52  <trevnorris>piscisaureus_: what calls the buffer class destructor?
21:33:07  <piscisaureus_>trevnorris: there is no destructor
21:33:15  <piscisaureus_>trevnorris: javascript has no destructors.
21:33:31  <trevnorris>piscisaureus_: hm? I mean in lib/node_buffer.cc
21:33:41  <piscisaureus_>trevnorris: only SlowBuffers have "weak callbacks" which is exactly what makes them expensive.
21:33:48  <piscisaureus_>and that's why we have only few of them
21:34:55  <trevnorris>isn't every buffer pool a slow buffer?
21:35:08  <trevnorris>from which fast buffers are created?
21:35:12  <piscisaureus_>trevnorris: yes, indeed
21:35:49  <trevnorris>ok. so I assume v8 frees each fast buffer when it falls out of scope, right?
21:36:49  <piscisaureus_>trevnorris: well -
21:37:08  <trevnorris>piscisaureus_: and I assumed that it was cleared by calling the Buffer class destructor that's in lib/node_buffer.cc#194
21:37:18  <piscisaureus_>trevnorris: when it is unreachable. So it is both out of scope *and* no longer referenced by the "parent" property of normal buffers
21:37:33  <piscisaureus_>trevnorris: the destructor is called here: https://github.com/joyent/node/blob/e501ce4b218fd462d20b45ba817f6232219e6fa2/src/node_object_wrap.h#L121
21:38:07  <trevnorris>so what's Buffer::~Buffer for?
21:38:12  <trevnorris>I don't see it getting used anywhere.
21:38:33  <piscisaureus_>trevnorris: see my previous comment.
21:38:50  <piscisaureus_>that is calling the destructor
21:39:09  * paddybyersquit (Ping timeout: 276 seconds)
21:39:29  <trevnorris>piscisaureus_: damn my newb-ness at C. ok.
21:39:48  <piscisaureus_>C++ even :=)
21:39:49  <kohai>C has 26 beers
21:39:51  <CoverSlide>desctructors are more a C++ thing
21:40:10  <trevnorris>heh, bad habit of using C and C++ interchangeably.
21:40:28  <piscisaureus_>I will no longer answer questions unless you guys pay me $ 300
21:40:45  <piscisaureus_>OR watch this video in full, with sound on: https://github.com/joyent/node/blob/e501ce4b218fd462d20b45ba817f6232219e6fa2/src/node_object_wrap.h#L121
21:41:00  <tjfontaine>heh
21:41:01  <CoverSlide>that's an awesome video
21:41:11  <piscisaureus_>AH SHIT
21:41:12  <CoverSlide>i love the delete obj; part
21:41:14  <piscisaureus_>www.youtube.com/watch?feature=player_embedded&v=v7qTHbOEiDY#!c <-- That
21:41:33  <CoverSlide>oh yeah that was amazing
21:42:03  <piscisaureus_>It is not allowed to minimize, close eyes or cringe
21:42:25  <piscisaureus_>and your toes gotta be relaxed
21:43:11  <CoverSlide>"I have a sweet job an a hot girlfriend"
21:43:34  <tjfontaine>and by hot, I mean ...
21:43:45  <CoverSlide>she's baking in the oven right now
21:43:51  <CoverSlide>apple flavor
21:44:44  <trevnorris>.... almost didn't make it through the first 20 sec.
21:47:34  <piscisaureus_>trevnorris: I will mail you my routing info then :-)
21:48:33  <trevnorris>heh! said I "almost" didn't make it through. (though can't vouch for my toes)
21:48:47  * paddybyersjoined
21:53:39  * sgallaghquit (Ping timeout: 248 seconds)
21:54:43  <trevnorris>piscisaureus_: as a side, since node only uses one context couldn't it be cached like node_isolate?
21:55:14  <piscisaureus_>trevnorris: it is possible to use separate contexts in node.
21:55:23  <trevnorris>ah, ok.
21:55:25  <piscisaureus_>trevnorris: it's even possible to load every module into a separate context
21:57:35  * EhevuTovquit (Quit: This computer has gone to sleep)
21:59:44  <indutny>back
22:00:03  <indutny>piscisaureus_ wanna ask me something?
22:00:17  <piscisaureus_>indutny: will you marry me?
22:00:22  <indutny>300 $
22:00:25  <indutny>for answer
22:00:37  <piscisaureus_>oh nvm then
22:00:38  <trevnorris>piscisaureus_: cool. ok the short of my idea is that I assumed v8's gc told node when a buffer could be cleaned up.
22:00:40  <tjfontaine>sounds cheaper than most wives
22:01:08  <indutny>trevnorris: you mean flattening slices?
22:01:08  <piscisaureus_>trevnorris: well, v8 tells node when a slowbuffer is to be cleaned up
22:01:36  <piscisaureus_>trevnorris: but that is only fine because there are few of these
22:02:08  <trevnorris>piscisaureus_: but then v8 must be keeping track of all the fast buffer references to the slowbuffer, right?
22:02:25  <piscisaureus_>trevnorris: yuop
22:02:28  <piscisaureus_>*yup
22:02:54  <trevnorris>piscisaureus_: so is there a way to have v8 tell node when a faster buffer is no longer used?
22:03:05  <piscisaureus_>trevnorris: no.
22:03:27  <piscisaureus_>well you could maybe think of a scheme with weak maps
22:05:33  <trevnorris>piscisaureus_: ok. basically I was thinking to detect when a fast buffer was cleaned up and then if the parent was, say, 50% unused then it would compact the parent slowbuffer and free the remaining memory.
22:06:55  <piscisaureus_>trevnorris: I think a better strategy would be to disable slabs, write a benchmark and profile with gprof or valgrind to see what the hot paths are
22:07:14  <piscisaureus_>trevnorris: then see if there are any optimization options
22:07:49  <indutny>trevnorris: there is one thing that you can check
22:07:56  <indutny>trevnorris: v8 is using generational GC
22:08:04  <indutny>so, when buffer, is transferred to Old space
22:08:05  <trevnorris>piscisaureus_: this one is more for memory conservation. there is an edge case where memory can leak through unused pools.
22:08:12  <indutny>it's some long-living thing
22:08:26  <indutny>and probably worth transforming it into slowbuffer
22:08:35  <piscisaureus_>trevnorris: the problem would not exist if we didn't have slabs
22:08:46  <piscisaureus_>trevnorris: so try to figure out why SlowBuffers are slow :-)
22:09:24  <indutny>piscisaureus_: so what do you think about https://github.com/joyent/node/pull/4595
22:09:31  <indutny>bnoordhuis: isaacs: ^
22:09:33  <indutny>TooTallNate: ^
22:10:20  <trevnorris>piscisaureus_: will work on it. waiting for 4504 to be accepted, then have another to make the remaining read/write methods faster.
22:11:08  <indutny>are everyone ignoring me?
22:11:09  <indutny>wtf
22:11:10  <piscisaureus_>4505 is v8 upgrade right? Didn't that land?
22:11:15  <trevnorris>piscisaureus_: and after that I'm going to work on a solution for a v8 deopt when calling a method on "parent" from a buffer that "target requires context change".
22:11:25  <TooTallNate>indutny: reading your code
22:11:25  <indutny>trevnorris: I landed it
22:11:34  <trevnorris>which looses us about 20% performance.
22:11:51  <piscisaureus_>indutny: yes, sorry. Marry me.
22:12:11  <TooTallNate>piscisaureus_: doesn't that just lead to more ignoring?
22:12:27  <trevnorris>indutny: hu?
22:12:33  <indutny>piscisaureus_: ok
22:12:39  <piscisaureus_>indutny: ok, nice
22:12:40  <indutny>piscisaureus_: will I become AMS citizen?
22:12:44  <indutny>well
22:12:52  <indutny>Netherlands
22:12:57  <piscisaureus_>indutny: yes, if you can prove that you know me well :-)
22:13:02  <indutny>huh?
22:13:05  <piscisaureus_>and truly love me
22:13:06  <indutny>what does it mean
22:13:08  <indutny>oh
22:13:10  <indutny>shit
22:13:15  <indutny>man
22:13:17  <indutny>erm
22:13:19  <indutny>you're man
22:13:23  <indutny>no way
22:13:32  <piscisaureus_>otherwise immigration will assume that you're just doing it for your visa
22:13:41  <piscisaureus_>indutny: this is amsterdam, man+man is not a problem here
22:13:44  <piscisaureus_>this is not russia
22:13:47  <trevnorris>indutny: think you read the number wrong. it's 4504, not 4505.
22:13:58  <indutny>aah
22:14:01  <indutny>sorry
22:14:15  <indutny>right
22:14:19  <trevnorris>it makes Buffer.writeFloat|Double about 3x's faster
22:14:29  <piscisaureus_>ah yeah, I think ben is reviewing that?
22:14:35  <trevnorris>ironically they're also faster than all the other write methods when using assert.
22:14:42  <trevnorris>have a patch ready for that too.
22:14:49  * rendarquit
22:15:05  <indutny>nice
22:16:11  <piscisaureus_>Oh crap I forgot I have to get up at 7 tomorrow
22:16:12  <piscisaureus_>:-(
22:18:05  <trevnorris>piscisaureus_: my 2 year old says that's weak sauce. ;-)
22:19:17  <indutny>oooh
22:19:23  <indutny>piscisaureus_: which reminds me that it's 2 am right now
22:21:23  <trevnorris>indutny: how'd you know that about v8's gc? swear I haven't been able to find ample documentation on how the internals work.
22:21:32  <indutny>I just know it
22:21:37  <indutny>because otherwise it will be slow
22:21:38  <indutny>also
22:21:44  <indutny>you can search for string OldSpace in source
22:22:13  <indutny>also I implemented my own generational GC once
22:22:28  <trevnorris>indutny: heh, wow. I've literally been learning c++ to make these buffer improvements. real jump in the deep end move.
22:22:40  <indutny>it's not that deep
22:22:52  <indutny>imagine two heaps
22:22:58  <indutny>one with old objects and one with new objects
22:23:09  <indutny>old objects tend to live much longer than young ones
22:23:17  <indutny>and therefore they shouldn't be cleaned to often
22:23:34  <indutny>so v8 performs GC and increments generational bits for each object
22:23:51  <indutny>once it reaches some specific value it moves object from NewSpace to OldSpace
22:24:20  <trevnorris>ah, interesting.
22:24:34  <bnoordhuis>piscisaureus_: lgtm
22:24:54  <indutny>bnoordhuis: oh, you're back
22:25:03  <trevnorris>my hope is that if the memory can be handled better than node can allocate larger pools (which I think would improve overall performance)
22:26:30  <indutny>erm, not really
22:26:34  <bnoordhuis>saghul: no, udp sockets are safe
22:26:36  <indutny>I think it's faster up to specific limit
22:26:45  <saghul>bnoordhuis thanks!
22:27:08  <trevnorris>and you think node's already allocating at that limit?
22:27:24  <indutny>well
22:27:32  <indutny>you should take in account startup time and everything
22:27:43  <indutny>and also yeah
22:27:50  <indutny>I think current size is pretty good
22:27:56  * qmxchanged nick to qmx|afk
22:28:13  <indutny>but benchmarking it and measuring accurately may point that it isn't
22:28:59  <trevnorris>ok, that's cool. two main things I want to accomplish are getting around the edge case in GH-4525, and
22:29:05  <trevnorris>also I want to remove the need for calling methods on "this.parent". for lightweight calls it craps on performance.
22:29:47  <indutny>kewl
22:30:00  <indutny>what's happening when calling methods on "this.parent"
22:30:04  <indutny>does it deoptimize function?
22:30:12  <indutny>isn't this.parent monomorphic?
22:30:22  <trevnorris>indutny: but also it has to do a context change. have benchmarks to show that.
22:30:37  <indutny>context change...
22:30:41  <indutny>why
22:30:51  <indutny>ah
22:30:54  <indutny>yeah
22:30:57  <indutny>I see the point
22:32:12  <trevnorris>yeah. my new writeFloat methods are 20% faster when called directly to this.parent.
22:32:58  <indutny>cool
22:33:01  <indutny>brb
22:45:24  * bnoordhuisquit (Ping timeout: 272 seconds)
22:45:39  <isaacs>Can someone review this? https://github.com/isaacs/node/commit/25a8d3d
22:45:52  <isaacs>piscisaureus_, TooTallNate, trevnorris ^
22:46:02  <isaacs>indutny oh, you're here, too, you can do it if you like
22:46:04  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
22:46:26  <isaacs>indutny: i typed idn<tab> and it diidn't complete, so i figured you were away :)
22:46:46  <isaacs>typos make me a bad team player >.<
22:46:47  * EhevuTovjoined
22:49:33  * mmalecki[fly]changed nick to mmalecki
22:50:50  * `3rdEdenquit
22:53:43  <indutny>isaacs: sure
22:53:47  <trevnorris>isaacs: is there ever a case where n could be a negative (other than if a user screwed up)?
22:54:11  <isaacs>trevnorris: no, but i believe that negative numbers are treated like zero anyway
22:54:13  <indutny>isaacs: can you add commit body?
22:54:18  <indutny>I mean it needs more explanation
22:54:40  <isaacs>indutny: sure thing
22:55:27  <indutny>otherwise lgtm
22:55:38  <indutny>isaacs: in exchange, please review this https://github.com/joyent/node/pull/4595
22:55:44  <indutny>it is mostly javascript changes
22:55:49  <indutny>I mean 100% javascript changes
22:55:55  <trevnorris>isaacs: ah, missed the re-assignation.
22:57:47  <isaacs>indutny: will do
23:00:02  <isaacs>indutny: https://github.com/isaacs/node/commit/master
23:00:17  <indutny>yes
23:00:25  <indutny>very good :)
23:00:35  <indutny>thank you
23:01:00  <trevnorris>isaacs: ok, so really it should only reach that error if a user manually changes length on the readable stream.
23:01:01  * wolfeidaujoined
23:01:54  <isaacs>trevnorris: yeah
23:02:17  <isaacs>trevnorris: if you are manually dicking around with foo._readableState.whatever, then you're off the reservatio, and deserve to be eaten by bears, and perhaps fire.
23:02:25  <trevnorris>lol
23:02:56  <isaacs>in a future incarnation, it might even be hidden behind a private symbol
23:03:03  <isaacs>which we don't share with non-core js
23:05:25  <trevnorris>in the comments you say "can override either this method..." so the user can write their own ".read" method, correct?
23:07:45  <isaacs>trevnorris: yeah
23:07:54  <isaacs>trevnorris: but i think that any time a user does that, we've failed slightly
23:08:12  <isaacs>trevnorris: eg with object streams (/cc Raynos)
23:08:31  <isaacs>not that they shouldn't do that, but we should make the "blessed" APIs so good that they don't have to
23:08:51  <isaacs>experience has shown that implementing streaming logic is pretty tricky actually
23:09:33  <isaacs>indutny: I'm not understanding why we need to track:true ever
23:09:43  <indutny>well
23:09:52  <indutny>you pass socket
23:09:59  <indutny>and want to know when it's destroyed
23:10:02  <indutny>this is the case #1
23:10:05  <indutny>case #2
23:10:18  <indutny>you want to know number of server connections
23:10:27  <indutny>but
23:10:36  <indutny>may be you're right
23:11:08  <isaacs>i think tracking it as an option is fine.
23:11:09  <isaacs>but it should default to false
23:11:14  <isaacs>node should be fast by default.
23:11:48  <isaacs>if the connections count is invalid, let's just make it 0
23:11:52  <isaacs>or -1 or null or whatever.
23:12:14  <isaacs>like, "Sorry, you don't get that info, because you didn't ask for it"
23:12:15  <isaacs>i think that's reasonable
23:12:19  <indutny>-1
23:12:30  <indutny>because I don't want server.close() to emit 'close' immediately
23:12:34  <isaacs>nono
23:12:43  <isaacs>server.close() will still wait for the children to report that they're closed.
23:12:46  <isaacs>justlike your patch does
23:12:58  <isaacs>but server.connections doesn't have to be anything useful if you're not tracking them
23:13:18  <isaacs>i mean, showing server.connections = "total number of connections since ever" is not so useful
23:13:30  <isaacs>but it looks like a number, then, not a `null` showing you that it's just not a thing
23:13:38  <isaacs>so it's hard to tell what's going on
23:14:02  <isaacs>we could also add server.connectionCount(cb)
23:14:14  <isaacs>so, in a cluster master, it'll poll the children
23:14:29  <isaacs>and in a non-master server, it'll just call the cb with server.connections
23:15:03  <trevnorris>isaacs: holy, keeping all the legacy bits in must have been a drag.
23:15:08  * c4miloquit (Remote host closed the connection)
23:15:42  <isaacs>trevnorris: yes.
23:15:42  <indutny>right
23:16:09  <indutny>isaacs: looks like I was wrong about CN matching
23:16:11  <Raynos>trevnorris: I overwrote .read in my object stream wrapper. It's a disaster. Having worked on streams in node core to make them support object streams I can tell you it's trivial to handle edge cases incorrectly. We should solve it once
23:16:15  <indutny>there're two things to change/fix
23:16:23  <indutny>1. CN should not allow wildcards if altname is present
23:16:31  <indutny>and apparently it's not present in dropbox's certificate
23:16:43  <indutny>nor in facebook's
23:16:56  <indutny>2. Wildcard is allowed only in left-most part of identifier
23:17:03  <indutny>(pointed by bnoordhuis)
23:17:14  <indutny>I've a patch to review
23:17:18  <indutny>but right now I'm just running tests
23:21:20  <isaacs>indutny: thanks
23:21:27  <isaacs>indutny: that makes sense iwth my experience.
23:21:35  <isaacs>indutny: so,i'm landing this stream thing
23:22:19  <indutny>ok
23:22:30  <indutny>isaacs: I wonder how many patches to this code will we make
23:22:35  <indutny>until it'll become useful :)
23:22:43  <indutny>it's like 20th patch to this small functions
23:22:50  <indutny>and still everyone is not satisfied
23:22:51  <isaacs>hahah
23:22:59  <isaacs>indutny: welcome to the wonderful world of tls :)
23:23:24  <isaacs>indutny: there are no heroes. only failures. your best hope is to fail less than average.
23:23:33  <isaacs>indutny: this is why security people are usually so grump.
23:23:35  <isaacs>*grumpy
23:23:38  <indutny>I've failed to fail less than average
23:23:40  <indutny>is it bad? :)
23:23:43  <isaacs>hahah
23:23:54  <isaacs>well, that'sjust one failure, so i'd say you're doing ok
23:25:47  <isaacs>indutny: speaking of failures, simple/test-tls-check-server-identity is failing for me on master.
23:25:50  <indutny>oh, actually
23:25:55  <indutny>forget about pt 2
23:25:58  <indutny>err
23:25:59  <indutny>pt 1
23:26:01  <isaacs>Test#4 failed: { host: 'b.a.com', cert: { subject: { CN: '*.a.com' } }, result: false }
23:26:05  <indutny>yes, I know
23:26:08  <isaacs>k
23:26:17  <trevnorris>isaacs: another user-failure case. but looks like no check if lowWaterMark < highWaterMark.
23:26:42  <isaacs>trevnorris: there was a check, but it slowed down http_simple
23:26:46  <isaacs>so we removed the seatbelts from the car.
23:26:50  <isaacs>to go faster.
23:27:04  <isaacs>that one is probably worthwhile
23:27:43  <MI6>joyent/node: isaacs master * 27fafd4 : stream: Do not call endReadable on a non-empty stream Say that a stream' - http://git.io/n21QAw
23:29:07  * paddybyersquit (Ping timeout: 248 seconds)
23:29:36  * EhevuTovquit (Quit: This computer has gone to sleep)
23:29:50  <trevnorris>isaacs: i'd think a check on instantiation (e.g. `this.hWM = ~~(hwm > lwm ? hwm : lwm)`) would be enough. was that causing a problem?
23:30:26  <indutny>pushing
23:30:54  <indutny>isaacs: please review very carefully https://github.com/indutny/node/commit/add5e12ab3bc940d73dd46eecbc9d6cf0a5ed6ea
23:30:57  <indutny>I'll reread it myself
23:32:52  <indutny>does it match quotes?
23:33:21  <isaacs>trevnorris: i had a bunch of asserts in there.
23:33:27  <trevnorris>ah, ok
23:33:29  <isaacs>trevnorris: removing them all sped things up a bit.
23:33:49  <isaacs>trevnorris: but yeah, in teh ctor, it would probably be good to just do if (hwm < lwm) throw
23:36:07  <isaacs>indutny: what is this? return /$./;
23:36:14  <indutny>falsy regexp
23:36:14  <isaacs>indutny: is that just a regexp that can never match anything?
23:36:16  <indutny>yes
23:36:17  <isaacs>i see.
23:37:53  <isaacs>indutny: it'd be good to put the RFC comments next to the tests that demonstrate them
23:38:01  <indutny>yeah, probably
23:38:06  <isaacs>indutny: since that's usually the first place I check to see why it's behaving the way it is
23:38:16  <indutny>can you do it? for me :)
23:38:27  <isaacs>indutny: if I think, "That's wrong" and i look at the test, and see that we're making SURE it's wrong, then i'm extra curious
23:38:28  <indutny>I'm afraid I can't handle it anymore tonight
23:38:31  <isaacs>indutny: np
23:38:35  <indutny>so
23:38:37  <indutny>lgtm?
23:38:46  <isaacs>indutny: i need to play with it a bit more.
23:38:51  <isaacs>indutny: just read, didn't test myself.
23:38:56  <indutny>ok
23:38:59  <indutny>good
23:39:01  <isaacs>indutny: but if you're happy with it, i'll land it today if it lgtm
23:39:08  <isaacs>and i'll add comments to the tests
23:39:13  <indutny>I don't have any concerns with it
23:39:15  <isaacs>kewl
23:39:17  <indutny>as far as I can see
23:39:21  <isaacs>thanks for doing this :)
23:39:38  <indutny>thank you :)
23:41:44  <trevnorris>isaacs: yeah. reason I don't use assert.ok on small functions is because I always get a "Did not inline ok called from testme (target requires context change)"
23:44:47  <trevnorris>in the super trivial case it makes it about 6x's slower: https://gist.github.com/4534623
23:47:39  <isaacs>trevnorris: wow
23:47:49  <isaacs>it'd be nice if assert() were like a language construct.
23:48:00  <isaacs>assert(booleanvalue, message)
23:48:10  <isaacs>maybe when we get macros, i can write it ;)
23:48:27  <isaacs>if (!booleanValue) throw new Error(message)
23:48:28  <indutny>we can do interesting thing now
23:48:37  <indutny>compile two version of each module
23:48:40  <indutny>s/version/versions
23:48:45  <indutny>one - original
23:48:50  <indutny>second - with commented out assertions
23:49:06  <indutny>and choose which one to run depending on env variables
23:49:12  <isaacs>hrm... meh.
23:49:18  <isaacs>i'll just add a if/throw check
23:49:26  <indutny>haha
23:49:28  <indutny>ok
23:49:30  <indutny>brb
23:49:33  <indutny>tea
23:52:31  <trevnorris>isaacs: it's actually from how the module system works. here's the most trivial module case: https://gist.github.com/4534623
23:52:44  <trevnorris>so it's not the assert that's slow, it's calling in the assert through require.
23:54:05  <isaacs>review? https://gist.github.com/4534672
23:54:20  <isaacs>trevnorris: interesting.
23:54:54  <trevnorris>isaacs: lgtm
23:55:35  <indutny>ok, time to sleep
23:55:40  <indutny>ttyl
23:55:53  <indutny>isaacs: lgtm