00:00:08  * ircretaryjoined
00:00:48  * philipsquit (Read error: Connection reset by peer)
00:01:07  * c4miloquit (Remote host closed the connection)
00:01:38  * philipsjoined
00:03:55  * st_lukejoined
00:07:14  <MI6>libuv-master-gyp: #135 UNSTABLE windows-x64 (3/193) windows-ia32 (3/193) smartos-ia32 (2/192) linux-x64 (2/192) linux-ia32 (2/192) smartos-x64 (3/192) http://jenkins.nodejs.org/job/libuv-master-gyp/135/
00:07:15  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:07:56  * st_lukequit (Ping timeout: 245 seconds)
00:33:53  * TooTallNatejoined
00:35:41  * pachetjoined
00:43:27  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:48:57  * groundwaterjoined
01:03:39  * kazuponjoined
01:21:34  * indexzerojoined
01:28:43  * indexzeroquit (Ping timeout: 264 seconds)
01:44:56  * abraxasjoined
02:11:58  * swajquit (Remote host closed the connection)
02:23:59  * stagasjoined
02:46:35  * pachetquit (Quit: [ +++ ])
02:46:41  * Guest42317quit (Read error: Connection reset by peer)
03:02:38  <pfox__>so how does on get the result of a uv_fs_stat() call in the "older" API w/ uv_statbuf_t . ?
03:03:02  <pfox__>is the ptr field in uv_fs_t pointing at the statbuf out on the heap somewhere?
03:03:06  <pfox__>not seeing any docs...
03:38:34  * kazuponquit (Remote host closed the connection)
03:58:55  * AvianFlujoined
04:08:59  * kazuponjoined
04:17:42  * kazuponquit (Ping timeout: 268 seconds)
04:18:05  * kazuponjoined
05:03:48  * c4milojoined
05:10:42  * c4miloquit (Remote host closed the connection)
05:26:04  * brsonquit (Quit: leaving)
05:46:26  * groundwaterquit (Quit: groundwater)
06:23:28  * Benviejoined
06:27:58  * rendarjoined
06:32:39  * bajtosjoined
06:42:42  * rendarquit (Ping timeout: 264 seconds)
06:43:55  * AvianFluquit (Remote host closed the connection)
06:44:27  * emilsedgh_quit (Changing host)
06:44:27  * emilsedgh_joined
06:47:38  <MI6>nodejs-v0.10-windows: #176 UNSTABLE windows-x64 (9/597) windows-ia32 (9/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/176/
06:53:18  * hzjoined
06:54:53  * defunctzombie_zzchanged nick to defunctzombie
07:10:05  * leonvvjoined
07:59:00  * defunctzombiechanged nick to defunctzombie_zz
08:23:32  * acrichtojoined
08:30:49  * dominictarrjoined
08:53:31  * hzquit (Ping timeout: 260 seconds)
08:55:47  * hzjoined
08:58:11  * julianduquequit (Ping timeout: 260 seconds)
09:07:51  * bajtosquit (Quit: bajtos)
09:08:32  * hzquit (Read error: Connection reset by peer)
09:08:53  * defunctzombie_zzchanged nick to defunctzombie
09:09:37  * hzjoined
09:10:49  * leonvvquit (Remote host closed the connection)
09:11:37  * bajtosjoined
09:18:52  * defunctzombiechanged nick to defunctzombie_zz
09:26:07  * bnoordhuisjoined
09:53:34  * kazuponquit (Remote host closed the connection)
09:54:37  * kazuponjoined
09:55:21  * kazuponquit (Remote host closed the connection)
09:56:26  <indutny>morning
10:35:53  * bajtosquit (Quit: bajtos)
10:46:28  <bnoordhuis>hello fedor
10:47:46  * piscisaureus_joined
10:49:33  <bnoordhuis>ci on smartos seems to progressively get worse
10:49:48  <bnoordhuis>we're up to 12 failures now for no good reason afaict
10:53:04  <bnoordhuis>pfox__: re uv_fs_stat(), req->ptr points to an embedded struct stat
10:53:16  <bnoordhuis>pfox__: with the new api, you can just use req->statbuf directly
10:57:37  <MI6>nodejs-v0.10: #1448 UNSTABLE osx-ia32 (2/597) smartos-ia32 (5/597) osx-x64 (1/597) linux-x64 (3/597) smartos-x64 (8/597) linux-ia32 (3/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1448/
10:58:08  <trevnorris>bnoordhuis: morning
11:00:35  <trevnorris>you too indutny
11:03:39  <bnoordhuis>hey trevor. up early today?
11:06:24  <trevnorris>bnoordhuis: heh, no. just about to hit the sack.
11:06:53  <trevnorris>just got involved in some performance testing and lost track of time.
11:08:06  <trevnorris>setup a tcp server that just delivers valid http headers then closes the socket. runs at ~60k req/sec. using it for some internals testing.
11:08:29  <trevnorris>bnoordhuis: part of what lead me to https://github.com/joyent/node/pull/6124
11:08:48  <bnoordhuis>yes, i saw the email
11:08:53  <trevnorris>all those util.is* methods really pollute the --trace-* output
11:09:02  <trevnorris>so more than anything just wanted to get rid of them.
11:09:58  * kazuponjoined
11:10:00  <bnoordhuis>oh, yeah - i agree heartily
11:10:43  <bnoordhuis>trevnorris: Failing tests -- linux-ia32: 212, osx-ia32: 200, smartos-ia32: 203, linux-x64: 212, osx-x64: 201, smartos-x64: 253
11:11:05  <trevnorris>whoa.
11:11:34  <indutny>woooo
11:11:36  <indutny>what was thet
11:12:00  <bnoordhuis>throw new TypeError('must start with number, buffer, array or string'); <- that
11:12:08  <indutny>haha
11:12:10  <indutny>ook
11:12:38  <trevnorris>strange. must have left some of the undefined api calls in js land.
11:12:58  <bnoordhuis>trevnorris: so what is your conclusion re: util.is*()?
11:13:37  <trevnorris>bnoordhuis: they can't be inlined because of a context change, and they're making my performance tracing fugly. don't like them.
11:14:47  <bnoordhuis>yeah
11:15:03  <bnoordhuis>i don't want to be the "told you so" guy but...
11:15:30  <trevnorris>heh
11:15:38  <trevnorris>there, suck on that Jenkins.
11:16:26  <trevnorris>honestly i'm not using the checks in super hot code paths (e.g. the ticker code changes i'm doing)
11:16:29  <trevnorris>too costly
11:19:33  <trevnorris>alright, it's passing. off to sleep for a few hours. see you two in a bit.
11:19:36  * trevnorris&
11:19:45  <trevnorris>LOUDBOT: bite me. i'm off to bed.
11:21:52  <bnoordhuis>sleep tight trevor
11:24:52  <bnoordhuis>http://coreperf.com/projects/rejit/ <- interesting
11:25:14  <piscisaureus_>Hello, any v8 experts in the room
11:25:16  <piscisaureus_>?
11:25:32  <piscisaureus_>Is a cast of a v8 object with .As<Object>() safe?
11:26:44  <bnoordhuis>piscisaureus_: if it's truly an Object, then yes
11:26:52  <piscisaureus_>sure
11:26:55  <bnoordhuis>if it's not, it'll assert in debug builds
11:26:57  <piscisaureus_>and if it isn't
11:27:00  <piscisaureus_>right
11:28:13  <piscisaureus_>what will happen in release builds? crash?
11:28:41  <bnoordhuis>that's one of the options, yes
11:31:14  <bnoordhuis>okay, groceries time. biab
11:35:09  <piscisaureus_>I wonder what drove Chris Malinchak to write this song
11:35:17  <piscisaureus_>"oh baby, you're my constipation"
11:35:55  * bnoordhuisquit (Ping timeout: 264 seconds)
11:40:55  * kazuponquit (Remote host closed the connection)
12:13:40  * kazuponjoined
12:14:58  * abraxasquit (Remote host closed the connection)
12:31:46  * bnoordhuisjoined
12:32:06  * kazuponquit (Remote host closed the connection)
12:32:22  * icarotjoined
12:40:26  * piscisaureus_quit (Ping timeout: 264 seconds)
13:02:18  * pachetjoined
13:15:55  <MI6>joyent/node: Ben Noordhuis master * 9ac75d1 : src: remove pointless node_os.h header file - http://git.io/IqTgaA
13:31:41  <MI6>nodejs-master: #480 UNSTABLE smartos-x64 (13/636) osx-ia32 (2/636) smartos-ia32 (6/636) http://jenkins.nodejs.org/job/nodejs-master/480/
13:32:27  * jmar777joined
13:35:28  * piscisaureus_joined
13:36:19  <MI6>nodejs-master-windows: #272 UNSTABLE windows-x64 (19/636) windows-ia32 (19/636) http://jenkins.nodejs.org/job/nodejs-master-windows/272/
13:46:39  * c4milojoined
13:46:41  <piscisaureus_>bnoordhuis: FIXED_ONE_BYTE_STRING is annoying. What about we add a separate class that just has a truckload of javascript string symbols?
13:47:16  <piscisaureus_>... which can be shared between all .cc files?
13:47:22  * swajjoined
13:47:58  <piscisaureus_>bnoordhuis: I guess it'd make your context work easier too
13:52:41  <Domenic_>I don't understand why we didn't call it node::as_string or something.
13:56:01  <piscisaureus_>that too
13:56:08  <piscisaureus_>it'd be nice to always cache them though
13:57:56  <piscisaureus_>we could do something like:
13:57:57  <piscisaureus_>struct JSStrings {
13:57:57  <piscisaureus_> Cached<String> type;
13:57:57  <piscisaureus_> Cached<String> bar;
13:57:57  <piscisaureus_> Cached<String> fd;
13:57:57  * bajtosjoined
13:57:57  <piscisaureus_> void Initialize() {
13:57:57  <piscisaureus_> type = Cached<String>::New("type");
13:57:58  <piscisaureus_> ...
13:57:58  <piscisaureus_> }
13:57:59  <piscisaureus_>};
13:57:59  <piscisaureus_>etc
13:58:04  <piscisaureus_>we could even generate the file
13:58:21  <piscisaureus_>or use x-macros
14:16:28  * kenperkinsjoined
14:25:53  <bnoordhuis>Cached<T> is gone in the multi-context branch actually
14:26:09  * c4miloquit (Remote host closed the connection)
14:27:09  <bnoordhuis>and "annoying", well, i don't care - you can call String::NewFromOneByte(isolate, string, sizeof(string) - 1) manually if that makes you feel better
14:28:35  <bnoordhuis>piscisaureus_: as to your 'class with symbols' idea, i suggest you look at the multi-context branch :)
14:29:51  <bnoordhuis>anyway, FIXED_ONE_BYTE_STRING is not going away anytime soon. it has its place
14:31:00  <Domenic_>probably best to just declare `inline Local<String> as_string(const char* s) { return FIXED_ONE_BYTE_STRING(node_isolate, s); }` at the top of the source file where you're feeling the pain.
14:31:28  <bnoordhuis>Domenic_: that doesn't work. FIXED_ONE_BYTE_STRING is for string literals
14:31:56  <piscisaureus_>bnoordhuis: I was thinking along these lines -> https://gist.github.com/piscisaureus/6342035
14:32:08  <Domenic_>bnoordhuis: what about it doesn't work?
14:32:43  <bnoordhuis>Domenic_: because it translates to this -> v8::String::NewFromOneByte(isolate, s, sizeof(s) - 1)
14:33:13  <bnoordhuis>that sizeof(s) == sizeof(const char*), i.e. 4 or 8 bytes
14:33:21  <Domenic_>bnoordhuis: ah, right, so macro instead of function, annoying.
14:34:25  <bnoordhuis>piscisaureus_: you're basically declaring a ton of Persistents there
14:34:33  <piscisaureus_>bnoordhuis: yup - I know
14:34:39  <piscisaureus_>bnoordhuis: but only doing it once, so who cares
14:34:48  <bnoordhuis>i care
14:34:58  <bnoordhuis>i've been working hard to reduce the number of Persistent handles
14:35:00  <Domenic_>if only we had C++ 11... `"MyString"_fobs`. http://en.cppreference.com/w/cpp/language/user_literal
14:35:20  <piscisaureus_>bnoordhuis: doesn't v8 have something more efficient than persistent nowadays?
14:35:31  * kevinswiberjoined
14:35:35  <bnoordhuis>yes, and that's what i'm using in the multi-context branch
14:35:44  <bnoordhuis>(eternal handles)
14:35:55  <bnoordhuis>still, that only makes sense for symbols that are used often
14:38:56  * c4milojoined
14:40:05  <piscisaureus_>bnoordhuis: you're secretly doing isolates
14:40:15  <piscisaureus_>bnoordhuis: but yeah it basically boils down to the same
14:40:16  <piscisaureus_>:)
14:41:52  <bnoordhuis>i'm working today on eradicating node_isolate so yeah :)
14:44:41  <piscisaureus_>good!
14:45:19  * AvianFlujoined
14:45:47  <piscisaureus_>bnoordhuis: DTLS -> very meh!
14:46:04  <bnoordhuis>me too but i'm also not dead set against it
14:46:08  <piscisaureus_>bnoordhuis: there's probably not even a handful of people that cares
14:46:22  <bnoordhuis>not currently
14:46:31  <bnoordhuis>but i expect that to change in a year or two
14:46:36  <piscisaureus_>bnoordhuis: should I repeat your mantra, which is "that's what modules are for"
14:46:37  <piscisaureus_>sure
14:46:49  <piscisaureus_>let's add it in a year or two minus 2 weeks
14:47:02  <bnoordhuis>modules, yeah
14:47:09  <bnoordhuis>that's what i'd normally suggest
14:47:25  <bnoordhuis>the issue is that you cannot really write an add-on for node that uses openssl
14:47:35  <piscisaureus_>let migounette fix that :)
14:47:40  <bnoordhuis>heh
14:47:56  <piscisaureus_>it's not hard. The hard part is to make it maintainable
14:48:09  <piscisaureus_>I think on most OS-es you can just re-export the entire library
14:48:13  <piscisaureus_>windows is the only problem
14:49:47  <bnoordhuis>and gyp
14:50:19  <piscisaureus_>we'd need some sort of script that generates a file like this:
14:50:19  <piscisaureus_>__declspec(dllexport) rsa_foobar_128_init(char* cat, int dog);
14:52:41  * bradleymeckjoined
14:53:13  <piscisaureus_>bnoordhuis: btw I don't think isaacs is going to be happy to put dtls on the roadmap in the short term
14:53:43  * paulfryzeljoined
14:53:59  <bnoordhuis>piscisaureus_: that's why i said v0.14 or v1.0 if ever
14:54:13  <piscisaureus_>bnoordhuis: well - that is the short-term roadmap :)
14:54:16  <mmalecki>hey guys
14:54:18  <bnoordhuis>i'd be happy with pushing it into a module though
14:54:28  <bnoordhuis>the thing is, that needs to be made possible first :)
14:54:28  <mmalecki>what do you think would be a good uv API for SO_REUSEPORT?
14:55:02  * pachetquit (Ping timeout: 240 seconds)
14:55:12  <bnoordhuis>mmalecki: fd = socket(AF_INET, SOCK_DGRAM, 0); setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &on, sizeof(on)); uv_udp_open(handle, fd);
14:55:17  <mmalecki>I came up with https://github.com/mmalecki/libuv/commit/a8cab4a089a63ac3873586fa61860a61bc9786b6 but it requires changing
14:55:23  <mmalecki>*changing API
14:55:31  <mmalecki>bnoordhuis: heh, okay
14:55:41  <mmalecki>bnoordhuis: no interest in adding a uv function?
14:56:10  <bnoordhuis>mmalecki: well... the thing is that it only works on linux >= 3.9
14:56:19  <bnoordhuis>at least, i'm assuming you want the linux behavior of sharing the port
14:56:36  <bnoordhuis>not the BSD version that is basically SO_REUSEADDR
14:56:38  <mmalecki>bnoordhuis: yes
14:56:42  <piscisaureus_>int val = 1;
14:56:42  <piscisaureus_>setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &val, sizeof val);
14:56:43  * kevinswiberquit (Remote host closed the connection)
14:56:49  <bnoordhuis>right
14:56:51  <piscisaureus_>^-- mmalecki good api
14:57:02  <mmalecki>piscisaureus_: heh
14:57:10  <bnoordhuis>piscisaureus_: already beat you to it
14:57:43  <bnoordhuis>mmalecki: there's no reasonabl way to simulate the linux 3.9 behavior on older kernels or other platforms
14:57:46  <piscisaureus_>bnoordhuis: dang. I hear you are always that fast.
14:57:52  * jmar777quit (Read error: Connection reset by peer)
14:58:18  * jmar777joined
15:09:19  * kevinswiberjoined
15:11:55  * pachetjoined
15:12:18  * pachetchanged nick to Guest25414
15:12:55  * Guest25414quit (Read error: Connection reset by peer)
15:14:13  * pachetjoined
15:15:19  * TooTallNatejoined
15:19:38  * TooTallNatequit (Ping timeout: 240 seconds)
15:23:19  * stagasquit (Ping timeout: 264 seconds)
15:23:34  <MI6>nodejs-master: #481 UNSTABLE smartos-x64 (11/636) osx-ia32 (4/636) smartos-ia32 (10/636) osx-x64 (1/636) http://jenkins.nodejs.org/job/nodejs-master/481/
15:27:30  * stagasjoined
15:28:56  * bajtosquit (Quit: bajtos)
15:31:23  * leonvvjoined
15:36:16  <isaacs>piscisaureus_: dtls? why would we put that in core?
15:36:26  <isaacs>piscisaureus_: i know that it's been asked for, but i don't see why it can't be in userland.
15:36:36  <piscisaureus_>isaacs: bnoordhuis knows
15:36:39  <isaacs>bnoordhuis: ?
15:40:17  * isaacsread the scrollback
15:40:18  <bnoordhuis>isaacs: because it's probably going to be big in a year or two and because you can't really do it from a userland module right now
15:40:25  <isaacs>bnoordhuis: yes, we should fix THAT, then
15:40:35  <isaacs>bnoordhuis: the "inability to use openssl in a module realistically"
15:40:45  <bnoordhuis>easier said than done
15:40:58  <bnoordhuis>but don't forget the other part
15:41:14  <isaacs>that it's going to be big in a year?
15:41:14  <bnoordhuis>that said, i don't have a really strong opinion
15:42:16  <bnoordhuis>well, maybe i do. i'd put it on the same level as importance of, say, ECDH cipher or GCM mode support
15:42:46  <isaacs>there are good reasons to make openssl easier to bind against propelry
15:42:58  <isaacs>and by "easier", i mostly mean "possible"
15:44:08  <bnoordhuis>yeah, but once again, easier said than done
15:44:16  <bnoordhuis>i could fix the unices
15:44:30  <bnoordhuis>but i believe piscisaureus_ has tried twice to get it to work on windows without success
15:44:52  <bnoordhuis>piscisaureus_: ^ that's correct, right?
15:44:52  <Domenic_>all you have to do is somehow get me emotionally invested in a project that desparately needs native openssl support to succeed
15:44:59  <piscisaureus_>StringBytes has a nice vulnerability
15:45:03  <Domenic_>and then watch a bunch of bug reports file in from poor windows users trying to get it to work
15:45:13  <Domenic_>and then i will get so frustrated i will make it happen, somehow
15:45:28  <bnoordhuis>Domenic_: well, go for it. you have my blessing :)
15:45:44  <Domenic_>bnoordhuis: nobody's managed step 1 yet, like they did for vm :P
15:47:21  * c4miloquit (Remote host closed the connection)
15:48:21  * Benviequit (Ping timeout: 245 seconds)
15:49:37  <isaacs>piscisaureus_: oh?
15:49:51  <piscisaureus_>well - I don't know if it's exploitable in any meaningful way
15:50:00  <piscisaureus_>but the assumption is that ToString() returns a constant value
15:50:28  <piscisaureus_>because if you call StringBytes::StorageSize(bar, UTF8) it will call bar->ToString()
15:50:40  <piscisaureus_>and then when you convert it'll call that function again
15:51:05  <piscisaureus_>that assumption is normally valid unless it's not :)
15:52:02  <bnoordhuis>that can only happen when bar is reassigned between the two calls, right?
15:53:31  <piscisaureus_>no you could do
15:53:38  <piscisaureus_>bar = new MyClass()
15:53:53  <piscisaureus_>bar.prototype.toString = function() { return global.something += 'xyz' }
15:54:11  <piscisaureus_>er well
15:54:14  <piscisaureus_>you get the idea
15:54:20  * bajtosjoined
15:54:21  <piscisaureus_>javascript is hard
15:54:31  <bnoordhuis>ah... StorageSize() doesn't check bar is a string?
15:54:39  <bnoordhuis>right
15:54:45  <piscisaureus_>it does - it calls ToString() always
15:54:57  * amartensjoined
15:55:13  <piscisaureus_>StorageSize should probably take a Local<String> and checking/coercing types should be left to the callert
15:55:55  <bnoordhuis>"callert" :) been mingling with rotterdammers, bertje?
15:56:34  <piscisaureus_>heh
15:56:56  <piscisaureus_>ken je effe gaan legge
15:56:56  <isaacs>piscisaureus_: https://gist.github.com/isaacs/6343070 fixes?
15:57:21  <piscisaureus_>isaacs: well yeah, as long as we compile with assertions on :)
15:57:27  <isaacs>piscisaureus_: which we do
15:57:31  <piscisaureus_>on unix
15:57:46  <bnoordhuis>it's bad style to rely on !defined(NDEBUG)
15:57:56  <piscisaureus_>we should do as v8
15:58:04  <bnoordhuis>ASSERT and CHECK macros?
15:58:11  <piscisaureus_>have "classic" asserts that are only in debug builds
15:58:16  <piscisaureus_>and CHECK macros that are always on
15:58:29  <bnoordhuis>agreed
15:58:37  <isaacs>sure, i'm fine with that.
15:58:44  <isaacs>at the moment, we use assert() in this way all over the codebase.
15:58:52  <isaacs>and windows, well...
15:58:56  <isaacs>it's a bit more loosey
15:58:56  <piscisaureus_>I know, but I tend to write a lot of asserts in my code
15:58:57  * c4milojoined
15:59:12  <piscisaureus_>most of them are pointless to have a in a release build
15:59:28  <isaacs>most times that i've thought that, i've ended up being proven wrong
15:59:32  <isaacs>i'm a big fan of asserts in production builds.
15:59:38  <piscisaureus_>but there are some asserts that we really rely on now (and I am pretty sure they're off on windows atm)
16:00:00  <isaacs>they used to be off even in javascript in release builds.
16:00:13  <piscisaureus_>v8 actually has 3 levels
16:00:17  <piscisaureus_>they also have "slow asserts"
16:00:26  <isaacs>but if there ever was a case where the cost is worth the benefit, asserts are it.
16:00:53  <piscisaureus_>still I like the distinction between "this is to catch bugs" vs "this is to be secure"
16:01:06  <isaacs>piscisaureus_: the line is very subtle there.
16:01:22  <piscisaureus_>"this is to catch security bugs"
16:01:25  <piscisaureus_>agreed
16:01:33  <isaacs>i like NOT having a line between "this runs here" and "this runs on the server"
16:01:43  <isaacs>dev and prod should be identical.
16:01:58  <piscisaureus_>isaacs: well, why don't we ship a debug build then?
16:02:05  <isaacs>because it's hella slow
16:02:16  <piscisaureus_>isaacs: how do you think that happens? :)
16:02:30  <piscisaureus_>isaacs: well - no optimizations for one. ok
16:02:35  <isaacs>right
16:02:41  <piscisaureus_>isaacs: but also the fact that most of the asserts in v8 are off
16:02:42  <isaacs>it's not the assert() calls
16:02:50  <isaacs>at least, not the assert() calls in node
16:13:33  * kevinswiberquit (Remote host closed the connection)
16:13:54  * bnoordhuisquit (Ping timeout: 264 seconds)
16:16:21  <saghul>re DTLS: WebRTC datachannels run on DTLS over SCTP, someone may want to write a server with node I guess
16:17:29  * hzquit
16:27:51  * dapjoined
16:31:19  * AvianFluquit (Remote host closed the connection)
16:31:22  * dominictarrquit (Quit: dominictarr)
16:34:36  * icarotquit (Remote host closed the connection)
16:38:40  * leonvvquit (Remote host closed the connection)
16:40:16  * AvianFlujoined
16:40:28  * bnoordhuisjoined
16:44:08  * Brett19quit (Read error: Connection reset by peer)
16:45:58  * Brett19joined
16:49:06  * bnoordhuisquit (Ping timeout: 264 seconds)
16:55:11  * kevinswiberjoined
16:56:24  * groundwaterjoined
17:01:15  * amartensquit (Quit: Leaving.)
17:09:05  * bnoordhuisjoined
17:13:16  * AvianFlu_joined
17:15:57  * dominictarrjoined
17:16:35  * AvianFluquit (Ping timeout: 260 seconds)
17:17:11  * TooTallNatejoined
17:17:31  * leonvvjoined
17:25:05  * pachetquit (Read error: Operation timed out)
17:25:51  * brsonjoined
17:28:20  <tjfontaine>bnoordhuis: any arguments with upgrading v8 to 3.20.17?
17:32:04  * othiym23`changed nick to othiym23
17:35:12  * AvianFlu_changed nick to AvianFlu
17:36:41  <bnoordhuis>tjfontaine: not from me
17:37:28  * amartensjoined
17:38:07  * pachetjoined
17:38:43  <tjfontaine>bnoordhuis: ok, I shall do that today then
17:44:30  * st_lukejoined
17:49:26  * piscisaureus_quit (Ping timeout: 240 seconds)
17:49:36  <indutny>hey people
17:49:47  <indutny>what are we doing today?
17:52:26  <hueniverse>I've been playing with 0.11 over the weekend. Got stuck on two stream bugs: https://github.com/joyent/node/issues/6119 and https://github.com/joyent/node/issues/6118
17:59:11  * bnoordhuisquit (Ping timeout: 245 seconds)
18:01:50  * piscisaureus_joined
18:02:06  <MI6>libuv-master: #197 UNSTABLE windows (3/193) smartos (10/192) http://jenkins.nodejs.org/job/libuv-master/197/
18:04:49  * DrPizza_quit (Ping timeout: 240 seconds)
18:15:19  <othiym23>so process.on('exit') is intended for synchronous cleanup
18:15:53  <bradleymeck>yep, its a last ditch effort situation, I would not rely on it though
18:16:05  <othiym23>is it reasonable to perform async I/O inside SIGINT / SIGKILL handlers as long as the expectation is that those will terminate in a timely fashion?
18:16:15  <bradleymeck>it won't fire if someone does a segfault etc.
18:16:23  <othiym23>yeah
18:16:44  <othiym23>I'm just trying to figure out if it's sane to install a handler to flush any transaction data from the New Relic agent on normal shutdown
18:17:23  <othiym23>hm, but that still wouldn't catch e.g. mocha or tap runs
18:17:40  <othiym23>maybe I could do a fs.writeSync to dump state and load it on startup if it's around
18:17:46  * ecrjoined
18:23:48  <trevnorris>morning
18:24:34  <othiym23>morning
18:24:52  <bradleymeck>othiym23: been wondering about spawning a child proc w/ shared fd and detecting death via fd close, no new procs for new relic agents?
18:25:14  <othiym23>bradleymeck: for the moment, no
18:25:39  <othiym23>bradleymeck: it's just a pure-JS parasite attached to the side of the instrumented app's process
18:25:41  <trevnorris>tjfontaine: i'll assume these failures are for other reason: http://jenkins.nodejs.org/job/node-pullrequest/1075/testReport/
18:25:51  <brson>which build system does libuv currently support mingw with? we've had some problems trying to use gyp
18:26:26  <tjfontaine># Error: listen EADDRINUSE
18:26:39  <tjfontaine>somehow got caught by two things running at the same time, odd doesn't usually happen
18:27:03  <trevnorris>tjfontaine: thanks
18:27:09  <trevnorris>then in that case anyone have a problem w/ https://github.com/joyent/node/pull/6124
18:29:47  * mikealjoined
18:32:03  <MI6>libuv-node-integration: #182 UNSTABLE smartos-x64 (12/636) smartos-ia32 (8/636) linux-x64 (2/636) linux-ia32 (2/636) http://jenkins.nodejs.org/job/libuv-node-integration/182/
18:34:15  * julianduquejoined
18:34:59  * dshaw_joined
18:41:09  * dshaw_quit (Quit: Leaving.)
18:47:13  <trevnorris>bn
18:47:26  * dshaw_joined
18:50:15  <tjfontaine>tab complete win trevnorris
18:54:45  * defunctzombie_zzchanged nick to defunctzombie
18:56:24  * bradleymeckquit (Quit: bradleymeck)
18:56:34  <trevnorris>:)
19:00:32  * leonvvquit (Remote host closed the connection)
19:01:28  * bradleymeckjoined
19:11:09  * ecr1joined
19:12:05  * ecrquit (Ping timeout: 245 seconds)
19:14:40  <trevnorris>review. anyone :(
19:15:00  <tjfontaine>it seems fine at first glance, but I honestly haven't looked at it in depth
19:16:48  * stagasquit (Ping timeout: 276 seconds)
19:16:51  <trevnorris>it's pretty straight forward. just allowing a super cheap way of returning an empty buffer instance.
19:17:04  * groundwaterquit (Ping timeout: 256 seconds)
19:17:08  * amartensquit (Quit: Leaving.)
19:17:17  <trevnorris>wouldn't have even noticed it weren't it for the util.is* functions
19:19:03  * groundwaterjoined
19:27:59  <MI6>nodejs-master-windows: #273 UNSTABLE windows-x64 (22/636) windows-ia32 (23/636) http://jenkins.nodejs.org/job/nodejs-master-windows/273/
19:35:11  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:35:50  * bradleymeckquit (Quit: bradleymeck)
19:37:09  * ecr1quit (Quit: ecr1)
19:39:20  * ecrjoined
19:39:49  * bajtosquit (Quit: bajtos)
19:41:35  * kevinswiberquit (Remote host closed the connection)
19:48:03  * amartensjoined
19:55:25  <mordy__>hrm, does getPropertyNames() return a copy of the keys, or does it point to some internal structure.. the question being:
19:55:43  <mordy__>can i rely on 'GetPropertyNames' to not be modified even if the object itself is modified?
19:58:28  * kevinswiberjoined
19:59:12  * bnoordhuisjoined
20:00:12  <bnoordhuis>brson: right now that's autotools. i actually deleted the Makefile.mingw this weekend but i can restore it if that makes life easier for you guys
20:01:14  <bnoordhuis>mordy__: GetPropertyNames() makes a copy
20:01:23  <mordy__>ah ok
20:01:25  <brson>bnoordhuis: Makefile.mingw works without autotools? so we would use gyp on unix and plain make on windows?
20:02:09  <bnoordhuis>brson: yes, if that works for you
20:02:29  <bnoordhuis>ideally gyp should support mingw but alas, it doesn't yet
20:02:56  <brson>bnoordhuis: yes, I think we can handle that
20:03:01  <brson>acrichto: does that sound workable? ^
20:03:11  <brson>bnoordhuis: sorry for the trouble, but we don't like autotools
20:03:12  <acrichto>yeah definitely
20:03:41  <bnoordhuis>hah, i don't think anyone likes autotools
20:04:13  <bnoordhuis>it's just this common standard the FOSS world converged on
20:04:23  <bnoordhuis>i'll restore the mingw makefile
20:04:29  <brson>thanks!
20:06:38  <MI6>joyent/libuv: Ben Noordhuis master * d5ab1c1 : Revert "build: remove mingw makefile" - http://git.io/N3kaUw
20:07:27  <acrichto>bnoordhuis: thanks!
20:08:02  * txdvjoined
20:09:35  <bnoordhuis>no problem :)
20:11:22  <acrichto>bnoordhuis: the build should just be `make -f Makefile.mingw`, right?
20:13:56  <bnoordhuis>acrichto: provided you have a cc and ar somewhere on the path, yes
20:14:36  <acrichto>it seems to be failing with syntax problems at src/win/winapi.h about some expectation of a specifier-qualifier-list
20:14:47  <acrichto>the syntax is "typedef struct {} name, *name"
20:14:58  <acrichto>I wasn't even aware that the ", *name" was valid syntax...
20:15:24  <bnoordhuis>oh? what version mingw is that?
20:15:27  <bnoordhuis>*version of
20:15:55  <acrichto>hmm... I barely use windows at all, how do I check?
20:16:26  <bnoordhuis>er, good question
20:16:38  <acrichto>gcc is 4.5.2 if that helps
20:16:45  <bnoordhuis>i confess i only cross-compile with the mingw package in yum
20:17:05  <MI6>libuv-master-gyp: #136 UNSTABLE windows-x64 (4/193) windows-ia32 (3/193) smartos-ia32 (4/192) smartos-x64 (4/192) http://jenkins.nodejs.org/job/libuv-master-gyp/136/
20:17:28  <trevnorris>bnoordhuis: thanks for the review. and nice &args trick.
20:17:29  <trevnorris>created a http server directly on top of tcp (so no keepAlive) and simple hello world is running ~55k req/sec. just trying to figure out where the bottlenecks are.
20:17:48  <trevnorris>that's almost 2x's faster than http w/ keepAlive
20:17:55  <bnoordhuis>very good :)
20:18:18  <bnoordhuis>acrichto: fwiw, the mingw in fc18 is mingw64 with gcc 4.7.2
20:18:48  <bnoordhuis>acrichto: i'll take patches that fix things with older versions :)
20:18:50  <acrichto>huh, I thought I downloaded the most recent version from about a week ago
20:19:04  <acrichto>bnoordhuis: cool, I'll investigate
20:20:36  <MI6>libuv-master: #198 UNSTABLE windows (5/193) smartos (11/192) http://jenkins.nodejs.org/job/libuv-master/198/
20:21:16  <acrichto>bnoordhuis: ah, got it to build just a small movement in the header
20:22:01  * st_lukequit (Remote host closed the connection)
20:22:32  * austojoined
20:24:03  * st_lukejoined
20:52:00  <MI6>libuv-node-integration: #183 UNSTABLE smartos-x64 (11/636) smartos-ia32 (13/636) linux-x64 (1/636) linux-ia32 (1/636) http://jenkins.nodejs.org/job/libuv-node-integration/183/
21:12:41  <MI6>joyent/node: Trevor Norris master * 873b5f8 : buffer: fix assert fail from JS API (+1 more commits) - http://git.io/_ph4oA
21:19:46  <trevnorris>bnoordhuis: ping
21:20:14  * AvianFlu_joined
21:20:28  * AvianFlu_quit (Remote host closed the connection)
21:21:40  * EhevuTovjoined
21:23:03  <trevnorris>isaacs: ping too :)
21:23:23  <isaacs>trevnorris: pong
21:23:26  * AvianFluquit (Ping timeout: 246 seconds)
21:24:05  <trevnorris>isaacs: so i've created a minimal tcp server that just responds with a simple http hello world. w/o keepAlive it's pushing 60k req/sec
21:24:28  <trevnorris>isaacs: but when I set socket.setKeepAlive() it runs slower. i'm not sure if i'm doing something wrong.
21:25:43  <creationix>just learned about SO_REUSEPORT in linuc 3.9
21:25:47  <creationix>*linux
21:26:26  <creationix>it lets you create pre-fork style clusters without the master process
21:26:41  <creationix>how hard would it be to add that to libuv?
21:26:58  <creationix>I guess it would be an option to the uv_tcp_bind function
21:27:42  <MI6>nodejs-master: #482 UNSTABLE smartos-x64 (11/636) osx-ia32 (2/636) smartos-ia32 (9/636) osx-x64 (1/636) http://jenkins.nodejs.org/job/nodejs-master/482/
21:29:32  * kevinswiberquit (Remote host closed the connection)
21:34:15  * Ralt_changed nick to Ralt
21:34:29  <bnoordhuis>creationix: you're the second one asking about that today, tim :)
21:34:53  <bnoordhuis>creationix: the tl;dr is "easy but we're not adding it""
21:35:04  <bnoordhuis>or at least not now
21:36:09  <bnoordhuis>that said, you can prepare the socket manually and then create a handle with uv_tcp_open() or uv_udp_open()
21:36:18  <bnoordhuis>trevnorris: pong
21:36:43  <isaacs>trevnorris: code?
21:37:02  <isaacs>trevnorris: also, are you doing setKeepAlive(boolean, number) to specify the flag and the timeout?
21:37:11  <isaacs>trevnorris: s/timeout/interval/
21:38:48  <trevnorris>isaacs, bnoordhuis: https://gist.github.com/trevnorris/6346973
21:38:55  * jmar777quit (Remote host closed the connection)
21:39:05  <trevnorris>the keep alive is commented out
21:39:37  <trevnorris>i ran this with: wrk -c 32 -t 4 -d 10 ''
21:40:19  <isaacs>trevnorris: nits: the cannonical http delimter is \r\n, not \n
21:40:30  <isaacs>trevnorris: and it should send Connection: keep-alive\r\n in the head
21:40:41  <trevnorris>ah, maybe that's it. thanks
21:41:43  * mikealquit (Quit: Leaving.)
21:42:04  <isaacs>trevnorris: so... also
21:42:09  <isaacs>trevnorris: trace this through
21:42:15  <isaacs>the client connects, onConnect gets called
21:42:22  <isaacs>you say "keep this connection alive"
21:42:26  <isaacs>client says, "ok"
21:42:38  <isaacs>(well, it doesn't, but presumably, it does keep the connection alive)
21:42:48  <isaacs>client sends a request, you send one response.
21:42:58  <isaacs>then hte client sends another request on the same connection, right?
21:43:22  <isaacs>but, you're not parsing the incoming data to see that it's sent another req
21:43:39  <isaacs>(also, you're sending the response before seeing the request, which is odd, if not exactly incorrect.)
21:44:16  <trevnorris>isaacs: the point was to see how quickly I could hit the server. don't actually care about the headers. not sure if that actually makes a difference.
21:44:30  <isaacs>trevnorris: well, let's say I'm wrk
21:44:41  <isaacs>i connect, write one request
21:44:43  <isaacs>you write one response
21:44:49  <isaacs>then i write another request *on the same socket*
21:44:54  <isaacs>and you... what?
21:45:29  <trevnorris>well, won't wrk have registered it's sent another request? or do I need to send back an 'hey thanks, I got that'?
21:45:58  <isaacs>wrk should be printing out that thousands of requests are not being answered.
21:46:02  <isaacs>i would think
21:46:06  <isaacs>or it's not actually doing http keepalive
21:46:21  * qardjoined
21:46:25  <trevnorris>must not be, because says there're no errors
21:46:27  * qardpart
21:47:10  <bnoordhuis>wrk's http parsing logic is extremely simple
21:47:21  <bnoordhuis>you can fool it easily
21:47:26  <trevnorris>heh
21:47:40  <isaacs>trevnorris: what you should do is just keep writing the response over and over again
21:48:05  <isaacs>trevnorris: ie, have afterWrite() call write()
21:48:10  <bnoordhuis>acrichto: left some comments on the PR. also, please sign the CLA :)
21:48:11  <isaacs>"Oh, you got that one? Here's anotheR!"
21:48:18  <trevnorris>cool. i'll try that
21:53:34  <creationix>bnoordhuis, sounds good
21:54:59  <isaacs>trevnorris: a more advanced approach would be to tally up the number of \r\n\r\n you get in the incoming socket, and write that many responses.
21:55:23  <isaacs>trevnorris: not that it'd matter for localhost benchmarking, of course, but if you're sending over a network, you'll save a lot of roundtrips
21:55:36  <trevnorris>isaacs: interesting. thanks for the tip.
21:55:52  <trevnorris>isaacs: still haven't gotten keepalive to work, but i'll get there :)
21:56:03  <trevnorris>w/o it the simple case is running at 65k req/sec
21:56:09  <trevnorris>a lot more than I would have expected.
22:01:40  * c4miloquit (Remote host closed the connection)
22:01:51  <isaacs>trevnorris: in short, socket.setKeepAlive(true, 10000) says "Send a KA packet every 10s if the socket has not had any other activity"
22:02:03  <isaacs>it's a heartbeat technique at the tcp level
22:02:16  <isaacs>one side sends a KA, the other side sends an ACK
22:02:24  <isaacs>if you don't get an ACK from the KA, you know that the socket died
22:02:25  <acrichto>bnoordhuis: ok thanks! I think I've singed the CLA now and also just updated the pull
22:02:39  <isaacs>more often, if you don't get an ACK, you get a RST
22:02:47  <isaacs>ie, ECONNRESET
22:03:05  <isaacs>if the other end restarted or something
22:03:17  <trevnorris>ok cool
22:03:45  * wolfeidauquit (Remote host closed the connection)
22:04:37  * c4milojoined
22:05:40  * paulfryzelquit (Remote host closed the connection)
22:06:56  <trevnorris>oh hell.
22:07:36  <trevnorris>isaacs: ok. so don't understand the mechanics, but I was calling .close() before I had a chance to read data. but I thought that close would keep it alive until all data was read in anyways.
22:07:59  <isaacs>trevnorris: oh, ok
22:08:21  <trevnorris>yeah. so onread was never getting called. just onconnection
22:11:08  <trevnorris>hells yes!!!
22:11:12  <trevnorris>120k req/sec
22:11:15  <trevnorris>isaacs: got it :)
22:11:30  <isaacs>nice :)
22:11:39  <isaacs>also, holy slow javascript, batman
22:11:42  <isaacs>:)
22:11:46  <trevnorris>heh, yeah.
22:11:52  <trevnorris>so now we know how much overhead http is adding :P
22:13:38  <isaacs>oh, http parsing, also
22:13:46  <isaacs>yeah, it's adding like 90% overhead
22:13:52  <isaacs>trevnorris: also, network
22:14:03  <isaacs>trevnorris: your test is probably more a test of wrk's limits than node's
22:14:28  <MI6>joyent/node: Ben Noordhuis master * 9fc0066 : src: fix up unused/unordered imports - http://git.io/gw8vRA
22:14:45  <trevnorris>isaacs: it's good to know that all the req_wrap stuff to create the request isn't adding much overhead.
22:14:51  <trevnorris>that's what I was mainly curious about
22:14:58  <isaacs>trevnorris: sure
22:16:29  * abraxasjoined
22:17:15  <MI6>nodejs-master-windows: #274 UNSTABLE windows-x64 (21/636) windows-ia32 (23/636) http://jenkins.nodejs.org/job/nodejs-master-windows/274/
22:17:16  <trevnorris>isaacs: so, there's one thing I'd like to see if possible in stream_wrap. right now we're passing the req_wrap object so MakeCallback can grab the applicable callback, but that means we loose the ability to set the context of the function. if we could pass the client object as the callback context we could completely remove all closures.
22:18:02  <isaacs>trevnorris: interesting
22:18:28  <isaacs>trevnorris: we could also just put a reference from the req_wrap to the stream_wrap (or js Stream)
22:18:45  <isaacs>trevnorris: we have a lot of unnecessary closures anyway
22:19:25  <trevnorris>isaacs: yeah. i was writing an example to demonstrate performance gains w/o closures, then realized we can't do a tcp connection w/o a bunch of closures :P
22:19:36  * groundwaterquit (Ping timeout: 245 seconds)
22:20:48  <isaacs>kew
22:20:54  * abraxasquit (Ping timeout: 264 seconds)
22:21:49  * groundwaterjoined
22:22:40  * txdvquit (Ping timeout: 264 seconds)
22:23:15  <MI6>nodejs-master: #483 FAILURE osx-ia32 (4/636) osx-x64 (4/636) http://jenkins.nodejs.org/job/nodejs-master/483/
22:23:31  <tjfontaine>hm
22:23:53  <tjfontaine>oh jenkins.
22:26:08  * AvianFlujoined
22:27:56  * txdvjoined
22:28:27  <MI6>joyent/libuv: Ben Noordhuis master * 5d2434b : unix, windows: add thread-local storage API - http://git.io/BOJARA
22:30:10  <bnoordhuis>it's kind of a shame to go through to the PLT (twice) to do a TLS lookup
22:30:31  <trevnorris>isaacs: can you elaborate on the "put a reference ..." comment?
22:30:39  <bnoordhuis>but what can you do? i don't really want to inline the functions into a header...
22:31:45  <isaacs>trevnorris: i mean, doesn't that stuf pass around an arbitrary js object?
22:32:00  <isaacs>trevnorris: why are we using closures? why not just pass a link to the object around?
22:32:19  <trevnorris>isaacs: yeah. the req_wrap creates an new object with each request that contains the callbacks and also any domain information.
22:32:46  <trevnorris>isaacs: domains are why the new object has to be created. there is an optimization that could default to the "default" object if no domain, but that'd be non-trivial
22:35:10  <trevnorris>isaacs: what would be most efficient is if we initialized a class w/ all callbacks and stored those as persistents, then they could be passed directly to MakeCallback instead of retrieved from the req_wrap object.
22:35:35  <trevnorris>but the only way I can think to do that is to tightly couple the Stream JS function and the Stream C++ class.
22:36:41  <trevnorris>bnoordhuis: ping
22:36:55  <MI6>joyent/libuv: Alex Crichton master * b647c27 : windows: fix mingw build (+1 more commits) - http://git.io/nq4xWQ
22:37:28  <bnoordhuis>acrichto: ^
22:37:44  <bnoordhuis>acrichto: btw, for future reference, set your textwidth to 72 next time when writing a commit log
22:38:04  <bnoordhuis>if you're a vim user, add this to your .vimrc -> autocmd BufEnter COMMIT_EDITMSG set textwidth=72
22:38:23  <bnoordhuis>and enable colorcolumn if your vim supports that
22:38:35  <bnoordhuis>trevnorris: pong
22:38:42  <trevnorris>hooya for colorcolumn!
22:38:55  <bnoordhuis>colorcolumn is nice :)
22:39:11  <bnoordhuis>well, unless you're on a really slow ssh connection
22:39:25  <trevnorris>i'll keep that in min
22:39:26  <trevnorris>d
22:39:28  <trevnorris>bnoordhuis: in stream_wrap.cc I see StreamWrapCallbacks::Self() that returns wrap()->object(), but then wrap()->object() is also just used in a lot of places.
22:39:50  <trevnorris>i'll assume they do the same thing,
22:40:05  <trevnorris>well, i mean. that's obvious, guess I don't see why they weren't all replaced
22:40:05  <bnoordhuis>they do
22:40:23  <bnoordhuis>i don't know, truth be told. StreamWrapCallbacks::Self() is something fedor introduced
22:40:29  <trevnorris>ah, ok
22:41:00  <trevnorris>bnoordhuis: also, you have any opposition to making the socket the context of the callback?
22:41:12  <trevnorris>right now it's just going to waste and requires we use closures in js to get around it
22:41:18  <bnoordhuis>i guess you could replace them with Self(). same thing, less typing
22:41:38  <bnoordhuis>what is your definition of 'callback'?
22:41:55  <trevnorris>onread, oncomplete
22:42:12  <bnoordhuis>and 'socket' is...? net#Socket?
22:42:56  <trevnorris>oh, sorry. here in server.onconnect https://gist.github.com/trevnorris/6346973
22:43:15  <trevnorris>you'll see how to do client.writeBuffer() i need to have onread in the onconnect closure?
22:43:22  <bnoordhuis>oh, you mean the HandleWrap object?
22:43:25  <trevnorris>yeah
22:43:38  <bnoordhuis>no objection from me
22:43:45  <trevnorris>awesome. thanks.
22:43:48  <trevnorris>that should flatten a lot of code
22:47:46  <bnoordhuis>okay, time for cereal and some papers on deforestation and LICM
22:47:55  <bnoordhuis>have a good night guys
22:48:53  <trevnorris>night ben
22:51:31  * dominictarrquit (Quit: dominictarr)
22:52:06  * bnoordhuisquit (Ping timeout: 245 seconds)
23:08:26  * jmar777joined
23:16:16  * paulfryzeljoined
23:20:14  * paulfryzelquit (Ping timeout: 240 seconds)
23:37:32  * dshaw_quit (Quit: Leaving.)
23:39:19  * dshaw_joined
23:39:41  <MI6>nodejs-master-windows: #275 UNSTABLE windows-x64 (20/636) windows-ia32 (28/636) http://jenkins.nodejs.org/job/nodejs-master-windows/275/
23:39:58  * c4miloquit (Remote host closed the connection)
23:41:17  * c4milojoined
23:43:04  <MI6>libuv-master-gyp: #137 UNSTABLE windows-x64 (4/194) windows-ia32 (4/194) smartos-ia32 (2/193) linux-x64 (1/193) smartos-x64 (3/193) http://jenkins.nodejs.org/job/libuv-master-gyp/137/
23:45:44  * AvianFluquit (Remote host closed the connection)
23:49:31  <MI6>libuv-master: #199 UNSTABLE linux (1/193) windows (7/194) smartos (11/193) http://jenkins.nodejs.org/job/libuv-master/199/
23:49:47  * dshaw_quit (Quit: Leaving.)
23:49:52  <kellabyte>damn missed bnoordhuis, meant to tell him I'm giving his code a shot :)
23:56:57  * st_lukequit (Remote host closed the connection)
23:58:25  * bnoordhuisjoined
23:59:42  * jmar777quit (Remote host closed the connection)