00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:24  <trevnorris>the big issue is finding out when the memory can be reused. calling the MakeWeakCallback for every allocation makes it run 27x's slower, and use 5x's the memory.
00:01:22  <tjfontaine>oh i thought that part was already solved
00:01:23  <tjfontaine>heh
00:03:16  <cjd>what does make weak do? instruct the GC to collect the trash?
00:03:34  <tjfontaine>weak means v8 calls your cb when it's doing gc
00:03:42  <cjd>ahh
00:03:47  <trevnorris>MakeWeakCallback is a function callback called when the Handle is about to be garbage collected
00:03:53  <tjfontaine>basically the notification from the vm that no more references to the object are held
00:04:03  <trevnorris>tjfontaine: what i've been trying to figure out is how v8 figures out when handles can be cleaned up as quickly as it does.
00:04:20  <trevnorris>and why it's so much slower when we want to know.
00:04:26  <cjd>^^that part is bl@ck majik
00:04:28  <MI6>nodejs-v0.10: #46 FAILURE smartos-ia32 (3/563) linux-x64 (1/563) osx-ia32 (2/563) windows-x64 (5/563) windows-ia32 (5/563) http://jenkins.nodejs.org/job/nodejs-v0.10/46/
00:04:44  <tjfontaine>I hate you so much windows
00:05:08  <cjd>welcome to the universe
00:08:22  <tjfontaine>trevnorris: wouldn't it be great if v8::Handle had a ::refcount or something? :)
00:08:37  <cjd>refcounts don't work because loops
00:09:14  <tjfontaine>that's not my point, I meant for what he's trying to accomplish avoiding the makeweak mess
00:09:48  <trevnorris>tjfontaine: exactly. and the fact that Persisting the Handle requires it to be Disposed. but it still remains in memory for a time afterwards.
00:09:55  <trevnorris>those two operations also kill you.
00:10:57  <cjd>I'm still really in the dark about how this works.... V8 allocates internally but you want to allocate on it's behalf?
00:11:56  <trevnorris>cjd: v8 creates a Handle (pointer to a js object) and we allocate external memory which we attach to the Handle.
00:12:49  <trevnorris>when we're required to Persist the Handle, and pass MakeWeakCallback, in which it's required to free the external memory.
00:16:14  * dominictarrjoined
00:18:17  <trevnorris>tjfontaine: wonder if it's possible to make a kinda persistent HandleScope, instead of persisting each handle.
00:18:30  <cjd>ok so all v8 allocation goes through you
00:19:24  <cjd>thought maybe you were just allocating stuff for buffers and things which are external to the actual js
00:19:27  <tjfontaine>cjd: no, v8 is responsible for allocating its own data, but one can attach an external pointer, which then you can also specify a callback for when v8 would free it
00:19:38  <cjd>ahhh
00:19:44  * bradleymeckquit (Quit: bradleymeck)
00:20:02  <tjfontaine>trevnorris: dunno, you need to spend some quality time with a v8 dev on your issue :)
00:20:24  <tjfontaine>github, stop fucking hanging up on me
00:20:25  <trevnorris>seriously. i should walk over to google and knock on their door
00:20:26  <cjd>so you can be like "v8 gimme a Int8Array" and then ref that from the handle and pile all of your C++ crap into that array
00:21:36  <tjfontaine>it's more like v8 gimmie Object, here's its prototype, also here's an external pointer to attach to it
00:32:15  <trevnorris>tjfontaine: well there is HandleScope::NumberOFHandles. but that is for the entire context.
00:36:49  * dominictarrquit (Quit: dominictarr)
00:39:00  * trevnorrisquit (Quit: Leaving)
00:40:54  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:42:24  * dominictarrjoined
00:42:48  * dominictarrquit (Client Quit)
00:50:11  <MI6>joyent/node: isaacs v0.10 * 3dd7938 : npm: upgrade to 1.2.15 - http://git.io/uEH-XQ
00:53:30  <isaacs>bnoordhuis: it makes me delighted to see a benchmark/common.js script that i didn't write :) <3
00:53:37  * loladirojoined
00:54:23  * loladiroquit (Client Quit)
01:00:33  * piscisaureus_joined
01:04:31  * dapquit (Quit: Leaving.)
01:08:47  <MI6>nodejs-v0.10: #47 UNSTABLE smartos-ia32 (1/563) osx-x64 (1/563) osx-ia32 (4/563) windows-x64 (5/563) windows-ia32 (5/563) http://jenkins.nodejs.org/job/nodejs-v0.10/47/
01:12:41  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:15:17  <MI6>joyent/node: isaacs created branch v0.10.1-release - http://git.io/gLMpgw
01:15:38  * stagasjoined
01:16:37  * ericktjoined
01:33:13  * defunctzombie_zzchanged nick to defunctzombie
01:34:59  * stagas_joined
01:37:24  * abraxasjoined
01:38:14  * stagasquit (Ping timeout: 256 seconds)
01:38:44  * stagasjoined
01:40:25  * stagas_quit (Ping timeout: 260 seconds)
01:41:20  * kazuponjoined
01:44:49  * kazuponquit (Remote host closed the connection)
01:48:06  * stagasquit (Ping timeout: 264 seconds)
01:48:08  * stagas_joined
01:48:13  * stagas_changed nick to stagas
01:49:08  * indexzerojoined
02:08:44  * stagasquit (Ping timeout: 245 seconds)
02:09:09  * stagasjoined
02:13:39  * kazuponjoined
02:13:59  * stagasquit (Ping timeout: 255 seconds)
02:15:23  * stagas_joined
02:15:27  * stagas_changed nick to stagas
02:17:59  * stagas_joined
02:18:34  * kazuponquit (Remote host closed the connection)
02:20:17  * stagasquit (Ping timeout: 252 seconds)
02:21:26  * stagasjoined
02:23:04  * stagas__joined
02:24:26  * stagas_quit (Ping timeout: 256 seconds)
02:25:54  * stagasquit (Ping timeout: 256 seconds)
02:25:58  * stagas__changed nick to stagas
02:28:57  * stagasquit (Read error: Connection reset by peer)
02:30:09  * stagasjoined
02:31:30  * philipsquit (Ping timeout: 256 seconds)
02:34:43  * stagas_joined
02:37:18  * stagasquit (Ping timeout: 264 seconds)
02:37:24  * stagas_changed nick to stagas
02:49:50  * bradleymeckjoined
03:04:48  * dominictarrjoined
03:10:38  * nsmquit (Quit: nsm)
03:10:48  * bnoordhuisquit (Ping timeout: 240 seconds)
03:16:21  * philipsjoined
03:27:53  * mikealjoined
03:28:22  <isaacs>tjfontaine: that's weird... some of those tests i can't get to fail, but jenkins shows them failing pretty reliably, it looks like.
03:29:02  <tjfontaine>which one where
03:30:03  * benoitcquit (Excess Flood)
03:30:34  <tjfontaine>the writefloat/double is probably because you haven't ./configure --dest-cpu=ia32
03:31:08  * qmxchanged nick to qmx|away
03:32:25  * benoitcjoined
03:35:27  * mikealquit (Quit: Leaving.)
03:36:18  * kazuponjoined
03:40:34  * abraxasquit (Remote host closed the connection)
03:47:19  <cjd>https://github.com/v8/v8/blob/master/src/heap.cc#L3691 <-- might do what you're looking for re quickly collected slab
03:47:39  * hzquit
03:49:42  * stagas__joined
03:50:18  * stagasquit (Ping timeout: 276 seconds)
03:50:21  * stagas__changed nick to stagas
03:51:46  * bradleymeckquit (Quit: bradleymeck)
03:54:54  * stagasquit (Ping timeout: 256 seconds)
03:57:16  * benoitcquit (Excess Flood)
04:03:26  * benoitcjoined
04:05:55  * philipsquit (Ping timeout: 258 seconds)
04:06:05  * kazuponquit (Remote host closed the connection)
04:07:36  * philipsjoined
04:08:37  * kazuponjoined
04:17:18  * bnoordhuisjoined
04:18:49  * loladirojoined
04:19:27  * mikealjoined
04:20:38  * mikealquit (Client Quit)
04:21:29  * bnoordhuisquit (Ping timeout: 246 seconds)
04:24:25  * benoitcquit (Excess Flood)
04:31:57  * benoitcjoined
04:37:10  * dominictarrquit (Ping timeout: 260 seconds)
04:40:13  * benoitcquit (Excess Flood)
04:40:46  * dominictarrjoined
04:46:54  * ericktquit (Quit: erickt)
04:47:27  * benoitcjoined
04:52:51  * trevnorrisjoined
04:58:18  * defunctzombiechanged nick to defunctzombie_zz
05:01:53  * philipsquit (Read error: Operation timed out)
05:02:31  * abraxasjoined
05:02:46  * AvianFlujoined
05:03:15  * mikealjoined
05:03:15  <trevnorris>well i figured out what's kicking the crap out of WriteAscii.
05:03:26  <trevnorris>one freakin command is making 2x's slower.
05:07:49  <trevnorris>wonder if they'd accept a patch
05:12:09  <cjd>what was it?
05:12:38  <cjd>oh btw
05:12:39  <cjd>23:47 < cjd> https://github.com/v8/v8/blob/master/src/heap.cc#L3691 <-- might do what you're looking for re quickly collected slab
05:12:51  <cjd>maybe I'm off base here but this seems like what you're looking for
05:13:01  <cjd>how do you test the patch?
05:13:24  * kevireillyjoined
05:15:35  <trevnorris>cjd: in api.cc WriteAscii runs "str->HasOnlyAsciiChars()".
05:15:46  <trevnorris>when I commented it out it runs 2x's faster
05:15:58  <cjd>ahh yeap
05:16:24  <cjd>so how do you check?
05:16:31  <cjd>on a per-char basis?
05:17:05  <trevnorris>i'd like a passable options like ONLY_HAS_ASCII, which tells v8 we know it only has ascii chars.
05:17:19  <trevnorris>when I say 2x's i meant against the net benchmark
05:17:30  <trevnorris>you can run the benchmark by "./node benchmark/net/tcp-raw-c2s.js len=65530 type=asc dur=5"
05:17:39  <cjd>how does HasOnlyAsciiChars check?
05:17:47  <trevnorris>i'm looking now
05:18:16  * cjdbets examine each char
05:21:57  <trevnorris>wow. that's convoluted. need to take a few notes on this
05:22:16  <cjd>big switch statement at the beginning and end?
05:24:38  * AvianFluquit (Remote host closed the connection)
05:24:47  <cjd>where is it defined?
05:24:52  <cjd>I can't find it searching v8
05:28:12  <trevnorris>cjd: here's the breakdown: https://gist.github.com/trevnorris/5210873
05:30:39  <cjd>hrm
05:30:42  <cjd>map() ?
05:33:17  <trevnorris>yeah. figuring that out right now
05:35:44  <cjd>not sure if reinterpret_cast imparts overhead
05:39:03  <cjd>it looks to me like something that should be compiling down to nothing isn't
05:44:25  * defunctzombie_zzchanged nick to defunctzombie
05:45:22  * philipsjoined
05:45:55  * dominictarrquit (Quit: dominictarr)
06:03:22  <cjd>perhaps the creation of a MapWord on the stack adds the extra cost
06:03:50  <cjd>return MapWord(reinterpret_cast<uintptr_t>(READ_FIELD(this, kMapOffset)));
06:07:19  * wolfeidauquit (Remote host closed the connection)
06:09:40  <cjd>oic
06:09:57  <cjd>MapWord is a pointer, it points to a map which is stored elsewhere in memory
06:10:22  <cjd>somewhere else in memory -> likely page fault
06:20:30  <trevnorris>interesting.
06:24:44  <cjd>re your memory allocator, how were you benchmarking that?
06:24:55  <cjd>also where is ::Alloc called from?
06:25:04  <cjd>somewhere in js I assume
06:26:25  <trevnorris>cjd: yeah. if you build the branch you can get to it by "process.binding('arraydata').Alloc"
06:28:25  <trevnorris>i'm still working on moving Buffer allocations over to see if it offers an improvement.
06:28:48  <cjd>ahh ic
06:29:02  * defunctzombiechanged nick to defunctzombie_zz
06:29:15  <cjd>what does it return? a Int8Array?
06:29:37  <cjd>or i guess you call it with something and it becomes an array
06:29:50  <cjd>got a 1 liner for how it's called?
06:30:11  <trevnorris>either "Alloc(n)" or "Alloc(obj, n)"
06:30:58  <cjd>ok and it returns a Int8Array ?
06:31:04  <cjd>or like a quasi-string?
06:31:25  <trevnorris>it's the simplest version of an Int8Array that you can get
06:31:39  <trevnorris>no properties, no prototype. just an object pointing to external memory
06:32:15  <cjd>ok so my question is why does the memory need to be external since you're just allocating it anyway
06:32:38  <trevnorris>oh, and it's Uint8
06:33:40  <trevnorris>external as in outside of the v8 heap. external memory is not constrained by v8's max heap size (~1.5GB)
06:34:00  <cjd>ahh ok
06:34:15  <cjd>no way to up that limit?
06:34:27  <trevnorris>yeah. but there's another reason.
06:34:49  <trevnorris>the pointer is passed to libuv which handles all the low level stuff.
06:35:08  <trevnorris>if it was alloc'd in the v8 heap then libuv couldn't get access to it.
06:35:08  <cjd>mhm
06:35:14  <cjd>really?
06:35:46  <cjd>you can't take a big buffer from v8land and fill it with crap in libuv?
06:36:10  <cjd>that seems ideal
06:36:27  <trevnorris>Handles in v8 don't stay in a fixed position. the gc constantly is moving the data around. so everything must go through the Handle.
06:36:32  <trevnorris>and those are freakishly slow
06:36:46  <cjd>ok
06:36:51  <trevnorris>external memory stays fixed, much easier to deal with.
06:37:04  <cjd>buuut it doesn't free quickly
06:37:28  <trevnorris>hm? you mean the whole MakeWeakCallback thing?
06:37:46  <cjd>well.. the free operation can never beat GC
06:38:34  <cjd>think about it this way
06:38:49  <cjd>when there's a page load of something which hits the server
06:38:55  <cjd>it allocates a crapton of memory
06:39:19  <cjd>when it's done sending off the page, it looks for anything which was persisted
06:39:29  <cjd>it might even do it through the handle facility
06:39:43  <cjd>so when you do like global.key = string;
06:39:50  <cjd>string becomes tenured
06:40:05  <cjd>then it goes through and grabs out the tenured stuff and cans the rest
06:40:09  <cjd>no callbacks, no worried
06:40:17  <trevnorris>v8 doesn't have a way to receive data from an external resource (e.g. network) except from external memory allocations.
06:40:48  <cjd>that doesn't sound right
06:40:56  <trevnorris>it's how v8 communicates
06:41:00  <trevnorris>even d8 uses it
06:41:13  * cjdwould break the rules on this one
06:41:57  <cjd>there are 2 approaches
06:42:07  <trevnorris>v8 has no api that allows you to allocate raw memory from it's own heap using a Handle.
06:42:43  <cjd>#1 is you take a uint8array and find the backing buffer by tracing the handle and then fill it with crap
06:43:21  <cjd>#2 is you call internal functions to allocate a new uint8array and then fill it and return it
06:43:32  <cjd>I'd go with #1 since it's less invasive
06:43:36  <trevnorris>v8 doesn't natively handle Uint8Array's.
06:43:47  <trevnorris>Chrome, d8 and node have all needed to implement their own
06:43:51  <cjd>ahh
06:44:00  <trevnorris>using SetIndexedPropertiesToExternalArrayData against an external allocation
06:44:16  <cjd>then take a string :)
06:44:23  <trevnorris>strings are immutable
06:44:32  <cjd>not in C++ :)
06:44:56  <trevnorris>hm? you mean like "char* str = new char[100]" ?
06:45:28  <cjd>mmm
06:45:31  <cjd>lemme think
06:45:35  <cjd>maybe array is easier
06:46:04  <trevnorris>oh no. Array is actually just an Object with a wrapper
06:46:21  <trevnorris>and in c++ land, all values will go in as doubles
06:46:24  <cjd>ahh so no guaranteed storage space
06:46:38  <trevnorris>(in js crankshaft can detect Smi values and optimzie for those)
06:46:42  <trevnorris>yeah.
06:46:51  <cjd>var data = Array(1024); <-- doesn't preallocate a bunch of space?
06:46:55  <trevnorris>no
06:47:00  <cjd>bastards :P
06:47:12  <trevnorris>because it doesn't know what each of those elements are going to be
06:47:21  <trevnorris>if the values are Smi then it will point to them directly
06:47:36  <cjd>mhm
06:47:40  <trevnorris>otherwise it will allocate memory elsewhere on the heap and add a pointer
06:47:49  <trevnorris>but that's only if it's done through js
06:47:50  <cjd>hah
06:47:59  <trevnorris>in cc you don't have that luxury
06:48:27  <trevnorris>getting values from an Array in c++ is a very very painful thing
06:48:39  <cjd>planB is to #import this bastard https://github.com/v8/v8/blob/master/src/heap.cc#L3691
06:48:46  <cjd>*#include
06:48:55  <cjd>C++, Java, no difference :P
06:49:21  <trevnorris>another benefit of external allocations is that you can set the allocation type (e.g. kExternalUnsignedByteArray)
06:49:28  <trevnorris>then writing to it like an array is hella fast
06:50:19  <trevnorris>and can't import that. it's part of the "v8::internal" namespace which can be changed at any time
06:51:10  <cjd>fast / clean / safe pick 2
06:51:19  <trevnorris>lol
06:51:53  <cjd>could offer them a patch to allocate things using their allocator if they want it
06:52:19  <cjd>if they don't then maintain a patchset if the node guys are willing
06:52:28  <cjd>no pull, no patchset, then live with slow
06:58:37  <trevnorris>ircretary: tell isaacs i've opened an issue about WriteAscii being so slow. either option would double the current speed of net type=asc benchs (http://code.google.com/p/v8/issues/detail?id=2588)
06:58:37  <ircretary>trevnorris: I'll be sure to tell isaacs
07:06:25  * `3rdEdenjoined
07:06:35  * `3rdEdenquit (Remote host closed the connection)
07:14:03  <trevnorris>there. just wrote up a quick patch that helps us gain the ascii regression back. hopefully they take it
07:17:34  * `3rdEdenjoined
07:28:31  * rendarjoined
07:32:21  * benoitcquit (Excess Flood)
07:36:27  * benoitcjoined
07:37:21  * benoitcquit (Excess Flood)
07:38:28  * indexzeroquit (Quit: indexzero)
07:42:27  * benoitcjoined
07:53:36  * csaohjoined
07:53:43  * trevnorrisquit (Quit: Leaving)
07:57:35  * dominictarrjoined
08:04:25  * csaohquit (Quit: csaoh)
08:04:37  * benoitcquit (Excess Flood)
08:08:27  * benoitcjoined
08:16:52  * loladiroquit (Quit: loladiro)
08:31:45  * benoitcquit (Excess Flood)
08:35:27  * benoitcjoined
08:41:56  * wolfeidaujoined
08:49:17  * csaohjoined
09:03:06  * dominictarrquit (Ping timeout: 264 seconds)
09:13:56  * dominictarrjoined
09:29:04  * benoitcquit (Excess Flood)
09:31:28  * benoitcjoined
09:38:46  * Kakerajoined
09:56:08  * benoitcquit (Excess Flood)
09:57:58  * stagasjoined
10:00:59  * benoitcjoined
10:01:02  * bnoordhuisjoined
10:02:49  * stagasquit (Ping timeout: 256 seconds)
10:10:27  * stagasjoined
10:15:23  * Ralt_joined
10:23:06  * kazuponquit (Ping timeout: 258 seconds)
10:23:17  * benoitcquit (Excess Flood)
10:29:37  * stagasquit (Ping timeout: 258 seconds)
10:31:18  * stagasjoined
10:32:30  * benoitcjoined
10:35:57  * stagas_joined
10:36:42  * stagasquit (Ping timeout: 264 seconds)
10:36:55  * stagas_changed nick to stagas
10:50:24  * benoitcquit (Excess Flood)
10:55:00  * stagasquit (Ping timeout: 256 seconds)
10:55:55  * stagasjoined
10:58:30  * benoitcjoined
11:08:37  * piscisaureus_joined
11:10:29  * abraxasquit (Remote host closed the connection)
11:18:23  <rendar>does libuv keeps track of all the pending requests? e.g. inserting them in a container?
11:18:43  * benoitcquit (Excess Flood)
11:23:15  * dominictarrquit (Quit: dominictarr)
11:25:00  * benoitcjoined
11:25:50  * stagas_joined
11:26:44  * stagasquit (Ping timeout: 256 seconds)
11:26:45  * stagas_changed nick to stagas
11:29:15  <saghul>rendar yes, it keeps a queue of them
11:30:39  * benoitcquit (Excess Flood)
11:32:37  * stagas_joined
11:35:03  * stagasquit (Ping timeout: 276 seconds)
11:35:17  * stagas_changed nick to stagas
11:35:55  * sgallaghjoined
11:38:41  * stagas_joined
11:40:01  * benoitcjoined
11:40:52  * stagasquit (Ping timeout: 260 seconds)
11:43:41  * stagas_quit (Ping timeout: 255 seconds)
11:44:11  * stagasjoined
11:44:20  <rendar>saghul: but why? is that necessary to avoid memory leaks? and, wouldn't it add contention between threads, because every completion request must be interlocked added to the container - right?
11:45:30  <saghul>rendar not sure what you mean. Libuv uses a single thread. When you call write, it may not be completed immediately, so the write req is added to a queue and processed when the fd is readable
11:47:44  * csaohquit (Quit: csaoh)
11:49:32  <rendar>saghul: libuv uses a threadpool to complete i/o requests
11:49:51  <saghul>rendar no, only for the fs operations
11:50:03  * stagas_joined
11:52:45  * stagasquit (Ping timeout: 256 seconds)
11:52:58  * stagas_changed nick to stagas
11:57:48  * benoitcquit (Excess Flood)
12:02:00  * benoitcjoined
12:04:23  * csaohjoined
12:18:52  * `3rdEdenquit (Ping timeout: 258 seconds)
12:22:38  * benoitcquit (Excess Flood)
12:23:41  * `3rdEdenjoined
12:32:30  * benoitcjoined
12:33:21  * qmx|awaychanged nick to qmx
12:40:12  * AvianFlujoined
12:58:46  <indutny>hey brucem
12:58:48  <indutny>oops
12:58:49  <indutny>hey bnoordhuis
12:59:31  <brucem>hi indutny
12:59:37  <brucem>I'm not bad to talk to.
12:59:52  <brucem>I'm just interesting in different ways than bnoordhuis
13:05:22  <indutny>I believe you
13:05:27  <indutny>but I need Ben
13:13:01  * stagas_joined
13:14:47  * stagasquit (Ping timeout: 252 seconds)
13:14:56  * stagas_changed nick to stagas
13:31:29  * AvianFluquit (Read error: Connection reset by peer)
13:32:01  * AvianFlujoined
13:33:29  <bnoordhuis>indutny: i hear that a lot
13:35:17  * AvianFluquit (Read error: Connection reset by peer)
13:35:44  * AvianFlujoined
13:44:30  * bradleymeckjoined
13:44:42  * c4milojoined
13:48:58  * stagas_joined
13:50:37  * stagasquit (Ping timeout: 256 seconds)
13:50:38  * stagas_changed nick to stagas
13:53:48  * bradleymeckquit (Quit: bradleymeck)
13:57:07  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 9b61939 : unix: make timers handle large timeouts This commit fixes two closely re - http://git.io/MoGLVQ
13:57:36  <bnoordhuis>^ not one but two integer overflow bugs. oh, the shame!
13:59:35  <MI6>joyent/node: Ben Noordhuis v0.10 * e47a3e3 : deps: upgrade libuv to 9b61939 - http://git.io/CHuJRQ
13:59:55  * indexzerojoined
14:12:29  <MI6>nodejs-v0.10: #48 FAILURE smartos-ia32 (1/563) osx-ia32 (2/563) windows-x64 (5/563) windows-ia32 (5/563) http://jenkins.nodejs.org/job/nodejs-v0.10/48/
14:22:51  * mikealquit (Quit: Leaving.)
14:40:22  * bradleymeckjoined
14:53:10  * sgallaghquit (Remote host closed the connection)
14:53:35  * sgallaghjoined
14:53:42  <indutny>bnoordhuis: yt?
15:03:11  * mikealjoined
15:03:47  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:04:13  * mikealquit (Client Quit)
15:13:07  <bnoordhuis>indutny: i'm in a call
15:14:32  * stagasquit (Ping timeout: 256 seconds)
15:15:28  * defunctzombie_zzchanged nick to defunctzombie
15:20:06  * kazuponjoined
15:26:12  * kevireillyquit (Read error: Connection reset by peer)
15:26:43  * kevireillyjoined
15:41:27  * hzjoined
15:45:03  * nsmjoined
15:53:45  * dapjoined
16:03:21  <isaacs>bnoordhuis: is this worth pulling into 0.10.1, or can it wait for next week?
16:03:34  <isaacs>bnoordhuis: (binaries all jsut finished, so it'd be about another few hours ofmy time, that's all)
16:04:33  * `3rdEdenchanged nick to `3E|GONE
16:04:50  <tjfontaine>hmm dear osx libuv-0.10 why did you fail
16:10:34  <isaacs>alright, pulling the trigger on it. overflow timers can wait until next one
16:10:50  <MI6>joyent/node: isaacs created tag v0.10.1 - http://git.io/elvgFw
16:12:50  * trevnorrisjoined
16:14:00  <trevnorris>what are your guys thoughts on http://code.google.com/p/v8/issues/detail?id=2588
16:15:03  <MI6>joyent/node: isaacs v0.10 * 92cc187 : blog: Post for v0.10.1 (+3 more commits) - http://git.io/6A3xvA
16:15:52  <cjd>ahh WriteOneByte is analogus to WriteAscii
16:15:53  <cjd>cool
16:15:57  <cjd>btw good morning
16:19:48  <tjfontaine>isaacs: do you want me to use the cla list, or the authors file to determine if a user has previously signed the cla?
16:20:26  <trevnorris>isaacs: ping
16:21:25  * piscisaureus_joined
16:23:17  <tjfontaine>trevnorris: hey, I jus realized there's a small layout issue with your nightlies html :)
16:23:20  <indutny>hoya
16:23:29  <trevnorris>tjfontaine: really? sorry
16:23:32  <trevnorris>what's it?
16:23:32  <indutny>isaacs: have you pulled lazy cryptostreams?
16:23:40  <indutny>ah
16:23:40  <indutny>I see
16:23:54  <tjfontaine>trevnorris: when a platform has multiple files they don't have their <li>'s
16:23:55  <tjfontaine>:)
16:23:58  <isaacs>tjfontaine: the CLA
16:24:03  <isaacs>tjfontaine: the CLA list
16:24:12  <trevnorris>tjfontaine: what's the url again?
16:24:12  <tjfontaine>isaacs: can you share that with me?
16:24:18  <tjfontaine>trevnorris: http://jenkins.nodejs.org/html/nightlies.html
16:24:28  <tjfontaine>trevnorris: see the windows builds
16:24:39  <trevnorris>isaacs: about to throw up a patch. it doubles the speed of all ascii writes
16:24:56  <tjfontaine>isaacs: thanks
16:25:21  <isaacs>trevnorris: huzzah!
16:25:36  <indutny>hurray
16:25:58  <trevnorris>tjfontaine: fixed: https://gist.github.com/trevnorris/5209053
16:26:23  * mikealjoined
16:26:45  <tjfontaine>trevnorris: thanks
16:27:10  <piscisaureus_>trevnorris: I think that the most recent v8 versions no longer use "ascii" and "two-byte" strings internally
16:27:40  <trevnorris>someone mentioned they switched from ascii to latin1
16:27:47  <trevnorris>think it was indutny
16:27:48  <MI6>nodejs-v0.10: #49 UNSTABLE smartos-ia32 (1/563) osx-ia32 (3/563) windows-x64 (4/563) windows-ia32 (5/563) http://jenkins.nodejs.org/job/nodejs-v0.10/49/
16:28:03  <indutny>no, it wasn't me
16:28:19  <trevnorris>oh, well. it was someone =P
16:28:52  <tjfontaine>they mentioned in your other issue :)
16:29:00  <trevnorris>oh. lol
16:29:00  <tjfontaine>also the same guy was in #node.js talking about it
16:29:16  <piscisaureus_>which is why HasOnlyAsciiChars is now slow. That function is very fast in older v8 versions (and much faster than Utf8Length()) which is why it was great for optimizing string writes.
16:29:30  <piscisaureus_>trevnorris: indeed they switched to latin1
16:29:34  <indutny>wtf
16:29:36  <indutny>why?
16:29:39  <bnoordhuis>and it was me who mentioned that :)
16:29:49  <piscisaureus_>which is because I just told you bnoordhuis
16:29:52  <trevnorris>oh, well. just updated api internals to use WriteOneByte and suddenly writing ascii strings is freakishly fast.
16:30:15  <bnoordhuis>piscisaureus_: haha, like i don't track v8 development :)
16:31:10  <tjfontaine>ignore the incoming aborts
16:31:13  <MI6>nodejs-v0.10: #50 ABORTED http://jenkins.nodejs.org/job/nodejs-v0.10/50/
16:31:14  <MI6>nodejs-v0.10: #51 ABORTED http://jenkins.nodejs.org/job/nodejs-v0.10/51/
16:31:32  <indutny>tjfontaine: prediction
16:31:45  <piscisaureus_>ABORTED? WHAT WTF HAPPENED
16:32:09  <indutny>WTF = WHAT WTF
16:32:17  <indutny>LOUDBOT: SHUT UP
16:32:21  <piscisaureus_>WWTF == WHAT WTF
16:32:24  <indutny>oh good
16:32:28  <tjfontaine>windows and jenkins I hate you *so* *very* *much* http://jenkins.nodejs.org/job/libuv-v0.10/label=windows/16/console
16:33:11  * benoitcquit (Excess Flood)
16:33:23  <piscisaureus_>tjfontaine: can you not have your own code to delete stuff?
16:33:32  <piscisaureus_>I mean
16:33:48  <MI6>libuv-v0.10: #16 FAILURE smartos (4/186) windows (7/187) linux (2/186) osx (2/186) http://jenkins.nodejs.org/job/libuv-v0.10/16/
16:33:58  <indutny>"For those of you who have already upgraded to 0.10, you may have encountered some pretty bad performance regressions in some crypto functions (like createHmac) which are currently being worked on by Ben."
16:34:00  <indutny>so true
16:34:05  <piscisaureus_>attrib -r -s -h /d "folder" & rd /s/q "folder"
16:34:16  <trevnorris>when's the next time v0.10 branch will be merged to master?
16:34:24  <tjfontaine>piscisaureus_: I can, but it means stopping jenkins from trying to manage git all on its own
16:34:44  <piscisaureus_>ase
16:34:46  <tjfontaine>quickly approaching the point where I'm just going to write my own
16:35:00  * mikealquit (Quit: Leaving.)
16:38:36  * bnoordhuisquit (Ping timeout: 264 seconds)
16:39:33  * benoitcjoined
16:42:44  <piscisaureus_>hmm. what
16:42:51  <piscisaureus_>'s the point of the commits list in our blog post
16:42:51  <tjfontaine>what?
16:43:05  <piscisaureus_>nvm not the right channel
16:44:00  <piscisaureus_>tjfontaine: can you patch jenkins btw? Or is that too painful?
16:45:31  <tjfontaine>piscisaureus_: the git plugin is further on a track to stop exec()'ing git and to continue to develop its use of jgit, which is predictably immature
16:46:02  <piscisaureus_>tjfontaine: basically what you want is to do the same as NPM does on windows
16:46:06  <tjfontaine>piscisaureus_: but mostly on windows the jenkins slave seems to be holdling fd's open after a build is done
16:46:10  <piscisaureus_>give it some time, and keep trying to delete files
16:46:27  <piscisaureus_>but never give up unless it's really taking waaaay too long
16:46:38  <piscisaureus_>. / too many attempts
16:46:48  * kazuponquit (Remote host closed the connection)
16:47:04  <tjfontaine>I will look and see if anyone has an alternative windows slave agent
16:48:33  * kazuponjoined
16:48:57  <cjd>for testing cjdns on windows I wrote a script which runs an http server and takes whatever you post to it, saves it as an exe file, runs it and sends you back the return code and stdout/stderr
16:49:06  <cjd>then I run windows in a kvm
16:49:10  <cjd>civilized
16:49:24  <piscisaureus_>tjfontaine: if it's open source you can hack Jenkins yourself. And I'd be more than happy to help you out because I really want a working windows buildbot
16:50:29  <tjfontaine>just frustrating to hack on java is all
16:50:47  <tjfontaine>not impossible, just depressing :)
16:53:08  <tjfontaine>it seems the plugin I'm using already tries 3 times at 3 second intervals https://github.com/jenkinsci/ws-cleanup-plugin/pull/5
16:53:48  * AvianFluquit (Remote host closed the connection)
17:02:49  * benoitcquit (Excess Flood)
17:03:15  <piscisaureus_>tjfontaine: possibly they should try to remove the +r (readonly) attribute from files
17:03:54  * perezdquit (Quit: perezd)
17:05:56  * qmxchanged nick to qmx|lunch
17:08:46  <tjfontaine>piscisaureus_: will that handle the case if a process is still holding the file open?
17:08:57  <piscisaureus_>tjfontaine: no
17:09:12  <piscisaureus_>tjfontaine: however it surprises me that any process would keep *that* handle open at any time.
17:09:26  <piscisaureus_>tjfontaine: unless you have installed msysgit which is somewhat notorious for doing that :)
17:09:32  <piscisaureus_>er, *tortoisegit
17:09:46  <piscisaureus_>if you have tortoisegit on those machines, get it out
17:09:58  <tjfontaine>no tortoisegit, msysgit and where I expect it to actually come from is jgit
17:10:03  * benoitcjoined
17:10:26  <piscisaureus_>There's ways to force-close a file
17:10:30  <piscisaureus_>but it's somewhat tedious
17:10:42  <piscisaureus_>I should probably write a tool that does all this one day :)
17:10:54  <piscisaureus_>there's unlocker which is a gui app and it's really slow
17:11:07  <tjfontaine>I'm looking to move to another solution, where the slave process gets shutdown when the build queue is idle
17:11:10  <piscisaureus_>otherwise it's close to being <s>right</s> effective
17:11:17  <piscisaureus_>tjfontaine: ah, that might help too
17:11:17  * perezdjoined
17:11:30  <trevnorris>isaacs: pr 5104. ascii writes are now 2x's faster than 3.14.
17:11:33  <tjfontaine>it involves me letting jenkins start the slave agent with dcom *sigh*
17:11:39  * benoitcquit (Excess Flood)
17:11:42  <piscisaureus_>tjfontaine: another trick would be to rename the dir before trying to rename it
17:11:53  <piscisaureus_>and just pretend it's all fine if not all files can be deleted
17:12:13  <trevnorris>well 2x's could be charitable.
17:12:40  <tjfontaine>hmm mv'ing it might also be doable
17:14:27  * c4miloquit (Remote host closed the connection)
17:15:03  * benoitcjoined
17:15:48  <MI6>joyent/node: Trevor Norris master * f150d56 : src: write ascii strings using WriteOneByte WriteAscii will be deprecate - http://git.io/hPBC8w
17:15:55  * perezd_joined
17:16:40  * perezdquit (Ping timeout: 252 seconds)
17:16:40  * perezd_changed nick to perezd
17:19:40  <piscisaureus_>trevnorris: you do realize that this an API change right?
17:19:55  <piscisaureus_>trevnorris: because the filtering for ascii strings will be different
17:20:25  <piscisaureus_>trevnorris: ascii now effectively becamse the same as binary encoding
17:20:25  <trevnorris>piscisaureus_: filtering by whom?
17:20:42  <piscisaureus_>trevnorris: v8 used to replace \0 by something else
17:20:49  <piscisaureus_>I don't think WriteOneByte does
17:21:11  <piscisaureus_>trevnorris: IMO this is actually better but it might be nice to document the change somewhere. Atleast be very clear about it in the commit log.
17:22:15  <trevnorris>piscisaureus_: sorry about that. didn't realize those intricacies
17:23:13  <trevnorris>hm.
17:23:21  <trevnorris>i'd assumed that they all follow the same options.
17:23:30  <trevnorris>since they're all under the same header area in v8.h
17:26:07  <trevnorris>looking at the code, it'll automatically end the write with '\0' unless NO_NULL_TERMINATION is passed.
17:26:39  <piscisaureus_>trevnorris: no - that didn't change
17:26:53  <piscisaureus_>trevnorris: it's about this: `var a = "foo\0bar"`
17:27:23  <piscisaureus_>trevnorris: old situation:
17:27:25  <piscisaureus_>> Buffer("foo\0bar", "ascii")
17:27:25  <piscisaureus_><Buffer 66 6f 6f 20 62 61 72>
17:27:28  <piscisaureus_>new situation:
17:27:31  <piscisaureus_>> Buffer("foo\0bar", "ascii")
17:27:31  <piscisaureus_><Buffer 66 6f 6f 00 62 61 72>
17:27:40  <isaacs>yeah, this is better.
17:27:54  <isaacs>but, the docs say specifically that \0 is replaced with " " so we need to chagne the doc
17:28:06  <piscisaureus_>yes
17:28:12  <isaacs>and should probably start a "differences from 0.10 to 0.12" *now* instead of waiting until after release this time :)
17:28:13  <piscisaureus_>that's all
17:28:17  <trevnorris>piscisaureus_: um. that happened before using WriteOneByte
17:28:28  <piscisaureus_>trevnorris: no
17:28:36  <trevnorris>WriteAscii uses WriteToFlat if only ascii characters were found.
17:28:51  <piscisaureus_>trevnorris: just try it! i'm right :-)
17:28:52  <trevnorris>oh...
17:28:53  <trevnorris>nm
17:29:05  <trevnorris>did try it, but forgot to rebuild after switching branches. =P
17:29:16  <piscisaureus_>run the code I showed you `Buffer("foo\0bar", "ascii")` on stock 0.10.0 :)
17:29:22  <piscisaureus_>ok I have to run
17:29:23  <piscisaureus_>bbl
17:29:58  <trevnorris>isaacs: if documented, where should it go?
17:30:20  <piscisaureus_>buffer docs
17:30:23  <trevnorris>ok
17:30:35  <piscisaureus_>well the buffer docs have to be updated
17:30:45  <piscisaureus_>trevnorris: the *change* goes into the wiki somewhere
17:31:05  * AvianFlujoined
17:35:04  * piscisaureus_quit (Ping timeout: 256 seconds)
17:36:26  <trevnorris>isaacs: i'm not sure devs aren't going to expect that. Buffer('foo\0barr', 'utf8') -> <Buffer 66 6f 6f 00 62 61 72> in v0.10
17:36:51  <trevnorris>i mean, it seems strange ascii did something different.
17:38:57  <MI6>nodejs-master: #106 UNSTABLE windows-x64 (4/563) windows-ia32 (4/563) osx-ia32 (3/563) http://jenkins.nodejs.org/job/nodejs-master/106/
17:41:12  <indutny>review anyone https://github.com/joyent/node/pull/5105 ?
17:41:15  <indutny>isaacs: ^
17:44:26  * c4milojoined
17:44:38  * bnoordhuisjoined
17:44:52  <indutny>bnoordhuis: oh, here you are
17:44:57  <indutny>https://github.com/joyent/node/pull/5105
17:45:38  <isaacs>indutny: looking
17:46:21  * c4miloquit (Remote host closed the connection)
17:46:22  <isaacs>indutny: why don't we just treat it as 0?
17:46:26  <isaacs>indutny: same as if you pass in Infinity?
17:46:52  <isaacs>oh, i guess... the special handling of 0 is only for sockets, not general timers
17:47:10  <isaacs>indutny: sure, rubber-stamp lgtm. if tests all pass, land at will.
17:47:50  <isaacs>trevnorris: yes, indeed. there's a caveat in the Buffer docs, I bleieve. you can just remove it.
17:49:03  * bnoordhuisquit (Ping timeout: 260 seconds)
17:49:12  * c4milojoined
17:51:46  * bnoordhuisjoined
17:52:11  * c4miloquit (Remote host closed the connection)
17:52:13  <bnoordhuis>indutny: https://github.com/joyent/node/pull/5105 <- does that timer thing still happen?
17:52:33  <trevnorris>isaacs: pr 5106
17:52:39  <MI6>joyent/node: isaacs master * 2f88272 : Merge remote-tracking branch 'ry/v0.10' into master Conflicts: src/node (+31 more commits) - http://git.io/m6MECw
17:53:18  * c4milojoined
17:54:30  <isaacs>trevnorris: thanks :)
17:54:35  <MI6>joyent/node: Trevor Norris master * f7ebb4d : doc: update that ascii write doesn't convert null Since WriteBuffer has - http://git.io/wCvO7g
18:00:29  <txdv>we need dualstack in the stable libuv version
18:01:33  <tjfontaine>that seems unlikely
18:01:50  <txdv>really
18:02:12  <tjfontaine>how much of a change is it?
18:02:25  * `3E|GONEquit (Quit: brbrb)
18:02:44  <txdv>one argument change in a function and 2 additional functions is the minimal version
18:02:44  <tjfontaine>if it's unlikely to go into node-v0.10 I would imagine the same is true for libuv-v0.10
18:03:05  <bnoordhuis>txdv: no api/abi changes in stable versions
18:03:32  <txdv>this shit is around for 3 months
18:03:44  <txdv>I have asked your for your opinion and all you could push out is a "i don't know yet"
18:04:11  * perezdquit (Quit: perezd)
18:04:27  <txdv>I have listed all 3 different api scenarios, even uncovered a bug where libuv behaves differently on the same paltform (when ipv6only is set to false on linux)
18:04:30  <bnoordhuis>and it will probably remain that way for the foreseeable future
18:04:37  <bnoordhuis>fedor's bugging me about it as well
18:04:43  * stagasjoined
18:04:57  <bnoordhuis>but you know, there's bigger fish to fry
18:05:08  <txdv>YOU WILL BURN IN HELL
18:05:30  <txdv>when the devil decides to use libuv on linux with ipv6only set to false
18:05:36  <bnoordhuis>i'm an atheist. i don't believe in an afterlife
18:06:04  <bnoordhuis>besides, everyone knows the devil uses freebsd
18:06:14  <txdv>that feature is just broken in its current state
18:06:24  <txdv>either remove it entirely or make it not broken
18:06:38  <bnoordhuis>you forgot the third option
18:07:05  <txdv>PR?
18:07:28  <txdv>make it stable and not give a fuck?
18:07:37  <bnoordhuis>no. just punt on it some more :)
18:07:38  <indutny>bnoordhuis: good question
18:07:40  <indutny>let me recheck
18:07:43  <indutny>it definitely happens in 0.10
18:07:54  <bnoordhuis>not for me after i upgraded libuv
18:08:31  <indutny>erm
18:08:34  <indutny>master fails
18:08:44  <indutny>I bet you haven't merged 0.10 yet, right?
18:08:49  <bnoordhuis>nope
18:09:33  * nsmquit (Quit: nsm)
18:09:53  <bnoordhuis>txdv: re dual stack, it's something i'll reconsider after node 0.10 has stabilized a bit
18:09:55  * stagasquit (Ping timeout: 260 seconds)
18:10:04  * `3rdEdenjoined
18:10:05  <bnoordhuis>but until then there's more important stuff
18:10:38  <indutny>like what?
18:10:41  <indutny>SL
18:10:46  * perezdjoined
18:11:21  * qmx|lunchchanged nick to qmx
18:11:37  <bnoordhuis>making node bigger, better, faster, stronger
18:11:52  <txdv>this is #libuv
18:11:55  <bnoordhuis>(queue daft punk)
18:12:02  <indutny>bbfs
18:12:14  <bnoordhuis>also, cue
18:12:23  <bnoordhuis>i want to fix up openssl
18:12:28  <bnoordhuis>or rather our bindings
18:12:33  <indutny>what's up with it ?
18:12:47  <bnoordhuis>have you benchmarked it lately?
18:13:50  <bnoordhuis>there's also the cluster load balancing issue
18:14:23  <indutny>load balancing is really issue
18:14:27  <indutny>bnoordhuis: meh
18:14:33  <indutny>bnoordhuis: not that much slower
18:14:40  * perezd_joined
18:14:45  <bnoordhuis>"only" 2x? :-/
18:14:50  <indutny>at least openssl
18:14:59  <indutny>bnoordhuis: that's problem on our side
18:15:00  <indutny>isn't it?
18:15:00  * perezdquit (Ping timeout: 256 seconds)
18:15:01  * perezd_changed nick to perezd
18:15:03  <bnoordhuis>yes
18:15:17  <bnoordhuis>that's why i added the "our bindings" bit :)
18:15:17  <isaacs>bnoordhuis: are you talking about the regression in crypto.Hash etc
18:15:18  <isaacs>?
18:15:28  <bnoordhuis>yes and no
18:15:35  <bnoordhuis>that regression is part of it
18:15:46  <isaacs>the regression is solveable, it seems like
18:15:48  <bnoordhuis>but crypto/tls performance is pretty abominable
18:15:55  <bnoordhuis>in general, i mean
18:16:01  <isaacs>yes, in general.
18:16:12  <isaacs>i mean, it wasn't *great* in 0.8 and before, either.
18:16:20  <bnoordhuis>no, indeed
18:16:27  <bnoordhuis>so that's something i want to address in v0.12 :)
18:16:40  <isaacs>tls throughput is better in 0.10, becuase of indutny and streams2, but connection hadnshake etc still sucks.
18:16:51  <isaacs>bnoordhuis: i would like you to address it in 0.12 :)
18:16:52  <trevnorris>indutny: is a v8 PATCH_LEVEL just the number of commits after it is released?
18:17:09  <indutny>huhuhuh?
18:17:37  <indutny>bnoordhuis: yeah, its worse than 0.9.8e
18:17:41  <indutny>but not that much
18:17:58  <indutny>anyway, that's on my list ;)
18:18:03  <indutny>and there're is tlsnappy for experiments
18:18:51  * loladirojoined
18:19:02  <MI6>nodejs-master: #107 UNSTABLE windows-x64 (11/565) windows-ia32 (10/565) osx-ia32 (2/565) http://jenkins.nodejs.org/job/nodejs-master/107/
18:19:21  <bnoordhuis>indutny: we'll discuss it some more this or next week
18:19:29  <bnoordhuis>but for now: pizza!
18:21:27  <trevnorris>indutny: oh, nm. forgot the git mirror doesn't properly do cross-branch tracking. that's why I never saw anything other than the initial release of a version.
18:22:11  * stagasjoined
18:23:51  * bnoordhuisquit (Ping timeout: 256 seconds)
18:27:51  * jez0990_changed nick to jez0990
18:36:33  * defunctzombiechanged nick to defunctzombie_zz
18:37:05  <trevnorris>isaacs: are there historical reasons why the Buffer function would need to continue supporting slice? it's not in the api.
18:37:19  <trevnorris>i mean, can slice be moved elsewhere?
18:40:21  <MI6>nodejs-master: #108 FAILURE windows-x64 (11/565) windows-ia32 (9/565) osx-ia32 (2/565) http://jenkins.nodejs.org/job/nodejs-master/108/
18:41:08  <tjfontaine>sigh
18:42:30  <trevnorris>tjfontaine: one of these days i'm going to scrap the logs for all your reactions after a windows build fails.
18:42:51  <trevnorris> /scrap/scrape
18:43:19  <tjfontaine>you could scrap windows :P
18:43:32  * bradleymeck_joined
18:43:36  <trevnorris>lol
18:44:39  * bradleymeckquit (Ping timeout: 252 seconds)
18:44:40  * bradleymeck_changed nick to bradleymeck
18:44:56  <trevnorris>i remember when node announced it would support windows....
18:45:12  <MI6>joyent/node: Fedor Indutny v0.10 * bfd16de : timers: handle signed int32 overflow in enroll() Before this patch calli - http://git.io/RJC9uQ
18:45:32  <indutny>isaacs: starting from now
18:45:38  <indutny>I'll write all comments on github in russian
18:45:44  <indutny>just to troll people
18:45:50  <indutny>and force them to learn russian words
18:49:54  * csaohquit (Quit: csaoh)
18:57:46  <isaacs>indutny: lol
18:57:58  <indutny>ага
18:58:04  <isaacs>indutny: yeah, and all node example scripts in the docs will use not-yet-implemented ES6 features.
18:58:15  <indutny>совершенно верно
18:58:33  <isaacs>cobe pwe ho ho bepho
18:58:34  <indutny>:)
18:58:37  * loladiroquit (Quit: loladiro)
18:59:47  <rendar>does libuv keeps track of all the i/o pending requests? e.g. inserting them in a container?
19:00:50  <bradleymeck>indutny: google autotranslate has made my life interesting reading your stuff
19:00:56  <indutny>haha
19:01:06  <indutny>I can write more
19:01:34  <bradleymeck>translate fails soo hard
19:01:41  <indutny>я думаю, изучение русского языка полезно каждому
19:01:47  <isaacs>i like dutch and swedish and danish better, because you can almost read them if you know english
19:01:58  <indutny>isaacs: well, I can transliterate
19:02:27  <indutny>sovershenno verno
19:02:46  <indutny>but english and dutch are both roman-german languages
19:03:19  * loladirojoined
19:08:59  <trevnorris>if you Dispose a persistent, then why do you also Clear it?
19:10:01  <MI6>nodejs-v0.10: #52 UNSTABLE smartos-ia32 (1/564) linux-x64 (1/564) osx-ia32 (3/564) windows-x64 (10/564) windows-ia32 (10/564) http://jenkins.nodejs.org/job/nodejs-v0.10/52/
19:10:43  * kazuponquit (Remote host closed the connection)
19:12:32  <indutny>trevnorris: better yes
19:13:07  <indutny>ah no
19:13:10  <indutny>you should
19:13:17  <indutny>otherwise it'll leak
19:19:28  * mikealjoined
19:20:02  <trevnorris>indutny: is there a reason to create an empty handle? like can you assign it something later?
19:21:23  <trevnorris>eh nm.
19:21:26  <trevnorris>don't care.
19:29:30  <indutny>oh
19:29:39  <indutny>did you guys knew that v8 uses a lot of different allocation spaces
19:29:47  <indutny>7
19:29:59  <indutny>very interesting
19:30:14  <indutny>so it seems to be pretty straightforward to introduce 8th one :)
19:30:16  <indutny>for buffers
19:30:26  <indutny>lets see if I can hack something about it
19:31:14  <trevnorris>indutny: but then buffers would be constrained by how much memory v8 can allocate?
19:31:26  <indutny>lets experiment
19:31:35  <indutny>and see what it'll give us
19:31:44  <indutny>and only then deal with limits
19:32:06  <trevnorris>sounds good. mind throwing any changes up somewhere? i'd like to see where you're messing around.
19:32:18  <indutny>yeah
19:32:23  <indutny>I'm just looking now
19:32:26  <indutny>so probably later
19:33:10  <trevnorris>whatevz. i'm working on improving the current buffers. =)
19:33:23  <trevnorris>so do you mean make Buffers a native v8 type?
19:35:02  <indutny>yep
19:35:11  <indutny>and create separate GC for them
19:35:11  <trevnorris>cool.
19:35:19  <indutny>not sure yet
19:35:25  <indutny>whether its cool or not
19:35:30  <indutny>need to create something working first
19:35:47  <trevnorris>interested to see what you come up with.
19:36:03  <trevnorris>for small memory allocations that would be awesome.
19:36:16  <indutny>it should still work for big allocations too
19:36:31  * sblomjoined
19:36:44  <indutny>in theory it should be *very* fast
19:37:12  <trevnorris>yeah. it's just the small allocations that are the PITA.
19:37:43  <trevnorris>b/c of current use of buffer pools, they're the reason for a few memory leaks.
19:38:07  * loladiroquit (Quit: loladiro)
19:39:25  * mikealquit (Quit: Leaving.)
19:40:38  <indutny>yeah
19:40:47  <indutny>actually, I was thinking about it
19:40:56  <indutny>there's another way of doing things there
19:41:02  <indutny>but it requires v8 patches too
19:41:11  <trevnorris>what's the concept?
19:41:13  <indutny>basically you need to store v8::External data
19:41:20  <indutny>its a pointer
19:41:27  <indutny>and you can perform your own garbage collection on it
19:41:39  <indutny>by asking v8 to determine which v8::External are alive
19:41:50  <indutny>and cleaning everything else
19:42:15  <indutny>so its like implementing our own GC and allocator, but in node.js
19:42:17  <indutny>not in v8
19:43:04  <trevnorris>that sounds pretty much like what I've been hoping for.
19:44:08  <indutny>yeah, I know
19:44:15  <indutny>hm...
19:44:20  <indutny>may be I should try doing this in first place
19:44:41  <indutny> static void VisitExternalResources(ExternalResourceVisitor* visitor);
19:44:56  <indutny>this is already here, but works only for external strings
19:50:05  <bradleymeck>how do ppl get gyp to not detect the wrong arch on a mac
19:50:37  <indutny>not sure
19:50:39  <indutny>it just works for me
19:52:28  * loladirojoined
19:55:51  <indutny>meh, that's actually harder than I though
19:55:54  <indutny>s/though/thought/
19:56:04  <trevnorris>really?
19:56:09  <indutny>yeah
19:56:22  <indutny>external strings are put in the table right now
19:56:30  <indutny>and this table is refreshed after each GC
19:56:40  <indutny>so its almost the same thing as persistent
19:56:53  <indutny>may be a little bit simplier
19:56:59  <indutny>but not sure if its faster
19:57:18  <indutny>ok, film time
19:57:18  <indutny>ttyl
20:00:45  * sgallaghquit (Ping timeout: 276 seconds)
20:03:00  <bradleymeck>always is defaulting to arch i386...
20:06:42  * defunctzombie_zzchanged nick to defunctzombie
20:16:54  * isaacsbbiab, chai thai time
20:16:55  * isaacs&
20:17:19  <MI6>libuv-v0.10: #17 UNSTABLE windows (6/187) linux (2/186) osx (2/186) smartos (4/186) http://jenkins.nodejs.org/job/libuv-v0.10/17/
20:20:20  * dominictarrjoined
20:20:41  * kazuponjoined
20:22:36  * bnoordhuisjoined
20:30:06  * kazuponquit (Ping timeout: 264 seconds)
20:35:21  * piscisaureus_joined
20:35:37  * piscisaureus_quit (Client Quit)
20:36:39  * piscisaureus_joined
20:37:11  * benoitcquit (Excess Flood)
20:39:23  <piscisaureus_>Hello
20:39:29  <piscisaureus_>Anyone needs me for anything?
20:39:36  * bradleymeckquit (Quit: bradleymeck)
20:39:51  <tjfontaine>we need you for everything, how could you think otherwise
20:40:20  <trevnorris>i could still use a review on how i've decided to structure my code: https://github.com/joyent/node/pull/4964
20:41:35  * benoitcjoined
20:42:13  <tjfontaine>what's the difference between the Large and not?
20:42:25  <piscisaureus_>trevnorris: Your code structure seems fine. However I'm interested in how this solves any problems - you want to explain to me what your plans are?
20:42:27  <tjfontaine>just if it's inside the allocated zone?
20:43:02  <trevnorris>tjfontaine: not large gets the size from the "define", otherwise it needs to read in the length from the beginning of the memory block
20:43:06  <MI6>nodejs-master: #109 UNSTABLE linux-ia32 (1/565) windows-ia32 (9/565) osx-ia32 (2/565) windows-x64 (10/565) http://jenkins.nodejs.org/job/nodejs-master/109/
20:43:22  <trevnorris>piscisaureus_: couple reasons:
20:43:52  <trevnorris>first is to centralize how external memory is managed. Right now there are buffer pools, SlabAllocators and SlabBuffers
20:44:14  <trevnorris>since Slab* use Buffers, and buffers always use pools, there can be some double referencing, which leads to memory leaks.
20:45:20  <trevnorris>also by centralizing then it'll be easier to work on more efficient ways of handling memory. indutny has a few ideas of things we can do, and i've been exploring others.
20:45:48  * stagas_joined
20:46:27  <trevnorris>Also it will remove the need for Fast/Slow Buffers. they can be combine into a single call.
20:46:48  <piscisaureus_>trevnorris: ok, well I'm very interested :-)
20:47:01  <trevnorris>thanks =)
20:47:11  <tjfontaine>and when that's all done pretty histograms for allocations and arena's!
20:47:13  <piscisaureus_>trevnorris: this code seems well-structured and fine. If you make the situation better, I'll be happy.
20:47:26  * stagasquit (Ping timeout: 246 seconds)
20:47:27  * stagas_changed nick to stagas
20:50:03  * sblomquit (Ping timeout: 252 seconds)
20:50:22  <trevnorris>yeah. the minimum criterion are: at least a little perf improvement, and improved memory usage.
20:51:17  * qmxchanged nick to qmx|away
20:51:23  <trevnorris>also will need benchmarks, tests, documentation... don't expect it pulled unless it's provably more solid than node is now.
20:56:18  <trevnorris>right now I can externally allocate 1e7 1024 byte allocs, and mem usage doesn't go over 15MB.
20:56:45  <trevnorris>whereas Buffers will peak at ~250MB
20:57:04  <trevnorris>gc seems to handle it a lot better.
21:03:04  <piscisaureus_>Cool
21:08:47  * loladiroquit (Quit: loladiro)
21:13:33  * loladirojoined
21:14:25  * sblomjoined
21:18:50  <trevnorris>indutny: would it be possible to use ExternalAsciiStringResource on an ascii string passed to Buffer, then assign Buffer->data_ to the external data()?
21:19:28  <trevnorris>or does it still need to be accessed by the handle?
21:20:20  <trevnorris>hm. nm. data needs to be immutable.
21:21:30  * bradleymeckjoined
21:22:21  <tjfontaine>isaacs: if there's an error on the cla spreadsheet should I just fix it?
21:25:54  <tjfontaine>there's one entry with the wrong offsets, and no valid address -- and the two others without valid emails
21:25:58  * kazuponjoined
21:27:12  * loladiroquit (Quit: loladiro)
21:31:07  * benoitcquit (Excess Flood)
21:31:07  * kazuponquit (Ping timeout: 264 seconds)
21:33:34  * benoitcjoined
21:48:02  * mikealjoined
21:56:19  * wolfeidauquit (Remote host closed the connection)
22:02:49  * kuplatupsuquit (Read error: Operation timed out)
22:03:36  * kuplatupsujoined
22:08:21  * perezdquit (Quit: perezd)
22:10:01  * wolfeidaujoined
22:10:43  * rendarquit
22:10:58  * dominictarrquit (Quit: dominictarr)
22:16:00  * c4miloquit (Remote host closed the connection)
22:18:12  <isaacs>tjfontaine: yeah, if it's a clear error that you can fix, just go for it
22:18:19  <tjfontaine>ok
22:18:38  <tjfontaine>isaacs: how interesting would it be for api queries to see if a user is on the cla by email/fullname
22:18:51  <isaacs>tjfontaine: VERY INTERESTING.
22:18:59  <isaacs>tjfontaine: but i think that clahub is going to eventually do this for us
22:19:14  <tjfontaine>ok well I can provide it today for the interim
22:19:42  <isaacs>tjfontaine: the tricky thing is that we don't ask for github username, so correllating to pul l reqs is hard.
22:19:51  <isaacs>tjfontaine: especially since some people dont' have their email in the gh acct
22:19:53  <tjfontaine>yes, it sucks, it's not perfect
22:20:03  <isaacs>tjfontaine: usually, if i have to look it up, i'll just put their gh name in the last column
22:20:10  <isaacs>(the first one past the "real" data)
22:20:25  <tjfontaine>even their gh fullname may not be what they use
22:20:39  <trevnorris>or we could just require everyone to use their PGP ;-)
22:20:59  * defunctzombiechanged nick to defunctzombie_zz
22:21:08  <tjfontaine>then everyone complains because they lost their key, or passphrase, or are unaware they can resign/change expiry :P
22:21:12  <isaacs>i think clahub is basically the exact correct approach
22:21:17  <isaacs>integrated with github, etc.
22:21:55  <tjfontaine>is there a timeline on such a thing?
22:24:47  <trevnorris>ok. this buffer thing is going to be a bitch. i can do the work. but having a hard time figuring out how to break up the commits.
22:24:53  <trevnorris>isaacs: how'd you do it w/ streams2?
22:25:20  <isaacs>trevnorris: i maintained a separate branch, where i continually rebased onto the upstream master, and then at the end, merged in with --no-ff
22:26:09  <trevnorris>isaacs: managing the git part is a breeze for me. it's figuring out how much/what type of work to do for each commit.
22:26:18  <trevnorris>but as you know i'm really anal about my commit structure.
22:26:21  * loladirojoined
22:26:38  * kazuponjoined
22:26:43  <isaacs>piscisaureus_: do you own libuv.org?
22:26:53  <isaacs>piscisaureus_: point your A records at
22:26:59  <isaacs>piscisaureus_: where you have root ssh access
22:27:13  * mikealquit (Quit: Leaving.)
22:27:14  <piscisaureus_>isaacs: kewl!
22:27:35  <isaacs>tjfontaine: there is a project, i'm not sure where it's at. last i checked it out (on one of my own random node modules) it didn't quite work right.
22:27:49  <isaacs>tjfontaine: but i know it's been active, and the creator very much wants to support projects like node
22:27:50  <tjfontaine>ya I looked at it, I'm not entirely impressed at the moment
22:27:55  <piscisaureus_>isaacs: let's dig up the login details...
22:28:01  <trevnorris>isaacs: guess i meant, did you just work and commit at random. or did you have a plan for what work to do between commits?
22:28:10  <isaacs>piscisaureus_: once upon a time you gave me a ssh key. that one should work.
22:28:11  <tjfontaine>but I am distracted by making it work today
22:28:25  <piscisaureus_>haha
22:28:26  <piscisaureus_>cool
22:28:31  <isaacs>trevnorris: oh, i just commit and work and rebase and mold the clay into something slowly over time.
22:28:43  <isaacs>trevnorris: it doesn't matter what your rough drafts look like, as long as the finished product is good.
22:28:55  <trevnorris>cool.
22:29:04  <tjfontaine>commit early, commit often
22:29:14  <isaacs>tjfontaine: in the short term, if it's easy to create a little dummy api to hit our google doc, then that's fine.
22:29:20  * indexzeroquit (Quit: indexzero)
22:29:25  <isaacs>tjfontaine: just don't waste too much time on it
22:29:36  <tjfontaine>it basically writes itself
22:29:38  <isaacs>er, dont' "waste" time at all. stop if it starts becoming wasteful :)
22:29:42  <tjfontaine>it'll be deployed shortly
22:29:47  <isaacs>wonderful :)
22:29:52  <trevnorris>isaacs: for 0.12 can we remove buffer.get/set?
22:30:03  <trevnorris>not documented, and seem really useless.
22:31:16  * mikealjoined
22:31:18  * kazuponquit (Ping timeout: 264 seconds)
22:31:21  <tjfontaine>trevnorris: there may be pushback, as I think some people use it to be blind to ArrayBuffer things
22:31:46  <piscisaureus_>isaacs: SmartMachine (base 1.9.0)
22:31:46  <piscisaureus_>http://wiki.joyent.com/jpc2/SmartMachine+Base
22:31:47  <piscisaureus_>:)
22:31:52  <piscisaureus_>isaacs: now the real work starts
22:32:03  <piscisaureus_>isaacs: thanks!
22:32:26  <isaacs>piscisaureus_: meh. just pkgin install nginx, and point it at some files.
22:32:35  <isaacs>nothing too hard.
22:32:50  <isaacs>or do you mean the real work of creating docs and uploading them?
22:33:06  <piscisaureus_>isaacs: the latter.
22:33:13  <isaacs>ah, yeah
22:33:17  <isaacs>that's rough :)
22:33:20  <trevnorris>isaacs: eh, ok. but fwiw. there is no "get/set" in the ArrayBuffer spec.
22:33:38  <isaacs>trevnorris: no "get/set"? means what?
22:33:44  * c4milojoined
22:33:59  <isaacs>oh, that (scrolled back)
22:34:03  <trevnorris>oh, that was meant for tjfontaine
22:34:29  <isaacs>trevnorris: i have no strong feelings about it. I think get/set is older, before it was [n]-style
22:34:39  <trevnorris>cool
22:35:11  <isaacs>piscisaureus_: i put it in eu-ams so that you can feel like it's really fast :)
22:35:40  <piscisaureus_>isaacs: I've been bitching about smartmachines, but speed was never a problem.
22:36:23  <piscisaureus_>Esp. once you have experienced amazon (or seen the bill)
22:36:26  <trevnorris>isaacs: oh, one other thing. seems that passing a buffer to Buffer() for a slice is only used internally, and not documented. can i move it, or keep it the same?
22:36:38  <piscisaureus_>isaacs: thanks!
22:38:24  <isaacs>trevnorris: passing a buffer to Buffer makes a copy, not a slice.
22:38:32  <isaacs>trevnorris: it's treated like new Buffer([1,2,3,4])
22:38:40  * philipsquit (Changing host)
22:38:40  * philipsjoined
22:38:54  <trevnorris>isaacs: then the comments suck "// Are we slicing?"
22:39:00  <isaacs>hahah
22:39:02  <isaacs>that's entirely possible.
22:39:08  <isaacs>lemme look at the code.
22:39:19  <isaacs>empirically, b2 = Buffer(b1) creates a copy
22:40:58  <trevnorris>isaacs: but b2 = Buffer(b1, n, m) slices
22:41:07  <isaacs>trevnorris: oh, that's SUPER weird
22:41:12  <isaacs>it slices from m to n, not the other way around
22:41:31  <isaacs>trevnorris: yes, please get rid of that i don't even know what that is even
22:41:46  <isaacs>trevnorris: if it's not documented, and especially if it's also not tested, consider it fair game.
22:42:07  <isaacs>trevnorris: if necessary, we can re-implement on top of whatever else you do.
22:44:35  <piscisaureus_>trevnorris: in my tests Buffer(buffer, n, m) doesn't copy nor creates a slice
22:44:40  <piscisaureus_>trevnorris: odd
22:45:27  <indutny>what have I missed? :)
22:45:31  <indutny>great buffer discussion?
22:45:33  <trevnorris>piscisaureus_: if it's giving you a zero length then you probably have n and m reversed.
22:45:36  <indutny>do you have plan how to speed up it?
22:45:43  <piscisaureus_>trevnorris: no
22:45:47  <piscisaureus_>trevnorris: look at this:
22:46:11  <trevnorris>piscisaureus_: oh, you're right.
22:46:29  <piscisaureus_>> base = new Buffer(4)
22:46:29  <piscisaureus_><Buffer 08 f3 34 00>
22:46:29  <piscisaureus_>> base.fill(0)
22:46:29  <piscisaureus_>undefined
22:46:29  <piscisaureus_>> base
22:46:29  <piscisaureus_><Buffer 00 00 00 00>
22:46:29  <piscisaureus_>> foo = Buffer(base, 4, 0)
22:46:30  <piscisaureus_><Buffer a8 0f 3b 00>
22:46:31  <trevnorris>ok, it always copies.
22:46:39  <trevnorris>but then wtf is that code there for?!
22:46:49  <piscisaureus_>maybe something internal?
22:47:20  <trevnorris>piscisaureus_: look at SlowBuffer.prototype.slice
22:48:46  * dominictarrjoined
22:48:56  * c4miloquit (Remote host closed the connection)
22:51:16  <trevnorris>well whatever. if no one else knows what it's for, then it's out.
22:52:26  <isaacs>trevnorris++
22:54:18  * benoitcquit (Excess Flood)
22:57:54  <piscisaureus_>trevnorris: it seems pointless
22:57:59  <piscisaureus_>so +1
22:59:50  * bradleymeckquit (Quit: bradleymeck)
23:00:36  * benoitcjoined
23:04:11  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:06:56  * dominictarrquit (Quit: dominictarr)
23:07:54  * creationixquit (Ping timeout: 264 seconds)
23:08:49  * creationixjoined
23:12:41  * indexzerojoined
23:12:46  * indexzeroquit (Client Quit)
23:12:54  * benoitcquit (Excess Flood)
23:15:00  * `3rdEdenquit (Remote host closed the connection)
23:17:06  * benoitcjoined
23:17:13  * stagasquit (Ping timeout: 245 seconds)
23:27:07  * kazuponjoined
23:29:00  * dominictarrjoined
23:30:45  * sblomquit (Ping timeout: 260 seconds)
23:31:05  * Kakeraquit (Ping timeout: 255 seconds)
23:31:33  * loladiroquit (Quit: loladiro)
23:31:55  * kazuponquit (Ping timeout: 260 seconds)
23:36:33  <bnoordhuis>this cork/uncork thing doesn't seem to be working out
23:36:55  <trevnorris>eh?
23:37:01  <bnoordhuis>it's 25% faster on really big messages (>100 kb)
23:37:28  <bnoordhuis>but it decimates with smaller buffers
23:37:43  <bnoordhuis>trevnorris: i was working on an optimization for http + buffers
23:37:53  <bnoordhuis>when you send a buffer, node copies the headers + buffer into a new buffer
23:38:08  <bnoordhuis>so it can send it in one tcp packet (and with one syscall)
23:38:38  <bnoordhuis>i had this idea of patching libuv and give it new api to tell it stop writing eagerly
23:38:44  <bnoordhuis>wait, let me link you to the issue
23:38:50  <trevnorris>interesting. cool
23:38:59  <bnoordhuis>trevnorris: https://github.com/joyent/node/issues/4975#issuecomment-14927524
23:39:40  <bnoordhuis>so you cork, write a few things, then uncork and libuv batches it up in a single writev syscall
23:40:14  <bnoordhuis>but alas, it doesn't seem to be very effective
23:40:44  <trevnorris>bnoordhuis: well, not giving the Content-Length is going to make that a bitch.
23:41:47  <bnoordhuis>trevnorris: how so?
23:43:23  <trevnorris>eh, just rambling. but need a little background. haven't spent a ton of time in there.
23:43:29  <trevnorris>so is data sent immediately on .write()?
23:45:02  <bnoordhuis>trevnorris: what .write()? :) there are several
23:45:18  <bnoordhuis>if you mean res.write() the answer is maybe
23:45:34  <trevnorris>heh, sorry. mind is still deep in buffers.
23:45:38  <trevnorris>yeah. ok so that's a maybe.
23:46:09  <bnoordhuis>res.end() tries to optimize by packing the headers and the body
23:46:50  <trevnorris>guess i figured that if the user properly sets Content-Length then you could make an assumption about how much data will be going through.
23:47:44  <bnoordhuis>yes, but it also works with Transfer-Encoding: chunked
23:48:01  <bnoordhuis>provided you do res.writeHead(...); res.end(body)
23:50:49  <trevnorris>ok. so to understand the logic. res.writeHead/write/end send the data directly to node::StreamWrap. would this immediately call uv_write()?
23:52:27  <trevnorris>then using the cork/uncork it doesn't send the data until it's complete?
23:53:28  <bnoordhuis>that's the idea
23:53:37  <bnoordhuis>to avoid that buffer copy
23:53:50  <bnoordhuis>which turns out to be expensive with really big response bodies
23:56:20  * sblomjoined
23:59:53  <isaacs>bnoordhuis: so, there's still this awful heuristic around that 100kb inflection point?