00:03:50  * travis-cijoined
00:03:50  <travis-ci>[travis-ci] joyent/node#332 (master - 5403a8c : Brandon Benvie): The build is still failing.
00:03:50  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/e3c0c86...5403a8c
00:03:50  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/596195
00:03:50  * travis-cipart
00:21:42  * lwillejoined
00:40:52  * mikealquit (Quit: Leaving.)
00:54:58  * mikealjoined
01:06:56  * lwillequit (Quit: Linkinus - http://linkinus.com)
01:09:03  * lwillejoined
01:15:23  * mikealquit (Quit: Leaving.)
01:17:12  * mikealjoined
01:25:21  * lwillequit (Quit: Linkinus - http://linkinus.com)
01:27:18  * lwillejoined
01:32:31  * mikealquit (Quit: Leaving.)
01:33:15  * brsonquit (Quit: leaving)
01:55:16  * mjr_quit (Quit: mjr_)
02:14:58  * mikealjoined
02:29:11  * isaacsquit (Remote host closed the connection)
02:33:23  * mikealquit (Quit: Leaving.)
03:09:32  * sh1mmerjoined
03:11:19  * bnoordhuisquit (Read error: Operation timed out)
03:20:35  * isaacsjoined
03:36:16  * isaacsquit (Remote host closed the connection)
03:39:07  * lwillequit (Quit: Linkinus - http://linkinus.com)
03:40:21  * mjr_joined
03:40:57  * lwillejoined
03:42:33  * lwillequit (Remote host closed the connection)
03:44:25  * lwillejoined
03:49:05  * lwillequit (Client Quit)
03:51:24  * lwillejoined
03:57:29  * orlandovftwjoined
03:58:44  * lwillequit (Quit: Linkinus - http://linkinus.com)
03:59:46  * lwillejoined
04:02:45  * lwillequit (Client Quit)
04:07:16  * dshaw_joined
04:25:35  * mjr_quit (Quit: mjr_)
04:28:19  * lwillejoined
05:14:03  * lwillequit (Quit: Linkinus - http://linkinus.com)
05:23:50  * isaacsjoined
05:29:49  * lwillejoined
05:42:26  * lwillequit (Quit: Leaving...)
05:49:54  * isaacsquit (Remote host closed the connection)
06:05:11  * mralephjoined
06:26:11  * mralephquit (Quit: Leaving.)
06:32:47  * mralephjoined
06:39:39  * mralephquit (Quit: Leaving.)
06:43:55  * mralephjoined
06:54:54  * mikealjoined
06:55:12  * luxigojoined
06:56:55  * mikealquit (Client Quit)
06:58:38  * paddybyersjoined
06:59:43  * mikealjoined
07:04:02  * mikealquit (Client Quit)
07:06:15  * mralephquit (Quit: Leaving.)
07:17:32  * luxigoquit (Ping timeout: 245 seconds)
07:20:27  * luxigojoined
07:30:36  * lwillejoined
07:35:05  * lwillequit (Ping timeout: 252 seconds)
07:45:03  * paddybyersquit (Quit: paddybyers)
08:16:50  * mikealjoined
09:03:07  * paddybyersjoined
09:30:00  * elijahwrightjoined
09:33:20  * elijah-mbpquit (Ping timeout: 252 seconds)
10:52:06  * orlandovftwquit (Ping timeout: 252 seconds)
11:34:26  * dshaw_quit (Quit: Leaving.)
12:00:31  * piscisaureus_joined
12:38:57  * bnoordhuisjoined
13:11:58  <CIA-115>node: Brandon Benvie master * r52bd0f9 / src/node.js : core: make .deprecate() warn only once - http://git.io/8grQTg
13:14:03  <CIA-115>node: Ben Noordhuis v0.6 * rb221fe9 / (lib/timers.js test/simple/test-timers-uncaught-exception.js):
13:14:04  <CIA-115>node: timers: add v0.4 compatibility hack
13:14:04  <CIA-115>node: If a timer callback throws and the user's uncaughtException handler ignores the
13:14:04  <CIA-115>node: exception, other timers that expire on the current tick should still run.
13:14:04  <CIA-115>node: If #2582 goes through, this hack should be removed.
13:14:04  <CIA-115>node: Fixes #2631. - http://git.io/bz26qQ
13:14:37  <piscisaureus_>bnoordhuis: that stat regression fix i put in last week doesn't handle all the edge cases
13:15:00  <piscisaureus_>bnoordhuis: I am going to try an alternative approach, otherwise we may have to put the path handling stuff in libuv
13:15:22  <piscisaureus_>(that would be better anyway but I am very scared of this string handling stuff)
13:16:10  <bnoordhuis>piscisaureus_: noted
13:21:53  * travis-cijoined
13:21:53  <travis-ci>[travis-ci] joyent/node#334 (v0.6 - b221fe9 : Ben Noordhuis): The build is still failing.
13:21:53  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/ca4b91a...b221fe9
13:21:53  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/598629
13:21:53  * travis-cipart
13:25:49  * travis-cijoined
13:25:49  <travis-ci>[travis-ci] joyent/node#333 (master - 52bd0f9 : Brandon Benvie): The build is still failing.
13:25:49  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/5403a8c...52bd0f9
13:25:49  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/598626
13:25:49  * travis-cipart
13:36:56  * AndreasMadsenjoined
14:39:07  <bnoordhuis>hah, i think i found a bug in v8's parser
14:39:30  <bnoordhuis>let's check if it still exists in v8's bleeding edge
14:39:59  <bnoordhuis>and it does
14:46:55  <AndreasMadsen>piscisaureus_: could you review the disconnect patch -> https://github.com/joyent/node/pull/2591
14:48:14  * luxigoquit (Ping timeout: 255 seconds)
14:50:34  <piscisaureus_>AndreasMadsen: what happens if I try to send a message to a disconnected worker?
14:50:49  <AndreasMadsen>piscisaureus_: it throws
14:51:19  <piscisaureus_>AndreasMadsen: how does that work?
14:51:51  <AndreasMadsen>piscisaureus_: a flag is set, only the name has changed -> https://github.com/joyent/node/pull/2591/files#L1R134
14:51:52  <piscisaureus_>AndreasMadsen: because of channel.close() ?
14:52:41  <AndreasMadsen>piscisaureus_: no when a channel is closed by onread or disconnect a flag is set.
14:52:43  <piscisaureus_>AndreasMadsen: you have to work on your english somewhat :-). But your patch looks good otherwise, i will land it
14:52:56  <bnoordhuis>http://code.google.com/p/v8/issues/detail?id=1924 <- fringe case!
14:53:15  <AndreasMadsen>piscisaureus_: I'm trying very hard every day :(
14:54:58  <piscisaureus_>AndreasMadsen: this fix buffering detection patch, is that separate from disconnect?
14:55:13  <AndreasMadsen>piscisaureus_: no
14:55:26  <piscisaureus_>kk
14:55:55  <AndreasMadsen>piscisaureus_: But I did it after indutny has made his final review, do I did not squash it
14:55:58  <bnoordhuis>piscisaureus_: are you at the office tomorrow?
14:56:02  <AndreasMadsen>s/do/
14:56:04  <piscisaureus_>bnoordhuis: yup
14:56:05  <AndreasMadsen>s/do/so
14:56:14  <bnoordhuis>piscisaureus_: cool, i'll drop by
14:56:20  <piscisaureus_>bnoordhuis: kewl
14:56:39  <bnoordhuis>so what's everyone working on today?
14:56:43  * luxigojoined
14:59:49  <piscisaureus_>bnoordhuis: alternative approach for uv_stat (and possibly finally implement uv_lstat for windows)
14:59:55  <piscisaureus_>bnoordhuis: after that, ud[
15:00:05  <piscisaureus_>right now, AndreasMadsen's patch
15:00:12  <bnoordhuis>piscisaureus_: did you see the test cases i wrote?
15:00:29  <piscisaureus_>bnoordhuis: nope. point me
15:00:41  <bnoordhuis>you should read your gh notifications >:(
15:00:45  <piscisaureus_>AndreasMadsen: why btw is the disconnect event documented but not the disconnect method
15:00:50  <piscisaureus_>?
15:00:59  <piscisaureus_>bnoordhuis: yep I will after github stops spamming
15:01:36  <AndreasMadsen>piscisaureus_: I just follow the bad pattern, fork().send is not documented with it own header too.
15:02:06  <piscisaureus_>AndreasMadsen: I am going to land your patch anyway
15:02:53  <bnoordhuis>piscisaureus_: https://github.com/bnoordhuis/libuv/compare/v0.6...ipv6-multicast
15:03:21  <bnoordhuis>piscisaureus_: https://github.com/bnoordhuis/libuv/compare/v0.6...test-udp-options
15:03:35  * luxigoquit (Ping timeout: 248 seconds)
15:04:09  <AndreasMadsen>This is my vision of the child_process documentation / API, hopefully someone will look at it -> https://github.com/AndreasMadsen/node-1/blob/child2/doc/api/child_processes.markdown
15:04:36  <AndreasMadsen>But that is another subject :)
15:07:11  <piscisaureus_>I want to rethink exec/spawn/execFile (we are lacking spawnShell btw)
15:07:22  <piscisaureus_>to complete that mess
15:07:32  <piscisaureus_>But that is another subject :)
15:08:37  * luxigojoined
15:08:57  <indutny>omg, bold text
15:09:03  <AndreasMadsen>piscisaureus_: I'm very seriouse about the mess in child_process, hopefully you have noted that I wrote a big patch about it. -> https://github.com/joyent/node/pull/2544
15:10:36  <piscisaureus_>AndreasMadsen: yes, big patches are painful to review
15:11:25  <bnoordhuis>that's what she said!
15:11:37  <bnoordhuis>well, something about big and painful anyway
15:11:53  * lwillejoined
15:12:01  * lwillequit (Client Quit)
15:12:27  <AndreasMadsen>piscisaureus_: I know - I had just hoped that someone would like do discuss the thought about simplify the child_process API.
15:13:07  * lwillejoined
15:16:55  <CIA-115>node: koichik v0.6 * r3fd13c6 / (lib/http.js test/simple/test-http-expect-continue.js):
15:16:55  <CIA-115>node: http: fix free http-parser too early
15:16:55  <CIA-115>node: when the status code is 100 (Continue).
15:16:55  <CIA-115>node: Fixes #2636. - http://git.io/USkQJg
15:24:49  * travis-cijoined
15:24:50  <travis-ci>[travis-ci] joyent/node#335 (v0.6 - 3fd13c6 : koichik): The build is still failing.
15:24:50  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/b221fe9...3fd13c6
15:24:50  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/599033
15:24:50  * travis-cipart
15:36:07  <CIA-115>node: Andreas Madsen master * r836344c / (doc/api/child_processes.markdown lib/child_process.js):
15:36:07  <CIA-115>node: Add disconnect method to forked child processes
15:36:07  <CIA-115>node: This disconnect method allows the child to exit gracefully.
15:36:07  <CIA-115>node: This also adds a disconnect event and connect property. - http://git.io/6B_QVA
15:51:25  * travis-cijoined
15:51:26  <travis-ci>[travis-ci] joyent/node#336 (master - 836344c : Andreas Madsen): The build is still failing.
15:51:26  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/52bd0f9...836344c
15:51:26  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/599092
15:51:26  * travis-cipart
15:57:23  <AndreasMadsen>^--- wow who poked cluster?
15:59:10  * isaacsjoined
16:01:01  <isaacs>piscisaureus_: good mornevening
16:01:51  <tjfontaine>once upon a time people tried to formalize on: GUG -- General UTC Greeting
16:02:05  <indutny>isaacs: hi
16:02:11  <indutny>isaacs: commented on that isolates gist
16:03:48  <isaacs>kewl
16:05:34  * sh1mmerquit (Quit: sh1mmer)
16:18:16  * mikeal1joined
16:18:16  * mikealquit (Read error: Connection reset by peer)
16:21:06  * pfox___joined
16:21:23  <pfox___>that's an encouraging topic
16:30:14  * bnoordhuistopic: ponies, unicorns and libuv
16:30:18  <bnoordhuis>pfox___: better?
16:31:39  <pfox___>meh, i didn't the nihilistic vision of the previous topic
16:31:46  <pfox___>"In the world of libuv, there is only war."
16:31:47  <pfox___>anywho.
16:33:48  <pfox___>so.. im interested in using libuv to replace my lame, handrolled event-loop-but-not-really for a project that i work on for my own entertainment..
16:34:49  <bnoordhuis>pfox___: go on
16:35:06  <pfox___>it's currently set up, like: i have n-"Workers", which are thread-isolated and [should] each have their own event loop
16:35:41  <pfox___>their is a per-process "message exchange" that uses locking behavior to allow each worker to poll it for messages (endpoint + JSON msg pairs) that the workers can send to each other
16:35:50  * AndreasMadsenquit (Remote host closed the connection)
16:37:12  <pfox___>so, right now.. my "event loop" is just a blocking loop that polls the message exchange and processes any incoming messages.. so if there's no incoming messages, the loop ends and the worker wraps.. which is fine.
16:37:46  <pfox___>if i wanted to replace my hand-rolled blocking loop with libuv, im curious how i would approach that. i know my explanation, thus far, is vague. but im just looking for a starting point.
16:37:57  <pfox___>im thinknig i can use a timer to replace the polling aspect of the loop.
16:38:45  <pfox___>but what about actually pushing my messages (which, as i said, are just a string "endpoint" url type thing + a JSON messages payload) into a worker for processing? would a TCP server be aprop, here? (and more importantly: is it portable?)
16:38:46  <bnoordhuis>pfox___: with libuv, you'd use the uv_mutex_* and uv_rwlock_* functions to lock
16:38:58  <bnoordhuis>pfox___: and uv_async_* to wake up other event loops
16:39:08  <bnoordhuis>so you don't have to poll
16:39:41  <bnoordhuis>pfox___: for the records, workers in this context are threads, not processes?
16:39:47  <pfox___>that's great. that's another thing i hoped for.. to move from a poll model to a push model..
16:39:47  <bnoordhuis>*record
16:39:50  <pfox___>yes.
16:39:58  <pfox___>this is all happening within the context of a single process
16:40:05  <pfox___>and it can be assumed that the threads aren't sharing anything
16:40:14  <bnoordhuis>right, in that case the things i said above apply
16:41:10  <pfox___>how do you make an event loop just "hang out" and await messages after calling uv_run() ? that's usually accomplished by registering some kind of socket server, correct?
16:42:09  <bnoordhuis>pfox___: define 'messages'?
16:42:15  <pfox___>events
16:42:37  <pfox___>my understanding is that uv_run will return immediately if there's no pending messages?
16:42:48  <bnoordhuis>no, uv_run blocks indefinitely
16:42:59  <pfox___>ah. good to know.
16:43:08  <bnoordhuis>until the last (non-unref'd) handle closes, that is
16:45:21  <pfox___>so basically anything in uv_handle_type..
16:46:12  <bnoordhuis>yes
16:48:28  * dshaw_joined
16:49:45  * paddybyers_joined
16:53:51  * dapjoined
16:53:52  * paddybyersquit (Ping timeout: 276 seconds)
16:53:52  * paddybyers_changed nick to paddybyers
17:04:45  <pfox___>bnoordhuis: ok, let me see if i got this straight.. so id 1) use uv_async_init() with a uv_loop* and a uv_async_t* .. then 2) later (from any thread), I can use uv_async_send with the uv_async_t* I got in step 1?
17:04:53  <pfox___>and then, like magic.. the uv_loop is awoken in its own thread and the callback registered in step 1 is called
17:05:18  <bnoordhuis>pfox___: that's correct
17:05:34  <pfox___>how would i pass arbitrary data along with the uv_async_send call?
17:05:43  <bnoordhuis>pfox___: you don't
17:06:15  <pfox___>ah. so i just wake it up when a new "message" comes in.. and the callback i regsistered fetches the data itself
17:06:18  <pfox___>fair enough.
17:06:54  <pfox___>but i can still pass in useful things via UV_HANDLE_FIELDS and void* data field..
17:06:54  <bnoordhuis>yep
17:07:24  <pfox___>gotcha. this has been useful. thanks a lot.
17:07:59  <bnoordhuis>pfox___: you'll have to be careful about threading issues if you do that
17:08:17  <pfox___>yes.
17:08:39  <pfox___>the above-mentioned "message exchange" already has a thread-safe (via locks) polling mechanism
17:08:54  <pfox___>which it seems i can reuse.. im just sort of inverting the notification mechanism so that it only polls on demand
17:09:40  <pfox___>or is there something im missing?
17:11:08  <bnoordhuis>pfox___: no, but you probably shouldn't modify handle->date or anything from other threads, that's asking for trouble
17:11:14  <bnoordhuis>just use a mutex-protected queue or something
17:12:21  <pfox___>is there any sane reason to mess with handle state in the course of normal (in-thread) use?
17:13:33  <pfox___>putting aside a multithreaded use case
17:13:51  <pfox___>because it didnt occur to me until you said something.. but if the handle itself is thread-sensitive, that's good to know :)
17:14:18  <bnoordhuis>pfox___: handles are not thread-safe yes
17:14:26  <bnoordhuis>and the only field you should ever touch is handle->data
17:14:49  <bnoordhuis>though i myself never do, i usually wrap the handle in another struct and use container_of to look it up
17:15:40  <pfox___>handles are not thread-safe, with the notable exception of uv_async_send() ?
17:16:02  <bnoordhuis>pfox___: yes
17:17:10  * bnoordhuisis off to dinner
17:17:43  * lwillequit (Quit: Linkinus - http://linkinus.com)
17:23:51  * orlandovftwjoined
17:24:36  * dshaw_quit (Quit: Leaving.)
17:46:40  * sh1mmerjoined
17:55:44  * elijahwrightchanged nick to elijah-mbp
18:05:08  * skabbesjoined
18:08:42  <piscisaureus_>igorzi: yt?
18:09:17  <piscisaureus_>(hopefully he looks at the logs)
18:09:58  * isaacsquit (Remote host closed the connection)
18:10:25  * `3rdEdenjoined
18:11:50  * igorzijoined
18:13:01  <igorzi>piscisaureus_: hey
18:14:43  * TooTallNatejoined
18:15:28  * isaacsjoined
18:22:26  * orlandovftwquit (Ping timeout: 255 seconds)
18:27:02  * dshaw_joined
18:30:57  * lwillejoined
18:34:33  * dshaw_1joined
18:36:36  * dshaw_quit (Ping timeout: 260 seconds)
18:42:23  * AndreasMadsenjoined
18:46:10  <igorzi>piscisaureus_: https://github.com/joyent/node/issues/2635
18:46:39  <igorzi>piscisaureus_: is the issue that path.exists doesn't go through _makeLong?
18:53:53  <piscisaureus_>igorzi: hmm I am not sure
18:54:25  <igorzi>piscisaureus_: because it uses fs binding directly (not through fs.js)
18:54:44  <piscisaureus_>igorzi maybe but that means there must be a bug in libuv as well
18:54:49  <piscisaureus_>igorzi: it is supposed to work
18:55:04  <igorzi>piscisaureus_: right
18:55:15  <piscisaureus_>igorzi: it's probably a regression after I fixed the stat("c:\\") regression
18:55:21  <piscisaureus_>:-()
18:55:33  <piscisaureus_>igorzi: btw that's something I'd like to discuss with you
18:55:55  <piscisaureus_>igorzi: you have a minute on skype?
18:56:16  <igorzi>piscisaureus_: i got a meeting coming up in 5 min.. how about i ping you in about an hour or so?
18:56:34  <piscisaureus_>igorzi: right
18:56:50  <piscisaureus_>igorzi: i can't really skype at home unfortunately. I will type it here
18:57:10  <piscisaureus_>igorzi: the stat fix also make solve stat('../../../..') work
18:57:50  <piscisaureus_>igorzi: I was thinking of replacing libuv's stat() by CreateFile / GetFileInformationByHandle / CloseHandle
18:58:17  <piscisaureus_>that's 3 syscalls, which is as much as the current FindNextFile chant we do now
18:58:29  <igorzi>piscisaureus_: i think that's what CRT's fstat does (except for CreateFile)
18:58:51  <piscisaureus_>igorzi: is there any reason you can think of not to do it?
18:59:05  <piscisaureus_>igorzi: I tried it and it seems to work just fine even on remote drives etc
18:59:20  <igorzi>piscisaureus_: no, i can't think of any reason not to
18:59:24  <piscisaureus_>and locked files (because you can just specify 0 for dwDesiredAccess and it still jsut works)
18:59:33  <piscisaureus_>also we could actually implement lstat :-)
18:59:42  <igorzi>piscisaureus_: nice
19:00:07  <piscisaureus_>igorzi: the only thing I am weary about... if it is that easy, why does crt not do it?
19:00:26  <piscisaureus_>(it actually has all that crap to detect c:\ and \\server\share etc)
19:01:25  <igorzi>piscisaureus_: don't know.. maybe whoever was coding it thought that doing FindNextFile is faster than CreateFile
19:01:33  <igorzi>* CreateFile + GetFileInformationByHandle
19:02:20  <igorzi>piscisaureus_: gtg.. i'll check here for any updates from you
19:02:27  <piscisaureus_>igorzi: yeah ok
19:02:30  <piscisaureus_>igorzi: ttyl
19:02:43  * sh1mmerquit (Ping timeout: 252 seconds)
19:04:33  * `3rdEdenquit (Quit: Leaving...)
19:11:41  * pieternjoined
19:13:48  * orlandovftwjoined
19:16:25  * `3rdEdenjoined
19:23:39  * lwillequit (Quit: Linkinus - http://linkinus.com)
19:24:54  <CIA-115>node: Roman Shtylman master * re97b961 / src/node.h :
19:24:54  <CIA-115>node: add node::SetMethod and node::SetPrototypeMethod
19:24:54  <CIA-115>node: defines cannot be used if the callback is a templated and has
19:24:54  <CIA-115>node: multiple template arguments. The comma separating the arguments
19:24:54  <CIA-115>node: breaks the preprocessor argument handling. Using a templated function
19:24:54  <CIA-115>node: is clearer and more idiomatic in c++. - http://git.io/5aATAQ
19:28:22  * lwillejoined
19:30:07  <isaacs>bnoordhuis: https://github.com/isaacs/libuv/commit/98c0498dbc00850d8d1a01c4111d143d80d96a9b review plz?
19:30:15  <isaacs>bnoordhuis: removing the assert that we should have removed for 0.6.9
19:32:04  * perezdjoined
19:32:26  <bnoordhuis>isaacs: yep, fine by me
19:32:41  <isaacs>k
19:32:42  <isaacs>thanks
19:33:29  <CIA-115>libuv: isaacs v0.6 * r98c0498 / src/unix/pipe.c :
19:33:29  <CIA-115>libuv: unix: Remove assert in uv__pipe_accept
19:33:29  <CIA-115>libuv: This assert unnecessarily prevents people from using the pipe_wrap
19:33:29  <CIA-115>libuv: class in node to send file descriptors over sockets. - http://git.io/Gz5L1Q
19:35:34  * travis-cijoined
19:35:34  <travis-ci>[travis-ci] joyent/libuv#63 (v0.6 - 98c0498 : isaacs): The build is still failing.
19:35:34  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f9b478c...98c0498
19:35:34  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/600426
19:35:34  * travis-cipart
19:39:26  * travis-cijoined
19:39:27  <travis-ci>[travis-ci] joyent/node#337 (master - e97b961 : Roman Shtylman): The build is still failing.
19:39:27  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/836344c...e97b961
19:39:27  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/600399
19:39:27  * travis-cipart
19:44:12  * dshaw_1changed nick to dshaw_
19:47:07  * lwillequit (Quit: Linkinus - http://linkinus.com)
19:48:18  * dshaw_quit (Quit: Leaving.)
19:52:09  * dshaw_joined
19:59:25  * creationixjoined
20:06:53  * sh1mmerjoined
20:08:16  <creationix>isaacs, brace for the flood of feature requests for node
20:09:20  <isaacs>:D
20:09:32  <isaacs>creationix: i'm really good at saying no :)
20:09:55  <creationix>indeed you are
20:09:57  <creationix>keep it up
20:10:04  <creationix>complexity can kill anything
20:11:42  <isaacs>yep
20:11:49  <isaacs>node core is just about done at this point.
20:11:51  <isaacs>lot of polishing,
20:11:57  <isaacs>but we're nearing feature-complete.
20:13:34  <igorzi>bnoordhuis: i'm going to pester you about export/import again :) were you able to make progress on that?
20:13:47  <bnoordhuis>igorzi: working on it now actually
20:14:03  <igorzi>bnoordhuis: ok cool
20:14:15  <bnoordhuis>there's a bug in the test where it copies the uv_async structs that confused libev no end
20:14:38  <piscisaureus_>fucking tele2
20:15:21  <bnoordhuis>piscisaureus_: switched isps?
20:16:13  * pfox___quit (Remote host closed the connection)
20:16:46  <piscisaureus_>bnoordhuis: well I moved so I ordered stuff from tele2
20:16:59  <piscisaureus_>bnoordhuis: but they just fail to process it
20:17:37  <piscisaureus_>bnoordhuis: and the only way to contact the assholes is by calling some super expensive number and then wait for more than 30 minutes
20:17:47  <piscisaureus_>(I gave up after half an hour)
20:17:58  <piscisaureus_>bnoordhuis: ah you are one of them right
20:18:05  <bnoordhuis>piscisaureus_: i used to work for tele2 yes :)
20:18:30  <bnoordhuis>i thought the helpdesk had this cheap local tariff number?
20:18:45  * mjr_joined
20:20:15  <piscisaureus_>nope
20:21:29  <bnoordhuis>piscisaureus_: pro tip: call the amsterdam office, it's local tariff and they'll put you through
20:21:35  <bnoordhuis>only works during office hours though
20:22:09  <bnoordhuis>i'd give you a phone number but i don't know anyone who works there anymore
20:27:21  * markqjoined
20:27:45  * markqpart
20:29:14  * mralephjoined
20:31:23  * skabbesquit (Ping timeout: 244 seconds)
20:32:13  * bradleymeckjoined
20:34:00  * mikeal1quit (Quit: Leaving.)
20:35:10  * AndreasMadsenquit (Remote host closed the connection)
20:35:53  * mikealjoined
20:44:50  <isaacs>piscisaureus_: hey
20:45:08  <isaacs>piscisaureus_: i forgot to mention on the call this morning, i'd like to tag all our APIs with a stability status.
20:45:26  <isaacs>ie, on a scale of 1 to 5, how likely is it that this will look the same in 5 years.
20:45:59  <isaacs>fs.open probably will never change. isolates and cluster, not as reliable. etc.
20:45:59  * piscisaureus_quit (Ping timeout: 248 seconds)
20:46:10  <bnoordhuis>igorzi: https://github.com/bnoordhuis/libuv/compare/export-streams
20:47:07  <bnoordhuis>isaacs: stdio=1
20:47:31  <bradleymeck>isaacs congrats on being the vision guy now, let me know if you need anything (just read the post)
20:47:48  <isaacs>thanks
20:48:05  * isaacsdoesn't know what "vision guy" is.
20:48:10  * isaacswears very thick glasses
20:48:30  <CoverSlide>will you still have time for NodeUp's ?
20:48:45  <bradleymeck>haha isaacs it that gatekeeper / keymaster / w/e. ryah posted thing
20:48:50  <isaacs>right :)
20:48:57  <isaacs>just being dumb.
20:49:06  <bradleymeck>:)
20:49:34  * CoverSlidewould die a little inside if he didn't get to hear isaacs' sexy voice on a regular basis
20:50:19  <isaacs>i'm flattered, but let's keep this room on-topic, please. take the other stuff to #node.js
20:52:22  <isaacs>bnoordhuis: can you make tomorrow at 8pm CET?
20:53:07  <bnoordhuis>isaacs: maybe, i might still be on the train back to gouda
20:53:48  <isaacs>bnoordhuis: can you take a few minutes to write down some things you'd like me to bring up if oyu won't be able to make it?
20:54:20  <isaacs>i'd like to not postpone this unless absolutely necessary, but if it's just me, that's less useful.
20:54:34  * skabbesjoined
20:55:00  <isaacs>i have a feeling it's mostly an initial show of interest, but it'd be good to have a few things to get them interested in
20:55:01  <bnoordhuis>isaacs: it's probably insomnia catching up with me but i'm not quite clear on the goal of that call
20:55:07  <bnoordhuis>"The V8 team has offered to meet with us in order to come up with some
20:55:07  <bnoordhuis>benchmarks for improving Node."
20:55:12  <isaacs>yeah
20:55:17  <bnoordhuis>which is jolly nice of them, of course
20:55:21  <isaacs>they want to make v8 better for node.
20:55:47  <isaacs>i guess they've decided that node is a real thing, and that node's failure will reflect badly on them, so they want to have some measurable way to know if they're making node better.
20:55:59  <isaacs>afaict, it's all about strings.
20:56:05  <bnoordhuis>i think the feature i would like best is advanced heap inspection
20:56:12  <isaacs>yes, that'd be nice.
20:56:29  <bnoordhuis>though i haven't really thought through how that should work
20:56:59  <bnoordhuis>i'll think about for a bit and send you an email (or ping you here)
20:57:05  <isaacs>if we had a way to prevent heap shuffling for a moment, we could do some useful stuff with writev and cut down our syscall overhead and string-copying stuff.
20:57:25  <isaacs>we can already get an array of pointers to raw string data, but we can't do anything async with it, since the heap might move.
20:57:52  <bnoordhuis>oh, i think that's something were we just need to use buffers more and more
20:58:03  <bnoordhuis>and actively discourage people to read / send strings
20:58:06  <isaacs>sure.. but that kind of sucks for a lot of use cases.
20:58:14  <isaacs>you can't json.decode a buffer, for instance.
20:58:26  <bnoordhuis>that'd be a nice feature actually
20:59:43  <isaacs>the problem is, in real life, it's just a lot better to work with strings in a lot of cases.
21:00:03  <isaacs>for example, http headers are *always* converted to strings
21:00:25  <isaacs>you can test equality, search in them, split them, etc
21:00:32  <isaacs>reproducing that whole api for buffers would be unreasonable.
21:01:03  <bnoordhuis>i think v8 has ExternalString types for that
21:01:16  <bnoordhuis>but we don't use them and i confess i never looked into it much
21:01:49  <isaacs>yeah, same here.
21:02:34  <isaacs>maybe there's some interesting approach we could take to use those and provide a string api on top of arbitrary non-heap-shifting data.
21:05:17  * bradleymeckquit (Quit: Leaving)
21:27:19  * mikealquit (Quit: Leaving.)
21:31:17  * piscisaureus_joined
21:34:06  * piscisaureus__joined
21:38:43  * toothrjoined
21:44:08  * sh1mmerquit (Quit: sh1mmer)
21:44:52  * sh1mmerjoined
21:46:56  * piscisaureus_quit (Read error: Connection reset by peer)
21:47:41  * creationixpart ("Ex-Chat")
21:50:44  * piscisaureus_joined
21:51:29  * piscisaureus_quit (Read error: Connection reset by peer)
21:54:28  <mjr_>bnoordhuis: in that meeting, you could certainly mention the UCS-2 thing, although I understand that they are just following the ECMA spec.
21:54:49  <isaacs>mjr_: i'm going to bring it up
21:54:51  <mjr_>And isaacs has pointed me to a string decoder that seems like it might work, but it's crazy.
21:55:00  <isaacs>mjr_: yes, it is indeed crazy :)
21:55:05  <isaacs>mjr_: but interesting
21:55:19  * isaacschanged nick to isaacs_thanks
21:55:22  <mjr_>Yes, very interesting.
21:55:27  * isaacs_thankschanged nick to isaacs
21:55:31  <isaacs>oh, i guess that's everywhere...
21:55:33  <isaacs>heh
21:56:33  <piscisaureus__>isaacs: can we get an array of raw string pointers?
21:56:39  <piscisaureus__>isaacs: I don't know how
21:56:48  <isaacs>piscisaureus__: i thought that there was some api to do that already
21:57:01  <isaacs>piscisaureus__: i recall some talking between ryah and mraleph about that
21:57:16  <isaacs>but it's no good, because at the end of the tick, it can all move around
21:57:18  <mraleph>I don't want to run ahead of the train but you should think about pure JS benchmarks not about APIs.
21:57:25  <isaacs>mraleph: yes, indeed.
21:57:50  <isaacs>mraleph: so, currently, a very relevant speed problem is copying data into and out of strings.
21:57:51  <piscisaureus__>isaacs: ah I never saw that
21:58:07  <piscisaureus__>isaacs: that is just an assumption really
21:58:21  <mraleph>isaacs: are we going to have a call tomorrow?
21:58:26  <isaacs>yes.
21:58:29  <piscisaureus__>I am for it
21:58:37  <piscisaureus__>isaacs: but you have to cancel the call with claudio
21:58:53  * piscisaureus_joined
21:58:58  <isaacs>piscisaureus__: i emailed claoudio about it. i'd like to have him on this, as well, if only as a listener.
21:59:10  <piscisaureus__>isaacs: ah, sure
22:00:24  <piscisaureus__>http://substack.net/images/coronation.png lol
22:03:24  <mraleph>piscisaureus__: last time we were talking about immovable raw string pointers there were no evidence that copying characters is bottleneck.
22:03:51  <mraleph>it was roughly a year ago or maybe even more :-)
22:04:30  <isaacs>i see.
22:04:54  <isaacs>mraleph: we have found that sending buffers over the wire is measurably faster than sending strings.
22:05:10  <isaacs>mraleph: the "hello, world" benchmark shows this very conclusively.
22:05:54  <mraleph>ok. maybe things changed over time as other parts of the system became faster.
22:06:26  <mraleph>thats obvious that non-copying characters is better than copying characters :-)
22:06:28  * piscisaureus_quit (Ping timeout: 252 seconds)
22:06:29  * piscisaureus__quit (Ping timeout: 252 seconds)
22:06:38  <isaacs>mraleph: :)(
22:06:42  <isaacs>mraleph: then we also have this thing: http://comments.gmane.org/gmane.comp.lang.javascript.nodejs/30282
22:07:42  <mraleph>that should become better in the recent V8, where idle notifications do things more gently.
22:07:48  <isaacs>that's good to know
22:08:16  <isaacs>mraleph: there's someone in #node.js saying that he was bumping into that, but i'm not sure yet. waiting on a simplified test.
22:08:26  <mraleph>though just invoking idlenotification in a loop might be still a bit "overzealous"
22:09:54  <mraleph>ah I see the issue was not updated despite the fact that work mostly has been completed there.
22:11:05  <mraleph>isaacs: yeah, testcases are very important; hard to diagnose anything without them :-)
22:13:16  <isaacs>bnoordhuis: think it's worth doing a 0.7.2 today?
22:13:26  * piscisaureus_joined
22:14:02  <mraleph>bnoordhuis: what do you mean by heap inspection?
22:14:11  <isaacs>oh, yeah, there is definitely a bunch of stuff.
22:15:00  * piscisaureus___joined
22:17:52  * piscisaureus_quit (Ping timeout: 252 seconds)
22:18:43  * piscisaureus__joined
22:19:16  * piscisaureus__changed nick to piscisaureus
22:19:47  <piscisaureus>isaacs: I am very curious why luvit is supposedly so much faster than node?
22:20:14  <isaacs>piscisaureus: the claim i've heard is that there's no string magic going on.
22:20:24  <piscisaureus>mraleph: Why should it all be javascript-only benchmarks? I'd say api performance is important too.
22:20:49  <isaacs>yeah, restricting the plan to pure-js benchmarks seems somewhat limiting.
22:20:55  <mraleph>piscisaureus: because there is no way to run API benchmarks in the browser.
22:21:18  <isaacs>right, but... as far as i've seen, pure-js is almost never the bottleneck in node.
22:21:24  <isaacs>unless you're doing something very strange.
22:21:47  <piscisaureus>isaacs: well, node-mysql
22:21:57  <isaacs>piscisaureus: like i said, very strange :)
22:22:13  <piscisaureus>isaacs: although felix's story was that as soon as he switched from buffers to strings, stuff got much faster
22:22:24  <isaacs>yeah.
22:22:28  <isaacs>which is interesting...
22:22:48  <mjr_>Two issues I know of with Lua: 1) no cons strings, so all strings are already bare pointers, and they don't get cleaned up out from under you, 2) less magic type coercion, so luajit has an easier time generating efficient code.
22:23:10  <mjr_>Not much to do about 2 that isn't already being done, I'd imagine.
22:23:23  <mraleph>reading number from a buffer is much slicker than indexing into a string
22:23:42  <mraleph>mjr_: oh, there are a lot of stuff to do :-)
22:23:45  <isaacs>mjr_: right, but they kill us on teh string/buffer stuff, because lua has no concept of utf-8 strings.
22:24:01  <piscisaureus>v8 also has no utf8 strings
22:24:03  <isaacs>mjr_: effectively, lua strings *are* buffers
22:24:06  <mjr_>mraleph: OK, I'm sure you guys have a lot more to do. Don't let me slow you down. :)
22:24:11  <isaacs>piscisaureus: er... ucs-2 strings :)
22:24:19  <isaacs>mjr_: no, your input is hugely valuable.
22:24:26  <isaacs>mjr_: where have you seen node be sadly slow?
22:24:49  <piscisaureus>I sometimes have seen it sadly slow
22:25:15  <isaacs>in my experience, the sad slowness is pretty much always the threadpool, and then usually becasue i'm doing way more syscalls than i ought to
22:25:19  <mjr_>Oh, I dunno. I'm a lot happier with V8 after we upgraded to 0.6. Getting crankshaft applied to Buffer index ops with [] was a big win for us, I think.
22:25:31  * AvianFluquit (Quit: Leaving)
22:25:32  <piscisaureus>I think that especially was very good for node
22:25:34  <isaacs>it's very easy to do something dumb and end up doing 2 syscalls instead of 1 in some place, and suddenly your performance drops in half.
22:25:35  <mjr_>I see sad slowness with disk IO for sure.
22:25:48  <piscisaureus>yeah we have to look into that.
22:26:17  <mjr_>I was complaining to isaacs about this last week, general disk IO bitching.
22:26:43  <TooTallNate>isaacs: glad to hear about the addon build system :)
22:26:53  <TooTallNate>i was about to take that one upon myself
22:26:54  <isaacs>TooTallNate: don't be so glad yet, it's still vapor :)
22:26:55  <mjr_>What I've seen is that disk IO performance works fine, and then it goes off a cliff, and once it gets back, it's almost impossible to make it get good again without killing the process.
22:27:03  <isaacs>TooTallNate: if you would like to take it on, i would appreciate it.
22:27:15  <piscisaureus>mjr_: a test case would rock :-)
22:27:33  <mjr_>But node still seems a bit too slow and simply proxying bytes between sockets.
22:27:33  <isaacs>mjr_: it seems like it might be worthwhile to have some kind of intelligently-throttling fs stream util.
22:27:38  <TooTallNate>isaacs: ok well i'll consider it still then
22:27:46  <piscisaureus>mjr_: I think the synchronization between the main thread and the thread pool is way too heavy as it stands
22:28:02  <TooTallNate>isaacs: the other problem, storing and loading the proper binary, i've solved here:
22:28:03  <TooTallNate>https://github.com/TooTallNate/node-bindings
22:28:14  <TooTallNate>but i know npm will/should take care of that eventually
22:28:27  <piscisaureus>isaacs: someone sent us a pull req for installing node.lib and headers on windows. Do we want that?
22:28:35  <isaacs>piscisaureus: no.
22:28:37  <TooTallNate>piscisaureus: i say no
22:28:45  <isaacs>piscisaureus: we *do* need something.
22:28:46  <isaacs>and soon.
22:29:10  <mjr_>piscisaureus: I wish I had a test case. I only just barely understand what's happening with it.
22:29:20  <isaacs>piscisaureus: I'm writing up a high-level roadmap of what i think we need to accomplish as soon as possible, but specifically before we can 0.7->0.8
22:29:24  <isaacs>piscisaureus: i'll send it to you.
22:29:30  <mjr_>We've thrown enough hardware at the problem right now, that I haven't seen it lately.
22:29:39  <piscisaureus>isaacs: I told the azure guys that we considered installing all binary addons globally, and they got very nervous
22:29:44  <isaacs>hhahah
22:29:46  <isaacs>how come?
22:29:56  <mraleph>isaacs & piscisaureus: you should raise your concerns about strings and API speed tomorrow; but also think about pure js stuff :-) I am going to sleep now. Looking forward to talking to you tomorrow.
22:29:58  <isaacs>(that's probably not going to be workable for other reasons, just curios)
22:30:06  * mralephquit (Quit: Leaving.)
22:30:09  <isaacs>mraleph: yes, same here. thanks :)
22:30:13  <isaacs>d'oh, missed him
22:30:22  <TooTallNate>why would we need to install addons globally?
22:30:32  <piscisaureus>he'll read the logs. mralpeh: yes, looking forward to it
22:30:34  <isaacs>TooTallNate: so, this was one idea about making binary addons suck less.
22:31:00  <piscisaureus>isaacs: well they basically bet on offering a bare vm with node
22:31:13  <isaacs>TooTallNate: binary addons change very rarely, and since they actually *can't* call require(), they never depend on js modules.
22:31:22  <piscisaureus>isaacs: and then users can drop all their dependencies via deploy
22:31:36  <isaacs>TooTallNate: it'd be simpler to just admit that they're a Different Thing, and handle .node files kind of like php's .so modules.
22:31:44  <piscisaureus>isaacs: but for the details, I invited glenn block to our msft meeting, but we keep on cancelling it :-)
22:31:45  <isaacs>piscisaureus: i see.
22:31:57  <TooTallNate>but what about the JS layer that make the C bindings all nice to use?
22:32:14  <TooTallNate>that part might depend on other modules
22:32:16  <isaacs>TooTallNate: yeah, it's not a trivial path to get there.
22:32:25  <isaacs>TooTallNate: but we need to get away from where we're at now.
22:32:32  <isaacs>i think a smaller step would be good to do first.
22:32:35  <TooTallNate>i don't like it personally, doesn't seem necessary
22:33:19  <isaacs>TooTallNate: in retrospect, i sometiems really wish i'd just said that npm is for js only.
22:33:35  <isaacs>but it probably wouldn't have taken off, since a lot of the early ndoe modules were binary addons for various platforms.
22:33:43  <isaacs>(or for things that ended up being pulled into node-core)
22:34:00  <mjr_>isaacs: by far my largest issue with node right now is this unicode thing. After that, it's probably 64 bit ints. Both of these things are pure V8 issues, but it sounds like the spec needs to change first. I'd hope that V8 could help us here somehow.
22:34:12  <sh1mmer>mjr_: I think the unicode thing is huge
22:34:34  <mjr_>I cornered Brendan about this at Node Summit, by sitting next to him at dinner.
22:34:36  <isaacs>yes, if v8 can't supply some solution to that, then we in node have to figure out a general purpose workaround.
22:34:41  <tjfontaine>it's a tough needle to thread, but I don't think it's terrible to expect lusers to have to deal with more pain for binary addons than pure-js, it's certainly how every other scripting language I've dealt with has worked
22:35:15  <mjr_>So he couldn't ignore me. His position is one of resignation. Sounds like nobody on the committee wants to deal with "modes" or "big red switches" that engage new functionality. This is a problem.
22:35:18  <sh1mmer>tjfontaine: if you have to have a binary add-on it's probably you know what you are doing and can deal with that
22:35:40  <piscisaureus>mjr_: I think we just need an option that converts non-BMP characters into surrogate pairs
22:35:46  <sh1mmer>mjr_: they already have "strict" I don't understand why this is such a big deal
22:35:59  <piscisaureus>mjr_: there is little hope otherwise, since we cannot change the spec
22:36:02  <mjr_>I'm bummed about the modes. Seems like such an obvious solution.
22:36:07  <isaacs>what we need to do is say that UCS-2 is a mistake, and use UTF-16 instead.
22:36:13  <mjr_>isaacs: yes
22:36:23  <isaacs>is there any program out there that depends on UCS-2's failure to interpret surrogate pairs?
22:36:24  <isaacs>seriously
22:36:27  <sh1mmer>mjr_: you said it was a requirement of the spec
22:36:31  <sh1mmer>I thought I read it was optional
22:36:34  <mjr_>That is the right solution, but it needs to be opt-in, because some people depend on ucs-2 behavior.
22:36:42  <sh1mmer>you had to implement either uc2 or utf-8
22:36:48  <isaacs>"Nono, you can't break my program, it DEPENDS on getting garbage characters from chinese users"
22:36:49  <isaacs>bullshit.
22:36:54  <mjr_>People do that fucking clever binary string packing thing like we used to do in node.
22:37:18  <isaacs>mjr_: i don't think that clever binary string packing is a valid use case.
22:37:18  <isaacs>but ok
22:37:26  <isaacs>"use nonretardedunicodestrings"
22:37:29  <mjr_>That's what Brendan said was the holdup.
22:37:39  <piscisaureus>I don't think we should really go for UTF16/UTF8
22:37:54  <piscisaureus>it hurts string indexing etc a lot
22:37:57  * isaacsso sad about javascript...
22:38:04  <sh1mmer>mjr_: but anything brendan does is going to be harmony
22:38:08  <sh1mmer>and that's still going to be a while
22:38:12  <piscisaureus>unless you want to use 32-bit internal representation for strings
22:38:19  <isaacs>yeah, if you need solutions today, be's not the guy to talk to
22:38:24  <mjr_>Obviously there are tradeoffs.
22:38:25  <isaacs>he lives 5 years in teh future.
22:38:38  <mjr_>Sure, my question was really why hasn't this happened yet, it seems to obvious.
22:38:47  <sh1mmer>the problem is finding a solution to this that can span the browser and node
22:39:00  <sh1mmer>mjr_: so does a good number system and modules
22:39:17  <sh1mmer>"good"
22:39:36  <piscisaureus>well I like the export keyword
22:39:38  <piscisaureus>for modules
22:40:38  <mjr_>Surely if you opt in to full UTF-8 with some kind of "use UTF-8", the VM could detect and adapt the proper internal representation for the strings depending on if they exceed the BMP.
22:40:49  <isaacs>mjr_: yes, that would be nice.
22:40:53  <mjr_>Just like they already do for all types
22:40:54  <isaacs>"use unicode" even
22:41:00  <mjr_>use unicode, sure.
22:41:10  <isaacs>then your strings just do the right thing
22:41:17  <isaacs>instead of being limited to 2 bytes forever everywhere
22:41:28  <sh1mmer>isaacs: atomic modes also seems like a reasonable solution
22:41:28  <mjr_>But they already have to apply lots of special magic for string construction and concatenation, so they have all the hook they need, so it would seem to me.
22:41:41  <bnoordhuis>isaacs: re 0.7.2: not much of interest has happened since 0.7.1
22:41:50  <isaacs>bnoordhuis: yeah, i'm going to drop it tomorrow instead.
22:42:01  <isaacs>bnoordhuis: the community already has had a big news day :)
22:42:09  <bnoordhuis>quite so :)
22:42:17  <piscisaureus>hehe
22:43:09  <piscisaureus>isaacs: so what does it mean for you? Will you now also have more time to actually do node work?
22:43:35  <piscisaureus>(good to finally be able to discuss this in public btw)
22:44:34  <isaacs>indeed :)
22:44:51  <isaacs>piscisaureus: allegedly all of my time currently is devoted to doing node work.
22:44:58  <piscisaureus>isaacs: aha
22:45:00  <sh1mmer>hey isaacs we need you to fix no.de stat!
22:45:03  <sh1mmer>:P
22:45:44  <piscisaureus>It's funny that ryan actually went offline
22:46:01  <sh1mmer>I assumed he's doing hipster things with Lisa
22:46:18  <piscisaureus>hehe
22:46:28  <piscisaureus>he always denied being a hipster
22:46:32  <isaacs>sh1mmer: yeah, it'd be better if that was more of a joke and less of a reality.
22:46:39  <sh1mmer>that's because he's a natural hipster
22:46:47  <sh1mmer>I'm a somewhat manufactured hipster
22:46:51  <isaacs>true hipsters are adamantly anti-hipster.
22:47:29  <isaacs>piscisaureus: anyway... yes, what ryan said in his email is true, though. there's more work to be done outside of core than within it.
22:47:38  <isaacs>at least, in terms of inventing new things.
22:47:40  <sh1mmer>although I've always denied being a hipster, because I have enough money to eat square meals
22:47:49  <isaacs>node-core has a lot of polish necessary, as you know well.
22:48:03  <piscisaureus>isaacs: we'll ssee where it ends up
22:48:06  <bnoordhuis>piscisaureus: what time will you be in tomorrow?
22:48:16  <piscisaureus>isaacs: there's so much I would do when I had time :-)
22:48:25  <piscisaureus>bnoordhuis: dunno. name it
22:48:29  <piscisaureus>bnoordhuis: I will be there
22:48:33  <piscisaureus>when you arrive
22:48:47  <bnoordhuis>okay, i'll try to get up at 10
22:48:52  <piscisaureus>ghe
22:48:59  <piscisaureus>so you'll arrive just before lunch?
22:49:13  <piscisaureus>or more like 2pm?
22:49:21  <bnoordhuis>an hour or two before lunch, i think
22:49:28  <bnoordhuis>provided mees doesn't keep me up like last night
22:49:48  <piscisaureus>bnoordhuis: we would have the libuv hack day
22:50:00  <bnoordhuis>i'm game
22:50:14  <piscisaureus>isaacs: are you also the libuv gatekeeper now?
22:50:20  <bnoordhuis>we can start a little later and stick around until 8 pm
22:50:20  * piscisaureusonly cares about libuv
22:50:28  <isaacs>piscisaureus: technically, yes, but you know libuv much better than i do.
22:50:32  <sh1mmer>anyone know the easiest way to instal glibc symbols on a mac?
22:50:41  <bnoordhuis>sh1mmer: glibc on a mac?
22:50:47  <sh1mmer>libc then
22:50:55  <bnoordhuis>that i don't know
22:57:08  <arlolra>isaacs: npm install cesu-2
22:57:12  <arlolra>cesu-8
22:57:13  <arlolra>oops
22:57:56  <isaacs>neat :)
22:58:00  <isaacs>mjr_: ^
22:58:25  <mjr_>Cool, I'll give it a try.
22:58:30  <mjr_>Not today, but soon.
22:58:54  <sh1mmer>mjr_: do you have a write up of your issue somewhere public?
22:59:27  <mjr_>Hmm, not really. I have an email from one of our iOS engineers.
22:59:53  <sh1mmer>k
23:00:51  <mjr_>I've asked him to put it on his blog, so I don't forward around his internal email.
23:01:25  <sh1mmer>mjr_: this issue will definitely affect others, even if they aren't there yet
23:02:43  <isaacs>mjr_: that email is so saddening.
23:02:48  <isaacs>mjr_: it breaks my heart every time i read it.
23:03:02  <mjr_>I do like this part though:
23:03:03  <mjr_>Unicode: U+1F604 (U+D83D U+DE04), UTF-8: F0 9F 98 84
23:03:12  <mjr_>That is in the fucking spec.
23:03:43  <igorzi>bnoordhuis: https://github.com/bnoordhuis/libuv/commits/export-streams is good to be landed?
23:03:58  <bnoordhuis>igorzi: in the sense that it works for me
23:04:12  <bnoordhuis>you may want to try the test case for yourself, i modified it quite a bit
23:04:41  <igorzi>bnoordhuis: yeah, will do
23:06:32  <mjr_>sh1mmer: here it is
23:06:32  <mjr_>https://gist.github.com/1707371
23:11:23  <piscisaureus>igorzi: did you sit down with your colleage yet?
23:11:29  <piscisaureus>igorzi: or - when is that going to happen?
23:11:48  <piscisaureus>igorzi: (the nothing works on windows bug)
23:12:03  <igorzi>piscisaureus: will debug it in about 30 min (he needed his laptop for most of the day)
23:12:21  <isaacs>arlolra: https://gist.github.com/1707371
23:13:43  <sh1mmer>mjr_: your engineers make me SMILING FACE WITH OPEN MOUTH AND SMILING EYES
23:19:00  <arlolra>isaacs: yikes. UCS-2 has no notion of no notion of surrogate pairs, but doesn't seem to mind them being there, for all extents and purposes
23:19:20  <piscisaureus>
23:19:50  <piscisaureus>^-- U+10FE44 FUCKING ASSHOLE WITH DICK ON HIS NECK
23:20:02  <arlolra>ha
23:20:19  <piscisaureus>let me submit an rfc for that
23:20:21  <piscisaureus>anyway
23:20:38  <arlolra>piscisaureus: https://github.com/arlolra/node-cesu-8
23:21:34  <piscisaureus>arlolra: that's correct. The ranges that were defined to be surrogate low/high characters were only defined to be invalid when UTF16 was invented
23:21:45  <piscisaureus>arlolra: before that they were just "unused"
23:22:44  <piscisaureus>arlolra: you should also know that the ECMA spec doesn't specify that javascript uses UCS2. It just says that a string is an array of unsigned 16-bit values,
23:24:40  <arlolra>interesting and weird
23:28:25  <`3rdEden>arlolra totally unrelated but the const keyword is pretty much not yet optimized by V8, so i would change that to var statement in your cesu-8 ;)
23:29:12  <arlolra>`3rdEden: thanks
23:31:14  * mikealjoined
23:32:41  <igorzi>bnoordhuis: verified that it works on windows; landing your patches in master
23:33:38  <bnoordhuis>igorzi: cool
23:34:51  <CIA-115>libuv: Ben Noordhuis master * r812e410 / test/test-ipc-threads.c : test: fix up stream import/export test (+5 more commits...) - http://git.io/bJeN-w
23:36:53  * travis-cijoined
23:36:53  <travis-ci>[travis-ci] joyent/libuv#64 (master - 812e410 : Ben Noordhuis): The build is still failing.
23:36:53  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/3de0411...812e410
23:36:53  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/601741
23:36:53  * travis-cipart
23:43:42  <igorzi>piscisaureus: of course it doesn't reproduce now
23:44:00  <piscisaureus>igorzi: heh
23:44:05  <piscisaureus>igorzi: that sucks
23:44:29  <piscisaureus>igorzi: different user account?
23:44:35  <piscisaureus>igorzi: different network?
23:45:38  * AvianFlujoined
23:45:48  <igorzi>not sure.. he was definitely trying to use it on a different network
23:52:04  <igorzi>piscisaureus: what about the other issue (with Corky)?
23:52:28  <piscisaureus>igorzi: basically for Corky the http server example from the website didn't work
23:52:46  <igorzi>piscisaureus: did you ever get more info from him?
23:52:56  * `3rdEdenquit (Quit: Zzzzz)
23:53:09  <piscisaureus>igorzi: no. I reached out to a couple of people with this issue but never got anything valueable back
23:54:02  <piscisaureus>igorzi: does the node http server example work on that machine?
23:54:48  <igorzi>piscisaureus: hold on
23:55:41  <igorzi>piscisaureus: yep, it works
23:56:02  <piscisaureus>hmm
23:56:03  <piscisaureus>crap