00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:02:26  <MI6>libuv-master-gyp: #122 UNSTABLE linux-ia32 (2/192) windows-x64 (3/193) smartos-ia32 (2/192) smartos-x64 (4/192) windows-ia32 (4/193) osx-x64 (1/193) linux-x64 (2/192) http://jenkins.nodejs.org/job/libuv-master-gyp/122/
00:03:43  <MI6>nodejs-master: #467 UNSTABLE smartos-x64 (8/636) smartos-ia32 (2/636) http://jenkins.nodejs.org/job/nodejs-master/467/
00:08:43  <mordy__>tjfontaine: ahhhh ok.. i discovered SetMethod vs SetPrototypeMethod
00:09:08  <mordy__>where presumably the former creates a normal "function" and places it inside the module, whereas SetPrototypeMethod adds a new method to some object's prototype
00:09:12  <tjfontaine>mordy__: yes, or helpers NODE_SET_METHOD
00:09:21  <tjfontaine>mordy__: that's correct.
00:10:34  <mordy__>the existing boilerplate uses the prototype variants here... is one particularly faster than the other?
00:12:32  <tjfontaine>mordy__: I've not benchmarked them, but they're generally only called only once at module initialization
00:29:06  * indexzerojoined
00:32:28  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:34:37  * EhevuTovquit (Quit: This computer has gone to sleep)
00:34:47  * groundwaterquit (Quit: groundwater)
00:39:24  * kevinswiberjoined
00:45:35  * indexzeroquit (Quit: indexzero)
00:52:22  * TooTallNatejoined
00:56:07  * dapquit (Quit: Leaving.)
00:56:28  * dapjoined
00:56:38  * dapquit (Client Quit)
01:01:28  * dominictarr_joined
01:04:56  * dominictarrquit (Ping timeout: 268 seconds)
01:04:56  * dominictarr_changed nick to dominictarr
01:05:29  * amartensquit (Quit: Leaving.)
01:09:52  <MI6>nodejs-master-windows: #261 UNSTABLE windows-x64 (19/636) windows-ia32 (24/636) http://jenkins.nodejs.org/job/nodejs-master-windows/261/
01:10:38  * TooTallNatequit (Ping timeout: 240 seconds)
01:13:36  * jmar777joined
01:20:31  * indexzerojoined
01:20:40  * TooTallNatejoined
01:27:47  * kevinswiberquit (Remote host closed the connection)
01:28:25  * abraxasjoined
01:29:54  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:32:46  * jmar777quit (Remote host closed the connection)
01:42:14  * AvianFluquit (Remote host closed the connection)
01:42:30  * st_lukequit (Remote host closed the connection)
01:53:17  * indexzeroquit (Quit: indexzero)
02:12:56  * c4milojoined
02:28:05  * Brett19joined
02:28:54  * indexzerojoined
03:05:24  * bradleymeckjoined
03:07:03  * TooTallNatejoined
03:34:38  * dominictarr_joined
03:37:41  * dominictarrquit (Ping timeout: 248 seconds)
03:37:42  * dominictarr_changed nick to dominictarr
04:04:54  * bradleymeckquit (Ping timeout: 264 seconds)
04:07:56  * bradleymeckjoined
04:08:03  * bradleymeckquit (Client Quit)
04:09:54  * stagasquit (Read error: Connection reset by peer)
04:15:25  * kazuponjoined
04:16:16  * c4miloquit (Remote host closed the connection)
04:30:50  * AvianFlujoined
04:39:13  * AvianFluquit (Ping timeout: 256 seconds)
04:39:22  * AvianFlujoined
04:54:24  * AvianFluquit (Remote host closed the connection)
05:17:41  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
05:23:20  * KiNgMaRquit (Ping timeout: 245 seconds)
05:23:51  * KiNgMaRjoined
06:00:02  * defunctzombiechanged nick to defunctzombie_zz
06:03:03  * defunctzombie_zzchanged nick to defunctzombie
06:17:21  * Brett19quit (Read error: Connection reset by peer)
06:17:34  * dominictarr_joined
06:20:38  * dominictarrquit (Ping timeout: 264 seconds)
06:20:39  * dominictarr_changed nick to dominictarr
06:41:03  * defunctzombiechanged nick to defunctzombie_zz
06:50:26  <indutny>hi
07:04:08  * chobie4quit (Ping timeout: 246 seconds)
07:04:38  * chobie4joined
07:04:54  * brsonquit (Ping timeout: 264 seconds)
07:17:05  * rendarjoined
07:19:02  * indexzeroquit (Quit: indexzero)
07:20:12  * hzjoined
07:23:28  * st_lukejoined
07:27:33  * hzquit (Disconnected by services)
07:27:37  * hzjoined
07:40:30  * dominictarrquit (Quit: dominictarr)
07:50:57  * defunctzombie_zzchanged nick to defunctzombie
08:00:59  * defunctzombiechanged nick to defunctzombie_zz
08:50:49  * bnoordhuisjoined
08:53:22  * bajtosjoined
09:03:17  * indexzerojoined
09:14:59  <bnoordhuis>i've never noticed it before, but v8's large object space has the executable bit set
09:15:31  <bnoordhuis>probably means it's a mix of data and code
09:18:33  <indutny>yeah
09:18:43  <indutny>bnoordhuis: well, actually no
09:18:46  <indutny>it shouldn't be so
09:18:51  <indutny>they're using separate spaces for it
09:18:59  <indutny>I suspect that they're just setting executable bit for all
09:19:06  <indutny>which is quite odd, actually
09:19:26  <indutny>yeah
09:19:32  <indutny>they just don't care much about it
09:19:41  <bnoordhuis>i'm pretty sure they do :)
09:19:45  <indutny>though, its not that important
09:19:48  <bnoordhuis>the other spaces don't have +x set
09:19:54  <indutny>huh?
09:20:00  <bnoordhuis>well, except the code space of course
09:20:19  <indutny>em...
09:20:21  <indutny>are you sure?
09:20:31  <indutny>I see in spaces.cc that they're allocating only executable memory
09:21:23  <bnoordhuis>look at heap.cc :)
09:21:42  <bnoordhuis>or run `pmap $(pidof node)`
09:22:17  <indutny>yeah, I see it now
09:22:18  <indutny>gosh
09:22:21  <indutny>oh, pmap
09:22:23  <indutny>nice :)
09:22:25  <indutny>didn't know about it
09:22:30  <indutny>ah
09:22:31  <bnoordhuis>now you do
09:22:32  <indutny>I don't have one
09:22:39  <bnoordhuis>and as gi joe always said, knowing is half the battle
09:22:53  <bnoordhuis>GEE! AAI! JOE!
09:22:53  <LOUDBOT>NOT EVEN SCIENCE CAN HELP US NOW
09:23:08  <bnoordhuis>^ very apropos
09:23:19  <bnoordhuis>oh, i don't know if pmap exists on os x
09:23:26  <bnoordhuis>linux and solaris have it though
09:23:26  <indutny>ok, I've vmmap
09:39:44  <MI6>nodejs-v0.10-windows: #172 UNSTABLE windows-ia32 (8/597) windows-x64 (8/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/172/
09:51:18  * leonvvjoined
09:57:10  * dominictarrjoined
10:02:52  <MI6>joyent/node: Ben Noordhuis master * bc28acd : buffer: fix regression in Buffer(buf) constructor - http://git.io/mOrrLA
10:11:10  * kazuponquit (Remote host closed the connection)
10:12:13  <MI6>nodejs-master: #468 UNSTABLE smartos-x64 (8/636) smartos-ia32 (3/636) http://jenkins.nodejs.org/job/nodejs-master/468/
10:12:38  <ik>GOOD  MORNING  FRIENDS
10:13:52  * bajtosquit (Quit: bajtos)
10:14:09  <bnoordhuis>'morning', he says
10:14:44  <ik>yea
10:15:00  <ik>you wanna fight about it???
10:15:18  <bnoordhuis>i don't know
10:15:24  <bnoordhuis>how skilled are you at martial arts?
10:15:41  <bnoordhuis>also, length and weight info would be appreciated
10:40:27  * kazuponjoined
10:40:47  * leonvvquit (Remote host closed the connection)
10:47:21  * indexzeroquit (Quit: indexzero)
11:13:19  <MI6>nodejs-master-windows: #262 UNSTABLE windows-x64 (18/636) windows-ia32 (19/636) http://jenkins.nodejs.org/job/nodejs-master-windows/262/
11:24:20  * abraxasquit (Remote host closed the connection)
11:29:08  * kazuponquit (Remote host closed the connection)
11:30:57  * stagasjoined
11:41:54  * hzquit (Ping timeout: 276 seconds)
11:55:08  * rendarquit (Ping timeout: 245 seconds)
12:31:49  <MI6>joyent/node: Ben Noordhuis master * 2891790 : vm: remove unnecessary Persistent<FunctionTemplate> - http://git.io/RKj-Tw
12:41:01  <MI6>nodejs-master: #469 UNSTABLE smartos-x64 (9/636) smartos-ia32 (3/636) linux-ia32 (1/636) http://jenkins.nodejs.org/job/nodejs-master/469/
12:56:56  * jmar777joined
13:04:11  <MI6>nodejs-master-windows: #263 UNSTABLE windows-x64 (17/636) windows-ia32 (17/636) http://jenkins.nodejs.org/job/nodejs-master-windows/263/
13:12:53  * pachetjoined
13:27:49  * AvianFlujoined
13:35:13  * hzjoined
13:44:21  * bajtosjoined
13:49:34  * AvianFluquit (Remote host closed the connection)
13:56:59  * c4milojoined
14:00:02  * kevinswiberjoined
14:03:24  * `3rdEdenchanged nick to `3E|IS|SILENT
14:11:37  <MI6>joyent/node: Ben Noordhuis master * 48976d2 : vm: fix Persistent<Context> leak - http://git.io/dtOxBA
14:12:34  <bnoordhuis>https://github.com/joyent/node/issues/6115 :(
14:14:12  <indutny>oh
14:14:14  <indutny>sadface
14:16:56  * hzquit (Disconnected by services)
14:17:00  * hzjoined
14:20:47  <MI6>nodejs-master: #470 UNSTABLE smartos-x64 (8/636) smartos-ia32 (1/636) http://jenkins.nodejs.org/job/nodejs-master/470/
14:20:50  * `3E|IS|SILENTchanged nick to `3rdEden
14:24:10  <bnoordhuis>the gc only collects ~10 ContextifyScript instances and zero ContextifyContext instances
14:24:19  <bnoordhuis>i think it's fair to say that ain't right
14:30:34  * c4miloquit (Remote host closed the connection)
14:35:34  <Domenic_>grr
14:36:30  <Domenic_>ContextifyContext was supposed to be GCed when the sandbox was
14:36:39  <Domenic_>maybe that didn't get set up right though, the ObjectWrap stuff was kind of confusing.
14:38:24  * c4milojoined
14:39:31  * rendarjoined
14:42:42  * bradleymeckjoined
14:43:10  <bnoordhuis>Domenic_: i think it's making some strategically placed MakeWeak() calls
14:43:16  <bnoordhuis>*missing, not making
14:44:37  * paulfryzeljoined
14:47:02  <MI6>nodejs-master-windows: #264 UNSTABLE windows-x64 (18/636) windows-ia32 (19/636) http://jenkins.nodejs.org/job/nodejs-master-windows/264/
14:49:14  <mordy__>hrm, so stuff is coming together quite nicely now
14:51:19  * AvianFlujoined
14:51:58  * kevinswiberquit (Remote host closed the connection)
14:52:25  * kazuponjoined
14:55:39  * kevinswiberjoined
14:55:50  <bnoordhuis>okay, apparently MakeWeak() is not the issue
14:57:13  * kazuponquit (Read error: Connection reset by peer)
15:01:29  <Domenic_>i thought ObjectWrap was supposed to obviate me of the need to do manual MakeWeak-ing.
15:02:16  <bnoordhuis>yeah, it does
15:02:44  <Domenic_>maybe https://github.com/joyent/node/blob/master/src/node_contextify.cc#L148 should be wrapping sandbox instead of args.This()?
15:04:13  <bnoordhuis>ah... sandbox->SetHiddenValue(hidden_name, contextify_context_object);
15:04:27  <bnoordhuis>that seems like it would prevent the object from ever getting collected
15:04:31  <Domenic_>ah :(
15:05:18  <Domenic_>i think I ended up doing the same thing two different ways, one with SetHiddenValue and one with the original ObjectWrap mechanism
15:05:44  <Domenic_>(recall that originally ContextifyContext stood on its own, derived from sandbox instead of hidden inside of it.)
15:05:47  <bnoordhuis>right
15:06:21  <bnoordhuis>when i comment out that call to SetHiddenValue(), i see ContextifyContext instances getting collected all the time
15:06:28  <bnoordhuis>so seems that's it
15:06:32  <Domenic_>ok cool
15:06:41  <bnoordhuis>now how to best fix it
15:06:53  <Domenic_>what is the correct pattern for hiding C++ objects on JS objects but doing the GC right?
15:07:06  <Domenic_>i imagine by manually combining MakeWeak + SetHiddenValue, and removing ObjectWrap, it should be doable.
15:07:17  <Domenic_>But I also imagine that ObjectWrap is meant to do that for me, somehow.
15:07:20  <bnoordhuis>yeah, or use two internal fields instead of one
15:07:41  <Domenic_>OK I think I have an idea what's going on
15:07:55  <Domenic_>It's hiding the C++ ContextifyContext on the JS ContextifyContext using ObjectWrap
15:08:04  <Domenic_>then hiding the JS ContextifyContext on the sandbox using SetHiddenValue
15:08:17  <Domenic_>See e.g. https://github.com/joyent/node/blob/master/src/node_contextify.cc#L178-L179
15:08:33  <Domenic_>this seems entirely unnecessary, i should just hide the C++ ContextifyContext on the sandbox.
15:08:40  <Domenic_>using ObjectWrap presumably.
15:08:50  <pfox__>so ... id like to learn about libuv's treatment of the st_mode field in uv_stat_t and portability..
15:09:10  <pfox__>im looking at the windows src right now and i see its not using fstat in the actualy impl
15:09:46  <pfox__>where are the _S_* bitmasks defined at that its |= onto st_mode ?
15:10:06  <pfox__>having no luck finding
15:10:37  <pfox__>(this is because im trying to establish some context for what the masks are on each platform .. )
15:11:05  <bnoordhuis>pfox__: those bitmasks from the windows system headers
15:11:35  <bnoordhuis>you probably have to include <sys/stat.h> and <io.h>
15:12:32  <pfox__>ah, ok. thanks.
15:13:27  <bnoordhuis>*are from. god, i need to learn to type
15:14:15  <Domenic_>bnoordhuis: I can give such a solution a try tonight
15:14:22  <Domenic_>I will comment on the bug in the meantime.
15:14:56  <mordy__>ahh windows
15:15:16  <mordy__>"we'll make our constants *look* similar to POSIX, but we'll still break your builds"
15:15:38  <mordy__>oh, but it's "ISO-Conformant"
15:15:58  * kazuponjoined
15:17:02  <mordy__>hrm, on that note: is there any chance to expose the (1) platform-specific socket object; and (2) the platform-specific error code?
15:17:20  <mordy__>i know they're both inside the structures, but they don't seem to be there for public consumption
15:17:42  <MI6>nodejs-master: #471 UNSTABLE smartos-x64 (8/636) smartos-ia32 (3/636) http://jenkins.nodejs.org/job/nodejs-master/471/
15:19:10  <bnoordhuis>mordy__: unlikely. if you start fooling around with the fd / HANDLE, you'll probably confuse libuv something fierce
15:20:20  <mordy__>bnoordhuis: hrm, that's entirely understood. but there might be some useful platform-specific (informative) APIs which aren't available via UV
15:20:38  <mordy__>for example, both linux and windows have little getsockopt APIs that return "extended" information about the buffer
15:20:42  * bajtosquit (Quit: bajtos)
15:20:44  <mordy__>err.. tcp stater
15:21:24  <bnoordhuis>well, maybe - you'd have to convince piscisaureus too though
15:21:55  <bnoordhuis>what kind of getsockopt data would you want to retrieve?
15:23:39  <bnoordhuis>Domenic_: i confess i don't fully understand why v8 doesn't manage to collect the objects when SetHiddenValue() is used
15:24:32  <bnoordhuis>or Set() - it's not SetHiddenValue() specific
15:25:22  * kazupon_joined
15:26:08  <mordy__>bnoordhuis: linux has TCP_INFO for example -- but there's also simpler stuff like getsockname. right now we have to have different branches for these informative functions depending on whether we're using "real" sockets or "UV" sockets
15:26:25  <mordy__>(though yes, there's uv_tcp_getsockname)
15:26:33  <bnoordhuis>i was about to point that out :)
15:26:38  <Domenic_>bnoordhuis: yeah, you'd kind of assume it would be just like in JS.
15:26:45  * kazuponquit (Read error: Connection reset by peer)
15:27:12  <mordy__>another usage case would be logging
15:27:44  <mordy__>if you were using something like lsof, strace, etc to see what was happening to your sockets it woudl be helpful to print out the socket id as the OS understands it
15:28:00  <bnoordhuis>mordy__: well, you could use handle->io_watcher.fd in a pinch
15:28:12  <isaacs>hey, this seems like a mistake, no? statbuf->st_ctime = FILETIME_TO_TIME_T(info.ftCreationTime);
15:28:15  <bnoordhuis>not portable or guaranteed stable of course but it's there
15:28:20  <isaacs>ctime is not "creation time", after all
15:28:25  <isaacs>it's "change time"
15:28:52  <isaacs>and, for bonus fun, on windows, if you delete a file and recreate it within 15 seconds, it doesn't update the creation time
15:28:58  <bnoordhuis>isaacs: probably. i think bert mentioned there's a reason for that but i forgot what
15:29:28  <isaacs>it seems like it'd be better to just use atime or mtime instead.
15:29:32  <mordy__>bnoordhuis: then there's the notorious SO_LINGER/SO_REUSEADDR :)
15:30:00  * kazupon_quit (Read error: Connection reset by peer)
15:30:35  <bnoordhuis>mordy__: libuv sets SO_REUSEADDR. SO_LINGER is almost always the wrong choice
15:31:23  * bradleymeckquit (Quit: bradleymeck)
15:31:25  <bnoordhuis>let me reword that as "i've never seen code where SO_LINGER was used for the right reasons"
15:33:55  * bradleymeckjoined
15:36:25  * kazuponjoined
15:38:56  * piscisaureus_joined
15:39:01  <piscisaureus_>notes
15:39:07  <piscisaureus_>ircretary: notes
15:39:14  <bnoordhuis>mi mi mi
15:39:21  <bnoordhuis>oh, that kind of notes
15:40:10  <mordy__>SO_LINGER is a tricky one
15:41:34  <mordy__>but it's normally choosing between "i don't care if i get stray packets" and "oh crap my server has five million open sockets in TIME_WAIT"
15:42:02  <mordy__>especially useful in unstable/slow peers
15:42:05  <bnoordhuis>^ that's the wrong reason :)
15:42:23  <bnoordhuis>if you had said CLOSE_WAIT2, i might have grudgingly agreed
15:43:19  <mordy__>i can't say i've seen things in CLOSE_WAIT2
15:43:24  <bnoordhuis>right
15:44:01  <bnoordhuis>TIME_WAIT is when the connection has terminated and the operating system keeps the port out of circulation for a while to avoid straggler packets messing up things
15:44:19  <mordy__>and close_wait is just code not calling code
15:44:21  <mordy__>close
15:44:28  <mordy__>when it's supposed to
15:44:30  <bnoordhuis>CLOSE_WAIT2 is where the connection has pretty much terminated but the operating system is still waiting on the final FIN
15:44:35  <bnoordhuis>exactly
15:44:53  <bnoordhuis>on most operating systems, connections can get stuck in CLOSE_WAIT2 indefinitely if you're not careful
15:45:18  <bnoordhuis>you could argue it's up to the operating system or the system administrator to take care of that rather than the program
15:45:37  <bnoordhuis>but that's a scenario where you might conceivably use SO_LINGER
15:46:47  <mordy__>TIME_WAIT might not wait indefinitely, but it's still a good chunk of time
15:47:24  <bnoordhuis>two minutes, usually
15:47:41  <bnoordhuis>on most platforms it's configurable too
15:47:58  <mordy__>yeah, and again you could argue it's an administrative task
15:48:10  <bnoordhuis>indeed :)
15:49:52  <mordy__>at least from my perspective though, when shipping something as a "Standalone appliance" kind of thing, it's best that things be done in code as much as possible.. i had to use this a few years ago where i had this server that crashed every now and then and made and accepted tons and tons of connections
15:50:35  <mordy__>this was at a different job.. "sure, run this server on some aging VM that's also running 500 perl instances"
15:51:54  <bnoordhuis>what would you do instead?
15:52:22  <bnoordhuis>disabling or lowering tcp linger can leave you vulnerable to confused deputy style attacks
15:52:45  <bnoordhuis>though that's a minor issue, reaaly
15:52:47  <bnoordhuis>*really
15:53:13  <bnoordhuis>what's more insidious is that you'll get bug reports from users complaining that their connections sometimes suddenly drop for no apparent reason
15:54:05  * kevinswiberquit (Remote host closed the connection)
15:55:19  <mordy__>that was happening 10% of the time anyway :) -- it was a proxy
15:55:39  <bnoordhuis>heh :)
15:56:33  <mordy__>it was pretty nifty. it also did bi-directional http/1.1 pipelining
16:09:30  * TooTallNatejoined
16:10:14  * bajtosjoined
16:11:53  * st_lukequit (Remote host closed the connection)
16:12:01  * groundwaterjoined
16:21:39  * paulfryzelquit (Remote host closed the connection)
16:26:11  * dapjoined
16:35:45  <MI6>joyent/libuv: Bert Belder master * 66ae0ff : process: make the 'status' parameter for exit_cb an int64_t (+1 more commits) - http://git.io/UthLhw
16:36:12  * `3rdEdenchanged nick to `3E|DINNER
16:40:10  <piscisaureus_>anyone objected to releasing libuv 0.11.9 and upgrading in node?
16:40:14  <piscisaureus_>bnoordhuis isaacs indutny ?
16:40:31  <indutny>no objections
16:40:32  <indutny>also
16:40:36  <indutny>please release v0.10 too :)
16:40:41  <indutny>if tjfontaine has nothing to say
16:40:54  <piscisaureus_>libuv v0.10 - tell me when it's time
16:41:09  <tjfontaine>heh, I have nothing particular to say, just that uv_async_send should probably assert the same on unix :P
16:41:24  <piscisaureus_>oh yeah I had to look at that hmm
16:41:28  <piscisaureus_>well it can wait
16:41:32  <piscisaureus_>indutny: ok, going to release both
16:41:35  * amartensjoined
16:41:42  <indutny>piscisaureus_: great :)
16:41:51  <indutny>I'll update node v0.10 after it
16:41:56  <MI6>libuv-master: #183 UNSTABLE smartos (9/192) windows (3/193) http://jenkins.nodejs.org/job/libuv-master/183/
16:42:09  <MI6>libuv-master-gyp: #123 UNSTABLE windows-x64 (3/193) smartos-ia32 (2/192) smartos-x64 (2/192) windows-ia32 (3/193) http://jenkins.nodejs.org/job/libuv-master-gyp/123/
16:42:13  * bnoordhuisquit (Ping timeout: 248 seconds)
16:42:14  <indutny>meanwhile
16:42:16  <indutny>lets play minecraft
16:42:20  <indutny>m0.indutny.com
16:47:41  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:49:00  <MI6>libuv-node-integration: #168 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/168/
16:50:27  * dominictarrquit (Quit: dominictarr)
16:50:57  <trevnorris>morning
16:51:01  <trevnorris>isaacs: ping
16:51:54  <MI6>joyent/libuv: piscisaureus created tag v0.11.9 - http://git.io/yXiOsg
16:51:57  <MI6>joyent/libuv: Bert Belder master * e47e6b2 : Now working on v0.11.10 (+1 more commits) - http://git.io/eeItfA
16:57:33  <MI6>joyent/libuv: piscisaureus created tag v0.10.15 - http://git.io/tXSrBg
16:57:37  <MI6>joyent/libuv: Bert Belder v0.10 * c8b6895 : Now working on v0.10.16 (+1 more commits) - http://git.io/cwlPag
16:57:54  <piscisaureus_>indutny: ok, released :)
16:58:13  <MI6>libuv-master-gyp: #124 UNSTABLE windows-x64 (3/193) smartos-ia32 (2/192) smartos-x64 (2/192) windows-ia32 (3/193) http://jenkins.nodejs.org/job/libuv-master-gyp/124/
17:01:29  <MI6>libuv-master: #184 UNSTABLE smartos (9/192) windows (3/193) http://jenkins.nodejs.org/job/libuv-master/184/
17:01:43  * TooTallNatejoined
17:02:59  <MI6>joyent/node: Bert Belder v0.10 * 5508236 : uv: update to v0.10.15 - http://git.io/bIOj5w
17:04:46  <MI6>joyent/node: Bert Belder master * 6fa8398 : uv: upgrade to v0.11.9 - http://git.io/_IfSfg
17:04:59  <indutny>piscisaureus_: thanks
17:05:13  <piscisaureus_>now I need to accomodate for an api change in node master
17:05:21  <piscisaureus_>it will fail many tests now
17:05:47  <MI6>libuv-v0.10: #109 UNSTABLE smartos (3/187) osx (2/188) linux (1/187) windows (4/188) http://jenkins.nodejs.org/job/libuv-v0.10/109/
17:07:03  <MI6>libuv-v0.10-gyp: #73 UNSTABLE windows-x64 (4/188) windows-ia32 (6/188) smartos-x64 (2/187) linux-x64 (1/187) linux-ia32 (1/187) smartos-ia32 (2/187) osx-x64 (1/188) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/73/
17:07:25  <TooTallNate>tjfontaine: should i open a ticket for the XP installation issues i was having?
17:07:27  <ryah>hi
17:07:43  * kevinswiberjoined
17:07:53  <tjfontaine>TooTallNate: yes, I think so
17:08:22  <ryah>82 people in #libuv wow
17:08:36  <ryah>and 1095 in #node.js
17:08:39  <ryah>:)
17:09:14  * kevinswiberquit (Remote host closed the connection)
17:09:15  <piscisaureus_>hello
17:09:51  <MI6>joyent/node: Bert Belder master * 7555227 : process_wrap: update after libuv api change - http://git.io/oS83Zw
17:12:22  * kevinswiberjoined
17:14:52  <MI6>libuv-review: #44 FAILURE smartos-ia32 (3/192) windows-ia32 (4/193) windows-x64 (3/193) smartos-x64 (6/192) http://jenkins.nodejs.org/job/libuv-review/44/
17:15:20  * defunctzombie_zzchanged nick to defunctzombie
17:15:49  <tjfontaine>I hate you so much jenkins
17:16:19  <piscisaureus_>how hard would it be to build jenkins in node and angularjs
17:16:21  <piscisaureus_>:)
17:17:18  <tjfontaine>not very, I have the client build stuff mostly done, I just need to do the dispatch
17:17:43  <tjfontaine>that is to say, I would let someone else write a pretty frontend
17:18:27  <MI6>libuv-node-integration: #169 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/169/
17:18:47  <tjfontaine>that was before the api fix went in
17:18:50  * julianduquequit (Quit: leaving)
17:18:57  <MI6>nodejs-master: #472 FAILURE http://jenkins.nodejs.org/job/nodejs-master/472/
17:20:22  <MI6>joyent/node: Trevor Norris master * 467e00e : domain: move error handling directly into instance - http://git.io/ZTTnPw
17:20:51  * piscisaureus_quit (Ping timeout: 260 seconds)
17:25:57  <MI6>nodejs-v0.10: #1445 UNSTABLE linux-x64 (5/597) osx-ia32 (2/597) smartos-x64 (6/597) linux-ia32 (2/597) smartos-ia32 (3/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1445/
17:29:03  <groundwater>tjfontaine: i will donate to your node-kins project
17:31:29  * st_lukejoined
17:33:06  <MI6>nodejs-v0.10-windows: #173 UNSTABLE windows-ia32 (8/597) windows-x64 (8/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/173/
17:33:38  * dominictarrjoined
17:39:40  * hzquit
17:40:13  * hzjoined
17:42:11  <mordy__>hrm.. just how much overhead to these ->IsFoo v8 methods have?
17:43:17  <mordy__>hrm i see in the big ocean that is v8.h
17:44:10  <MI6>nodejs-master: #473 UNSTABLE smartos-x64 (9/636) smartos-ia32 (135/636) osx-ia32 (1/636) linux-x64 (2/636) http://jenkins.nodejs.org/job/nodejs-master/473/
17:44:23  <tjfontaine>mordy__: I would advocate you write it the way you want, and then actually benchmark
17:44:26  <MI6>libuv-node-integration: #170 UNSTABLE smartos-x64 (19/597) http://jenkins.nodejs.org/job/libuv-node-integration/170/
17:46:14  <MI6>nodejs-master-windows: #265 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/265/
17:46:20  <mordy__>i'm just curious. i think my real issue was trying to write a template function that checks to see if a value is of a given type, and if it isn't whether it's null/false/undefined
17:46:38  <mordy__>so T::Cast doesn't really check anything
17:47:35  <mordy__>and there's no GetTypeCode or similar (unless one uses v8::internals)
17:47:48  <mordy__>trying to remove some boilerplate
17:48:29  * bnoordhuisjoined
17:49:51  <MI6>libuv-review: #45 UNSTABLE smartos-ia32 (4/187) windows-ia32 (3/188) windows-x64 (3/188) smartos-x64 (5/187) linux-x64 (1/187) http://jenkins.nodejs.org/job/libuv-review/45/
17:52:31  * piscisaureus_joined
17:53:01  * bnoordhuisquit (Ping timeout: 246 seconds)
17:53:19  <MI6>nodejs-master: #474 UNSTABLE smartos-x64 (11/636) smartos-ia32 (3/636) osx-ia32 (1/636) http://jenkins.nodejs.org/job/nodejs-master/474/
17:56:39  <mordy__>meh, screw barney strapstrap. i'll use a macro
17:57:12  * indexzerojoined
18:01:07  * c4miloquit (Remote host closed the connection)
18:13:44  * ecrjoined
18:20:02  * brsonjoined
18:20:09  * c4milojoined
18:20:13  * hzquit
18:22:35  <MI6>nodejs-master-windows: #266 UNSTABLE windows-x64 (17/636) windows-ia32 (19/636) http://jenkins.nodejs.org/job/nodejs-master-windows/266/
18:24:25  <MI6>libuv-master: #185 UNSTABLE smartos (10/192) windows (3/193) http://jenkins.nodejs.org/job/libuv-master/185/
18:28:28  * bajtosquit (Quit: bajtos)
18:38:11  <MI6>libuv-node-integration: #171 UNSTABLE smartos-ia32 (2/636) linux-x64 (1/636) smartos-x64 (9/636) http://jenkins.nodejs.org/job/libuv-node-integration/171/
18:40:07  <isaacs>piscisaureus_: no objection
18:40:14  * bradleymeckquit (Quit: bradleymeck)
18:40:21  <isaacs>piscisaureus_: hey, why is ctime "creation time" on windows?
18:40:35  <piscisaureus_>isaacs: because
18:40:59  <piscisaureus_>isaacs: I had almost changed it some day but I had doubts
18:41:21  <piscisaureus_>isaacs: (remember that ctime is *always* creation time on windows, whichever programming language or library you ask)
18:41:46  <piscisaureus_>has been so since DOS 2.0 or something
18:42:18  <piscisaureus_>isaacs: but if you want it changed, open a libuv issue :)
18:42:26  <piscisaureus_>we might be able to do it before 1.0 ships
18:42:47  <piscisaureus_>the patch would be a 2-liner
18:43:30  * kevinswiberquit (Remote host closed the connection)
18:43:48  <piscisaureus_>we could also do a poll
18:45:21  <piscisaureus_>isaacs: I'll run a twitter poll on a boring day (monday morning?)
18:45:24  <piscisaureus_>that'd be fun
18:47:30  * `3E|DINNERchanged nick to `3rdEden
18:49:43  * piscisaureus_quit (Ping timeout: 245 seconds)
18:55:45  * kazuponquit (Remote host closed the connection)
18:57:52  <MI6>nodejs-master-windows: #267 UNSTABLE windows-x64 (17/636) windows-ia32 (18/636) http://jenkins.nodejs.org/job/nodejs-master-windows/267/
19:01:26  * ecrquit (Ping timeout: 264 seconds)
19:01:47  <isaacs>ircretary: tell piscisaureus_ Yeah, "ctime" on windows means "creation time", but "ctime" on unix doesn't mean that. so what happens is that modules I write that rely on "changed time" end up breaking on Windows. i'm sure i'm not the first to encounter this.
19:01:47  <ircretary>isaacs: I'll be sure to tell piscisaureus_
19:02:31  <isaacs>ircretary: tell piscisaureus_ Well, I might be the first to notice it, but i'm willing to bet that there are other modules out there affected by the same bug, and just dno't realize it yet.
19:02:32  <ircretary>isaacs: I'll be sure to tell piscisaureus_
19:03:51  * paulfryzeljoined
19:04:31  * EhevuTovjoined
19:05:14  * EhevuTovquit (Read error: Connection reset by peer)
19:05:29  * EhevuTovjoined
19:05:55  * mikealjoined
19:24:01  <isaacs>Well... hm.
19:24:11  <isaacs>It seems like windows might not even HAVE st_ctime or anything like it.
19:25:35  * abraxasjoined
19:29:55  * abraxasquit (Ping timeout: 240 seconds)
19:45:05  * bnoordhuisjoined
19:49:08  * c4miloquit (Remote host closed the connection)
19:56:33  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:02:48  * c4milojoined
20:06:41  * bnoordhuisquit (Ping timeout: 245 seconds)
20:08:13  * dominictarrquit (Quit: dominictarr)
20:09:13  * st_lukequit (Remote host closed the connection)
20:10:51  * dominictarrjoined
20:10:58  * st_lukejoined
20:25:41  * julianduquejoined
20:30:20  * st_lukequit (Remote host closed the connection)
20:31:29  * TooTallNatejoined
20:34:21  * st_lukejoined
20:38:35  * bradleymeckjoined
20:40:10  <trevnorris>othiym23: ping
20:47:33  * ecrjoined
20:53:24  <othiym23>trevnorris: pong
20:54:24  <trevnorris>othiym23: just want to get something straight, I assume you want to be alerted when the async callback is queue, and not actually when it's called, so you can capture the stack?
20:54:39  <trevnorris>*queued
20:59:38  * AvianFluquit (Remote host closed the connection)
21:03:55  <othiym23>correct, although it's the context and not the stack I'm concerned about
21:05:22  <trevnorris>well, the first part is more my concern :)
21:06:45  * julianduquequit (Ping timeout: 276 seconds)
21:07:00  <othiym23>if there were a mechanism that could communicate between the queueing of the callback and the invocation of the callback that didn't involve the creation of a closure, that would be awesome
21:07:17  <trevnorris>othiym23: ok, so it's going to be like this, an object will be passed to the async listener. in there will { callback: <function>, domain: <context> }, either which you can override with your own.
21:08:05  * julianduquejoined
21:08:44  <othiym23>I don't want to touch the domain, because I don't want to alter how the domain behaves
21:09:05  <othiym23>so right now my main option is wrap callback in a closure so it can do its thing before the actual callback gets executed
21:09:59  <trevnorris>othiym23: i'm going to pass it anyways, and you can choose not to touch it. :)
21:10:25  <trevnorris>honestly I hate process.domain, and it is technically possible to get rid of completely, but eh. legacy.
21:10:29  <othiym23>just sayin'
21:10:42  <othiym23>why do you hate it?
21:11:01  <othiym23>it's a genuinely useful point of unobtrusive extension for node
21:11:24  <trevnorris>it's global. using this technique I could capture and keep context within the module itself w/o needing to screw w/ some object on process.domain.
21:13:23  * bnoordhuisjoined
21:15:11  * txdvjoined
21:16:53  <trevnorris>othiym23: well, the closure technique comes at zero cost at core. going to start there and hopefully can figure out a better way en route.
21:17:31  <othiym23>kk
21:17:42  * bnoordhuisquit (Ping timeout: 256 seconds)
21:18:06  <othiym23>the nice thign about it being as a global is that user code can check the global and do something with it if it's there, and not alter anything's behavior if it's not
21:18:24  <othiym23>if require('domain') didn't have side effects, I'd be fine with telling everyone to use domain.active instead
21:19:45  <trevnorris>what side effects you talking about?
21:20:32  <othiym23>under 0.10, requiring domain is what triggers the side effects in EventEmitter, isn't it?
21:20:49  <trevnorris>yup. that'll all be gone w/ this patch
21:21:03  <trevnorris>core will operate just the same w or w/o require('domain')
21:21:15  * EhevuTovquit (Quit: This computer has gone to sleep)
21:21:53  <othiym23>so really the main issue is that we've had process.domain in 0.8 and 0.10
21:22:16  <trevnorris>yeah
21:22:33  <othiym23>nobody has complained at me yet about the New Relic agent breaking under 0.6, but that probably says more about how little the agent was doing before, because I know there are still people running 0.6, and *lots* of people running 0.8
21:22:57  <trevnorris>yeah. the patch won't land w/o backwards compatibility.
21:23:09  * c4miloquit (Remote host closed the connection)
21:23:17  * EhevuTovjoined
21:23:35  <trevnorris>othiym23: did you see https://github.com/joyent/node/pull/6096
21:24:53  * trevnorrispart ("Leaving")
21:24:58  * trevnorrisjoined
21:26:07  <othiym23>yeah, LGTM
21:28:28  <othiym23>one step closer to the glorious future of no.js
21:28:43  <trevnorris>what?
21:29:35  <tjfontaine>heh
21:29:42  <othiym23>pulling everything out of core into userland modules
21:30:19  <trevnorris>everything modular, everything with an api. hm. I like it.
21:32:20  * indexzeroquit (Quit: indexzero)
21:55:32  * rendarquit
22:06:51  <trevnorris>isaacs: ping
22:06:57  <isaacs>pong
22:07:15  <isaacs>othiym23: no one is using 0.6
22:07:31  <isaacs>othiym23: at least, no one wh's using new relic.
22:07:42  <isaacs>othiym23: (can you run new relic on Azure?)
22:07:48  <tjfontaine>heh
22:07:55  <trevnorris>isaacs: was looking at performance output and it seems the way modules work doesn't allow for inline of functions that're cross domain
22:08:01  <trevnorris>isaacs: because they require a context switch
22:08:10  <trevnorris>so all the util.is* aren't inlinable
22:08:12  <isaacs>trevnorris: you mean, each module is in a separate function context?
22:08:13  * bradleymeckquit (Quit: bradleymeck)
22:08:17  <isaacs>oh, that's kinda crappy
22:08:17  <trevnorris>isaacs: yeah
22:08:47  <isaacs>Let's just turn all our internal functions into macros.
22:08:54  <isaacs>INLINE THIS, V8!!
22:08:55  <LOUDBOT>HAPPY BIRTHDAY GRANDMA
22:08:59  <trevnorris>hah
22:09:56  * AvianFlujoined
22:22:10  <trevnorris>isaacs: just double checking, you serious about that?
22:22:39  <tjfontaine>he better not be :)
22:22:53  <trevnorris>;P
22:23:03  <trevnorris>it's the weekend
22:23:09  <trevnorris>ANYTHING IS POSSIBLE!
22:23:09  <LOUDBOT>GO DRINK A BOTTLE OF POTASSIUM BENZOATE. VOMIT ON YOUR CAT.
22:23:20  <trevnorris>LOUDBOT: yes, even that
22:23:20  <LOUDBOT>trevnorris: WHAT THE FUCK IT'S CALLED HDPARM HOW DID I MISS THAT
22:34:39  * trevnorris&
22:34:40  <LOUDBOT>WHAT DID I JUST SAY?
22:37:29  <indutny>oh
22:37:29  <indutny>https://github.com/gnustep
22:37:34  <indutny>people
22:37:45  <indutny>you should croudfund this http://www.kickstarter.com/projects/203272607/gnustep-project
22:37:47  <indutny>seriously
22:38:22  <tjfontaine>oh man.
22:39:14  * stagasquit (Read error: Connection reset by peer)
22:49:22  <othiym23>isaacs: we have at least 10 applications reporting using 0.6, some of them pretty big and high-throughput beacons
22:49:56  <othiym23>othiym23: and yeah, you can totally run New Relic on Azure -- the Node agent was even working once upon a time, but it's bitrotted a little and I need to spend some time on Windows
22:50:12  <isaacs>othiym23: ok, then, have fun supporting 0.6
22:50:18  <isaacs>othiym23: i'd recommend dropping it.
22:50:31  <isaacs>othiym23: after all, it's no longer supported by Node, or Joyent, or anyone else.
22:50:57  <isaacs>trevnorris: no,i'm not serious about macroifying all our functions.
22:50:59  <othiym23>isaacs: I'm more of a descriptivist than a prescriptivist, but for now I've made clear in the release notes that 0.6 users are on their own, and there may or may not be support for them in the future
22:51:17  <isaacs>trevnorris: it'd be better to bug V8 about giving us a way around that constraing.
22:51:20  <isaacs>*constraint
23:36:14  * st_lukequit (Remote host closed the connection)
23:37:54  * st_lukejoined
23:40:09  * rphillipsquit (Remote host closed the connection)
23:50:00  * rphillipsjoined