00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:10  <trevnorris>oh, yeah. her
00:00:12  <isaacs>trevnorris: guessing by avatar pic and name, anyway. seems to present as female.
00:01:19  <trevnorris>oh, yup. her pic on twit
00:02:12  * amartensquit (Quit: Leaving.)
00:02:22  <isaacs>i think we should try to assume, in absence of knowledge, that developers are female.
00:02:30  <isaacs>of course, point of fact, you'll be wrong more often.
00:02:46  * hzquit
00:03:17  <isaacs>but analyzed from a utility model of knowledge, the damage done by ostracizing a male programmer is much lower than ostracizing a female programmer.
00:06:00  * EhevuTovquit (Quit: This computer has gone to sleep)
00:06:36  * piscisaureus_quit (Ping timeout: 276 seconds)
00:07:37  <trevnorris>isaacs: holy fuck dude. simple hello world: node - Requests/sec: 20236.10; Haywire - Requests/sec: 216798.00
00:07:54  <isaacs>yeah
00:08:02  <isaacs>buffers and v8 contexts aren't free :)
00:08:25  <trevnorris>mother. seriously.
00:10:28  <trevnorris>but by an order of magnitude? that's way more than I thought.
00:11:05  <isaacs>sounds about right
00:11:12  <isaacs>she's also not implementing ALL of http
00:11:30  <isaacs>just some specific paths, and not in a completely generic way
00:11:40  <isaacs>that's why node.c would be so exciting
00:11:41  <trevnorris>true true. mainly I was just looking for an upper limit.
00:11:54  <isaacs>http_parser.c and libuv are great, but too low level
00:11:57  <trevnorris>to determine how hard to push the boundary.
00:12:00  <isaacs>right
00:12:10  <trevnorris>cool. yeah. node.c sounds awesome.
00:12:17  <isaacs>if we had a similarly-powerful node.c platform, we could really get some serious comparisons
00:12:25  * piscisaureus_joined
00:12:46  <trevnorris>man. performance tuning is a seriously deep rabbit hole.
00:13:13  <isaacs>my guess is that it's somewhere around an oom
00:13:30  <isaacs>maybe not quite as much as haywire, but at least 5x
00:14:17  <trevnorris>cool. yeah.
00:16:54  * abraxasjoined
00:19:14  <trevnorris>isaacs: so users don't have access to the stream .buffer array, right?
00:20:30  * kenperkinsquit (Quit: Computer has gone to sleep.)
00:20:53  * stagasquit (Read error: Connection reset by peer)
00:21:33  * abraxasquit (Ping timeout: 276 seconds)
00:22:12  * octetcloudquit (Ping timeout: 276 seconds)
00:23:13  <trevnorris>oh, this is going to be good. hopefully have something for tomorrow.
00:25:52  <isaacs>trevnorris: they should not be touching that, correct.
00:25:56  <isaacs>trevnorris: not directly
00:26:10  <isaacs>trevnorris: only via .push(), .unshift(), .read(), .write() etc.
00:27:05  * kenperkinsjoined
00:29:33  * dominictarrquit (Quit: dominictarr)
00:30:57  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:31:13  * st_lukejoined
00:32:22  <isaacs>trevnorris: got a teaser?
00:40:41  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:41:38  * inolen1quit (Quit: Leaving.)
00:50:53  * kenperkinsquit (Quit: Computer has gone to sleep.)
00:57:05  * st_lukequit (Remote host closed the connection)
00:59:43  * kenperkinsjoined
01:02:15  * qardjoined
01:02:20  <trevnorris>isaacs: it's basically a way to get around the persistent/makeweak overhead while making them mostly safe.
01:02:51  <trevnorris>isaacs: the use case is that the .buffer[] is just a holder for the data until it's .concat() onto another buffer.
01:03:09  <trevnorris>so we don't need an entire buffer instance there since it'll be put into a buffer instance later.
01:03:50  * kenperkinsquit (Read error: Connection reset by peer)
01:03:52  * abraxasjoined
01:04:15  * dapquit (Quit: Leaving.)
01:04:19  * kenperkinsjoined
01:07:20  * perezdjoined
01:20:51  * c4milojoined
01:24:30  * kazuponjoined
01:32:17  * mikealquit (Quit: Leaving.)
01:44:55  * hzjoined
01:45:57  * hzquit (Client Quit)
01:49:40  * wolfeidauquit (Remote host closed the connection)
02:21:38  <isaacs>trevnorris: intriguing. won't that be worse when there's only one of those in the list, though?
02:21:51  <isaacs>trevnorris: right now, Buffer.concat([oneBuffer]) just returns [0]
02:22:50  * benoitcquit (Changing host)
02:22:51  * benoitcjoined
02:23:55  * TooTallNatejoined
02:34:10  * kenperkinsquit (Quit: Computer has gone to sleep.)
02:39:01  * perezdquit (Quit: perezd)
02:39:02  * brsonquit (Quit: leaving)
02:44:43  * perezdjoined
02:45:33  * wavdedjoined
02:45:52  * kazuponquit (Remote host closed the connection)
02:53:24  * kazuponjoined
02:56:48  * defunctzombie_zzchanged nick to defunctzombie
03:02:32  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:02:38  * qardquit (Quit: Leaving.)
03:03:12  * wavdedquit (Quit: Hasta la pasta)
03:07:12  * amartensjoined
03:10:37  * amartensquit (Client Quit)
03:14:05  * amartensjoined
03:27:28  * c4miloquit (Remote host closed the connection)
03:27:55  * c4milojoined
03:32:48  * c4miloquit (Ping timeout: 272 seconds)
03:32:59  * qardjoined
03:35:45  * defunctzombiechanged nick to defunctzombie_zz
03:36:50  * inolenjoined
03:41:53  * qardquit (Ping timeout: 240 seconds)
03:47:21  * kenperkinsjoined
03:47:40  * amartensquit (Quit: Leaving.)
04:08:56  <isaacs>ok, i'm dumb.
04:09:20  <isaacs>the more i start trying to actually use this thing, I'm realizing it's exactly DecodeWrite and DecodeBytes, which we should just fucking be using in StreamWrap.
04:09:21  * wolfeidaujoined
04:09:23  <isaacs>DERP
04:14:18  <isaacs>and they can be improved to match the thing in StreamWrap, which is better, afaict
04:14:56  * wolfeidauquit (Remote host closed the connection)
04:15:29  <isaacs>ohhh, wait, no. becuase it does this "max size" thing
04:15:39  <isaacs>which avoids a lot of Utf8Length() calls.
04:17:48  * kenperkinsquit (Read error: Connection reset by peer)
04:18:28  * octetcloudjoined
04:22:33  * octetcloudquit (Ping timeout: 240 seconds)
04:30:25  * amartensjoined
04:30:29  * amartensquit (Client Quit)
04:33:36  * qardjoined
05:00:30  * kazuponquit (Remote host closed the connection)
05:03:43  * kazuponjoined
05:04:18  * bajtosjoined
05:17:02  * bnoordhuisjoined
05:41:19  <bajtos>bnoordhuis: I am looking at seting debuger port for cluster workers, will you have time to discuss the implementation?
05:52:44  * benoitcquit (Excess Flood)
05:54:48  * mikealjoined
05:57:53  * benoitcjoined
05:58:27  * csaohjoined
06:10:03  * porcojoined
06:11:42  * csaohquit (Quit: csaoh)
06:12:28  * qardquit (Quit: Leaving.)
06:14:14  <isaacs>bnoordhuis: good morning
06:24:56  * stolsmajoined
06:29:58  <inolen>isaacs: were there any slides related to that image you tweeted out the other day of npm / the jenga tower?
06:30:13  * rendarjoined
06:30:18  <isaacs>inolen: you'll have to wait for the talk, I think :)
06:30:29  <inolen>ah, when is that?
06:31:11  <isaacs>inolen: oh, actually: https://skydrive.live.com/?cid=10c1b8af05aea524&id=10C1B8AF05AEA524%21125
06:31:22  <isaacs>https://twitter.com/eranhammer/status/329637546596376577
06:31:28  <isaacs>inolen: not sure when it'll be online
06:31:39  <isaacs>inolen: but really, the slides are just pictures. you need the story to go with it
06:31:46  <inolen>Sure, I'll wait for that then :)
06:32:38  * perezdquit (Quit: perezd)
06:54:31  <MI6>joyent/node: Miroslav Bajtoš v0.10 * a32a243 : debugger: breakpoints in scripts not loaded yet - http://git.io/o4Kk-g
06:54:58  <bnoordhuis>hey isaacs, what's up?
06:55:18  <bnoordhuis>bajtos: i'm around for a couple more minutes
06:56:01  <isaacs>bnoordhuis: not too much
06:56:29  <isaacs>bnoordhuis: realized that iw as reinventing DecodeBytes and DecodeWrite, and came up with a simpler API for my idea with piscisaureus
06:56:48  <bnoordhuis>okay, good
06:57:01  <isaacs>bnoordhuis: bonus, gonna support base64 and hex writes to streamwraps as well, though no one actually cares about that anyway
06:57:01  <bnoordhuis>simpler is better, grandma always used to say
06:57:06  <isaacs>yep :)
06:57:15  <isaacs>smart grandma :)
06:57:43  <bnoordhuis>yeah... she also said things about people with different skin colors but let's not go there today
06:57:55  <bnoordhuis>so what is the api going to look like?
06:58:50  * chiltsquit (Ping timeout: 255 seconds)
06:59:18  <isaacs>bnoordhuis: size_t StringBytes::Length(Handle<String>string, enum encoding encoding);
06:59:53  <isaacs>bnoordhuis: size_t StringBytes::Write(char *buf, size_t buflen, Handle<String> string, enum encoding encoding);
07:00:03  * chiltsjoined
07:00:03  <isaacs>basically, DecodeBytes and DecodeWrite
07:00:14  <isaacs>except, the buflen is an upper limit.
07:00:31  <isaacs>and the length calculation is fast rather than guaranteed
07:00:43  <isaacs>(can be oversized, espcially for utf8)
07:01:52  <isaacs>anyway, it's way past my bedtime. see you in 8 hours or so.
07:01:57  * isaacs&
07:01:57  <LOUDBOT>I'M NOT SAYING THERE SHOULD BE A CAPITAL PUNISHMENT FOR STUPIDITY, BUT WHY DON'T WE JUST TAKE THE SAFETY LABELS OFF OF EVERYTHING AND LET THE PROBLEM SOLVE ITSELF?
07:03:21  <bnoordhuis>sleep tight, isaac
07:03:29  <bnoordhuis>api looks reasonable to me
07:16:20  * piscisaureus_joined
07:16:58  <bnoordhuis>piscisaureus_: question about rerere
07:17:07  <piscisaureus_>ok
07:17:15  <bnoordhuis>if i set it up, will it auto-fix the merge conflict in libuv's src/version.c?
07:17:31  <bnoordhuis>it's trivial to fix by hand of course but automate what you can, right?
07:20:52  <bnoordhuis>piscisaureus_: btw, there's a bug in the release tool. it should wrap changelog lines at 80 columns
07:21:10  <piscisaureus_>bnoordhuis: probably not
07:21:20  <piscisaureus_>bnoordhuis: instead of... 79?
07:21:26  <bnoordhuis>oh wait, looks like it does (wrapping at 80 cols, that is)
07:21:43  <bnoordhuis>sorry, my bad
07:21:55  <piscisaureus_>there is a bug in the release tool in that it includes the bump commit in the changelog sometimes
07:21:59  <piscisaureus_>unless you manually edit it out
07:22:06  <piscisaureus_>it doesn't for me but it apparently does for isaac
07:23:18  <piscisaureus_>bnoordhuis: I don't know an off-hand trick to avoid merge conflicts in version.c (and AUTHORS / ChangeLog)
07:24:30  <piscisaureus_>bnoordhuis: btw we should make a v0.10 release if saghul is going to release pyuv today
07:24:37  <piscisaureus_>bnoordhuis: you can do it if you want :)
07:24:47  <MI6>nodejs-v0.10: #169 UNSTABLE windows-x64 (8/582) smartos-x64 (3/582) windows-ia32 (8/582) linux-ia32 (1/582) http://jenkins.nodejs.org/job/nodejs-v0.10/169/
07:24:58  <MI6>joyent/libuv: Ben Noordhuis master * ebdeaed : Merge remote-tracking branch 'origin/v0.10' (+9 more commits) - http://git.io/BBDeaw
07:25:05  <saghul>piscisaureus_ yeah, I was planning to do so this evening
07:30:18  <MI6>libuv-master-gyp: #23 UNSTABLE windows-x64 (4/189) smartos-ia32 (3/188) windows-ia32 (4/189) smartos-x64 (3/188) osx-ia32 (1/189) osx-x64 (1/189) http://jenkins.nodejs.org/job/libuv-master-gyp/23/
07:31:12  <MI6>libuv-master: #85 UNSTABLE windows (5/189) osx (2/189) smartos (3/188) linux (1/188) http://jenkins.nodejs.org/job/libuv-master/85/
07:31:32  * csaohjoined
07:34:31  <bnoordhuis>piscisaureus_: i'll give it a spin
07:36:14  <bnoordhuis>piscisaureus_: how does it work? just `node release`?
07:36:54  <piscisaureus_>bnoordhuis: 1) you have to check out the correct branch/commit that you want to release in a libuv working tree.
07:37:27  <piscisaureus_>bnoordhuis: that tree should have the upstream tags and only those (well, atleast no private tags that look like v0.1.2)
07:37:27  <bnoordhuis>and i have to set up gpg, it seems
07:37:31  <piscisaureus_>bnoordhuis: yes
07:37:49  <piscisaureus_>bnoordhuis: then you use `node release --dir /path/to/libuv`
07:38:02  <piscisaureus_>bnoordhuis: you must also ensure you can ssh into libuv@libuv.org
07:38:22  <bnoordhuis>i don't think i can
07:38:47  <bnoordhuis>is the password 'hunter2'?
07:49:05  <piscisaureus_>bnoordhuis: bennetjedegekste1991
07:51:01  * bnoordhuisquit (Ping timeout: 248 seconds)
08:00:13  <MI6>libuv-node-integration: #40 UNSTABLE windows-ia32 (146/587) osx-ia32 (1/587) windows-x64 (146/587) osx-x64 (1/587) http://jenkins.nodejs.org/job/libuv-node-integration/40/
08:02:29  * dominictarrjoined
08:13:02  * groundwaterquit (Ping timeout: 252 seconds)
08:21:05  * dominictarrquit (Quit: dominictarr)
08:26:37  * kazuponquit (Remote host closed the connection)
08:53:39  * stagasjoined
08:56:53  * kazuponjoined
08:57:17  * bnoordhuisjoined
09:01:41  * bnoordhuisquit (Ping timeout: 255 seconds)
09:05:56  * kazuponquit (Ping timeout: 272 seconds)
09:06:10  * kazuponjoined
09:16:25  * timoxleyjoined
09:42:20  * dominictarrjoined
09:57:28  * wolfeidaujoined
10:08:58  * csaohquit (Quit: csaoh)
10:11:07  * bajtosquit (Quit: Nettalk6 - www.ntalk.de)
10:16:16  * stolsmaquit (Ping timeout: 245 seconds)
10:21:51  * dominictarrquit (Quit: dominictarr)
10:26:33  * abraxasquit (Remote host closed the connection)
10:29:39  * csaohjoined
10:33:41  * dominictarrjoined
10:46:09  <MI6>joyent/libuv: Bert Belder v0.10 * c8d39cc : ChangeLog: fix minor errors - http://git.io/MxRXTQ
10:48:14  <MI6>libuv-v0.10: #50 UNSTABLE smartos (3/186) windows (5/187) linux (1/186) osx (1/187) http://jenkins.nodejs.org/job/libuv-v0.10/50/
10:51:01  * timoxleyquit (Quit: Computer has gone to sleep.)
10:51:40  * stagasquit (Read error: Connection reset by peer)
10:52:09  * porcoquit (Quit: Linkinus - http://linkinus.com)
10:53:17  <MI6>libuv-v0.10-gyp: #13 UNSTABLE smartos-ia32 (3/186) windows-x64 (4/187) linux-ia32 (1/186) smartos-x64 (4/186) windows-ia32 (5/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/13/
11:00:41  <MI6>joyent/libuv: isaacs refs/tags/v0.10.5 * 751c127 : 2013.04.24, Version 0.10.5 (Stable) - http://git.io/E-Ghug
11:00:43  <MI6>joyent/libuv: Bert Belder refs/tags/v0.10.3 * 5716386 : 2013.02.04, Version 0.10.3 (Stable) - http://git.io/F0EqmQ
11:08:16  <piscisaureus_>SHIT
11:10:22  <MI6>joyent/libuv: isaacs refs/tags/v0.10.5 * 1c18137 : 2013.04.24, Version 0.10.5 (Stable) - http://git.io/oVgU3w
11:10:24  <MI6>joyent/libuv: Bert Belder refs/tags/v0.10.3 * 50c57ab : 2013.02.04, Version 0.10.3 (Stable) - http://git.io/M8571A
11:11:37  <MI6>libuv-node-integration: #41 FAILURE smartos-x64 (1/582) linux-x64 (1/582) http://jenkins.nodejs.org/job/libuv-node-integration/41/
11:15:39  <MI6>joyent/libuv: isaacs refs/tags/v0.10.5 * 637ecf8 : 2013.04.24, Version 0.10.5 (Stable) - http://git.io/HEhqhw
11:15:55  <MI6>joyent/libuv: Bert Belder v0.10 * f6fb1df : ChangeLog: fix incorrect release date - http://git.io/JvY4nA
11:26:57  * kazuponquit (Remote host closed the connection)
11:29:56  * bnoordhuisjoined
11:31:21  * dominictarrquit (Read error: Connection reset by peer)
11:31:33  * hzjoined
11:32:09  * stolsmajoined
11:39:16  * bajtosjoined
11:40:08  * c4milojoined
11:44:07  <bajtos>bnoordhuis: piscisaureus_: are you around? I'd like to discuss my commit that enables cluster debugging. https://github.com/bajtos/node/commit/16714af7dcaabdb6679678be29f023f5f941b21e
11:45:16  <bajtos>bnoordhuis: piscisaureus_: the first question is - which parts can be backported to v0.10 (if not all of them)?
11:55:23  <bnoordhuis>bajtos: i'm here but i'm finishing up something
12:12:10  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 9b801d5 : darwin: rename darwin-getproctitle.m (+1 more commits) - http://git.io/CdTizw
12:13:27  <bnoordhuis>okay, done
12:13:57  <bnoordhuis>bajtos: the lib/cluster.js diff between v0.10 and master is unfortunately very big
12:14:11  <bnoordhuis>straight-up cherry-picking is not possible
12:15:23  <bajtos>bnoordhuis: I was more concerned about possible breaking changes - piscisaureus_ was not sure about the bit where SIGUSR1 to master triggers SIGUSR1 in workers
12:18:46  <bajtos>bnoordhuis: i looked at v0.10, seems that for example the part about setting debug ports (read from environ variable + change --debug=port to --debug) should be easy to backport
12:18:47  <bnoordhuis>ah that
12:19:12  <bnoordhuis>well, the SIGUSR1 thing is certainly a change in behavior, therefore not eligble
12:19:17  <bnoordhuis>*eligible
12:19:52  <bajtos>ok.
12:20:30  <bajtos>what would be the best approach? create PR for master with single commit containing all changes, and then PR for v0.10 with hand-crafted commit containing only debug port changes?
12:22:01  <bajtos>(btw that will be a change of behaviour too, although it is more like a bug fix than a feature)
12:22:42  * AvianFlujoined
12:27:08  * dominictarrjoined
12:32:54  * dominictarrquit (Read error: Connection reset by peer)
12:33:34  * kazuponjoined
12:40:14  * kazuponquit (Remote host closed the connection)
12:40:48  * kazuponjoined
12:45:31  * kazuponquit (Ping timeout: 264 seconds)
12:48:42  * dominictarrjoined
13:01:47  * defunctzombie_zzchanged nick to defunctzombie
13:21:35  <bnoordhuis>bajtos: getting there :)
13:22:22  * kevinswiberjoined
13:26:16  * bettajoined
13:28:30  <betta>hi
13:29:23  <bnoordhuis>sup betta?
13:30:02  <betta>a little question I fear....
13:30:14  <betta>if I create a new "server"-socket using uv_tcp_bind an a port of 0, is there any way to get the port
13:30:17  <betta>?
13:30:29  <betta>(the port which was choosen by the OS)
13:30:59  * stolsmaquit (Ping timeout: 260 seconds)
13:31:00  <betta>up till now I used getsockname() in connection with "stream->io_watcher.io"
13:31:23  <bnoordhuis>betta: uv_tcp_getsockname()
13:31:29  <betta>.___.
13:31:43  <betta>oh well
13:34:11  * defunctzombiechanged nick to defunctzombie_zz
13:34:55  <betta>thanks bnoordhuis
13:35:47  <bnoordhuis>no problem :)
13:35:51  <bnoordhuis>bajtos: you around?
13:36:11  * defunctzombie_zzchanged nick to defunctzombie
13:36:26  <bajtos>bnoordhuis: yep
13:36:58  <bnoordhuis>bajtos: so NODE_DEBUG_PORT
13:37:05  <bnoordhuis>i already posted a comment on the commit
13:37:12  <bnoordhuis>but for the record, i don't object to the env var
13:37:13  <bajtos>bnoordhuis: yes, it's a tricky thing
13:37:23  <bnoordhuis>i just don't like that it comes with 30+ lines of c++ code
13:37:57  <bajtos>bnoordhuis: I understand, I am not very happy about it either (plus it's copy and pasted and modified from env getter/setter for JS)
13:38:09  <bnoordhuis>i gathered that much, yes :)
13:39:41  <bajtos>bnoordhuis: I don't see any way how to move it to javascript while running it before we start V8 (for `node --debug` case)
13:40:16  <bajtos>(from obvious reasons)
13:40:58  <bnoordhuis>no, okay
13:41:17  <bnoordhuis>that's why i suggested to hack the worker's process args
13:41:32  <bnoordhuis>the reason i'd rather see it in js even if means some disparate code
13:41:55  <bnoordhuis>is that there's only two or three people that realistically maintain the c++ code
13:42:06  <bnoordhuis>while there is a much larger pool of people willing to dive into the js side of things
13:42:25  <bnoordhuis>iow, more js and less c++ means less work for me :)
13:43:08  <bajtos>understood.
13:44:55  <bajtos>what about using --debug-port=xyz instead of NODE_DEBUG_PORT then? it is still some C++ code, but it should be much less than for environment variables
13:45:48  <bajtos>the ugly thing about --debug-port is that you will see it in `ps` output even when running production processes without debugging
13:45:48  <bnoordhuis>bajtos: i can live with that
13:46:21  <bnoordhuis>meh. on a scale of 1 to 10 of things to worry about, that ranks a 3 at best
13:47:20  <bnoordhuis>turning it around, it makes debugging the debugger easier :)
13:47:35  <bajtos>now I realized that node handles --debug only if it's a first parameter. that would simplify cluster code - either there is --debug/--debug-brk as the first parameter, or we add --debug-port
13:47:53  <bnoordhuis>yep
13:48:04  <bajtos>ok, I'll do it this way
13:48:51  <bajtos>oh, I am wrong, it looks at all parameters - there is a loop in ParseArgs
13:49:54  <bnoordhuis>yeah, but it stops at the first non-arg argument
13:50:08  <bnoordhuis>'non-arg argument' <- oxymoron
13:50:12  <bnoordhuis>you get my point
13:50:32  <bajtos>yes :)
13:51:28  * kazuponjoined
13:52:43  <piscisaureus_>bnoordhuis: what doesn't strike you as very safe
13:53:43  * kazuponquit (Read error: Connection reset by peer)
13:54:13  <bnoordhuis>piscisaureus_: calling uv_async_init() from another thread
13:54:26  <piscisaureus_>ooh
13:54:39  <piscisaureus_>bajtos: that was not the idea. you need to async_init from the main thread when node starts up.
13:55:19  <bnoordhuis>piscisaureus_: well, node already seems to be doing it
13:55:32  <bnoordhuis>EnableDebugThreadProc() -> EnableDebug() -> uv_async_init()
13:55:59  * bettaquit (Quit: - nbs-irc 2.39 - www.nbs-irc.net -)
13:56:00  <bnoordhuis>(in src/node.cc)
13:58:42  <bajtos>I guess we should fix both calls to uv_async_init() - think of a case when somebody sends SIGUSR1 twice
13:59:35  <bnoordhuis>bajtos: yep. the handle should be initialized (and unref'd) at startup, not when the signal arrives
14:01:38  <bajtos>I'll address it in different PR after I finish this cluster debugging changes, if that's ok?
14:04:33  <bajtos>bnoordhuis: ad --debug-port - what about this? https://github.com/bajtos/node/commit/d42ad766dfee0b5ca3a8c92c26e091c3374d06c6
14:15:42  <piscisaureus_>wait - what
14:16:00  <piscisaureus_>bnoordhuis: if that's true then what bajtos is doing shouldn't be necessary
14:16:32  <bnoordhuis>piscisaureus_: you're way behind, we've iterated, pivoted and so on at least three times
14:16:49  <piscisaureus_>bnoordhuisL ok
14:16:54  <piscisaureus_>* bnoordhuis
14:19:20  * kenperkinsjoined
14:19:47  <bajtos>bnoordhuis: I think it's time to squash all commits and submit a PR, what do you think?
14:22:18  <bnoordhuis>bajtos: go ahead
14:23:36  * dominictarrquit (Ping timeout: 264 seconds)
14:27:58  * dominictarrjoined
14:29:48  <bajtos>bnoordhuis: https://github.com/joyent/node/pull/5397
14:36:35  <bajtos>bnoordhuis
14:37:02  <bajtos>regarding moving uv_async_init() out of EnableDebug
14:37:27  <bajtos>the change is small, shall I add it to PR 5397 or start a new one?
14:41:34  <bnoordhuis>bajtos: don't care as long as it's a separate commit
14:41:57  <bajtos>bnoordhuis: ok, it will be there in a minute
14:47:00  <bajtos>bnoordhuis: done
14:47:37  <bajtos>bnoordhuis: could you please review? I'll have to leave soon :(
14:48:09  <bnoordhuis>that's my life, reviewing other people's code all day
14:48:17  <bnoordhuis>momma was right, i should've become a lawyer
14:49:02  <bajtos>bnoordhuis: programmers are at least more popular than lawyers :)
14:49:19  <bajtos>at least among other programmers :-D
14:49:54  <bnoordhuis>yeah, that's true. they get paid significantly less than lawyers though
14:50:14  <bnoordhuis>i was talking to a lawyer this morning at $500/hour :-/
14:50:48  <bnoordhuis>bajtos: "Fixed bug in initialization of uv_async_t handles related to debugging." <- too vague
14:50:53  <bnoordhuis>also, past tense :)
14:50:59  <bajtos>oh
14:51:24  <bnoordhuis>describe what the bug was, its (potential) effect and how you fixed it
14:53:57  <bnoordhuis>bajtos: same for the other commit btw, i.e. s/Implemented/Implement/
15:00:10  * dapjoined
15:05:51  * mikealquit (Quit: Leaving.)
15:09:11  * bajtos2joined
15:09:48  * bajtosquit (Ping timeout: 264 seconds)
15:09:55  * bajtos2changed nick to bajtos
15:10:08  * bajtosquit (Client Quit)
15:10:27  * bajtosjoined
15:16:05  * dominictarrquit (Quit: dominictarr)
15:18:47  * bajtosquit (Quit: Nettalk6 - www.ntalk.de)
15:23:00  * bnoordhuisquit (Ping timeout: 264 seconds)
15:42:54  <isaacs>who uses Buffer.charsWritten?
15:42:59  <isaacs>this thing is a pita
15:47:11  * dominictarrjoined
15:55:49  <trevnorris>isaacs: forgot that still exists in v0.10. at least it's gone in master. :)
16:02:03  * defunctzombiechanged nick to defunctzombie_zz
16:03:39  * kevinswiberquit (Remote host closed the connection)
16:04:34  <isaacs>orly?
16:04:35  <isaacs>nice.
16:04:42  <isaacs>i was just about to suggest we remove it :)
16:06:16  <trevnorris>isaacs: it getting in the way of some changes you want to make?
16:07:16  <isaacs>trevnorris: nah, just making this a bit more sticky, that's all.
16:07:36  <isaacs>trevnorris: need to pass a int* to a function that was otherwise a bit simpler.
16:08:28  * bnoordhuisjoined
16:08:34  <tjfontaine>lets see why windows died today
16:09:02  * octetcloudjoined
16:10:22  <tjfontaine>oh look it bluescreen'd, how predictable
16:12:17  <bnoordhuis>hah, seriously?
16:13:02  <tjfontaine>ya
16:13:02  <isaacs>tjfontaine: omg
16:13:08  <isaacs>tjfontaine: you are a saint, sir.
16:14:01  <tjfontaine>heh
16:14:11  * benoitcquit (Ping timeout: 245 seconds)
16:15:19  <MI6>libuv-v0.10-gyp: #14 FAILURE osx-ia32 (1/187) smartos-ia32 (3/186) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/14/
16:17:28  * benoitcjoined
16:17:39  <isaacs>it's so confusing, this chars written thing
16:17:55  <MI6>libuv-master-gyp: #24 FAILURE windows-x64 (4/189) http://jenkins.nodejs.org/job/libuv-master-gyp/24/
16:17:55  <isaacs>like, for buf.write(string, 'utf8'), i mean, ok, it's the number of characters in the string that were written
16:18:06  <isaacs>but for buf.write(string, 'hex')? i can't figure out what this is even supposed to mean..
16:18:39  <trevnorris>isaacs: well, if you can
16:18:54  <trevnorris>'t figure it out, then doubt anyone else is using it.
16:19:02  <isaacs>yeah
16:19:17  <isaacs>in that case, it's double the number of bytes written
16:19:23  <isaacs>like, the number of hex chars consumed, i guess?
16:19:31  <tjfontaine>seems that way
16:20:13  <tjfontaine>I interpret charsWritten as "usually equal to bytes, unless it's utf8"
16:22:48  * kenperkinsquit (Quit: Computer has gone to sleep.)
16:22:52  <trevnorris>anyone know if it's possible to set what a prototype of an ObjecTemplate should be on NewInstance(), or do you have to start with a FunctionTemplate()?
16:23:30  <isaacs>tjfontaine: well, unless it's utf8 or ucs2 or hex
16:23:40  <isaacs>tjfontaine: it's the number of characters consumed in the string
16:23:52  <isaacs>tjfontaine: so you can do another write of the rest, if it wasn't all written
16:23:54  <tjfontaine>isaacs: evil
16:23:56  * kenperkinsjoined
16:24:09  <isaacs>but at least, for ucs2 and hex, it's just double
16:24:12  <isaacs>utf8 is the only hard one
16:24:20  <tjfontaine>trevnorris: I didn't see one, but if you find it let me know
16:24:31  <trevnorris>tjfontaine: will do
16:24:40  <tjfontaine>trevnorris: I only saw NewInstance() and NewInstance(argv) more or less
16:24:46  <isaacs>trevnorris: this is up your alley... it looks like HexWrite swallows errors and returns 0 bytes written for bounds violations. the others all thrwo.
16:25:10  <trevnorris>isaacs: oh mother.
16:25:23  * trevnorrischecks if new buffer implementation does the same.
16:25:24  <isaacs>(good example of the class of errors that DRY code prevents, btw. not that DRY is always best, but in this case, yes.)
16:25:24  <MI6>libuv-v0.10-gyp: #15 UNSTABLE osx-ia32 (1/187) smartos-ia32 (3/186) windows-x64 (5/187) smartos-x64 (3/186) windows-ia32 (5/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/15/
16:25:25  <MI6>libuv-v0.10: #51 UNSTABLE smartos (3/186) windows (6/187) linux (1/186) osx (1/187) http://jenkins.nodejs.org/job/libuv-v0.10/51/
16:25:54  <isaacs>trevnorris: i'm unifying our "put string+encoding into char*" code
16:25:59  <isaacs>trevnorris: so that i can use it in crypto
16:26:22  <isaacs>trevnorris: i think i'm gonna make hex just throw for bounds violations, since it ought to anywya.
16:26:38  <isaacs> if (start >= parent->length_) {
16:26:38  <isaacs> Local<Integer> val = Integer::New(0);
16:26:38  <isaacs> constructor_template->GetFunction()->Set(chars_written_sym, val);
16:26:38  <isaacs> return scope.Close(val);
16:26:38  <isaacs> }
16:26:44  <isaacs>^ that is kinda sad.
16:26:57  <isaacs>if only because the other Buffer::*Write() functions all throw on tha
16:26:58  <isaacs>t
16:27:09  <isaacs>(or just lack protection, in some of them)
16:27:14  <trevnorris>isaacs: new buffers have a unified ParseArrayIndex. right now it coerces. but if it should throw then easy change. :)
16:27:30  <isaacs>trevnorris: kewl.
16:27:46  <isaacs>trevnorris: i suspect that landing this change in 0.10 will make life a bit annoying for you when we merge into master.
16:27:50  <isaacs>trevnorris: i apologize in advance.
16:28:11  <trevnorris>no worries. nature of coding. :)
16:39:15  * TooTallNatejoined
16:43:35  * mikealjoined
16:47:23  * perezdjoined
16:48:56  <MI6>joyent/node: isaacs v0.10 * 0e21d7b : doc: link joyent logo in website footer - http://git.io/59qq7A
16:49:09  <isaacs>^ surprised no one complained harder about that sooner
16:49:55  <tjfontaine>heh
16:50:59  * benoitcquit (Quit: unexpected thing makes me to quit)
16:56:50  * qardjoined
16:57:16  * bnoordhuisquit (Ping timeout: 260 seconds)
16:58:20  <MI6>libuv-node-integration: #42 UNSTABLE windows-ia32 (9/582) smartos-x64 (1/582) windows-x64 (8/582) smartos-ia32 (1/582) http://jenkins.nodejs.org/job/libuv-node-integration/42/
16:58:29  * benoitcjoined
17:01:44  * st_lukejoined
17:02:21  * hzquit
17:03:04  * hzjoined
17:05:39  * csaohquit (Quit: csaoh)
17:05:41  <trevnorris>bugger. SetWrapperClassId can only be set on persistents. which means it's the only way to track memory for a heap dump. =P
17:06:00  <trevnorris>isaacs: have my initial implementation ready. and works fine.
17:06:21  * rphillipsquit (Excess Flood)
17:06:26  <trevnorris>isaacs: and turning them into a buffer isn't an issue.
17:06:35  <isaacs>nice
17:06:52  * rphillipsjoined
17:06:55  <isaacs>trevnorris: this is for the "Streams use fake buffers instead of real buffers" thing?
17:07:01  * hzquit (Read error: Connection reset by peer)
17:07:03  <isaacs>minibuffers
17:07:07  <isaacs>whatever you're calling them :)
17:07:08  <tjfontaine>thinbuffers
17:07:09  <tjfontaine>:)
17:07:17  <isaacs>call them FastBuffers
17:07:22  <isaacs>just for extra confusion :)
17:07:25  <tjfontaine>hehe
17:07:26  <trevnorris>lol
17:07:50  <trevnorris>they're super fast, but just can't track them in a heapdump.
17:07:52  * amartensjoined
17:07:57  <trevnorris>(as mentioned above)
17:08:41  * eris0xffjoined
17:08:52  <eris0xff>good morning
17:09:18  <trevnorris>isaacs: the api is basically "var obj = _ucalloc(N, {})", then when you're done with it: "_dipose({})"
17:09:29  <trevnorris>it'll clear out the attached memory.
17:09:48  <trevnorris>or you can pass it to an internal Buffer function that will convert it into a normal buffer.
17:10:30  <isaacs>trevnorris: can you set some recognizable field on theM?
17:10:44  <trevnorris>isaacs: yeah. what did you have in mind?
17:10:44  <isaacs>trevnorris: thingie.isMiniBuffer = true
17:10:50  <trevnorris>sure.
17:11:06  <isaacs>trevnorris: just something so that if you dump them in ::findjsobjects or ::jsprint in mdb, they'll stand out
17:11:19  <trevnorris>isaacs: ah. great idea. ok.
17:11:30  <tjfontaine>have we indoctrinated him enough to make him leave linux?
17:11:36  <isaacs>trevnorris: could also be useful to put the length or whatever other minimal debuggery could be good.
17:11:56  <trevnorris>ok. let me whip something up.
17:12:47  * rphillipsquit (Max SendQ exceeded)
17:13:22  * rphillipsjoined
17:23:04  * txdvquit (Read error: Connection reset by peer)
17:23:24  * txdvjoined
17:23:46  * stagasjoined
17:26:04  * hzjoined
17:36:26  * mikealquit (Quit: Leaving.)
17:36:48  * kevinswiberjoined
17:39:17  <MI6>nodejs-master: #190 FAILURE windows-x64 (147/587) http://jenkins.nodejs.org/job/nodejs-master/190/
17:40:30  <MI6>nodejs-v0.10: #170 FAILURE linux-x64 (1/582) windows-x64 (5/342) windows-ia32 (8/582) http://jenkins.nodejs.org/job/nodejs-v0.10/170/
17:40:34  <tjfontaine>ah build timeout ont eh first one
17:40:56  <tjfontaine>yup same for that one
17:41:05  * tjfontainechanges how that works
17:43:03  * AvianFluquit (Remote host closed the connection)
17:48:38  * mikealjoined
17:51:22  * brsonjoined
17:55:18  * indexzerojoined
17:55:55  * mcavagequit (Remote host closed the connection)
17:56:43  * eris0xffquit (Ping timeout: 245 seconds)
18:03:10  * bnoordhuisjoined
18:05:17  * st_lukequit (Remote host closed the connection)
18:05:53  * st_lukejoined
18:07:33  * bnoordhuisquit (Ping timeout: 240 seconds)
18:09:23  <trevnorris>for future reference, going to refer to these as ThinBuffer.
18:09:39  <tjfontaine>I win!
18:10:03  <trevnorris>well, it's more like a thin wrapper around external memory allocation, but that's too long.
18:10:10  <tjfontaine>hehe
18:10:47  <trevnorris>but they are now faster than even pooled buffers on the js side. and almost twice as fast on the cc side.
18:11:18  <isaacs>hmmm.... i think i'm getting carried away.
18:11:31  <isaacs>probably shouldnot try to DRY out the Buffer::*Slice() methods as well...
18:11:33  <tjfontaine>refocus time
18:11:35  <isaacs>yep
18:12:43  <isaacs>though, it would be nice to havea single node::StringEncoding class that just converted back and forth between a string/buffer+encoding and a char*/size_t
18:12:59  <isaacs>we have a lot of not-quite-identical implementations kicking around, in buffer.cc and node.cc
18:13:07  <tjfontaine>yup
18:13:11  <isaacs>dating to various different node epochs
18:13:20  <isaacs>with comments and assertions that don't always make sense.
18:13:22  * TooTallNatequit (Quit: Computer has gone to sleep.)
18:13:41  <isaacs>it's one of those things where you start sweeping the floor, then realize it's a dirt floor. at some point you either get out the shovel, or just accept it.
18:14:13  <tjfontaine>haha
18:14:52  * c4miloquit (Remote host closed the connection)
18:15:18  * c4milojoined
18:16:20  <trevnorris>isaacs: so this is going onto the v0.10 branch, right?
18:16:29  <isaacs>trevnorris: yeah
18:16:42  <isaacs>it's all internal, and will improve crypto performance considerably.
18:16:48  <trevnorris>ok.
18:17:12  * trevnorrisprepares for the rebase after merge
18:17:20  <trevnorris>man, buffers are getting a serious overhaul.
18:18:52  <isaacs>trevnorris: if you wanna follow the action, my crypto-fix-perf is starting to look like the intended shape.
18:19:06  <isaacs>trevnorris: just pushed the (hopefully) last changes that affect Buffer and other generic stuff.
18:19:41  <isaacs>trevnorris: basically just moving all the string decoding into one place, and thus making the Buffer::*Write() functions all consistent in their behavior at the same time
18:19:55  <isaacs>now on to the actual motivation for this :)
18:20:06  * c4miloquit (Ping timeout: 272 seconds)
18:20:13  <isaacs>oh! and, with this, it should be pretty easy to move more of our string-to-buffer stuff below the C++ boundary
18:20:24  <trevnorris>isaacs: does that touch much of the actual argument parsing, or just the encode/decode part?
18:20:27  <isaacs>so maybe fs etc can get faster.
18:20:40  <isaacs>trevnorris: just the decode part (not encode)
18:20:59  <isaacs>trevnorris: but i made a Buffer::StringWrite<encoding> template, so they're all going through the same code path now
18:21:31  <isaacs>this also highlights just how awful Buffer._charsWritten really is, since you can see it doing opposite things right in the same function :)
18:21:36  <trevnorris>coolio. I didn't touch any of that. just the argument parsing.
18:21:39  <trevnorris>lol, yeah.
18:22:06  <isaacs>you knwo, i <3 the speed that you can crank shit out with JS, but C and C++ really do feel so much more pure in a very satisfying wya.
18:22:33  <isaacs>fewer mysteries. just you and your memory and the operations your'e telling it to perform on it.
18:24:03  * kevinswiberquit (Remote host closed the connection)
18:29:20  * timoxleyjoined
18:33:00  * TooTallNatejoined
18:34:29  * c4milojoined
18:38:38  * kevinswiberjoined
18:40:51  <trevnorris>isaacs: ok. api is now: "var a = ucalloc(n); a.dispose()". also .isThinBuffer and .length are set.
18:41:11  <trevnorris>and it's hella fast.
18:41:39  <isaacs>nice
18:53:21  * indexzeroquit (Quit: indexzero)
19:04:02  <wolfeidau>Anyone have any tips on building mac-tick-processor in the node-v0.10.5 tar source bundle can't seem to compile v8 standalone even after removing gyp file for tests
19:07:22  * normanmjoined
19:07:40  <normanm>hi there.. one small question… does libuv support edge-triggered epoll on linux ?
19:07:58  <normanm>I know it was discussed to support it some time ago but not know the outcome
19:22:43  * normanmquit (Quit: Computer has gone to sleep.)
19:25:25  * inolenquit (Quit: Leaving.)
19:25:58  * perezdquit (Quit: perezd)
19:27:01  * inolenjoined
19:27:58  <trevnorris>isaacs: ok, this is beautiful. so I can ucalloc and turn that into a full Buffer instance in the same time it takes to generate a new Buffer instance.
19:28:09  <isaacs>awesome!
19:28:50  <trevnorris>isaacs: and ucalloc is same speed for 1 byte buffers, as pooled Buffers, but +100% faster for anything over 1kB
19:31:19  <trevnorris>isaacs: and i'm anxious to see the outcome of what you're doing now.
19:31:29  <isaacs>trevnorris: it's coming along pretty nicely
19:31:30  <isaacs>just tedious
19:31:40  <isaacs>crypto isn't the dryest bit of code in node.js :0
19:31:47  <isaacs>in fact, it's soaking wet :)
19:31:55  <trevnorris>lol. well, it'll be nice to get it there.
19:32:02  * isaacsresisting the urge to dig up the dirt floor...
19:32:06  * EhevuTovjoined
19:32:26  <trevnorris>let's hold that off for v0.13, in prep for v1. :)
19:33:01  * timoxleyquit (Quit: Computer has gone to sleep.)
19:35:07  <creationix>remind me what EPIPE means
19:35:36  <isaacs>creationix: the thing you're trying to write to is no longer there.
19:35:40  <creationix>I'm trying to pipe stdin to stdout using only process.binding('tty_wrap').TTY on fd 0 and 1
19:35:41  <isaacs>creationix: ie, the socket's been closed, etc.
19:35:54  <isaacs>creationix: in a unix pipe situation, usually it means that the other side has closed.
19:35:56  <creationix>implement a bare-bones cat essentially
19:36:09  <isaacs>creationix: ie: ./writeALot | ./readALittle
19:36:17  <isaacs>creationix: right.
19:36:22  <creationix>I using node on windows
19:36:24  <isaacs>creationix: cat just detects EPIPE and shuts down
19:36:30  <isaacs>creationix: you should probably do the same
19:38:22  <creationix>hmm, I get epipe the first time I try to write to stdout
19:38:34  <creationix>do I need to do something special to setup stdout?
19:39:12  <isaacs>trevnorris: pushed the first bit of the crypto changes to my branch
19:39:20  <isaacs>trevnorris: i don't think the buffer stuff is going to change any further.
19:39:41  <isaacs>trevnorris: so if you want to try seeing how your stuff and mine collides, could get a head start on it. but it's probably not so bad.
19:41:35  <trevnorris>isaacs: coolio. thx.
19:43:09  <isaacs>and already got back most of the crypto stream creation performance regression.
19:43:15  <isaacs>lunch, and then the rest :)
19:47:00  * kevinswiberquit (Remote host closed the connection)
19:48:01  * dapquit (Quit: Leaving.)
19:49:21  * indexzerojoined
19:53:17  <tjfontaine>wolfeidau: ben has a separate tool that generates the tick processor that I generally use
19:53:33  * kevinswiberjoined
19:54:22  <creationix>weird, as soon as I mess with a TTY instance for fd 1 my node process hard-exits
19:54:35  <creationix>is there something special about stdout on windows?
19:54:48  <tjfontaine>wolfeidau: https://github.com/bnoordhuis/node-profiler/tree/master/tools the nprof one
19:55:05  <wolfeidau>tjfontaine: o that would rock, turns out I also ran into also bug in v8 raising an error on private field, just worked out the cxxflag to fix it
19:55:45  <tjfontaine>nod
19:56:13  <creationix>by TTY instance I mean new (process.binding('tty_wrap').TTY)(1, false);
19:58:01  <wolfeidau>tjfontaine: wow that is awesome, so you just run that in the v8 snapshot within deps in nodes source tree?
19:59:05  <tjfontaine>wolfeidau: no he ships the necessary v8 bits I think, so you don't need node to build it
19:59:18  <wolfeidau>o sweet so just clone that and build
19:59:21  <tjfontaine>yup
19:59:44  <tjfontaine>it may be that those bits may need updating for newer v8's at times, dunno how fragile it is
20:00:03  * kuebkjoined
20:00:08  <tjfontaine>they are 4months old, so releatively fresh
20:00:19  <piscisaureus_>https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/nodejs/hello.js
20:00:20  <trevnorris>you do need to make sure the version of the parser matches the version of v8 in node.
20:01:14  <wolfeidau>yeah i ran the latest v8 mac-tick-processor and it spewed out warnings, hence the journey through v8 and trying to get it built in the nodes v8 source tree
20:01:21  <creationix>well, using process.stdout._handle works, I guess you can't open it twice
20:01:50  <wolfeidau>tjfontaine: But I will try that now, should be able to hack sometihng together either way :)
20:01:58  <tjfontaine>enjoy!
20:02:00  <tjfontaine>:)
20:02:22  <tjfontaine>os.unlink() [Error 32] The process cannot access the file because it is being used by another process: 'c:\\users\\admini~1\\appdata\\local\\temp\\2\\tmp5w8yjz'
20:02:29  <tjfontaine>I love you so much windows
20:02:52  * c4miloquit (Remote host closed the connection)
20:03:11  <indutny>rust is so fucking cool
20:03:15  <creationix>isaacs: the EPIPE was because I was opening stdout in read mode and then writing to it
20:03:17  <indutny>I don't want to write C :)
20:03:18  * c4milojoined
20:03:25  <creationix>so that makes sense
20:03:30  <trevnorris>indutny: cool. i'll go tell the team that. :)
20:03:36  <indutny>haha
20:03:41  <indutny>great
20:03:43  * c4miloquit (Read error: Connection reset by peer)
20:04:02  * c4milojoined
20:04:51  * dpemmonsquit (Read error: Operation timed out)
20:06:26  * dpemmonsjoined
20:07:16  * pquernaquit (Ping timeout: 256 seconds)
20:07:29  * pquernajoined
20:07:52  <trevnorris>indutny: i added an api to the allocator. it's user controlled memory. the user has to run .dipose() on the object before it goes out of scope.
20:07:56  <trevnorris>but man it's freakin fast.
20:08:05  <indutny>hah
20:08:11  <indutny>no doubts
20:09:07  <trevnorris>and I can convert it onto a full Buffer instance in about the same time instantiating a Buffer takes.
20:09:44  <isaacs>trevnorris: * ThinBuffer: New API for Leaking Memory (Trevor Norris)
20:09:50  <isaacs>trevnorris: ;P
20:09:57  <trevnorris>lol
20:10:23  <isaacs>seriously, though, i think we really need this.
20:10:28  <isaacs>like a buffer, but you manually dispose i.
20:10:29  <isaacs>*it
20:10:48  <tjfontaine>yes, I agree
20:10:50  <isaacs>we do a lot of gymnastics to keep buffers referenced in async stuff anyway
20:11:18  <isaacs>with this, we can just pass around the actual void* or whatever, and dispose it when it's finished, rather than relying on gc
20:11:40  <isaacs>i doubt it's the answer to all our problems, but certaily a handy tool.
20:11:48  <trevnorris>:)
20:11:48  <tjfontaine>it will make for some annoying use after free's
20:11:55  * isaacs&
20:11:56  <LOUDBOT>HAHAHAHHAHHAHAHHAHAHAHAHA
20:12:00  <tjfontaine>exactly
20:12:32  <trevnorris>tjfontaine: how do you mean?
20:12:46  <tjfontaine>trevnorris: if/when people DoItWrong
20:14:06  <indutny>isaacs: it could hurt extensibility
20:14:25  <indutny>i.e. spdy and others
20:14:38  <indutny>but
20:14:42  <indutny>probably they can handle it
20:14:47  <trevnorris>tjfontaine: for now it's very not public api. and has very BIG warnings about using it.
20:15:06  <tjfontaine>trevnorris: doesn't mean when I'm using it I won't make a mistake ;)
20:15:12  <trevnorris>lol, yeah.
20:15:26  <tjfontaine>but a bug in general will likely manifest itself as use-after-free
20:15:50  <trevnorris>the only possible problem is a memory leak.
20:15:59  <tjfontaine>the difference is that now we see that scenario as a "leak" because something has a reference and they shouldn't care about it anymore
20:16:22  <trevnorris>when you .dispose() it zeros the allocated memory on the object. so at least no seg fault. =P
20:16:36  * AvianFlujoined
20:16:38  <tjfontaine>that seems even worse :/
20:16:44  <trevnorris>lol
20:17:11  <tjfontaine>you're trying to reference memory that isn't there anymore and only get a subtle reaction :)
20:17:26  <tjfontaine>unless you throw on the .read*/.write*
20:17:49  <trevnorris>well. nothing should be done with the object after .dipose(). and the memory won't disappear until you do.
20:17:56  <trevnorris>so getting a seg fault is impossible either way.
20:18:08  <tjfontaine>trevnorris: from an api I agree with you, but it needs to do something when the user doesnt' follow the api
20:18:21  <trevnorris>hm.
20:18:41  <trevnorris>that would be, the object going out of scope and .dispose() hasn't been run.
20:18:50  <tjfontaine>I'm not saying it needs to be overly resilient and protect you, just that the user needs to know they've done something wrong
20:19:11  <trevnorris>agreed. i'll keep thinking about a way to do that.
20:19:25  <trevnorris>for now only way I can think is to Persist the object
20:19:26  <tjfontaine>trevnorris: consider if I have a reference, and someone else .dispose'd it
20:20:11  <trevnorris>yeah. then memory is free'd and array indexes will be "undefined"
20:20:21  <tjfontaine>right, which is pretty subtle
20:20:53  <trevnorris>i mean. I guess you could see this as js version of malloc/free
20:21:04  <trevnorris>users can screw that up (heavens knows I have)
20:21:26  <trevnorris>oh, but that will explode in a fireball
20:21:48  <tjfontaine>right, and we're js and have enough information to provide the user with a little better world
20:22:04  <trevnorris>ok, well. if I don't zero out the memory on the object then the program will fail w/ a stack trace and dump.
20:22:35  <tjfontaine>can we just have an if(this._disposed) throw()?
20:22:56  <tjfontaine>I mean, people are doing really bad things :)
20:23:00  <trevnorris>oh, yeah. I can set that when .dispose is run. no problem.
20:24:19  <tjfontaine>I'm not sure if its the right thing to do of course, just that if we're going to provide this disposable memory mechanism we need to have a way to know about use-after-free's
20:24:25  <trevnorris>hm. may have to re-think the names. now I have ._dipose and ._disposed =P
20:24:37  <trevnorris>tjfontaine: seems right. we're doing that same thing a lot of other places.
20:24:42  <tjfontaine>nod
20:24:56  <tjfontaine>this is one of those cases where i think `throw` is right
20:25:13  <tjfontaine>I guess maybe it could respect noAssert
20:25:19  <trevnorris>also exists in the v8 api. e.g. IsNearDeath
20:26:32  * kuebkquit
20:30:20  <trevnorris>tjfontaine: done. now can check ._disposed.
20:30:28  <tjfontaine>trevnorris: excellent
20:30:38  <trevnorris>good idea. thanks.
20:33:03  * st_lukequit
20:35:51  * st_lukejoined
20:37:13  * kevinswiberquit (Remote host closed the connection)
20:43:31  <trevnorris>isaacs: nothing big, but just noticed in _stream_readable: "[...]This way, it might trigger a nextTick recursion warning[...]"
20:43:56  <trevnorris>isaacs: problem is that'll be removed in v0.12. so just have to keep that in mind.
20:46:05  * indexzeroquit (Quit: indexzero)
21:02:00  * hzquit (Ping timeout: 264 seconds)
21:06:30  <trevnorris>ah man. I was so close to getting all green from jenkins.
21:06:53  <tjfontaine>haha
21:07:25  * c4miloquit (Remote host closed the connection)
21:07:50  * c4milojoined
21:08:01  * hzjoined
21:10:46  * hzquit (Client Quit)
21:11:22  <pquerna>mmmm haystack.
21:11:32  <pquerna>haywire.
21:13:00  * c4miloquit (Ping timeout: 272 seconds)
21:13:09  <st_luke>can we get ##leveldb added to http://logs.nodejs.org/channels? it's the node.js specific leveldb channel
21:16:57  * benoitcquit (Read error: No route to host)
21:20:43  * hzjoined
21:24:06  <tjfontaine>hmm nodejs-jenkins why aren't you complaining about pull requests
21:24:28  <piscisaureus_>st_luke: done
21:24:42  <st_luke>piscisaureus_: thanks
21:26:27  * rendarquit
21:29:13  <trevnorris>mother effing. 2 months working on this thing and I'm still finding stupid issues like number of tabs...
21:30:48  * bnoordhuisjoined
21:31:51  * perezdjoined
21:32:07  <isaacs>trevnorris: well, the warning will disappear
21:32:25  <isaacs>trevnorris: but the warning will disappear because nextTick will just keep spinning, which is actually fine in this case.
21:32:55  <trevnorris>isaacs: oh. well cool. so it's not infinitely recursive. it just hits the warning. alright.
21:33:02  <isaacs>righ
21:33:28  <isaacs>also, in some cases, triggering a warning in Writable can have *terrible* effects
21:33:36  * mcavagejoined
21:33:38  <isaacs>since process.stderr is a Writable
21:33:53  <trevnorris>oh. freak.
21:38:05  <isaacs>it'd be nice for maybe console.error to not go through the same process.stderr Writable, but meh.
21:41:17  * mcavagequit (Remote host closed the connection)
21:56:27  * hzquit
21:56:36  * c4milojoined
21:57:16  * hzjoined
21:58:31  * stolsmajoined
22:00:22  * TooTallNatequit (Quit: Computer has gone to sleep.)
22:00:27  * benoitcjoined
22:01:32  * pachetjoined
22:09:50  * st_lukequit (Remote host closed the connection)
22:12:32  * stagasquit (Read error: Connection reset by peer)
22:20:14  <trevnorris>bnoordhuis: while you're here. i've implemented a persistentless data store that required the user to manually free memory when they're done.
22:20:25  <trevnorris>bnoordhuis: right now it's only for internal use, but it's also very fast.
22:20:59  <trevnorris>bnoordhuis: problem is you can't assign a class_id to a non-persistent, so there isn't a way to view the memory in a heap dump.
22:23:46  <bnoordhuis>trevnorris: that's a little sad but not really a showstopper
22:23:58  <bnoordhuis>as long as the memory is relatively shortlived anyway
22:26:04  <trevnorris>bnoordhuis: cool. didn't know if you'd have a problem with that. :)
22:26:39  <isaacs>bnoordhuis: i got him to add a .length and .isThinBuffer fields.
22:26:48  <isaacs>bnoordhuis: so at least you'll be able to view it in ::jsprint
22:26:54  <isaacs>and tell wtf it is
22:27:06  * TooTallNatejoined
22:27:34  <isaacs>bnoordhuis: mind telling me if i'm doing something stupid?
22:28:06  <isaacs>bnoordhuis: i've got this StringBytes thing working for decoding a Handle<Value> to a char*+size_t pair
22:28:21  <trevnorris>I just need to write a doc on the wiki or something why we won't be using Uint8Array...
22:28:42  <isaacs>bnoordhuis: but it turns out that our code that goes the other way is ALSO kinda crap. so i'm thinking of adding StringBytes::Encode as well as StringBytes::Decode
22:29:10  <isaacs>and then having Buffer basically just consume all its encoding/decoding stuff from the StringBytes functions
22:29:21  <isaacs>bnoordhuis: too much stuff in one place? or sensible?
22:29:46  <bnoordhuis>it sounds sensible. i guess i'd need to see the code
22:29:58  <trevnorris>isaacs: since users shouldn't be touching the stream buffers array, couldn't we just track the char* in cc, then use what you're doing now to turn a chunk into a buffer before it's returned?
22:30:31  <isaacs>trevnorris: maybe.
22:31:08  <isaacs>trevnorris: oh, btw, if you set decodeStrings:false in the options for writable, or do setEncoding for readable, then there'll be strings in that array, not buffers.
22:32:14  * st_lukejoined
22:32:36  <trevnorris>isaacs: ah, thanks.
22:41:45  * dominictarrquit (Quit: dominictarr)
22:47:21  * pachetquit (Quit: leaving)
22:49:11  * stolsmaquit (Ping timeout: 252 seconds)
23:07:28  * rjequit (Ping timeout: 256 seconds)
23:09:56  * rjejoined
23:10:39  <MI6>joyent/node: Sam Roberts v0.10 * 41cbdc5 : doc: document return values of EventEmitter methods - http://git.io/GrmFUw
23:12:14  * c4miloquit (Remote host closed the connection)
23:12:41  * c4milojoined
23:14:37  * st_lukequit (Remote host closed the connection)
23:15:55  <MI6>joyent/node: Sam Roberts master * f8d8122 : event: make setMaxListeners() return this (+6 more commits) - http://git.io/0hCNQg
23:17:36  * c4miloquit (Ping timeout: 276 seconds)
23:18:19  <isaacs>bnoordhuis: thanks
23:19:35  * mikealquit (Quit: Leaving.)
23:29:01  * hzquit
23:29:45  <bnoordhuis>isaacs: for what?
23:29:54  <isaacs>bnoordhuis: the v0.10 merge
23:30:02  <bnoordhuis>oh, no problem
23:30:04  <isaacs>bnoordhuis: though i guess it's pretty easy right now, not much there.
23:30:21  <bnoordhuis>today's was easy, yes. i did the difficult merge a couple of days ago :)
23:31:54  <bnoordhuis>trevnorris: i'd give up if i were you
23:32:19  * c4milojoined
23:32:22  <trevnorris>bnoordhuis: heh, yeah.
23:33:07  <bnoordhuis>he probably means well, just a little clueless
23:33:09  <trevnorris>isaacs: which crypto branch?
23:33:50  <isaacs>trevnorris: crypto-fix-perf
23:34:04  <isaacs>trevnorris: on my fork
23:34:09  <trevnorris>:)
23:34:13  <isaacs>trevnorris: you still going with AAA?
23:34:21  <isaacs>omg, yes.
23:34:22  <isaacs>ok
23:34:27  <isaacs>I <3 our users!
23:34:32  <isaacs>and that's all i'll say about that.
23:34:38  <trevnorris>isaacs: gave up now.
23:34:39  <isaacs>:)
23:34:44  <trevnorris>want to try the rebase before I end today.
23:34:48  <isaacs>seems like a nice guy.
23:34:59  <isaacs>i've chatted with him before, he's been around node forever.
23:35:17  <trevnorris>my wife told me I need to work on my people skills. figured he be a good victim.
23:36:03  <bnoordhuis>my wife says the same thing. it's just something they do
23:36:12  <trevnorris>lol
23:36:48  * perezdquit (Quit: perezd)
23:37:38  <trevnorris>isaacs: bugger. just rebased your branch on master. has conflicts.
23:39:35  <trevnorris>isaacs: also, do your changes build?
23:40:25  <isaacs>trevnorris: yeah
23:40:32  <trevnorris>oop. that was my bad.
23:40:33  <isaacs>trevnorris: but maybe the latest isn't pushed to that branch
23:40:42  <isaacs>trevnorris: it's been a messy wip kind of thing
23:40:54  <trevnorris>something like that usually is. :)
23:41:23  <tjfontaine>`/bin/rm: /bin/rm: cannot execute binary file` sigh
23:46:29  <isaacs>tjfontaine: i usually use the rimraf module to delete stuf on windows
23:46:33  <isaacs>tjfontaine: rm is not reliable.
23:46:42  <isaacs>tjfontaine: especially if you have a long filename somewhere.
23:46:45  <tjfontaine>isaacs: that was from the build system
23:47:10  <tjfontaine>http://jenkins.nodejs.org/job/node-pullrequest/291/DESTCPU=x64,label=osx/console
23:48:10  <isaacs>oh, jeez
23:48:25  <tjfontaine>keith thinks there's EMI in the server room :P
23:49:06  <tjfontaine>I'm content in remembering that poor laptop wasn't doing so well before I made it our bitch
23:49:49  <trevnorris>isaacs: ok. i'm going to wait until you've rebased on master.
23:51:16  <isaacs>k
23:51:24  <isaacs>trevnorris: it'll be more like "merged into master"
23:51:27  <isaacs>trevnorris: but yeah
23:51:30  <trevnorris>isaacs: erm. yeah. :)
23:51:43  <isaacs>trevnorris: and basically, that'll just be a matter of removing the chars_written stuff
23:53:35  <trevnorris>coolio
23:54:09  <trevnorris>isaacs: i did that in ccda6bb, in case that helps.
23:54:53  <isaacs>trevnorris: kelw
23:55:23  <isaacs>trevnorris: i can probably just branch off v0.10, cherry-pick that commit, then apply my stuff, and have an easier time of it
23:55:35  <isaacs>trevnorris: more likely, i'll just do the merge, and hand-fix.
23:55:48  <isaacs>it's not that hard when you grok the code (ie, because you jsut wrote it)
23:55:57  <trevnorris>heh, yeah.
23:58:35  <MI6>nodejs-v0.10: #171 UNSTABLE windows-x64 (8/582) smartos-x64 (3/582) windows-ia32 (8/582) http://jenkins.nodejs.org/job/nodejs-v0.10/171/