00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:02  <tjfontaine>no no
00:00:09  * ircretaryjoined
00:00:12  <tjfontaine>don't give a fuck yet :)
00:00:16  <isaacs>ok
00:00:22  <tjfontaine>those are almost certainly eaddrinuse
00:00:24  * isaacsretrieves the previous given fucks
00:01:25  <MI6>libuv-master: #32 FAILURE smartos (5/183) osx (1/183) linux (2/183) http://jenkins.nodejs.org/job/libuv-master/32/
00:01:37  <tjfontaine>which seems to happen when both master and v0.8 jobs start running at the same time, despite v0.8 being in 8000 world, and master being 9000
00:01:44  <isaacs>hm.
00:01:54  <tjfontaine>or v0.8 never got the common port change
00:02:39  <bnoordhuis>i'm reasonably sure that os.cpus() has been returning bogus time values ever since it was added
00:02:45  <bnoordhuis>on os x, that is
00:03:36  <bnoordhuis>it's calling the wrong mach function and blindly casts the out arg to the expected type
00:03:43  * bnoordhuissighs
00:03:49  <tjfontaine>ok, v0.8 does not have the common port fix
00:04:01  <bnoordhuis>tjfontaine: oh, i'll back-port it
00:04:07  <tjfontaine>bnoordhuis: please and thank you
00:05:28  <bnoordhuis>apparently i already did on march 2
00:05:41  <tjfontaine>hm
00:05:51  <bnoordhuis>commit 0b70a14
00:06:12  <tjfontaine>my build slaves are revolting, in as many senses possible
00:07:21  <isaacs>yep
00:07:23  <isaacs>0.8 has it
00:07:24  <isaacs>exports.PORT = +process.env.NODE_COMMON_PORT || 12346;
00:08:44  <tjfontaine>ok then jenkins workspace tree lied, I have verified that osx workspace does have it, so that would mean it's just not passing through the child process
00:08:48  <tjfontaine>I shall investigate
00:14:48  * c4miloquit (Remote host closed the connection)
00:17:17  * mikealquit (Quit: Leaving.)
00:17:20  <MI6>joyent/node: isaacs created tag v0.8.22 - http://git.io/JtDXIQ
00:17:39  <isaacs>0.8.22 going out now
00:17:43  <isaacs>almost nothing in it.
00:19:55  <bnoordhuis>isaacs: build, windows: disable SEH (Ben Noordhuis) <- i didn't land that in v0.8, did i?
00:20:08  <isaacs>bnoordhuis: you did, yes.
00:20:44  <isaacs>* d879042 Ben Noordhuis build, windows: disable SEH (6 days ago)
00:21:13  <bnoordhuis>oh, so i did
00:21:30  * mikealjoined
00:21:47  <bnoordhuis>it's not quite the correct but at least it unbreaks the build
00:21:52  <bnoordhuis>*correct fix
00:21:54  <isaacs>k
00:22:00  <isaacs>i don't really care that much
00:22:05  <isaacs>i saw we reverted it in master.
00:22:30  <bnoordhuis>yeah, replaced it with the proper fix :)
00:22:32  <MI6>joyent/node: isaacs v0.8 * 9c58125 : blog: Post for v0.8.22 (+3 more commits) - http://git.io/pClM0A
00:29:07  <isaacs>ok, i'm gonna disconnect and run benchmarks for the blog post. probably won't be back in the next few hours.
00:29:19  <tjfontaine>heh
00:29:58  <isaacs>i'm going to cut the v0.10 branch tomorrow
00:30:45  <tjfontaine>bnoordhuis: wanna review the windows libuv tap stuff?
00:31:00  <tjfontaine>I'll just assume that's mostly a no, but I was hoping you might anyway :)
00:31:59  <bnoordhuis>well... i can't test it, don't have a windows vm on this machine
00:32:10  <tjfontaine>nod
00:32:21  <MI6>libuv-master: #33 UNSTABLE smartos (5/183) osx (1/183) linux (2/183) http://jenkins.nodejs.org/job/libuv-master/33/
00:32:28  <bnoordhuis>i'll tell bert tomorrow to review it, he's coming over to gouda
00:32:50  <tjfontaine>k, since he wouldn't let me do hacks to use fgets :)
00:33:23  <bnoordhuis>there's no fgets?
00:33:40  <bnoordhuis>or is that because we don't link to the windows equivalent of libc?
00:33:41  <tjfontaine>there is, but it wants FILE* and the test runner has a HANDLE for stdout
00:33:45  <bnoordhuis>ah
00:34:02  <tjfontaine>so while I can get to FILE* it's not pretty
00:34:59  <MI6>nodejs-v0.8: #29 FAILURE windows-ia32 (5/468) osx-x64 (1/468) smartos-ia32 (2/468) linux-ia32 (1/468) osx-ia32 (2/468) smartos-x64 (2/468) linux-x64 (1/468) http://jenkins.nodejs.org/job/nodejs-v0.8/29/
00:35:26  * qmx|awaychanged nick to qmx
00:35:37  <tjfontaine>ok lets rebuild v0.8 again
00:43:21  * bnoordhuisquit (Ping timeout: 276 seconds)
00:45:16  <MI6>nodejs-v0.8: #30 FAILURE windows-ia32 (5/468) osx-x64 (1/468) smartos-ia32 (2/468) linux-ia32 (1/468) osx-ia32 (2/468) smartos-x64 (2/468) linux-x64 (1/468) http://jenkins.nodejs.org/job/nodejs-v0.8/30/
00:45:16  * bnoordhuisjoined
00:45:32  <tjfontaine>yes yes, but now only windows failed on you this time
00:49:32  * bnoordhuisquit (Ping timeout: 250 seconds)
00:53:56  <trevnorris>TooTallNate: the dude that has code for everything. have an example of the simplest way to attach external data to an object that will be cleaned up when the object gets gc'd?
00:54:49  <tjfontaine>beyond WeakCallback?
00:55:13  * kazuponjoined
00:56:05  <trevnorris>tjfontaine: where i'm getting is that WeakCallback has to be on a Persistent object. Which needs to be part of a class and that is instantiated from a FunctionTemplate (since you need to SetInternalFieldCount)
00:56:33  <trevnorris>wait...
00:57:31  <TooTallNate>trevnorris: have you tried node-weak?
00:57:48  <MI6>joyent/libuv: Ben Noordhuis master * 8fbe433 : unix: please valgrind, free memory in threadpool.c - http://git.io/h7XJJw
00:58:41  <TooTallNate>trevnorris: it's a native module, so that's the only downside…
00:58:55  <tjfontaine>I think that's a good example for what he wants to do though
00:59:08  * dapquit (Quit: Leaving.)
00:59:10  <tjfontaine>at least in my head
00:59:13  <TooTallNate>trevnorris: what is it that you want to do?
00:59:20  <tjfontaine>take over the wrold
00:59:22  <tjfontaine>*world
00:59:24  <trevnorris>=))
00:59:51  <MI6>libuv-master: #34 UNSTABLE smartos (4/183) osx (1/183) linux (2/183) http://jenkins.nodejs.org/job/libuv-master/34/
01:00:15  * kazuponquit (Ping timeout: 276 seconds)
01:01:15  <trevnorris>TooTallNate: allocByteArray(n) -> will malloc some mem, tie it to a new object using SetIndexedPro...ArrayData(), return the object, then cleanup the malloc'd mem when the object is gc'd.
01:01:54  <trevnorris>where i'm having issues is having the malloc'd mem be cleaned up after the object is gc'd
01:03:06  <MI6>nodejs-master: #77 UNSTABLE osx-ia32 (1/551) windows-ia32 (12/551) windows-x64 (11/551) linux-ia32 (1/551) osx-x64 (1/551) http://jenkins.nodejs.org/job/nodejs-master/77/
01:03:13  <TooTallNate>wtffffossxxxxx
01:03:27  <tjfontaine>hm?
01:04:13  <TooTallNate>oh nvm
01:04:23  <TooTallNate>still learning how to read these test runner outputs :p
01:04:45  <tjfontaine>hehe
01:04:47  <tjfontaine>hudson.plugins.git.GitException: Command "git fetch -t origin +refs/heads/*:refs/remotes/origin/*" returned status code 128:
01:04:50  <tjfontaine>stdout:
01:04:52  <tjfontaine>stderr: fatal: pack has 3 unresolved deltas
01:04:55  <tjfontaine>:/
01:05:03  <tjfontaine>how the fuck did it get into that state
01:05:25  <trevnorris>tjfontaine: so will the WeakCallbackReference be called when the persistent object is about to be gc'd?
01:05:46  <tjfontaine>trevnorris: I really don't have the answer to that right now :)
01:05:51  * loladirojoined
01:06:16  <trevnorris>tjfontaine: no worries. looks like you have bigger issues to deal with.
01:10:36  <_ry>does anyone have benchmarks for 0.9.12 vs v0.8 up somewhere?
01:11:51  <trevnorris>TooTallNate: thanks much. that has exactly what I was looking for.
01:12:16  * dominictarrjoined
01:13:33  * loladiropart
01:14:05  * loladirojoined
01:15:01  * loladiroquit (Client Quit)
01:15:34  <TooTallNate>trevnorris: node-weak does?
01:15:53  <TooTallNate>trevnorris: ya i think all that you want is to create a Persistent handle in C++ land, but make it a weak reference with a callback
01:16:27  <TooTallNate>_ry: this might be a little outdated but isaacs showed me that yesterday I think: http://static.izs.me/benchmark-write-refactor-vs-0.8.html
01:16:43  <trevnorris>TooTallNate: yeah. i just had a hard time seeing through all the inheritance and classes in node. coudln't see the simplest case.
01:21:52  * trevnorrisquit (Quit: Leaving)
01:31:42  * loladirojoined
01:38:27  * abraxasjoined
01:49:34  * dominictarrquit (Ping timeout: 245 seconds)
01:56:11  * qmxchanged nick to qmx|away
01:56:16  * kazuponjoined
02:01:02  * kazuponquit (Ping timeout: 252 seconds)
02:02:03  * c4milojoined
02:14:10  * bnoordhuisjoined
02:18:59  * bnoordhuisquit (Ping timeout: 260 seconds)
02:28:41  * loladiroquit (Quit: loladiro)
02:34:30  * mikealquit (Quit: Leaving.)
02:46:54  * dapjoined
02:57:08  * kazuponjoined
02:59:59  * indexzeroquit (Quit: indexzero)
03:01:41  * kazuponquit (Ping timeout: 245 seconds)
03:06:09  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:08:47  <tjfontaine>jenkins I won't let you break my spirit
03:38:54  * kazuponjoined
03:43:19  * kazuponquit (Ping timeout: 245 seconds)
03:44:52  * loladirojoined
03:55:12  * brsonquit (Quit: leaving)
03:56:19  * loladiroquit (Quit: loladiro)
04:01:01  * indexzerojoined
04:26:17  * benoitcquit (Excess Flood)
04:27:56  * benoitcjoined
04:29:28  * abraxasquit (Remote host closed the connection)
04:36:25  * kazuponjoined
04:37:14  * brsonjoined
04:46:29  <c4milo>has anyone used POSIX realtime signals before?
04:47:09  * abraxasjoined
04:47:14  <c4milo>and probably sigtimedwait4 too
04:48:15  <c4milo>I'm just wondering about its scalability, it seems pretty good but it hasn't taken off. I can't find why though
05:01:38  * c4miloquit (Remote host closed the connection)
05:09:12  * pooyajoined
05:10:04  * abraxasquit (Remote host closed the connection)
05:11:14  * abraxasjoined
05:11:40  * mikealjoined
05:23:32  * mikealquit (Quit: Leaving.)
05:25:42  * mikealjoined
05:35:30  * kevireillyjoined
05:41:31  * benoitcquit (Excess Flood)
05:42:44  * wolfeidauquit (Read error: Connection reset by peer)
05:42:55  * wolfeidaujoined
05:51:26  * benoitcjoined
05:54:17  * dominictarrjoined
05:54:28  * dapquit (Quit: Leaving.)
06:05:23  * kevireillyyjoined
06:05:27  * kevireillyquit (Read error: Connection reset by peer)
06:19:06  * wolfeidauquit (Remote host closed the connection)
06:49:31  * zotjoined
06:50:52  <zot>anybody lively here?
06:51:14  * TooTallNatejoined
06:51:14  * TooTallNatequit (Client Quit)
06:52:15  * csaohjoined
06:56:36  * csaohquit (Ping timeout: 252 seconds)
07:01:46  * loladirojoined
07:23:27  <tjfontaine>zot: hm?
07:25:48  * rendarjoined
07:30:49  <zot>is there an expectation that if you call uv_loop_delete() before a timer is stopped, that the process SEGVs?
07:30:57  <zot>(i'm seeing that behavior, which surprised me a bit)
07:31:44  * `3rdEdenjoined
07:35:02  <zot>i'll bring this question back later :)
07:46:45  * benoitcquit (Excess Flood)
07:47:59  * benoitcjoined
07:57:13  * stagas_joined
07:59:12  * stagasquit (Ping timeout: 256 seconds)
07:59:23  * stagas_changed nick to stagas
08:17:40  * dsantiagoquit (Ping timeout: 240 seconds)
08:26:00  * brsonquit (Quit: leaving)
08:32:38  * csaohjoined
08:46:21  * txdvjoined
08:46:50  * stagasquit (Ping timeout: 255 seconds)
08:47:53  * stagasjoined
09:08:04  <saghul>zot I think so, yes
09:08:15  <saghul>you can close all handles first with uv_walk
09:08:36  <indutny>morning
09:08:39  <saghul>then run the loop so that callbacks are called with UV_RUN_NOWAIT, then delete it
09:11:51  * zotquit (Quit: Leaving.)
09:13:58  * loladiroquit (Quit: loladiro)
09:15:29  * kazuponquit (Remote host closed the connection)
09:18:42  * stagasquit (Ping timeout: 250 seconds)
09:29:45  * pooyaquit (Quit: pooya)
09:33:38  * stagasjoined
09:35:09  <rendar>saghul: what is the purpose of uv_walk?
09:35:33  <saghul>rendar iterate through the handles in a loop
09:35:47  <saghul>so you can iterate on them and call uv_close on them
09:35:56  <saghul>(in your case)
09:35:57  <rendar>i see
09:38:44  * stagasquit (Ping timeout: 245 seconds)
09:42:59  * stagasjoined
09:45:59  * stagas_joined
09:48:42  * stagasquit (Ping timeout: 276 seconds)
09:50:49  * stagas_quit (Ping timeout: 245 seconds)
10:09:01  * stagasjoined
10:09:10  * indexzeroquit (Quit: indexzero)
10:13:37  * kazuponjoined
10:18:47  * abraxasquit (Remote host closed the connection)
10:24:57  * kevireillyyquit (Read error: Connection reset by peer)
10:24:59  * kazuponquit (Remote host closed the connection)
10:25:16  * kevireillyjoined
10:53:12  * benoitcquit (Excess Flood)
10:56:30  * benoitcjoined
10:57:40  * dominictarrquit (Quit: dominictarr)
11:01:34  * dominictarrjoined
11:09:01  * stagasquit (Read error: Connection reset by peer)
11:12:47  * stagasjoined
11:17:38  * stagasquit (Ping timeout: 252 seconds)
11:28:45  * csaohquit (Quit: csaoh)
11:41:57  * csaohjoined
11:45:26  * kevireillyquit (Quit: Bye!)
11:46:04  * benoitcquit (Excess Flood)
11:56:31  * benoitcjoined
12:13:15  * hzjoined
12:22:21  * kazuponjoined
12:23:39  * zotjoined
12:24:32  <zot>saghul: part of me finds it strange that the delete call doesn't do that on my behalf… is it by design? or would a patch be welcome?
12:25:32  <saghul>zot I'm not a member of the core team, but i'd say it's by design.
12:27:09  <zot>i wonder if an assert or sth might be well placed, so it's more clear… gdb'ing into the libuv code delete feels like overkill for what seems a likely common mistake
12:27:22  * sgallaghjoined
12:28:08  * dominictarrquit (Quit: dominictarr)
12:28:26  * bnoordhuisjoined
12:44:33  <zot>is there a way to bind my own arbitrary information to a watcher? so that in a cb I can get at things that can't live in statics?
12:48:06  <saghul>zot the data field of a handle is a void* where you can store whatever you want
12:48:18  <zot>how did i miss that?!?!?
12:48:23  <zot>i was just looking at those structs
12:49:59  <zot>seriously. ridonkulous. face, meet palm.
12:58:53  <bnoordhuis>zot: though Real Men(TM) embed the uv handle in another struct and use container_of
12:59:11  <zot>heh. actually, that was my other plan.
12:59:19  <zot>since it's already in there.
12:59:29  <zot>however, i may have a situation down the road where that won't work
13:03:22  <indutny>Real Men
13:03:23  <indutny>(TM)
13:04:27  * qmx|awaychanged nick to qmx
13:04:29  * saghulrealized he may not be a real man yet
13:04:59  <zot>hrm. is container_of standardized these days? i remember when i started using offset_of all over the place, and found that many archs didn't have it, and i had to add it to my headers to steal from :/
13:09:16  * benoitcquit (Ping timeout: 276 seconds)
13:15:06  <bnoordhuis>zot: it's not part of any standard but as long as you include stddef.h, you should have offsetof
13:15:44  <zot>yep yep. just stole it and localized.
13:15:55  <bnoordhuis>here is how you can implement it without any headers
13:15:55  <bnoordhuis> 21 #define QUEUE_DATA(ptr, type, field) \
13:15:58  <bnoordhuis> 22 ((type *) ((char *) (ptr) - ((long) &((type *) 0)->field)))
13:16:34  <zot>i stole the linux list.h version
13:16:45  <bnoordhuis>that works too, of course :)
13:17:19  <csaoh>when I try to compile a little test file using "gcc test.c -I include/ -L. -luv" I get "ld: library not found for -luv collect2: ld returned 1 exit status". Is it normal ? or am I forgetting something ? i'm on mac osx
13:18:10  <MI6>joyent/node: Ben Noordhuis master * 7169436 : doc: dgram: add v0.10 bind() behavior note dgram.Socket#bind() is always (+1 more commits) - http://git.io/EXWgPQ
13:18:14  <zot>csaoh: does libuv.a or libuv.so exist in '.', and does your make/compile thing run from the directory that you think it does? for recursive/complicated make setups, it frequently does not.
13:18:22  <csaoh>yes
13:18:33  * AvianFluquit (Remote host closed the connection)
13:18:38  <zot>i'm on mac, and having no problem
13:18:42  <csaoh>it's not a compacted setup, i literally just run gcc by hand
13:19:10  <csaoh>i have libuv.a in . indeed
13:19:11  <bnoordhuis>csaoh: what file exactly do you have in .? libuv.a, libuv.so or libuv.dylib?
13:19:24  <csaoh>only libuv.a
13:19:37  <bnoordhuis>ah, that should work. what happens if you replace -L -luv with libuv.a?
13:20:03  <bnoordhuis>i.e. gcc test.c -Iinclude libuv.a
13:20:20  <csaoh>Undefined symbols for architecture x86_64:
13:20:21  <csaoh> "_AbsoluteToNanoseconds", referenced from:
13:20:22  <csaoh> _uv_hrtime in uv.a(darwin.o)
13:20:23  <csaoh>ld: symbol(s) not found for architecture x86_64
13:20:24  <csaoh>collect2: ld returned 1 exit status
13:20:48  <zot>probably missing -framework Foundation -framework CoreServices
13:20:49  <bnoordhuis>oh, add -framework CoreServices
13:20:53  <bnoordhuis>what zot said
13:20:59  <zot>i just went through all this 2 days ago :)
13:21:13  <csaoh>yes, thanks ! :D
13:21:19  <zot>check out https://github.com/benfleis/samples/ the libuv subdir
13:21:35  <zot>for quick and dirty, but mac working builds
13:21:46  <csaoh>great !
13:22:21  <zot>actually, i should push - there was a problem in one of them. let me do that :)
13:23:59  <zot>ok, pushed.
13:25:32  * benoitcjoined
13:26:24  <csaoh>:)
13:26:57  <zot>and this code isn't generally written for public consumption just yet — it's my sandbox for working out an API
13:27:16  <zot>but you can get what you need out of the makefiles i think :)
13:31:22  * bnoordhuisquit (Ping timeout: 276 seconds)
13:32:23  <MI6>nodejs-master: #78 UNSTABLE windows-x64 (11/551) osx-ia32 (1/551) windows-ia32 (11/551) http://jenkins.nodejs.org/job/nodejs-master/78/
13:33:21  * bnoordhuisjoined
13:42:40  * bnoordhuisquit (Ping timeout: 240 seconds)
13:46:16  * hzquit
13:54:54  * kazuponquit (Remote host closed the connection)
14:24:47  * kazuponjoined
14:27:34  * stagasjoined
14:36:14  * stagas_joined
14:36:50  * stagasquit (Ping timeout: 256 seconds)
14:36:53  * stagas_changed nick to stagas
14:46:06  * c4milojoined
14:49:35  * bnoordhuisjoined
14:53:23  <mmalecki>bnoordhuis: hey. ever seen node in a complete latch?
14:53:47  <indutny>huh?
14:53:48  <mmalecki>well, not complete. wouldn't accept network connections, but would maintain existing outgoing connections.
14:53:55  <indutny>strace it
14:53:58  <indutny>or it didn't happen
14:53:59  * philips_quit (Excess Flood)
14:54:02  <indutny>(or dtrace)
14:54:07  <indutny>(syscalls)
14:54:15  <mmalecki>yeah, if I knew what to trace, I'd
14:54:25  <indutny>mmalecki: also, are you sure that you're not running out of ephemeral ports?
14:54:30  <indutny>or just TCP ports
14:54:38  <indutny>check netstat
14:54:42  <indutny>and lsof
14:54:51  * bnoordhuisquit (Ping timeout: 276 seconds)
14:54:54  <mmalecki>indutny: that I'm hella sure of, we've been there
14:54:55  <indutny>usually this happens when ulimit -n is too small
14:55:06  <indutny>ok
14:55:20  <indutny>so everything mentioned is fine?
14:55:27  <indutny>but it still stops accepting new connections?
14:55:43  <mmalecki>yeah. it wouldn't even trigger events :/
14:56:03  <mmalecki>it's 165.225.130.238, port 80, in case you want to hit it
14:57:03  <indutny>well, can you just dtrace all processes?
14:57:08  <indutny>all node processes
14:57:19  <indutny>is it smartos?
14:57:27  <mmalecki>yeah, I get all syscalls. I guess I could give it a try
14:57:36  <mmalecki>not sure what to look for tho
14:57:45  <indutny>well, you can just give them too me
14:57:48  <indutny>if they're not secret
14:58:22  <mmalecki>syscalls aren't secret at all, we don't have our own secret syscalls yet ;)
14:58:34  <indutny>haha
14:59:09  <mmalecki>just a sec, I'm doing the voodoo dance now (rebooting, reprovisioning). I'll try tracing them after I'm done with that.
15:01:30  * philips_joined
15:03:55  * zotquit (Quit: Leaving.)
15:07:40  * kazuponquit (Remote host closed the connection)
15:13:48  * mikealquit (Quit: Leaving.)
15:33:26  * stagas_joined
15:33:40  * bradleymeckjoined
15:34:37  * stagasquit (Ping timeout: 245 seconds)
15:34:51  * stagas_changed nick to stagas
15:41:25  * pooyajoined
15:41:56  * stagasquit (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner 1.9.0.17/2009122204])
15:46:18  <c4milo>silly question: does the stream2 implementation in node.js use sendfile() + TCP_NOPUSH/ TCP_CORK?
15:46:34  <indutny>no
15:46:41  <c4milo>silly because since I'm not familiar with its current implementation I could be asking something out of context ;D
15:46:57  <c4milo>indutny: is there any special reason?
15:47:28  <c4milo>for not having it
15:47:46  <indutny>better ask ben, but I think its behaving differently on different platforms and not supported everywhere (or half broken)
15:48:32  <c4milo>right, OSX implementation is very shitty
15:49:21  <c4milo>I'm curious how other platforms have approached that, erlang for instance
15:50:11  * dapjoined
15:53:32  <indutny>we will use it eventually
15:57:42  * pooyaquit (Quit: pooya)
15:58:13  <c4milo>indutny: is anyone working on that already?
15:58:44  <c4milo>I guess it is more about leveraging sendfile in the streams implementation than exposing the syscall itself.
16:08:51  * mikealjoined
16:11:12  * mmaleckichanged nick to mmalecki[out]
16:18:09  * kazuponjoined
16:19:20  * bnoordhuisjoined
16:19:48  * abraxasjoined
16:20:56  * `3rdEdenquit (Quit: dinnar)
16:23:36  * kazuponquit (Ping timeout: 264 seconds)
16:24:08  * abraxasquit (Ping timeout: 252 seconds)
16:26:55  <indutny>bnoordhuis: hey man
16:26:56  <indutny>yt?
16:27:00  <bnoordhuis>indutny: ho man
16:27:03  <bnoordhuis>ih
16:27:12  <indutny>wanna see some ultimate awesomeness?
16:27:33  <bnoordhuis>only if it's not indecent
16:28:02  <indutny>hope it isn't
16:28:02  <indutny>https://github.com/indutny/jit.js
16:28:12  <indutny>I know you was working on something similar while ago
16:28:22  <indutny>but I wasn't able to locate it
16:28:30  <indutny>so I thought... why not do the same thing myself
16:28:35  <bnoordhuis>hah, nice
16:28:45  <indutny>I haven't finished it yet
16:28:49  <bnoordhuis>yeah, mine was only a proof of concept, i never published it or anythin
16:28:53  <indutny>only 4 instructions are supported
16:29:05  <indutny>bnoordhuis: ah, it was just a gist?
16:29:07  <indutny>https://github.com/indutny/jit.js/blob/master/test/api-test.js#L6
16:31:46  * bnoordhu1sjoined
16:32:18  <bnoordhu1s>sorry, lost connection
16:32:44  <indutny>np
16:32:45  <indutny>so
16:32:45  <indutny>https://github.com/indutny/jit.js/blob/master/test/api-test.js#L6
16:32:54  <bnoordhu1s>but i see you've implemented enough to implement void f(void) {} :)
16:32:54  <indutny>it looks this way now
16:32:59  <indutny>yep :)
16:33:00  <bnoordhuis>yeah
16:33:00  * bnoordhuisquit (Quit: Reconnecting)
16:33:10  * bnoordhu1schanged nick to bnoordhuis
16:39:09  * bnoordhu1sjoined
16:39:18  * mikealquit (Quit: Leaving.)
16:40:26  <indutny>bnoordhuis: bnoordhu1s: so if you're like interested - feel free to contribute some instructions :)
16:40:28  <indutny>or arxhs
16:43:46  * bnoordhuisquit (Ping timeout: 276 seconds)
16:44:06  * bnoordhu1schanged nick to bnoordhuis
16:52:11  <MI6>joyent/node: Andreas Madsen master * bdf7ac2 : child_process: support sending dgram socket child.send can send net serv - http://git.io/cmW_Pg
16:58:29  * mcavagejoined
17:01:33  <tjfontaine>bnoordhuis: you're brekaing your own rules, "(I kid. Landed in bdf7ac2, thanks.)"
17:05:03  * qmxchanged nick to qmx|lunch
17:07:09  <MI6>nodejs-master: #79 UNSTABLE windows-x64 (12/552) osx-ia32 (1/552) windows-ia32 (13/552) osx-x64 (1/552) http://jenkins.nodejs.org/job/nodejs-master/79/
17:11:44  <bnoordhuis>tjfontaine: what rules?
17:11:54  <tjfontaine>"I never kid"
17:12:57  <bnoordhuis>oh. did i unintentionally do something funny?
17:12:59  <isaacs>tjfontaine: bnoordhuis was kidding when he said that
17:13:41  * AvianFlujoined
17:14:13  <tjfontaine>isaacs: clearly
17:16:28  * mikealjoined
17:20:10  * bradleymeck_joined
17:20:40  * bradleymeckquit (Ping timeout: 240 seconds)
17:20:40  * bradleymeck_changed nick to bradleymeck
17:21:25  * pooyajoined
17:26:26  <bnoordhuis>isaacs: any showstopper bugs so far?
17:26:49  <tjfontaine>he's on his way to the office, so may be a bit before he responds
17:26:54  <bnoordhuis>oh, okay
17:27:19  <bnoordhuis>tjfontaine: you're already at the office or ?
17:27:25  <tjfontaine>bnoordhuis: indeed
17:36:56  * stagasjoined
17:37:12  * dsantiagojoined
17:38:03  * `3rdEdenjoined
17:39:21  * csaohquit (Quit: csaoh)
17:40:34  * chrisdicojoined
17:44:04  <MI6>libuv-master: #36 UNSTABLE osx (1/183) linux (2/183) smartos (5/183) http://jenkins.nodejs.org/job/libuv-master/36/
17:45:47  * chrisdickinsonquit (*.net *.split)
17:45:47  * hij1nxquit (*.net *.split)
17:49:27  * mcavagequit (Remote host closed the connection)
17:53:13  <MI6>joyent/node: piscisaureus created branch msi-fixes - http://git.io/hjYLSQ
17:53:15  <bnoordhuis>tjfontaine: http://jenkins.nodejs.org//job/libuv-master/36/label=linux//tapTestReport/test.tap-18/ <- any idea why that assert happens?
17:53:30  <bnoordhuis>for posterity -> Assertion failed in test/test-tty.c on line 68: ttyin_fd >= 0
17:53:51  * hij1nxjoined
17:54:18  <tjfontaine>bnoordhuis: I don't off hand, it could be a by product of the test runner environment, lemme test independently
17:54:46  * `3rdEdenquit (Remote host closed the connection)
17:56:57  * sblomjoined
17:57:09  <tjfontaine>bnoordhuis: I'm guessing it's from the fact that stdin is likely a file instead of a pipe
17:57:35  <bnoordhuis>that seems plausible, only it doesn't happen when i run it locally
17:58:35  * piscisaureus_joined
17:58:38  <tjfontaine>same here, I had a similar problem with node that tried to listen() on fd0, I worked around it at the time by doing python tools/test.py < /dev/null
18:01:14  <tjfontaine>bnoordhuis: default for spawn is inherit right? what if I change the spawn to use pipe?
18:02:09  <bnoordhuis>tjfontaine: that's correct. but you shouldn't have to fix the test, it shouldn't assert in the first place :)
18:02:41  * brsonjoined
18:02:51  <tjfontaine>no I mean my test runner
18:03:01  <MI6>joyent/node: Bert Belder msi-fixes * 1b15063 : win/msi: miscellaneous style cleanups (+6 more commits) - http://git.io/3A3IVg
18:03:21  * loladirojoined
18:05:54  <MI6>libuv-master: #37 UNSTABLE osx (1/183) linux (2/183) smartos (5/183) http://jenkins.nodejs.org/job/libuv-master/37/
18:06:03  <MI6>libuv-master: #38 FAILURE osx (1/183) linux (2/183) smartos (5/183) http://jenkins.nodejs.org/job/libuv-master/38/
18:06:13  <tjfontaine>whoops
18:07:11  <MI6>libuv-master: #39 FAILURE http://jenkins.nodejs.org/job/libuv-master/39/
18:10:09  <MI6>libuv-master: #40 UNSTABLE osx (11/183) linux (17/183) smartos (5/183) http://jenkins.nodejs.org/job/libuv-master/40/
18:10:11  <tjfontaine>bnoordhuis: every tweak I make to spawn(run-tests) seems to only make it worse :)
18:10:45  <tjfontaine>that run was stdio: ['ignore', null, null]
18:11:05  <bnoordhuis>hm, okay
18:11:44  <tjfontaine>I'm going to look for the javur that sets up these child environments to see what I'm actually dealing with so I can figure out how to test it properly
18:12:15  <MI6>libuv-master: #41 UNSTABLE osx (1/183) linux (2/183) smartos (6/183) http://jenkins.nodejs.org/job/libuv-master/41/
18:16:32  * `3rdEdenjoined
18:21:20  <tjfontaine>bnoordhuis: looking over the test, I'm not sure I could ever get an environment in jenkins such that that test would be happy?
18:21:41  <tjfontaine>I mean what does get_winsize really mean in a headless environment
18:27:04  * _ritchjoined
18:29:06  <piscisaureus_>isaacs: sblom: I'm getting assertion failures in libuv when I run the tests against rc0 :-(
18:29:28  <piscisaureus_>Assertion failed: handle->reqs_pending > 0, file src\win\tcp.c, line 1026
18:30:56  <indutny>all red
18:30:57  <indutny>omg
18:32:00  <piscisaureus_>D:\slnode\test\simple\test-stream2-transform.js:235
18:32:01  <piscisaureus_> t.equal(pt.read(5).toString(), 'abcd');
18:32:39  <indutny>read(5) === 'abcd'?
18:35:23  * qmx|lunchchanged nick to qmx
18:36:36  <piscisaureus_>test-http-client also fails
18:36:41  <indutny>ah
18:36:43  <indutny>that's the last
18:37:02  <piscisaureus_>as well as test-http-onerror
18:37:25  <indutny>on windows?
18:37:29  <piscisaureus_>yeah
18:37:35  <piscisaureus_>also http-client-timeout
18:38:03  <piscisaureus_>The windows situation: [10:41|% 100|+ 584|- 17]: Done
18:38:31  <piscisaureus_>isaacs: I am very happy that you managed to work out the perf regressions. However rc0 is definitely not looking good...
18:39:04  <tjfontaine>I'm only seeing 12 or 13 failures on master for windows right now
18:39:42  * brsonquit (Ping timeout: 264 seconds)
18:39:50  <tjfontaine>http://jenkins.nodejs.org/job/nodejs-master/DESTCPU=ia32,label=windows/lastCompletedBuild/tapTestReport/
18:40:24  <piscisaureus_>tjfontaine: do you run test-all?
18:40:25  * brsonjoined
18:40:28  <piscisaureus_>or just test?
18:40:39  <tjfontaine>piscisaureus_: simple and message, which I guess is equivalent to just test
18:41:01  <piscisaureus_>you probably want to the gc and pummel tests too
18:41:04  <piscisaureus_>and ideally internet tests
18:41:11  <piscisaureus_>but I can imagine getting those to work are hard
18:41:12  <tjfontaine>I run all those on the full nightly
18:41:50  <tjfontaine>http://jenkins.nodejs.org//job/nodejs-master/DESTCPU=ia32,label=windows/lastCompletedBuild//tapTestReport/test.tap-509/ is this failing for you as well?
18:41:53  <bnoordhuis>some of those tests really shouldn't fail, should they?
18:41:57  <bnoordhuis>how does it compare to v0.8?
18:42:04  * TooTallNatejoined
18:42:11  <tjfontaine>I can't keep a stable build of v0.8 on windows :/
18:42:30  <bnoordhuis>hah :)
18:43:17  <tjfontaine>I'm probably going to have to start deleting its workspace entirely before starting a build to make it work, as that's the only time I can seem to get it to be build cleanly
18:44:49  <piscisaureus_>tjfontaine: yeah 509 is because the test requires some openssl command line flag that msys-openssl doesn't support
18:44:57  <piscisaureus_>it fails for me too
18:45:00  <tjfontaine>ok
18:45:16  <piscisaureus_>0.8 had 5 failures at some point
18:45:25  <piscisaureus_>also the current master branch had 0 failures at some point
18:45:38  <bnoordhuis>i don't believe it
18:45:42  <indutny>yeah, me too
18:45:45  <indutny>was it just random run?
18:46:05  * bradleymeckquit (Quit: bradleymeck)
18:46:14  <tjfontaine>they were just hidden by other bugs that got fixed :P
18:46:23  <indutny>bugs hiding bugs
18:46:31  <indutny>that feels like windows way
18:49:28  * bradleymeckjoined
18:49:31  <tjfontaine>sigh http://jenkins.nodejs.org/job/nodejs-v0.8/DESTCPU=ia32,label=windows/31/console
18:50:14  <sblom>piscisaureus_: I'm spending time today and tomorrow to work on Windows unit tests.
18:50:49  <sblom>I'm focused on just test for now, but I can move on to test-all next.
18:51:08  <sblom>Are you working on this, too? I.e. do we need to coordinate work?
18:51:55  <sblom>Some of them look straightforward for me to fix.
18:52:01  <sblom>And some of them look terrifyingly deep.
18:53:36  <indutny>not as terrifying as they look for us ;)
18:53:46  <indutny>I'll get licensed windows copy soon
18:53:53  <sblom>Heh.
18:53:53  <indutny>but that may happen only on next week
18:54:05  <piscisaureus_>sblom: I can work on it a little but I have more time next week
18:54:06  <indutny>and if we won't fix everything - I'll probably give you a hand of help
18:54:16  <sblom>Okay.
18:54:28  <tjfontaine> v8_base.vcxproj -> ..\..\..\..\build\Release\lib\v8_base.lib
18:54:29  <tjfontaine>Command exited with non-zero: cmd /c call g:\jenkins\buildwrap.bat x64 release nosi
18:54:36  <tjfontaine>+gn
18:54:39  <tjfontaine>thanks msbuild.
18:54:42  <piscisaureus_>so if isaacs really pushes forward with the release on monday then it may be too late for me to improve this :)
18:55:34  * trevnorrisjoined
18:58:04  * stagasquit (Ping timeout: 250 seconds)
18:58:31  <MI6>nodejs-v0.8: #31 FAILURE osx-x64 (2/468) smartos-ia32 (3/468) linux-ia32 (1/468) osx-ia32 (1/468) windows-ia32 (5/468) linux-x64 (2/468) smartos-x64 (2/468) http://jenkins.nodejs.org/job/nodejs-v0.8/31/
18:59:33  * stagasjoined
19:04:45  <bnoordhuis>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c617f398edd4db2b8567a28e899a88f8f574798d <- SO_REUSEPORT. interesting
19:08:04  <indutny>yeeeees
19:08:20  <indutny>automatic dispatch?
19:08:22  <tjfontaine>only 10 years until it sees wide deployment
19:08:28  <indutny>not really 10
19:08:35  <indutny>linux is moving faster than in 90's
19:08:39  <tjfontaine>ok I was optimistic, 20 :P
19:09:01  <indutny>haha
19:09:19  <indutny>I think in 2-3 years it'll be on 75% of linux servers
19:09:27  <indutny>because we're in the cloud now
19:09:40  <indutny>anyway
19:09:45  <indutny>this is very good thing
19:09:47  <tjfontaine>there are lots of people with > 2year uptime in the cloud
19:09:51  <tjfontaine>but yes I agree it's a GoodThign
19:09:56  <tjfontaine>*GoodThing
19:10:05  <indutny>(TM)
19:10:12  <tjfontaine>:)
19:10:57  * bnoordhuisquit (Ping timeout: 252 seconds)
19:22:22  * pooyaquit (Quit: pooya)
19:22:56  * piscisaureus_quit (Ping timeout: 245 seconds)
19:23:57  <trevnorris>indutny: other than makeweak/persistent object thing, is there any way from cc to tell if a js object has or is about to be gc'd?
19:24:31  <indutny>nope
19:24:49  <trevnorris>=P
19:26:54  * sblomquit
19:27:20  <isaacs>indutny: in if you read(n) after the EOF is seen, and n > length, then you get length, not n
19:27:24  <indutny>yeah
19:27:28  <indutny>I figured out
19:27:35  <isaacs>indutny: so read(5).toSring() === 'asdf' is actually approrpriate in that test
19:27:38  <isaacs>otherwise you'd never see the end
19:28:24  <trevnorris>indutny: so basically even if memory was preallocated, each chunk handed off would still need to be made persistent to know when it's no longer used. hm...
19:28:48  <trevnorris>bugger, making an object persistent is way more expensive then a malloc.
19:29:57  * loladiroquit (Quit: loladiro)
19:31:02  <indutny>yes
19:31:28  <indutny>expense of this is that GC will check all persistent objects on each cycle
19:31:36  <trevnorris>ugh.
19:32:04  <isaacs>ok, so, i guess i'm also joinging the "tests pass on windows" push here.
19:33:51  <isaacs>tjfontaine: http://jenkins.nodejs.org//job/nodejs-master/DESTCPU=ia32,label=windows/lastBuild//tapTestReport/test.tap-57/
19:35:28  * pooyajoined
19:36:01  <isaacs>http://jenkins.nodejs.org//job/nodejs-master/DESTCPU=ia32,label=windows/lastBuild//tapTestReport/test.tap-461/
19:37:07  * bnoordhuisjoined
19:37:17  <trevnorris>isaacs: so the Utf8Regression should be mostly fixed in 3.17.8 and completely fixed in 3.17.9.
19:37:26  <isaacs>trevnorris: rad
19:37:27  <trevnorris>*Utf8Length regression
19:37:28  <isaacs>0.12
19:37:31  <trevnorris>awesome
19:42:26  <isaacs>ircretary: tell piscisaureus Yes, 0.10 will go out Monday. If you have breaking API changes that have to happen, please let me know. If there are some tests failing on Windows-only, we can still fix those afterwards.
19:42:26  <ircretary>isaacs: I'll be sure to tell piscisaureus
19:43:06  <isaacs>ircretary: thanks
19:43:07  <ircretary>isaacs: You're welcome :)
19:44:36  <isaacs>ircretary: tell sblom Ping me when you get back. I'm going to start working on these. Maybe one of us can take the list top-down, the other can go bottom-up, and we'll meet in the middle with a green build?
19:44:36  <bradleymeck>indutny: you are a crazy person
19:44:36  <ircretary>isaacs: I'll be sure to tell sblom
19:45:48  * bnoordhuisquit (Ping timeout: 272 seconds)
19:46:35  * mmalecki[out]changed nick to mmalecki
19:49:49  <trevnorris>just to double check, should you only need a HandleScope if you create Local handles that need to be cleaned up?
19:54:49  <tjfontaine>for historical purposes these are the tests bert was seeing failing previously, https://github.com/joyent/node/issues/4094
19:54:59  <tjfontaine>on the plus side the debugger failures are fixed :)
19:55:51  <isaacs>ircretary: tell sblom Actually, if you have cycles for it, digging into this assertion error in libuv would be awesome: http://jenkins.nodejs.org//job/nodejs-master/DESTCPU=ia32,label=windows/lastBuild//tapTestReport/test.tap-57/
19:55:51  <ircretary>isaacs: I'll be sure to tell sblom
19:56:21  * benoitcquit (Excess Flood)
19:57:03  <MI6>joyent/node: isaacs master * e7b8bad : bench: Do math on numbers in compare.js, not strings (+1 more commits) - http://git.io/BcRi3g
19:57:08  * benoitcjoined
20:04:49  <indutny>bradleymeck: why?
20:05:33  <bradleymeck>jit.js / knowing when gc is going to hit, idk
20:11:41  <MI6>nodejs-master: #80 UNSTABLE windows-x64 (12/552) osx-ia32 (1/552) windows-ia32 (12/552) http://jenkins.nodejs.org/job/nodejs-master/80/
20:15:51  * _ritchquit (Quit: Leaving.)
20:18:28  * Chip_Zeroquit (Ping timeout: 245 seconds)
20:20:47  * Chip_Zerojoined
20:22:17  <trevnorris>could someone help point me to do docs of why the second return is a function? https://gist.github.com/trevnorris/5111477
20:29:21  * dominictarrjoined
20:33:34  * wolfeidaujoined
20:35:56  * chrisdicoquit (Quit: ZNC - http://znc.sourceforge.net)
20:38:45  * chrisdickinsonjoined
20:49:20  * trevnorrisquit (Read error: Operation timed out)
20:53:39  * trevnorrisjoined
20:54:45  <trevnorris>well that was fun. misplaced a free () and kissed my ram goodbye.
20:54:48  * mjr_joined
20:54:50  * mjr_quit (Client Quit)
20:54:58  * mjr_joined
20:59:46  <mjr_>Is there any public knowledge of people using libuv on window phone 8?
21:00:01  <mjr_>or even Windows Phone 8, for that matter.
21:08:55  * qmxchanged nick to qmx|afk
21:11:53  * loladirojoined
21:14:09  * bradleymeckquit (Quit: bradleymeck)
21:20:58  * sgallaghquit (Remote host closed the connection)
21:32:58  * EhevuTovjoined
21:38:10  * EhevuTovquit (Quit: This computer has gone to sleep)
21:38:46  * EhevuTovjoined
21:41:36  * bnoordhuisjoined
21:42:44  * rendarquit
21:44:43  * brsonquit (Ping timeout: 260 seconds)
21:45:34  * brsonjoined
21:46:07  * bnoordhuisquit (Ping timeout: 260 seconds)
21:48:12  * benoitcquit (Excess Flood)
21:50:39  * benoitcjoined
21:53:24  * wolfeidauquit (Remote host closed the connection)
21:57:01  * qmx|afkchanged nick to qmx
22:01:55  * stagas_joined
22:04:21  * stagasquit (Ping timeout: 256 seconds)
22:04:35  * stagas_changed nick to stagas
22:07:39  <trevnorris>TooTallNate: i'm trying to implement the basics from node-weak, but i'm leaking memory like a sieve: https://gist.github.com/trevnorris/5112274
22:08:54  <TooTallNate>trevnorris: does it go back down after they're gc'd?
22:09:35  <trevnorris>TooTallNate: if I manually run gc() it only goes down to 251 MB
22:10:20  <TooTallNate>trevnorris: well it lgtm i think… i don't see anything wrong in your code…
22:10:50  <indutny>is callback invoked?
22:11:08  <trevnorris>yeah. ran fprintf from the callback and it's being run.
22:11:18  <indutny>interesting
22:11:53  <trevnorris>ugh. what the freak. ok, if I run gc like every other time in the loop, mem usage goes down to around ~22MB.
22:12:02  <trevnorris>before Iwas just runnign it right after the loop.
22:12:12  * wolfeidaujoined
22:12:40  <indutny>I guess one gc() run isn't enough
22:12:49  <indutny>you might be triggering incremental gc
22:12:56  <indutny>and it stops after scavenging for some time
22:13:09  <indutny>also
22:13:18  <indutny>yeah, this
22:13:57  <indutny>try calling gc() multiple times in setTimeout() cb
22:14:06  <indutny>like 3-4 times
22:14:28  <trevnorris>yeah. now it's down to 1MB.
22:15:15  <indutny>good
22:15:22  <indutny>so if you'll run it with --trace-gc
22:15:26  <indutny>you'll see if I was right
22:16:23  <trevnorris>indutny: know what "[allocation failure]" in --trace-gc means?
22:16:30  <indutny>yes
22:16:39  <indutny>its ok
22:18:00  <trevnorris>when I don't run gc manually there are a couple Mark-sweeps w/ a "[promotion limit reached]", and a bunch of scavenge.
22:18:24  <indutny>obviously
22:18:31  <indutny>it spends too much time in gc
22:18:37  <indutny>and decides to continue later
22:18:48  <trevnorris>ah, ok.
22:18:48  <indutny>incremental!
22:18:49  <indutny>:)
22:19:01  <indutny>yeah, v8 tries to keep your app as realtime as possible
22:19:03  <indutny>ok, brb
22:20:53  <trevnorris>indutny: cool. thanks.
22:21:04  <trevnorris>TooTallNate: you know what's happening to the Object* reference in this: https://gist.github.com/trevnorris/5111477
22:21:46  <TooTallNate>trevnorris: you're not using a Persistent handle
22:22:11  <TooTallNate>trevnorris: so the Object ref is being released once the AttachData function returns
22:22:31  <trevnorris>TooTallNate: even though I pass it through Close()?
22:23:16  <trevnorris>then I guess the pointer just ends up pointing to some other random place. hm. ok.
22:23:44  <TooTallNate>trevnorris: ya, you need Persistent for sure :)
22:24:12  * stagas_joined
22:25:57  * stagasquit (Ping timeout: 248 seconds)
22:26:07  * stagas_changed nick to stagas
22:27:03  <trevnorris>bugger. this whole persistent/makeweak as the only way to track if a js object is still really chaffing me.
22:27:29  <trevnorris>TooTallNate: guess what I don't totally understand is that the js object that was passed still exists, but Object* just no longer points to it.
22:28:04  <TooTallNate>trevnorris: well it sounds like you do understand :)
22:28:39  <TooTallNate>trevnorris: you have to use a Persistent handle so that V8 knows the object is still being referenced (by C++, not JS), so that it doesn't GC it from under your feet
22:30:07  <trevnorris>TooTallNate: well, what i'm looking for is a way to check if the object has been cleaned up. i don't care when it gets cleaned up, just that it was.
22:30:53  <trevnorris>w/o the expense of persistent. since I don't need a callback telling me it's about to be gc'd. just like a obj.WasGCd() === true type thing.
22:31:06  <TooTallNate>trevnorris: you'd have to create a Persistent handle, call MakeWeak() and from then on you can check .isDead() at any time
22:31:14  <trevnorris>or even obj.StillExists()
22:32:11  <trevnorris>suck. persistent is way too expensive. like for buffers, we create a large pool then tie small chunks to other objects. but we can't tell when a chunk is free.
22:32:51  <trevnorris>if we could tell when a chunk is no longer referenced in js-land w/o needing a persistent then that memory segment could be reallocated.
22:32:52  * qmxchanged nick to qmx|away
22:33:02  * c4miloquit (Remote host closed the connection)
22:33:11  <TooTallNate>trevnorris: it kinda sounds like you want a weakmap… not sure
22:37:23  <trevnorris>TooTallNate: so if i understand weakmaps, the key can be anything. including an reference. if the ref is gc'd then the key no longer exists?
22:38:27  <TooTallNate>trevnorris: i think it's "if the key (an object) get's GC'd then the entry in the map is removed"
22:38:46  <TooTallNate>idk though… i've never used them yet :D
22:39:22  <trevnorris>TooTallNate: well, that's along the lines of what i'm looking for.
22:49:07  <trevnorris>TooTallNate: do you know if v8 will move object around in memory? guess that would explain why the object needs to be referred to by the handle.
22:49:37  <TooTallNate>trevnorris: i don't really know what it does under the hood
22:49:40  <TooTallNate>'tis magic
22:49:55  <trevnorris>yeah. same for me.
22:50:31  <trevnorris>indutny: when you have a moment. a couple questions regarding the memory consolidation stuff.
22:50:54  <indutny>sure
22:50:55  <indutny>shoot
22:52:40  <trevnorris>indutny: the changes I was thinking of aren't really useful unless there's a cheaper way to know when an object has been gc'd. i mean
22:52:49  * dominictarrquit (Quit: dominictarr)
22:53:13  <trevnorris>buffers create a large pool, then dish out bits, then v8 will cleanup the pool once nothing else references it.
22:53:44  <trevnorris>but we have no way of knowing if one of those chunks is no longer in use, right?
22:54:27  * kuebkjoined
22:58:10  <trevnorris>indutny: really the point was to consolidate the fact that node uses Buffers (which have Slow/Fast Buffers), the SlabAllocator and SlabBuffers (which both use Buffers).
22:58:23  <trevnorris>each one using their own little memory saving techniques.
22:59:50  <trevnorris>it's a freakin nightmare, but i'm having a hard time seeing how to create the api for exeternal memory allocation/management when we can't cause the cost of using persistent objects.
23:06:40  <trevnorris>indutny: guess what i'm looking for is advice on how the api should look. my initial idea was a simple "AllocExtern(n)", which would return a new object with an n-length byte length external data array attached.
23:06:42  * zotjoined
23:06:58  <trevnorris>indutny: or "AllocExtern(obj, n)" to do the same, but on the passed Object.
23:07:04  * bnoordhuisjoined
23:08:53  * zot1joined
23:11:10  * zotquit (Ping timeout: 252 seconds)
23:12:06  * bnoordhuisquit (Ping timeout: 276 seconds)
23:14:32  <MI6>libuv-master: #42 UNSTABLE osx (2/183) linux (2/183) smartos (5/183) http://jenkins.nodejs.org/job/libuv-master/42/
23:21:04  * `3rdEdenquit (Quit: zzz)
23:25:21  * zot1quit (Read error: Connection reset by peer)
23:30:15  * c4milojoined
23:34:15  * kuebkquit
23:34:17  * pooyaquit (Quit: pooya)
23:40:13  <isaacs>hmmmm...
23:40:17  <isaacs>any windows people around?
23:40:24  <isaacs>sblom? piscisaureus?