00:03:14  <dmkbot>joyent/node: tjanczuk: Support for building MSI installers on Windows - https://github.com/joyent/node/issues/1706
00:08:50  * felixgejoined
00:08:50  * felixgequit (Changing host)
00:08:50  * felixgejoined
00:09:35  <felixge>I'm meeting with the principal program manager of the chakra engine tomorrow, she wants to know if we want node running on chakra
00:09:39  <felixge>what should I tell her? :)
00:10:34  <mikeal>bnoordhuis: nope, i don't publish it or maintain it
00:11:03  <bnoordhuis>felixge: have them send over the source and we'll have a look
00:11:31  <felixge>bnoordhuis: hah
00:11:36  <felixge>bnoordhuis: yeah right
00:11:40  <felixge>:)
00:11:43  <mikeal>i just talk on it
00:11:55  <bnoordhuis>tell her she gets bonus points for relicensing it under the mit license :)
00:11:56  <felixge>I'll tell her they should do it if they think their JS engine stands a chance
00:11:57  <felixge>:D
00:12:00  <igorzi>ryah: https://github.com/joyent/node/pull/1706
00:12:56  <bnoordhuis>mikeal: tell me, how does it feel to be married?
00:13:51  <igorzi>felixge: are you meeting with amanda?
00:13:51  <mikeal>it's nice
00:13:56  <felixge>igorzi: yes
00:14:05  <igorzi>felixge: tell her i said hi :)
00:14:06  <mikeal>:)
00:14:24  <felixge>igorzi: will do. Is your first name Igor (infering from your IRC handle)?
00:14:46  <bnoordhuis>mikeal: any different from just living together?
00:15:04  <igorzi>felixge: yep
00:15:04  <mikeal>yeah, surprisingly
00:15:13  <mikeal>we've been together for 7 years, and it's still different being married
00:15:21  <felixge>igorzi: cool, I'll say hello for you.
00:15:23  <bnoordhuis>in what respect?
00:15:32  <felixge>I have to say the windows 8 JS apis are pretty cool
00:15:46  <igorzi>felixge: we used to work together on a previous team..
00:15:51  <felixge>igorzi: cool
00:15:56  <felixge>igorzi: which one?
00:16:02  <igorzi>felixge: VS
00:28:14  <dmkbot>joyent/node: isaacs: hasOwnProperty usage - https://github.com/joyent/node/issues/1707
00:28:15  <dmkbot>joyent/node: isaacs: hasOwnProperty usage - https://github.com/joyent/node/issues/1707
00:36:11  * mikealquit (Quit: Leaving.)
00:41:24  <ryah>igorzi: nice
00:45:44  <bnoordhuis>ryah: did you start on the kqueue stuff yet?
00:45:59  <ryah>bnoordhuis: no
00:46:12  <ryah>bnoordhuis, igorzi: also - i think there's a problem with uv_fs_event api
00:46:19  <bnoordhuis>now he tells us!
00:46:50  <bnoordhuis>but what i wanted to say, i can take care of freebsd if you double-check darwin
00:46:56  <bnoordhuis>*on darwin
00:47:53  <igorzi>ryah: what's the issue with the api?
00:48:43  * felixgequit (Quit: felixge)
00:51:42  <ryah>(sorry office hours is taking my attention)
00:51:55  <ryah>i dont think we can provide the "filename" paramenter in the callback
00:52:14  <bnoordhuis>why not?
00:54:05  <bnoordhuis>now handle->filename, i don't mind seeing that one go, it's superfluous / unnecessary
00:54:42  <ryah>bnoordhuis: i dont think you get that in kqueue
00:54:52  <ryah>you can watch a dir, and know that something hanged, but not what changed
00:55:18  <ryah>we'd need to do dir listing all the time to know..
01:00:15  <bnoordhuis>hmm, you may be right
01:00:21  <bnoordhuis>(checking the freebsd source)
01:01:28  * ericktquit (Quit: erickt)
01:05:43  * felixgejoined
01:10:27  <ryah>so basically i think we need to throw away information on linux and windows
01:10:28  <ryah>:(
01:10:38  <ryah>lowest common denominator
01:12:18  <indutny>ryah: doing overwork for linux to have a it working on windows?
01:12:51  <bnoordhuis>ryah: that kind of sucks
01:13:05  <bnoordhuis>what about darwin's fsevents or whatever it's called?
01:13:36  <rmustacc>bnoordhuis: fsevents only tells you what directory it is in a directory tree.
01:13:57  <bnoordhuis>rmustacc: oh, that doesn't help either
01:14:47  * brsonquit (Ping timeout: 258 seconds)
01:18:05  <rmustacc>bnoordhuis: No it doesn't.
01:18:50  <rmustacc>fsevents is really just a more Apple-y kqueue for dir change notification.
01:22:45  * brsonjoined
01:22:53  <bnoordhuis>so how does mdfind work? it seems to pick up changes immediately
01:43:44  <igorzi>ryah: bnoordhuis: yeah, that sucks.. what about making filename parameter (on the callback) optional? is that out of the question?
01:44:48  <ryah>maybe we can split it into two calls
01:45:06  <ryah>first you do fs.watch("something/dir", function() { })
01:45:20  <ryah>then inside the callback do fs.getChanges("something/dir")
01:45:34  <ryah>and on windows and linux it will just cache the changes as it gets them
01:45:49  <ryah>on solaris and osx it will do a readdir
01:46:30  * brsonquit (Ping timeout: 260 seconds)
01:47:16  <felixge>ryah: the call would need a callback then
01:47:24  <felixge>or would you want to block on solaris/osx?
01:48:54  <igorzi>ryah: fs.getChanges just returns file/event pairs?
01:49:00  * felixgequit (Read error: Connection reset by peer)
01:49:05  <bnoordhuis>this makes me unhappy
01:49:14  <bnoordhuis>but i can't think of a fundamentally better way :/
01:50:44  <igorzi>maybe getChanges should be on the object that is returned from fs.watch()?
01:53:02  <bnoordhuis>perhaps, but that's just icing, not fundamentally better
01:56:18  <igorzi>so, if my understanding is correct, solaris and osx would do readdir before and after to know what actually changed.. could this be done in libuv behind the proposed interface?
01:57:26  <bnoordhuis>not efficiently if you always have to pass the filename parameter
01:58:32  <igorzi>i know it's ugly, but is it somehow less ugly than doing it in node? (assuming people will call getChanges for every event)
02:00:16  <bnoordhuis>the thing is that watching a directory without caring what actually changed is a valid use case
02:00:26  <bnoordhuis>it's what some modules use to dynamically reload stuff
02:01:07  <bnoordhuis>in most cases those watched directories will have few entries so doing a full scan won't hurt
02:01:33  <bnoordhuis>but that's a dangerous assumption
02:01:55  <bnoordhuis>and there are probably other use cases i can't think of right now
02:09:49  * bnoordhuisis off to bed
02:10:12  * bnoordhuisquit (Quit: Leaving)
02:17:30  * mikealjoined
02:26:36  * ericktjoined
02:54:09  * isaacsquit (Quit: isaacs)
03:13:14  <dmkbot>joyent/node: bronson: Can't execute repl with node -e - https://github.com/joyent/node/issues/1708
04:08:14  <dmkbot>joyent/node: seebees: Tests for Sockets - https://github.com/joyent/node/issues/1699
04:08:47  * isaacsjoined
04:23:14  <dmkbot>joyent/libuv: erickt: Fix a couple warnings, added some asserts, and compiling with gcc-4.5 and mingw-w64 - https://github.com/joyent/libuv/issues/186
04:51:50  <isaacs>ryah: zlib branch ready for review.
05:00:28  * isaacsquit (Quit: isaacs)
05:09:18  <ryah>isk
05:21:19  * felixgejoined
05:21:35  * isaacsjoined
05:39:24  * felixgequit (Read error: Connection reset by peer)
05:47:57  * felixgejoined
06:00:26  * felixgequit (Ping timeout: 252 seconds)
07:06:11  * mralephjoined
07:14:00  * isaacsquit (Quit: isaacs)
08:22:52  * mikealquit (Read error: Connection reset by peer)
08:22:57  * mikealjoined
08:48:17  * mralephquit (Quit: Leaving.)
08:53:13  <dmkbot>joyent/node: seebees: Tests for Sockets - https://github.com/joyent/node/issues/1699
08:58:13  <dmkbot>joyent/node: seebees: Tests for Sockets - https://github.com/joyent/node/issues/1699
09:03:13  <dmkbot>joyent/node: seebees: Tests for Sockets - https://github.com/joyent/node/issues/1699
09:18:13  <dmkbot>joyent/node: runner-mei: a Run-Time Check Failure #3 at window while call child_precess.spaw(undefine) - https://github.com/joyent/node/issues/1709
10:13:13  <dmkbot>joyent/node: BillBarnhill: Fix memory allocation in uv__fs_after - https://github.com/joyent/node/issues/1686
12:35:25  * ericktquit (Quit: erickt)
13:33:18  * pieternjoined
13:52:20  * piscisaureusjoined
13:56:46  * dmkbot1joined
13:59:45  * dmkbotquit (Ping timeout: 260 seconds)
14:44:35  * mikealquit (Quit: Leaving.)
15:06:43  <dmkbot1>joyent/node: exi: std::bad_alloc exception if a too big buffer is allocated - https://github.com/joyent/node/issues/1710
15:21:57  * brsonjoined
15:35:13  * isaacsjoined
15:36:15  * ericktjoined
15:46:43  <dmkbot1>joyent/node: davglass: HTTP parser fails if server returns no headers - https://github.com/joyent/node/issues/1711
15:54:04  * ericktquit (Quit: erickt)
15:56:43  <dmkbot1>joyent/node: isaacs: hasOwnProperty usage - https://github.com/joyent/node/issues/1707
16:01:18  <isaacs>so, pretty much all our files seem to have this cpplint error: Do not use namespace using-directives. Use using-declarations instead.
16:01:35  <isaacs>are we going to stop caring about this, or stop do `using namespace v8;`?
16:05:45  <indutny>isaacs: should we do `namespace v8 { ... }`
16:05:56  <isaacs>ahh, i see
16:06:01  <indutny>I think we should ignore that
16:06:15  <indutny>because we would need to prefix all v8 stuff otherwise
16:06:22  <indutny>or move `node` namespace behind v8
16:06:28  <indutny>v8::node::Buffer
16:06:35  <indutny>that doesn't sounds good
16:06:43  <isaacs>yeah, it's painful to not have the v8 namespace already there
16:06:50  <isaacs>conflicts are rare and easily avoided anyway
16:07:08  <isaacs>indutny: got it passing now, thanks :)
16:07:14  <indutny>isaacs: np
16:07:15  <indutny>:)
16:08:41  <indutny>good morning, btw
16:09:00  <indutny>ryah: github.com/indutny/node/tree/feature-debugger-round-2
16:09:27  <indutny>ryah: everything except tests, going to work on them tomorrow
16:10:59  * felixgejoined
16:10:59  * felixgequit (Changing host)
16:10:59  * felixgejoined
16:26:16  <ryah>indutny: great thanks
16:26:58  <indutny>ryah: I'm not sure if breakpoints will work for scripts that're loaded after apps start
16:27:10  <indutny>ryah: To be honest - I think they won't do it :)
16:27:37  <indutny>ryah: so I'll try to figure out this somehow
16:30:57  * bnoordhuisjoined
16:31:19  <bnoordhuis>good news everyone: gyp: add solaris support
16:31:19  <bnoordhuis>http://code.google.com/p/v8/issues/detail?id=1684
16:31:19  <bnoordhuis>Fixed in r9291 (will be in 3.6.5).
16:31:43  <dmkbot1>joyent/node: isaacs: hasOwnProperty usage - https://github.com/joyent/node/issues/1707
16:32:35  <indutny>bnoordhuis: great
16:32:49  <indutny>ryah: 3.6.4 released
16:32:59  <indutny>can we consider updating to upstream?
16:35:41  <ryah>bnoordhuis++
16:36:34  <piscisaureus>igorzi: NDJS-WIN7 is dead
16:36:44  <dmkbot1>joyent/node: isaacs: hasOwnProperty usage - https://github.com/joyent/node/issues/1707
16:37:10  <ryah>indutny: does that have your fix?
16:37:35  <indutny>ryah: yes
16:37:54  <ryah>piscisaureus: looking forward to hearing about linear speedup with your prefork today at scrum :)
16:39:44  <ryah>two fixes need to get into todays release
16:39:56  <ryah>https://github.com/joyent/node/issues/1711 and https://github.com/joyent/node/issues/1707
16:40:00  <bnoordhuis>is the file watcher stuff targeted for today's release?
16:40:05  <ryah>bnoordhuis: no
16:40:16  <bnoordhuis>good (didn't expect it to either)
16:40:21  <ryah>we're going to do v0.4.12 for #1707
16:41:36  <bnoordhuis>good, that'll make it include the multi-line headers fix too
16:42:05  <pietern>bnoordhuis: thanks for the stream_close and write callbacks fix
16:42:12  <pietern>looks solid!
16:42:45  <bnoordhuis>pietern: much gnashing of teeth was involved to make it work properly, you wouldn't believe
16:42:53  <pietern>bnoordhuis: oh I do believe
16:43:11  <pietern>thing of the right behavior and implementing it in a solid way are two different things ;)
16:43:15  <pietern>bnoordhuis: one thing though:
16:43:15  <pietern>https://github.com/joyent/libuv/commit/3c96410902cb6180b2e3bad97b009242bc930b26#diff-2
16:43:28  <pietern>this calls the pending write callbacks before the completed ones
16:43:42  <bnoordhuis>yes
16:43:47  <pietern>could be something that is unexpected (users may expect same ordering)
16:44:33  <bnoordhuis>yes, it's a problem
16:44:48  <bnoordhuis>that i haven't decided how to deal with quite yet
16:44:58  <ryah>indutny: please rebase your branch and force push
16:45:05  <indutny>ryah: k
16:45:21  <pietern>bnoordhuis: why is it a problem?
16:45:26  <bnoordhuis>pietern: https://github.com/joyent/node/issues/1697
16:45:40  <bnoordhuis>for the record, it's already broken
16:46:32  <pietern>don't the writes remain ordered in the way they are pushed in?
16:46:43  <dmkbot1>joyent/node: isaacs: hasOwnProperty usage - https://github.com/joyent/node/issues/1707
16:46:49  <pietern>since uv__Write only pushes write_t's onto the completed queue when then are fully written?
16:47:21  <bnoordhuis>pietern: apparently not (before) and certainly not now
16:47:54  <bnoordhuis>a failed write is moved immediately to the completed queue now
16:48:15  <indutny>ryah: done
16:49:12  <CIA-53>node: isaacs v0.4 * r98990b9 / (lib/module.js lib/querystring.js lib/repl.js): Fix #1707 hasOwnProperty usage - http://git.io/u439bA
16:49:18  <bnoordhuis>pietern: it needs some investigation; a failed write should maybe abort the connection, that would guarantee the ordering
16:49:35  <bnoordhuis>but i haven't made up my mind yet
16:50:16  <pietern>bnoordhuis: shouldn't write requests (failed or successful) being popped off the head of the write list be pushed onto the tail of the completed list
16:50:20  <pietern>thus guaranteeing ordering?
16:50:27  <pietern>(checking the code btw)
16:50:31  <ryah>bnoordhuis: do you get this:
16:50:31  <ryah>=== release test-fs-utimes ===
16:50:32  <ryah>Path: simple/test-fs-utimes
16:50:32  <ryah>Assertion failed: (r == 0), function FUTimes, file ../src/node_file.cc, line 995.
16:50:32  <ryah>Command: out/Release/node /Users/ryan/projects/node/test/simple/test-fs-utimes.js
16:50:47  <ryah>bnoordhuis: sounds like an easy fix
16:51:12  <bnoordhuis>ryah: test-fs-utimes works here
16:51:42  <ryah>bnoordhuis: k - i'll check it out
16:51:43  <dmkbot1>joyent/node: isaacs: hasOwnProperty usage - https://github.com/joyent/node/issues/1707
16:51:52  <CIA-53>node: Ryan Dahl master * r1b15af9 / (202 files in 15 dirs): Upgrade V8 to 3.6.4 - http://git.io/EuzKBA
16:52:21  <bnoordhuis>pietern: yes, fair point - but apparently that's not always happening (not then and probably not now either)
16:52:38  <pietern>bnoordhuis: I'll take a look later, pretty weird
16:52:50  <bnoordhuis>i've seen it happen myself once or twice but i wasn't able to reproduce it
16:52:51  <pietern>maybe I can spot something..
16:53:16  <CIA-53>node: isaacs v0.4 * rb3af074 / test/simple/test-querystring.js : Add querystring test for hasOwnProperty usage - http://git.io/1--cpA
16:53:23  <pietern>bnoordhuis: anyway, it's details
16:53:31  <pietern>the bulk is already done, great stuff, thanks again
16:53:41  <bnoordhuis>my pleasure, pietern :)
16:55:17  <ryah>indutny:
16:55:17  <ryah>ryan@mac1234:~/projects/node% ./node debug benchmark/http_simple.js
16:55:17  <ryah>debug> r
16:55:17  <ryah>debugger listening on port 5858TypeError: Cannot call method 'on' of undefined at Interface.trySpawn (_debugger.js:1314:21) at Interface.run (_debugger.js:917:10) at native at repl:1:2
16:55:28  <indutny>oh, wtf
16:55:47  <indutny>ryah: can spawn return undefined?
16:56:03  <ryah>indutny: i dont think so...
16:56:10  <ryah>it can throw?
16:56:13  <indutny>looks like it's returning :)
16:56:22  <ryah>can you reproduce?
16:56:26  <indutny>ryah: yeah, but it won't reach next statement
16:56:38  <indutny>ryah: 1 sec
16:56:53  <indutny>ryah: nope
16:57:47  <indutny>that's odd
16:58:20  <ryah>indutny: i got to do other stuff - i'm going to wait until tomorrow to look into it
16:58:27  <indutny>ryah: np
16:58:36  <indutny>ryah: I'll work on tests anyway
16:58:42  <ryah>indutny++
17:00:52  <bnoordhuis>piscisaureus: fork() cannot be backported since the 0.4 api is frozen.
17:01:05  <ryah>bnoordhuis: locking the http-parser issue
17:01:08  <bnoordhuis>existing api is frozen, but this would be an extension no?
17:01:14  <bnoordhuis>ryah: sure
17:11:43  <dmkbot1>joyent/node: piscisaureus: windows/spawn asserts w/ invalid argument - https://github.com/joyent/node/issues/1659
17:20:53  * ericktjoined
17:26:21  <igorzi>piscisaureus: NDJS-WIN7 should be back online in a few minutes
17:26:43  <dmkbot1>joyent/node: davglass: HTTP parser fails if server returns no headers - https://github.com/joyent/node/issues/1711
17:31:43  <dmkbot1>joyent/node: Skomski: Added new win32 platform function: getNetworkInterfaces() - https://github.com/joyent/node/issues/1652
17:31:44  <dmkbot1>joyent/node: Skomski: New win32 platform function: GetCPUInfo - https://github.com/joyent/node/issues/1664
17:34:00  <bnoordhuis>ryah: the test-fs-utimes thing, you need to have HAVE_FUTIMES defined for the platform you're testing it on
17:34:26  <ryah>bnoordhuis: oh
17:35:09  <bnoordhuis>i added that because futimes is apparently a recent-ish darwin addition (and sunos doesn't have it at all)
17:35:47  <ryah>https://github.com/joyent/node/blob/1b15af9dd2bf4adb7a2e73ae17a12e2e98a88f72/deps/uv/src/unix/eio/config_darwin.h#L18
17:35:51  <ryah>seems i have it
17:36:43  <dmkbot1>joyent/node: piscisaureus: windows/spawn asserts w/ invalid argument - https://github.com/joyent/node/issues/1659
17:36:44  <dmkbot1>joyent/node: piscisaureus: windows/spawn asserts w/ invalid argument - https://github.com/joyent/node/issues/1659
17:38:08  <bnoordhuis>ryah: adding a #ifdef __apple__\n#define HAVE_FUTIMES 1 in internal.h should fix it in that case
17:39:40  <piscisaureus>igorzi: are these test client machines
17:39:46  <piscisaureus>only dualcore?
17:40:00  <indutny>what is milestone of 0.6.x ?
17:40:06  <igorzi>piscisaureus: no, they should be 2x4
17:40:08  <indutny>libuv stability?
17:40:17  <piscisaureus>igorzi: the control server shows only 2 cores
17:40:29  <piscisaureus>it is fully saturated during a test
17:41:23  <igorzi>piscisaureus: can you reboot it? i think it might have been booted-in with 2 cores. we changed it, but maybe didn't reboot it.
17:41:35  <piscisaureus>yeah sure
17:41:43  <dmkbot1>joyent/node: piscisaureus: windows/spawn asserts w/ invalid argument - https://github.com/joyent/node/issues/1659
17:41:44  <dmkbot1>joyent/node: piscisaureus: windows/spawn asserts w/ invalid argument - https://github.com/joyent/node/issues/1659
17:41:54  <isaacs>review please? https://github.com/isaacs/node/commit/ab5e783
17:42:46  <ryah>isaacs: 1sec
17:43:31  <isaacs>sure
17:43:43  <bnoordhuis>isaacs: If obj.hasOwnProperty has been overridden <- when do people do that?
17:43:44  <ryah>isaacs: can you link to the issue in the test?
17:43:54  <isaacs>ryah: k
17:44:16  <ryah>isaacs: maybe in the code too?
17:44:23  <bnoordhuis>ah, probably external input
17:45:10  <indutny>ryah: oh, strange
17:45:10  <isaacs>bnoordhuis: yeah, external input
17:45:15  <indutny>ryah: I can reproduce it on master now
17:45:33  <isaacs>bnoordhuis: you can crash a majority of node servers by doing ?hasOwnProperty=x&y
17:46:36  <piscisaureus>lol
17:47:02  <indutny>that was a secret information :)
17:47:41  <piscisaureus>can you also crash them by setting __proto__?
17:47:42  <isaacs>updated with links: https://github.com/isaacs/node/commit/646a741507501798a722d850f8f388e1f6c64bef
17:47:56  <indutny>ryah: oh, you removed stdout and stderr from spawn results
17:48:33  * felixgequit (Ping timeout: 260 seconds)
17:49:15  <isaacs>piscisaureus: no, but that does make the querystring.parse result an array rahter than an object which is... weird?
17:49:39  <piscisaureus>eh, to say the least :-)
17:49:57  <piscisaureus>we should filter out all Object.prototype stuff
17:50:09  <indutny>ryah: actually, chld_process_uv is different from child_process_legacy
17:50:12  <ryah>indeed
17:50:23  <ryah>indutny: how so?
17:50:39  <indutny>ryah: spawn() doesn't return object with .stdout nomore
17:51:08  <indutny>ryah: while it's still documented here http://nodejs.org/docs/v0.5.6/api/child_processes.html
17:51:23  <isaacs>piscisaureus: i'm not sure i agree.
17:51:39  <isaacs>piscisaureus: that would mean that you can't use toString as a query string key
17:51:43  <dmkbot1>joyent/node: indutny: [debugger] fix for #1707 - https://github.com/joyent/node/issues/1712
17:51:53  <ryah>isaacs: LGTM
17:51:57  <isaacs>kew
17:52:30  <isaacs>ryah: the parent of that reverts the half-baked commits. would you prefer that, or force-push?
17:53:05  <ryah>isaacs: no force push - just do a single fast-forward commit
17:53:20  <isaacs>oh, so no revert?
17:53:25  <ryah>squash it
17:53:28  <isaacs>kewl
17:54:06  <ryah>indutny: just add that to your queue of patches for me tomorrow
17:54:08  <indutny>ryah: why have you introduced options.stdinStream in ChildProcess.prototype.spawn , line 314
17:54:13  <indutny>ryah: k
17:54:30  <indutny>ryah: trying to figure out, why that was done, to decide how is better to fix it
17:55:00  <CIA-53>node: isaacs v0.4 * re06ce75 / (4 files in 2 dirs):
17:55:00  <CIA-53>node: Fix #1707 hasOwnProperty usage
17:55:00  <CIA-53>node: If hasOwnProperty is overridden, then calling `obj.hasOwnProperty(prop)`
17:55:00  <CIA-53>node: can fail. Any time a dictionary of user-generated items is built, we
17:55:00  <CIA-53>node: cannot rely on hasOwnProperty being safe, so must call it from the
17:55:01  <CIA-53>node: Object.prototype explicitly. - http://git.io/w-PWyA
17:55:14  <ryah>indutny: windows doesn't work very well with FDs - so instead of customFds we'd rather have users provide full pipes
17:55:55  <indutny>ryah: ok, I think I know how to fix it
17:55:56  <ryah>isaacs++ thanks. i'll merge v0.4 into master soon
17:55:58  <indutny>thanks
17:56:06  <isaacs>great
17:56:46  <piscisaureus>44000 r/s seems to be about the number of connections I can accept on this machine
17:56:50  <piscisaureus>saturating all 8 cores
17:56:59  <isaacs>feeling pretty embarrassed that i let that one get through in the first place. it was an issue that we'd fixed in the original lib/querystring.js, and reviewing the rewrite, i didn't catch that it'd regressed.
17:57:38  <igorzi>piscisaureus: how many r/s with just one core?
17:57:57  <bnoordhuis>piscisaureus: that's rather pitiful, isn't it?
17:57:59  <isaacs>ugh, what's worse, i'm the one who replaced the "in" with "hasownProperty" in the first place.
17:58:06  * isaacshands in his JavaScript badge.
17:58:10  <piscisaureus>*shrug* I don't now
17:58:14  <piscisaureus>bnoordhuis: ^
17:58:29  <bnoordhuis>i can do more accepts on my laptop
17:59:02  <piscisaureus>bnoordhuis: I am doing accept + writing hello world response
17:59:08  <piscisaureus>bnoordhuis: but okay - how many do you get?
17:59:29  <bnoordhuis>piscisaureus: what benchmark are you using?
17:59:36  <igorzi>i was getting ~5500 r/s for node http_simple (on linux and windows) - on that same cluster
17:59:51  <bnoordhuis>piscisaureus: pure accepts (non libuv) is in the 100s of thousands/s
18:00:26  <igorzi>bnoordhuis: that's on loopback, right?
18:00:33  <bnoordhuis>igorzi: yes
18:00:40  <bnoordhuis>not a great test admittedly
18:00:46  <piscisaureus>bnoordhuis: that's not an interesting number
18:01:20  <igorzi>piscisaureus: so, how many r/s were you getting before your prefork?
18:01:30  <piscisaureus>igorzi: trying that now
18:01:47  <piscisaureus>igorzi: I think about 12K
18:02:46  <piscisaureus>igorzi: that saturates ~23% of all cores combined
18:03:15  <igorzi>and with prefork, all cores get saturated?
18:03:21  <piscisaureus>yes
18:03:27  <piscisaureus>I am currently running 6 processes total
18:03:39  <piscisaureus>I think I could also saturate all with 5 processes
18:04:01  <bnoordhuis>DigiNotarectomy <- 'to remove diginotar ca certs', i like it
18:04:10  * pieternquit (Remote host closed the connection)
18:04:17  * pieternjoined
18:05:22  <piscisaureus>igorzi: 1 process -> 15277 r/s
18:05:36  <ryah>piscisaureus, bnoordhuis, isaacs, igorzi: skype?
18:05:43  <piscisaureus>yes
18:05:44  <igorzi>yep
18:05:52  <bnoordhuis>yes
18:06:04  <bnoordhuis>let me turn off abba
18:06:43  <dmkbot1>joyent/node: cwolves: 0.5.6: fs.readdirSync crashes on empty directory (OSX) - https://github.com/joyent/node/issues/1713
18:06:44  <dmkbot1>joyent/node: cwolves: 0.5.6: fs.readdirSync crashes on empty directory (OSX) - https://github.com/joyent/node/issues/1713
18:11:43  <dmkbot1>joyent/node: bnoordhuis: process_wrap memory leak? - https://github.com/joyent/node/issues/1714
18:11:44  <dmkbot1>joyent/node: bnoordhuis: process_wrap memory leak? - https://github.com/joyent/node/issues/1714
18:13:36  * felixgejoined
18:13:37  * felixgequit (Changing host)
18:13:37  * felixgejoined
18:16:43  <dmkbot1>joyent/node: hildjj: Results of stat() incorrect, don't match statSync - https://github.com/joyent/node/issues/1401
18:16:44  <dmkbot1>joyent/node: BillBarnhill: Fix memory allocation in uv__fs_after - https://github.com/joyent/node/issues/1686
18:24:14  <bnoordhuis>piscisaureus: https://github.com/joyent/node/pull/1652 <- can you look at this?
18:24:36  * felixgequit (Quit: felixge)
18:31:43  <dmkbot1>joyent/node: seebees: Tests for Sockets - https://github.com/joyent/node/issues/1699
18:35:09  <piscisaureus>bnoordhuis: am going to skype you again in a few minutes
18:35:42  <bnoordhuis>piscisaureus: i'm off to dinner now but i'll ping you in 45 minutes or so
18:36:49  <ryah>https://github.com/SteveSanderson/Node.js-Site-Templates-for-WebMatrix
18:36:52  <ryah>^-- sweet
18:39:54  <piscisaureus>yeah msft seems to be pretty serious about node
18:41:37  <ryah>its nice how they are using github
18:46:43  <dmkbot1>joyent/node: japj: Fix options file memory leak - https://github.com/joyent/node/issues/1715
18:50:39  <ryah>bnoordhuis: did you find that memleak with valgrind?
19:00:43  <CIA-53>node: isaacs master * r98990b9 / (lib/module.js lib/querystring.js lib/repl.js): Fix #1707 hasOwnProperty usage - http://git.io/u439bA
19:00:46  <CIA-53>node: isaacs master * re06ce75 / (4 files in 2 dirs):
19:00:46  <CIA-53>node: Fix #1707 hasOwnProperty usage
19:00:46  <CIA-53>node: If hasOwnProperty is overridden, then calling `obj.hasOwnProperty(prop)`
19:00:46  <CIA-53>node: can fail. Any time a dictionary of user-generated items is built, we
19:00:46  <CIA-53>node: cannot rely on hasOwnProperty being safe, so must call it from the
19:00:47  <CIA-53>node: Object.prototype explicitly. - http://git.io/w-PWyA
19:00:47  <CIA-53>node: isaacs master * rb3af074 / test/simple/test-querystring.js : Add querystring test for hasOwnProperty usage - http://git.io/1--cpA
19:00:54  <CIA-53>node: Ryan Dahl master * ra1bafc5 / (5 files in 2 dirs):
19:00:54  <CIA-53>node: Merge remote branch 'origin/v0.4'
19:00:54  <CIA-53>node: Conflicts:
19:00:54  <CIA-53>node: deps/http_parser/http_parser.c
19:00:55  <CIA-53>node: deps/http_parser/test.c
19:00:55  <CIA-53>node: lib/repl.js - http://git.io/9h7SAA
19:03:28  <CIA-53>node: Jeroen Janssen master * r3e66780 / src/process_wrap.cc :
19:03:29  <CIA-53>node: Fix options_file_memory_leak
19:03:29  <CIA-53>node: Fixes #1714.
19:03:29  <CIA-53>node: Fixes #1715. - http://git.io/ZL0NCA
19:08:05  <igorzi>piscisaureus: http://nodejs.org/dist/v0.5.6/node.exe is built without debug info
19:08:17  <piscisaureus>igorzi: hmm
19:08:29  <piscisaureus>igorzi: I tried to strip but that did not make it smaller?
19:08:33  <piscisaureus>how do I do this?
19:10:26  <igorzi>piscisaureus: the project that gets generated with GYP should already have <GenerateDebugInformation>true</GenerateDebugInformation>
19:10:49  <piscisaureus>igorzi: oh so you want it to be generated with debug info
19:10:49  <isaacs>it looks like process.stdout.writable isn't set to true any more.
19:10:54  <piscisaureus>?
19:10:55  <isaacs>that breaks npm a little. easy to workaround, though
19:11:52  <igorzi>piscisaureus: yeah.. this way if someone gets a crash - they could report a stack trace, etc
19:12:02  <piscisaureus>hmm
19:12:08  <piscisaureus>not good for the file size though
19:12:21  <piscisaureus>igorzi: I have uploaded the pdb file if that helps
19:14:20  <igorzi>piscisaureus: VS debugger won't load the PDB now ("Binary was not built with debug information.")
19:14:34  <piscisaureus>hmm
19:14:40  <piscisaureus>igorzi: okay
19:14:46  <piscisaureus>igorzi: I should figure that out then
19:15:17  <igorzi>piscisaureus: when i run symcheck on node.exe - i get: "FAILED - Built without debugging information."
19:15:36  <piscisaureus>igorzi: apparently that gyp option is not propagated properly then - I juist built that exe with vcbuild
19:16:14  <igorzi>piscisaureus: let's see if this happens with the next release
19:16:27  <piscisaureus>yes
19:16:42  <piscisaureus>the next release is today so let's check the exe before releasing
19:16:49  <piscisaureus>ryah: ^-- that
19:17:58  <ryah>hm
19:18:01  <ryah>DrPizza: you there?
19:18:27  <igorzi>btw, http://nodejs.org/dist/v0.5.5/node.exe is build with debug info
19:19:23  <piscisaureus>igorzi: what happens if you symcheck the vcbuild result w/ master?
19:19:43  <piscisaureus>maybe it was only then, or there's something fishy with my VS configu\
19:20:32  * mralephjoined
19:20:42  <igorzi>piscisaureus: trying now
19:21:43  <dmkbot1>joyent/node: jifeon: node_waf: 'no such environment: default' - https://github.com/joyent/node/issues/1716
19:26:01  <piscisaureus>igorzi: btw what is the point of running ping after every bench round?
19:26:43  <dmkbot1>joyent/node: tjanczuk: Support for building MSI installers on Windows - https://github.com/joyent/node/issues/1706
19:27:02  <igorzi>piscisaureus: sleep
19:27:25  <igorzi>(there's no sleep command in cmd)
19:28:22  <igorzi>ryah: did you download the wix toolset (http://wix.codeplex.com/releases/view/60102)?
19:30:34  <igorzi>piscisaureus: symchk is not complaining on node.exe from "vcbuild release" on node master
19:30:51  <piscisaureus>igorzi: okay, I will check my setup
19:39:13  <igorzi>ryah: 'vcbuild release msi' worked for me (after installing wix toolset)
19:40:07  <igorzi>ryah: btw, pthread-win32 should be taken out of license
19:40:13  * brsonquit (Ping timeout: 240 seconds)
19:47:42  <isaacs>ryah: using spawn with childFds 0,1,2, i'm seeing a lot of ./test.sh: line 3: echo: write error: Resource temporarily unavailable
19:51:43  <dmkbot1>joyent/node: jifeon: context in EventEmitter.on - https://github.com/joyent/node/issues/1717
19:51:44  <dmkbot1>joyent/node: tjanczuk: Support for building MSI installers on Windows - https://github.com/joyent/node/issues/1706
19:55:00  <isaacs>ryah: also, in my prompt_command, i have a $(node -v), and it's triggering this:
19:55:00  <isaacs>Assertion failed: (stream->write_queue_size == 0), function uv__write, file src/unix/stream.c, line 324.
19:55:30  <bnoordhuis>ryah: what memleak? the one i opened an issue for? that was spotted by jeroen j.
20:00:03  * brsonjoined
20:01:14  * felixgejoined
20:01:14  * felixgequit (Changing host)
20:01:14  * felixgejoined
20:02:02  * igorziquit (Ping timeout: 252 seconds)
20:06:13  <CIA-53>node: Ryan Dahl master * r763059e / LICENSE : Remove pthread-win32 from license file (no longer using it) - http://git.io/RvjjdA
20:06:43  <dmkbot1>joyent/node: tjanczuk: Support for building MSI installers on Windows - https://github.com/joyent/node/issues/1706
20:06:44  <dmkbot1>joyent/node: tjanczuk: Support for building MSI installers on Windows - https://github.com/joyent/node/issues/1706
20:06:45  <dmkbot1>joyent/node: tjanczuk: Support for building MSI installers on Windows - https://github.com/joyent/node/issues/1706
20:07:50  <ryah>http://soundcloud.com/smixx/takin-vc-money-money-cash-ipos
20:09:07  <ryah>there's a node mention :)
20:10:18  <ryah>http://square.github.com/cube/
20:10:58  <piscisaureus>https://gist.github.com/1220252
20:11:13  <piscisaureus>bnoordhuis: the floor is yours
20:11:35  <ryah>piscisaureus: thanks!
20:11:59  <bnoordhuis>piscisaureus: roger
20:12:11  <bnoordhuis>that's a libuv benchmark?
20:13:17  <piscisaureus>bnoordhuis: this is what my test does:
20:13:17  <piscisaureus>- uses libuv
20:13:17  <piscisaureus>- fork N child processes.
20:13:17  <piscisaureus>- accept as fast as possible
20:13:17  <piscisaureus>- write "HTTP 1.1 200 OK\r\nContent-Length: 12\r\nConnection: close\r\n\r\nhello world\n" and then close from the write callback
20:13:18  <piscisaureus>- uv_tcp_t and uv_write_t are malloc'ed every time
20:13:37  <piscisaureus>bnoordhuis: any more questions?
20:13:42  <bnoordhuis>piscisaureus: can i have a gist of the code?
20:14:56  <CIA-53>libuv: Bert Belder prefork * r8afa067 / (include/uv-win.h prefork.c src/win/tcp.c): prefork II - http://git.io/kXXXZg
20:15:12  <piscisaureus>bnoordhuis: It's a mess but it's all there --^
20:15:30  <ryah>piscisaureus: put those notes in the gist please
20:15:38  <ryah>piscisaureus: and a link to the code you're running
20:16:05  <ryah>just so we have it all collected in one place
20:19:20  <piscisaureus>ok, done
20:27:40  <bnoordhuis>piscisaureus: how do i boot it to linux without killing the rdp session?
20:27:52  <piscisaureus>bnoordhuis: you can't heh
20:28:00  <piscisaureus>bnoordhuis: you gotta talk to igor, he has to do it manually
20:28:15  <piscisaureus>bnoordhuis: I don't think the KVM solution for this is in place yet
20:28:20  <bnoordhuis>and igorzi is offline, of course...
20:28:39  <piscisaureus>email him?
20:28:50  <bnoordhuis>he's still at work?
20:28:50  <piscisaureus>He's also online on skype
20:29:35  <piscisaureus>it's 13:29 there, he should be :-)
20:30:24  <bnoordhuis>okay, emailed him
20:30:26  <piscisaureus>My 2 cents, he's grabbing a sandwitch
20:30:37  <bnoordhuis>a silicon hexen?
20:30:41  <piscisaureus>without the t
20:30:51  <bnoordhuis>oh, a boterham
20:30:54  <bnoordhuis>or a bammetje
20:31:43  <dmkbot1>joyent/node: tjanczuk: Support for building MSI installers on Windows - https://github.com/joyent/node/issues/1706
20:31:44  <dmkbot1>joyent/node: tjanczuk: Support for building MSI installers on Windows - https://github.com/joyent/node/issues/1706
20:31:46  <piscisaureus>a butter ham?
20:32:33  <piscisaureus>a small bam?
20:35:00  <CIA-53>libuv: Erick Tryzelaar master * r9700181 / test/test-ping-pong.c : test: fix compiling with gcc-4.5 - http://git.io/1y8QWg
20:35:00  <CIA-53>libuv: Erick Tryzelaar master * r905fe71 / src/unix/fs.c : unix: fix a compiler warning - http://git.io/gZxXog
20:35:00  <CIA-53>libuv: Erick Tryzelaar master * r533418d / (7 files): test and bench: assert return values of *_init functions in tests - http://git.io/bVKYmA
20:36:09  <CIA-53>node: Ryan Dahl master * r5cb1fd2 / (lib/net_uv.js test/simple/test-console.js): net.Socket(fd) should start readable and writable - http://git.io/KeW73g
20:36:43  <dmkbot1>joyent/libuv: erickt: Fix a couple warnings, added some asserts, and compiling with gcc-4.5 and mingw-w64 - https://github.com/joyent/libuv/issues/186
20:41:43  <dmkbot1>joyent/libuv: erickt: Fix a couple warnings, added some asserts, and compiling with gcc-4.5 and mingw-w64 - https://github.com/joyent/libuv/issues/186
20:42:51  * igorzijoined
20:45:02  <igorzi>bnoordhuis: rebooting NDJS-Win4 into linux.. will let you know once it's ready to be used
20:45:13  <bnoordhuis>igorzi: cool, thanks
20:45:20  * felixgequit (Quit: felixge)
20:51:03  * felixgejoined
20:51:03  * felixgequit (Changing host)
20:51:03  * felixgejoined
20:58:03  <CIA-53>node: Ryan Dahl master * rb281171 / (src/node.js test/simple/test-console.js): Support legacy API: process.stdout.fd - http://git.io/VE3Xew
21:31:44  * brsonquit (Ping timeout: 252 seconds)
21:36:43  <dmkbot1>joyent/node: vitorbal: Add anchor links next to each function - https://github.com/joyent/node/issues/1718
21:44:28  * isaacsquit (Quit: isaacs)
21:45:09  * pieternquit (Quit: pietern)
21:46:43  <dmkbot1>joyent/node: mikeal: streams2 - https://github.com/joyent/node/issues/1681
21:56:43  <dmkbot1>joyent/node: ry: SSL hanging due undrained error queue? - https://github.com/joyent/node/issues/1719
22:04:29  <ryah>^-- painful
22:07:25  <ryah>[10:23|% 100|+ 480|- 0]: Done
22:07:29  <ryah>^-- OSX, v0.4
22:07:36  <ryah>so beautiful to have no failing test
22:07:40  <CIA-53>node: Ryan Dahl v0.4 * r6312e88 / src/node_crypto.cc : Drain OpenSSL error queue? Addresses #1719 - http://git.io/J1M7Fg
22:09:01  <CIA-53>node: Ryan Dahl master * r6312e88 / src/node_crypto.cc : Drain OpenSSL error queue? Addresses #1719 - http://git.io/J1M7Fg
22:09:01  <CIA-53>node: Ryan Dahl master * r1b0a5cb / src/node_crypto.cc : Merge remote branch 'origin/v0.4' - http://git.io/VXfl-A
22:10:04  <piscisaureus>felixge: so what did you tell Amanda?
22:11:26  <felixge>piscisaureus: we had a pretty interesting chat. She was is really interested in node and potentially running it with Chakra because she feels like her VM team could miss out on some important problems / use cases we run into with node (and that they will run into with windows 8)
22:12:09  <felixge>and I told her that the node community would probably like to see node run on chakra, but that it would only be useful if it was running stable
22:13:08  <piscisaureus>felixge: okay but, are they now open sourcing it?
22:13:40  <piscisaureus>felixge: also, I don't know. I certainly wouldn't mind running node on chakra, but moving away from v8 seems undesirable
22:13:55  <felixge>piscisaureus: I don't they are open sourcing it
22:14:01  <ryah>slash impossible
22:14:14  <piscisaureus>yes, that too
22:14:16  <felixge>I told her the only way to do it would be to provide a v8 API like mozilla
22:14:50  <felixge>either way, chakra would probably never run on windows
22:14:58  <felixge>she said they are very much tied into the operating system
22:15:08  <piscisaureus>felixge: I presume you mean unix?
22:15:12  <felixge>sorry
22:15:13  <felixge>I do
22:15:13  <felixge>yes
22:15:17  <felixge>: p
22:15:33  * pieternjoined
22:15:41  <piscisaureus>felixge: I can hardly imagine how that is true - I mean VMs don't deal with OS features so much
22:15:45  <piscisaureus>probably memory allocation, threads
22:15:53  <felixge>but she was also very interested in our views on common.js, js / harmony and coffeescript
22:15:59  <pietern>bnoordhuis: did the write callback reordering bug only happen on windows?
22:16:25  <felixge>piscisaureus: well, their operating system is now essentially a web runtime
22:16:27  <felixge>; )
22:16:36  <bnoordhuis>pietern: it happened on unix
22:16:37  <felixge>but maybe I misunderstood her
22:16:41  <felixge>and she meant tied to IE itself
22:16:46  <felixge>because of the DOM and optimizing for that
22:16:50  <pietern>bnoordhuis: using the new code, old, or both?
22:17:03  <piscisaureus>felixge: ah tied to the dom. that's pretty unfortunate
22:17:28  <bnoordhuis>pietern: the old code (and only once or twice)
22:17:32  <felixge>as far as JS language features, I told her the following:
22:17:41  <felixge>We want good support for binary data / c-strings
22:17:51  <pietern>bnoordhuis: thanks
22:17:52  <felixge>she said they have typed arrays now
22:18:18  <felixge>we would also like arbitrary precision decimals / big ints
22:18:33  <ryah>bnoordhuis: you you review https://gist.github.com/1220643
22:18:35  <felixge>which they are actually working on
22:18:37  * brsonjoined
22:18:38  <ryah>*can you
22:18:46  <bnoordhuis>ryah: i can can
22:18:53  <felixge>when you get decimals from the Windows Runtime they have more precision than JS floats
22:19:11  <felixge>but as soon as you do math on them they loose precision and turn into JS floats
22:19:14  <felixge>but you can toString() the,
22:19:18  <felixge>them
22:19:19  <felixge>which is neat
22:19:37  <ryah>felixge: they should publish the header file
22:19:44  <ryah>so we can have a look at the API
22:19:45  <felixge>ryah: for chakra?
22:19:47  <ryah>yes
22:19:50  <piscisaureus>felixge: precise 64-bit ints is also nice :-) And nice interaction with the GC.
22:19:55  <piscisaureus>ryah: +1
22:20:09  <ryah>igorzi: can we get the header file for chakra?
22:20:20  <felixge>ryah: I can send her a follow up email
22:20:31  <felixge>she also asked us what we think about common.js
22:20:44  <ryah>did you scoff and roll your eyes?
22:20:47  <felixge>and I told her that we take it as inspiration but not much more
22:20:48  <piscisaureus>muhaha
22:20:50  <felixge>haha
22:20:57  <igorzi>ryah: yeah, let me find them..
22:21:04  <felixge>well they actually implemented the Common.js Promises/A proposal
22:21:13  <felixge>and they do a *ton* of async stuff in their APIs
22:21:21  <bnoordhuis>ryah: won't that leave stdin/out/err in blocking mode?
22:21:23  <felixge>so that's a pretty commitment to that implementation
22:21:24  <ryah>yes promises/A sounds like the winner now
22:21:30  <ryah>bnoordhuis: yes
22:21:40  <ryah>bnoordhuis: for the child process only
22:21:42  <felixge>the only thing I dislike about promises/A is the explicit need for error handling
22:21:49  <ryah>bnoordhuis: i think
22:21:52  <felixge>it should throw if no error handler is attached
22:21:55  <piscisaureus>[00:16] <pietern> bnoordhuis: did the write callback reordering bug only happen on windows?
22:21:56  <piscisaureus>^-- pietern: what bug?
22:21:56  <felixge>but otherwise I'm cool with it
22:22:19  <felixge>she said they had tons of discussion about this and other promise things internally as well :)
22:22:20  <bnoordhuis>ryah: okay, lgtm
22:22:31  <felixge>and it's not cast in stone just yet
22:22:44  <ryah>non-blocking stdout has been a lot more trouble than it's worth
22:22:48  <pietern>piscisaureus: one bnoordhuis told me about: https://github.com/joyent/node/issues/1697
22:23:09  <pietern>looking into it b/c of the new write callback code
22:23:28  <felixge>then we talked about coffeescript, and I told her that I would really like JS engines add support for source code annotations
22:23:34  <felixge>to fix the line number problems
22:23:45  <piscisaureus>bnoordhuis: hmm. does that happen always, or only after closing a socket?
22:23:55  <bnoordhuis>piscisaureus: sometimes the write requests come back in a different order than what they're sent in
22:24:14  <bnoordhuis>piscisaureus: only rarely, i've only seen it happen a few times
22:24:15  <felixge>I mean I think languages compiling to JS will be big in the future, be it coffeescript or not
22:24:19  <CIA-53>libuv: Ryan Dahl master * r2640aae / src/unix/process.c : unix: Reset flags for stdio fds after fork - http://git.io/-xkaMg
22:24:30  <felixge>ryah: she also wanted to know what I think about Joyent
22:24:45  <felixge>and I told her that so far Joyent has been incredibly good for node ;)
22:25:15  <felixge>minus some initial trademark hickups that is ^^
22:25:39  <piscisaureus>also, being on the wrong continent
22:25:57  <bnoordhuis>and having an office on top of a fault line
22:26:18  <felixge>anyway, it was a very nice chat, and she told me to contact her anytime we want to reach out to her team
22:26:38  <felixge>igorzi: I said hi from you, she says hello back : )
22:26:45  <bnoordhuis>felixge: but the gist is that chakra is tied to windows?
22:26:53  <igorzi>felixge: thanks :)
22:27:14  <felixge>bnoordhuis: I will clarify that in a follow up email, but that's the general impression I got
22:27:39  <ryah>is she the PM for chakra?
22:28:06  <ryah>where P stands for either project, program, or product... (i haven't figured out msft titles yet)
22:28:17  <felixge>ryah: she has a bunch of P's in her title, yes
22:28:25  <felixge>I think "Principal Program Manager for Chakra"
22:28:26  <felixge>is her title
22:28:35  <ryah>oh, i think that means she is important
22:28:57  <piscisaureus>Well it depends
22:29:02  <piscisaureus>Principal Program Manager for Chakra < Senior Principal Program Manager for Chakra
22:29:15  <piscisaureus>:-p
22:29:32  <igorzi>yeah, she's important
22:29:59  <ryah>program mangers = big wigs
22:30:11  <ryah>(i think)
22:30:30  <bnoordhuis>i thought program managers were the people getting you coffee come crunch time?
22:30:31  <felixge>she certainly knew her tech well
22:30:42  <ryah>bnoordhuis: no those are project managers
22:30:55  <bnoordhuis>oh right, important distinction
22:32:02  <piscisaureus>I wonder if we can get a reliable test case for #97
22:32:08  <piscisaureus>eh
22:32:10  <piscisaureus>#97
22:32:16  <piscisaureus>wut
22:32:21  <ryah>link?
22:32:30  <piscisaureus>https://github.com/joyent/node/issues/1697
22:32:38  <felixge>anyway, I'll cc you guys in my follow up email
22:32:46  <piscisaureus>felixge: :-)
22:32:51  <felixge>so you can shoot off additional questions directly as they arise
22:33:10  <piscisaureus>wft I can't type # 1 6 7 8 because my IM client will strip the 16
22:33:41  <mraleph>piscisaureus: what's your problem with V8's GC integration? :-)
22:34:18  <ryah>mraleph: when is experimental gc branch going to land?
22:34:27  <felixge>I also asked Amanda about Chakra's heap limits / gc pauses, but she couldn't give me exact numbers right away
22:35:07  <piscisaureus>mraleph: it should allow us to manage our own memory blobs without great inefficiency
22:35:33  <piscisaureus>mraleph: if I had a great api proposal I would crank it out right here
22:36:04  <bnoordhuis>also, it should be faster than luajit's
22:36:08  * bnoordhuisducks
22:36:28  <mraleph>bnoordhuis: V8's GC _is_ faster than luajit's
22:36:43  <dmkbot1>joyent/node: davglass: HTTP parser fails if server returns no headers - https://github.com/joyent/node/issues/1711
22:36:46  <felixge>: p
22:36:47  <igorzi>ryah: chakra hosting is based on IActiveScript interface (http://msdn.microsoft.com/en-us/library/zwzhawfx(v=VS.94).aspx).. it's in ActivScp.h of windows sdk (in Program Files\Microsoft SDKs\Windows\v7.0A\Include). afaik, that's not the latest interface. i'll let you know once i know where the latest interface is.
22:37:19  <piscisaureus>IScriptNode Interface
22:37:26  <piscisaureus>^-- they already have it :-)
22:37:28  <felixge>Btw. I had an idea while chatting with Ryan in SF. We could build a JSON.stringify() that spits out buffers directly, that would be neat
22:37:40  <felixge>might hack up an npm module at some point
22:39:40  <CIA-53>node: Ryan Dahl master * r2d0b1ed / (12 files in 4 dirs):
22:39:40  <CIA-53>node: Upgrade libuv to 2640aae
22:39:40  <CIA-53>node: Add test for bug fixed in joyent/libuv@2640aae1 - http://git.io/ik04NQ
22:39:48  <mraleph>piscisaureus: I think the only ineffeciency that V8 WeakCallback's currently have (applied to node's needs) is that V8 assumes that they they can resurrect the object. which I think never happens in your case
22:40:00  <piscisaureus>nope. never happens
22:40:16  <bnoordhuis>mraleph: what's the use case for that? dom nodes?
22:40:24  <piscisaureus>mraleph: w/ MarkIndependent it's already but it still causes the scavenge algorithm to be run twice
22:40:38  <piscisaureus>it's already better, i meant
22:40:52  <mraleph>piscisaureus: but otherwise they are as efecient as you can get them.
22:41:28  <mraleph>bnoordhuis: yeah, I think WeakCallbacks in WebKit bindings are pretty hairy
22:41:47  <mraleph>bnoordhuis: they can even call back into V8
22:41:57  <mraleph>bnoordhuis: and cause another GC by that
22:42:06  <mraleph>"we need to go deeper"
22:42:07  <bnoordhuis>sounds tricky
22:43:20  <bnoordhuis>it's probably not as easy as adding a F_NEVER_RESURRECT flag?
22:43:38  <piscisaureus>or MarkNeverSurrect :-)
22:43:41  <bnoordhuis>or is that what MarkIndependent does?
22:43:58  <bnoordhuis>no, i don't think so
22:44:11  * isaacsjoined
22:44:27  <mraleph>piscisaureus: MarkIndependent should help a lot for short lived buffers. A limited weakcallback would be nice to have but I think it's complicate APIs and the gain is not clear. it should be easy to prototype it.
22:45:25  <mraleph>bnoordhuis: no. MarkIndependent just tells V8 that it can assume that object does not participate in object grouping (another thing for the DOM support). so V8 can dispose weakly reachable things in scavenges.
22:45:45  * felixgequit (Quit: felixge)
22:46:25  <igorzi>ryah: bnoordhuis: so what are we doing with uv_fs_event_t api? what about doing what we discussed yesterday? node to cache filepaths if they are available in the callback? and then getChanges() either returns cached filepaths or readdir.
22:46:40  <piscisaureus>mraleph: we're currently having this issue with the slab allocator, we want to allocate a medium chunk of memory (like 64kb or so) and then make it smaller shortly after that
22:46:43  <dmkbot1>joyent/node: davglass: HTTP parser fails if server returns no headers - https://github.com/joyent/node/issues/1711
22:46:45  <bnoordhuis>igorzi: i did some work on that, let me commit it and link you to it
22:47:20  <pietern>bnoordhuis: I have an hypothesis:
22:47:42  <piscisaureus>mraleph: it seems that is something that a proper heap manager could handle - but we have no entry points to do this, so we'll probably have to do it on our own.
22:48:02  <mraleph>piscisaureus: I am not sure I follow :-) How is it related to JS heap?
22:48:12  <bnoordhuis>pietern: speak to me
22:48:23  <bnoordhuis>^ got that from west wing
22:48:48  <pietern>in one tick two calls to uv_write are done, where the first one saturates the kernel's write buffer, and the write listener is started
22:49:12  <pietern>sorry, the first one can write everything, but the second gives EAGAIN because the write buffer is full
22:49:28  <pietern>when the write event fires, the kernel's buffer was flushed, but the socket was closed
22:49:29  <piscisaureus>mraleph: not anything necessarily. But it would be nice if we could just allocate a block in v8's heap just like you would allocate a string.
22:49:37  <piscisaureus>At least, that's one of the options I considered
22:49:50  <pietern>so the pending write returns a ECONNRESET, is returned from uv__write
22:49:56  <pietern>and the callback with status=-1 is called
22:50:06  <pietern>WHILE the other callback is still sitting in the complete queue
22:50:19  <piscisaureus>pietern: ah!
22:50:31  <piscisaureus>pietern: it might have to do with write requests short-citcuiting
22:50:34  <pietern>and the second callback is called with status=-1 before the initial one, called immediately, with status=0
22:50:47  <piscisaureus>igorzi: ^
22:51:00  <pietern>it's a possible code path
22:51:07  <pietern>in the old code
22:51:25  <bnoordhuis>igorzi: https://github.com/bnoordhuis/libuv/compare/inotify <- wip, obviously
22:51:38  <piscisaureus>pietern: is this still about https://github.com/joyent/node/issues/1697?
22:51:58  <pietern>piscisaureus: yep, wrong ordering for write callbacks
22:52:11  <pietern>on unix, for this case
22:52:14  <bnoordhuis>pietern: sounds plausible
22:52:19  * bnoordhuisponders
22:52:31  <pietern>bnoordhuis: this of course depends on the status they were called with
22:52:35  <rmustacc>bnoordhuis: is uv_fs_event_filename() telling you the name of what you're watching that changed?
22:52:43  <pietern>bnoordhuis: but it can be tested
22:52:46  <bnoordhuis>rmustacc: yes
22:52:50  * felixgejoined
22:52:50  * felixgequit (Changing host)
22:52:50  * felixgejoined
22:53:04  <rmustacc>Sigh.
22:53:08  <bnoordhuis>rmustacc: e.g. filename of new file in watched directory
22:53:15  <bnoordhuis>blame freebsd
22:53:26  <rmustacc>I don't.
22:53:35  <rmustacc>It's the tradeoff between losing events and not losing them.
22:54:17  <bnoordhuis>rmustacc: it works for inotify but i suspect you're thinking of something else
22:54:28  <rmustacc>bnoordhuis: No, inotify can drop events.
22:55:05  <bnoordhuis>rmustacc: the api works like this now: you watch a directory and when your callback gets called, you call uv_fs_event_filename(cookie) to get the filename
22:55:18  <bnoordhuis>inotify already has the filename cached at that point
22:55:31  <rmustacc>Right, so how are you doing that on other platforms?
22:55:39  <bnoordhuis>pietern: i'll investigate that
22:55:48  <bnoordhuis>rmustacc: less elegantly
22:55:50  <rmustacc>The Event port API is similar to that one.
22:56:00  <pietern>bnoordhuis: great
22:56:01  <rmustacc>Yeah, I talked a long time with ryah about it.
22:56:08  <bnoordhuis>it's actually kqueue that triggered it
22:56:14  <bnoordhuis>hence the 'blame freebsd' quip
22:56:34  <bnoordhuis>kqueue won't tell you what changed, just that something did
22:56:36  <rmustacc>In the higher level libuv framework, you're right you won't lose it.
22:56:43  <dmkbot1>joyent/node: kingkaeru: net_uv.js throws assertion error - https://github.com/joyent/node/issues/1697
22:56:51  <pietern>bnoordhuis: I think something along the lines of writing to a socket which is not accepted on the server side until EAGAIN, close the server socket, wait for the event loop to trigger the write event, where the next-in-line write_t will fail
22:56:55  <rmustacc>bnoordhuis: Yes, the tradeoff there is that inotify can lose the events where kqueue never will.
22:57:08  <rmustacc>i.e. inotify sets a flag that says it dropped events.
22:57:10  <pietern>and have sequence numbers embedded in the write_t's or similar
22:57:28  <rmustacc>I did a comparison of all the Unix APIs.
22:57:48  <bnoordhuis>i was thinking of checking out how fam does it
22:57:52  <pietern>hmm, or write 1 byte for the first request, write 10M for the second one, which will definitely fail after closing
22:58:13  <rmustacc>I guess.
22:58:40  <rmustacc>The real question is how will the user deal with the fact that they can not get an event because IN_Q_OVERFLOW.
22:59:11  <rmustacc>The classis example for this is that you have something watching a directory of source files to see what changed.
22:59:23  <rmustacc>Now you've missed that a file changed.
22:59:42  * mralephquit (Quit: Leaving.)
22:59:44  <rmustacc>Or at best, you know something changed, just not what and you're in the same problem as the other platforms.
23:00:03  <bnoordhuis>what can you do?
23:00:24  <rmustacc>Few options you can do.
23:00:29  <bnoordhuis>tell people to bump max_queued_events
23:00:39  <rmustacc>First is that you have an app not assume they'll get what changed.
23:01:01  <rmustacc>Because you're just waiting for yourself to lose a semanticly important event.
23:01:10  <rmustacc>But, another way a user could do this is have multiple watchers.
23:01:27  <rmustacc>You have one on the directory to tell you what changed, so you can rescan the directory and have a watcher on each file.
23:01:35  <rmustacc>Probably what you have to do if you want to be reliable.
23:01:48  <bnoordhuis>that's a very bad idea with inotify
23:01:50  <bnoordhuis>it scales like crap
23:02:07  <rmustacc>Not saying it's a good idea there.
23:02:10  <rmustacc>But that's the problem.
23:02:27  <rmustacc>Basically you have to make sure the user writes their app with inotify knowing they may miss evens.
23:02:31  <rmustacc>*events
23:02:38  <bnoordhuis>there's only a fairly low upper limit to the # of watchers, like 8K
23:02:41  <rmustacc>And then we penalize the other platforms because of that and doing the readdir.
23:02:44  <bnoordhuis>s/only/also/
23:02:53  <rmustacc>The number per inotify instance?
23:03:04  <rmustacc>Or just across the board.
23:03:19  <bnoordhuis>not sure, let me check
23:03:36  <rmustacc>Well, I imagine the readdir caching you'll have to do for Mac OS, *BSD, and SunOS really is going to be terrible and even more racy then this stuff normally is.
23:04:30  <rmustacc>i.e. you'll be doing an O(n) search on the directory for each event.
23:04:36  <rmustacc>That's definitely not going to scale at all.
23:04:50  <piscisaureus>I am going to bed
23:04:56  <piscisaureus>bnoordhuis: you should too
23:05:12  <bnoordhuis>what? it's only 1 am, i'm just getting started
23:05:20  <igorzi>bnoordhuis: i thought that we would leave uv api as is (with filename callback), and then have node do caching, readdir, etc.
23:05:22  <bnoordhuis>rmustacc: max_user_watches is a per-user limit
23:05:45  <rmustacc>Mm, okay.
23:05:50  <bnoordhuis>igorzi: were we? i must've missed that discussion
23:06:06  <igorzi>bnoordhuis: at least that was my understanding..
23:06:19  <rmustacc>Readdir caching really can't scale or be efficient.
23:06:36  <bnoordhuis>it's not impossible to revert and store the cookie in the uv_fs_event_t struct, this just seemed cleaner
23:06:45  <bnoordhuis>rmustacc: no indeed
23:07:06  <rmustacc>Then why are we committing something that can't scale into the API?
23:07:21  <rmustacc>Especially when a non-trivial node base actually uses Mac OS.
23:07:58  <rmustacc>(Well, and I care about it actually working efficiently on SunOS)
23:08:10  <bnoordhuis>well, one argument is that file monitoring already works like crap in node
23:08:28  <bnoordhuis>how would it work on sunos? event ports?
23:08:33  <rmustacc>Yes, event ports.
23:08:39  <rmustacc>But you have the same problem you do with kqueue.
23:09:01  <bnoordhuis>no filename reported?
23:09:10  <rmustacc>Nope
23:09:14  <bnoordhuis>*sigh*
23:09:18  <rmustacc>Because it's the tradeoff between losing events and not losing them.
23:09:44  <bnoordhuis>if by losing events you mean rename races
23:09:51  <rmustacc>No, not at all.
23:10:05  <rmustacc>I mean you get a ton of modifications to your files in there, you'll lose a bunch because you hit the queue limit.
23:10:18  <bnoordhuis>oh right, overflow
23:10:34  <igorzi>bnoordhuis: with cookie, we'll need to manage the lifetime of the cookie/filename.. seems like we don't have to worry about that if we just include the filename with the callback.. then node can manage the caching in js-land
23:11:06  <isaacs>npm tests passing on head
23:11:09  <rmustacc>bnoordhuis: On Linux it drops events, on Windows when the buffer fills up it just empties it entirely.
23:11:10  <isaacs>+1, ship it
23:11:36  <bnoordhuis>igorzi: 'filename with the callback'? you mean `handle->cb(handle, filename events)`?
23:11:45  <isaacs>ryah: actually, still seeing this "Assertion failed: (stream->write_queue_size == 0), function uv__write, file src/unix/stream.c, line 324." from my PROMPT_COMMAND node -v call
23:11:50  <bnoordhuis>windows does that?
23:11:52  <rmustacc>So you have to code your application basically with the knowledge that you're going to not get that filesystem.
23:11:54  <isaacs>it's really odd, since it seems like it works
23:12:00  <rmustacc>bnoordhuis: Yup, look at the logs from yesterday, that's what I was told.
23:12:01  <igorzi>bnoordhuis: yeah
23:12:14  <rmustacc>Oops, not filesystem, filenme.
23:12:21  <rmustacc>filename
23:12:49  <bnoordhuis>rmustacc: so what's a practical solution?
23:13:08  <rmustacc>bnoordhuis: In my opinoin the UV api just doesn't give you the filename.
23:13:15  <rmustacc>*opinion
23:13:23  <bnoordhuis>and let user land figure it out?
23:13:46  <bnoordhuis>user land = libuv api consumer
23:13:49  <rmustacc>Yeah, or you can do something in node.js. I'd just say the lowest level one.
23:13:49  <piscisaureus>maybe, just optionally?
23:14:15  <rmustacc>Sure, we could do it optionally where it's null for other systems, but Node can't use it then.
23:14:23  <piscisaureus>so the user can avoid diff'ing when not necessary?
23:14:32  <bnoordhuis>yeah, i think that was ruled out
23:14:36  <rmustacc>i.e. we need to not fall into the trap of making it better on one platform vs another.
23:14:42  <bnoordhuis>lowest common denominator and identical behaviour on all platforms
23:14:48  <rmustacc>The lowest common denominator here kind of sucks.
23:14:51  <piscisaureus>yes, meh
23:14:53  <bnoordhuis>blame freebsd!
23:15:04  <rmustacc>Well, it's all the tradeoff.
23:15:09  <piscisaureus>when did we become communists?
23:15:19  <piscisaureus>if one platform sucks they must all suck!
23:15:23  <rmustacc>Either you have to buffer and lose events or you can't provide the information.
23:15:39  <bnoordhuis>you discussed it with ryah? what did he say?
23:15:50  <igorzi>why can't we make filename optional, and then have node cache it, like we discussed yesterday?
23:16:02  <piscisaureus>I am +1 for igorzi's solution
23:16:10  <rmustacc>You can I guess, I just don't think that scales on a bunch of platforms.
23:16:19  <rmustacc>I give you 10k+ files and you're doing a readdir every time?
23:16:20  <igorzi>no, this was the same conversation that we had yesterday.. my understanding is that the caching would be done in node
23:16:31  <rmustacc>I missed yesterday's discussion -- sorry.
23:16:32  <bnoordhuis>igorzi: that's not how i read it
23:16:51  <piscisaureus>yes, libuv should just provide the filename if it has one, otherwise report null
23:16:52  <bnoordhuis>i read it as libuv would do the Right Thing on each platform
23:17:04  <bnoordhuis>piscisaureus: that was ruled out
23:17:16  * piscisaureuscalls the boss
23:17:17  <bnoordhuis>let's get ryah in here
23:17:25  <bnoordhuis>ryah, clean up in isle #3!
23:17:32  <piscisaureus>ghe
23:18:00  <igorzi>yeah, let's see what ryah meant with:
23:18:01  <igorzi>01:44:48 <ryah> maybe we can split it into two calls
23:18:05  <igorzi>01:45:06 <ryah> first you do fs.watch("something/dir", function() { })
23:18:08  <igorzi>01:45:20 <ryah> then inside the callback do fs.getChanges("something/dir")
23:18:12  <igorzi>01:45:34 <ryah> and on windows and linux it will just cache the changes as it gets them
23:18:16  <igorzi>01:45:49 <ryah> on solaris and osx it will do a readdir
23:18:43  <bnoordhuis>right, but that .getChanges() function maps onto a libuv function
23:18:53  <rmustacc>Sigh, I mean, we can do that. It just means that we're baking something into node that we know is going to suck on certain platforms.
23:19:08  <piscisaureus>actually, overflowing is also a problem on windows
23:19:15  <piscisaureus>"If the buffer overflows, the entire contents of the buffer are discarded and the lpBytesReturned parameter contains zero."
23:19:19  <igorzi>bnoordhuis: that's open to interpretation :)
23:19:34  <bnoordhuis>heh
23:19:38  <rmustacc>I mean, you have to assume you're going to lose events.
23:20:10  <piscisaureus>can't we just have a flag for that
23:20:27  <rmustacc>Sure.
23:20:55  <piscisaureus>that means "I desperately need the filename. Kill me!"
23:21:27  <rmustacc>If you desperately need it, all the more you need to write your app to handle the case when you don't get it.
23:21:34  <rmustacc>due to drops that is.
23:22:08  * brsonquit (Ping timeout: 252 seconds)
23:22:27  <piscisaureus>rmustacc: in that case node/libuv should take care of it
23:22:42  <rmustacc>How are you going to know what changed then?
23:22:50  <rmustacc>You'll have to be doing the readdir every time on every platform then.
23:23:19  <piscisaureus>rmustacc: not necessarily - if you know what changed you can just update your cached readdir or?
23:23:44  <bnoordhuis>piscisaureus: no, the problem is that inotify may drop events
23:23:57  <bnoordhuis>it'll set a flag so you know you lost *something* but not what
23:24:10  <piscisaureus>bnoordhuis: yes, so if it has dropped events, *then* you need to call readdir yourself
23:24:11  <bnoordhuis>if that something is a file being added or deleted, well, that's pretty significant
23:24:40  <igorzi>so, is it bad to just propogate filename all the way to js API? on some oses it'll be null..
23:25:02  <bnoordhuis>no, the api's behaviour needs to be consistent on all platforms
23:25:03  <pietern>bnoordhuis: got a failign test
23:25:06  <piscisaureus>bnoordhuis: I think this is also a problem on windows. It will drop all events as soon as the buffer overflows
23:25:12  <rmustacc>igorzi: The problem there is that you now have a node app that will be written to assume you have it and then fail on another platform.
23:25:13  <bnoordhuis>pietern: can you post it?
23:25:22  <bnoordhuis>or gist it, rather
23:25:26  <pietern>bnoordhuis: one sec
23:26:18  <bnoordhuis>piscisaureus: doing a readdir is race-y and potentially lethal if you have several watchers that all trigger a refresh
23:26:29  <pietern>bnoordhuis: https://gist.github.com/1220786
23:26:31  <igorzi>rmustacc: maybe we don't call it filename in the api.. call it additional-data or something, and make it clear in the API that it might be null
23:26:37  <pietern>based off of your tcp-close test
23:26:47  <pietern>does a small write and a huge write
23:26:50  <pietern>and closes the server
23:26:59  <piscisaureus>bnoordhuis: not necessarily race-y
23:27:02  <pietern>the huge write fails on the next loop tick, and its callback gets called
23:27:05  <pietern>boom
23:27:18  <bnoordhuis>pietern: thanks, i'll give it a spin
23:27:33  <pietern>it fails consistently on osx 10.7
23:27:41  <rmustacc>igorzi: Maybe that'd work, but if it's there you'll have people who assume they should rely on it, etc.
23:27:55  <pietern>bnoordhuis: to clarify, this fails on the OLD code
23:27:56  <bnoordhuis>piscisaureus: it is on unices, the directory might be updated again while you're running the readdir operation
23:28:12  <bnoordhuis>pietern: right, with what commit did you test it?
23:28:19  <piscisaureus>bnoordhuis: so make sure you restart inotify before doing the readdir :-)
23:28:23  <pietern>bnoordhuis:
23:28:24  <pietern>066dc6bcc86f
23:28:31  <pietern>the one before you committed the revamp
23:28:42  <pietern>didn't test against the new code yet..
23:28:46  <bnoordhuis>pietern: okay sweet, thanks
23:28:47  <pietern>exciting! ;)
23:29:10  <bnoordhuis>piscisaureus: and risk another overflow?
23:29:15  <bnoordhuis>that way lies madness
23:30:14  <pietern>Output from process `tcp_write_callback_order`:
23:30:14  <pietern>callback nr 0, (expected: 0)
23:30:15  <pietern>callback nr 1, (expected: 1)
23:30:15  <pietern>Assertion failed: (stream->write_queue_size == 0), function uv__drain, file src/unix/stream.c, line 261.
23:30:20  <pietern>that's good..
23:30:48  <pietern>(on the new code)
23:31:34  <bnoordhuis>hmm, that assertion shows up a lot lately
23:31:43  <dmkbot1>joyent/node: isaacs: node -v in bash PROMPT_COMMAND causes assertion error - https://github.com/joyent/node/issues/1720
23:32:35  <isaacs>pietern: that looks oddly similar to the bug i just posted.
23:33:24  <pietern>isaacs: different spot in the code though
23:33:33  <pietern>bnoordhuis: I'm calling it a day
23:33:46  <pietern>1h30am is late enough
23:33:48  <piscisaureus>pietern: sleep tight
23:33:53  <bnoordhuis>pietern: sleep tight
23:33:59  <pietern>thanks, you too
23:34:14  <piscisaureus>bnoordhuis: rmustacc: the problem is really, there is no reliable way to monitor infinite-size directories. Either the OS needs to keep an infinite buffer of changes, or the use needs to have an infinite cache of the previous directory contents
23:34:18  <pietern>later!
23:34:26  * pieternquit (Quit: pietern)
23:34:27  <bnoordhuis>later pietern
23:34:30  <bnoordhuis>ah, too late
23:34:55  <bnoordhuis>piscisaureus: yes, that's correct
23:35:03  <rmustacc>piscisaureus: Yup, that's correct. But we're trying to say there is in the API.
23:35:54  <piscisaureus>bnoordhuis: maybe we should just be honest and give the user 2 types of callbacks, 1 that means "hey, this file changed", and one that means "hey, something changed, we don't know what"
23:36:38  <bnoordhuis>piscisaureus: re option #1: you mean a single file watcher?
23:37:50  <piscisaureus>bnoordhuis: suppose you are implementing something that keeps 2 directories in sync. On #1 you would copy one file, on #2 you would trigger full refresh of some kind.
23:38:15  <igorzi>piscisaureus: i just now noticed the "requests short-citcuiting" issue.. did you debug it?
23:39:24  <bnoordhuis>piscisaureus: okay, so option #1 is a directory watcher that checks for you what file changed?
23:39:46  <piscisaureus>igorzi: I can't tell if this caused what the user ran into. But I am pretty sure that this short-circuiting *could* cause that.
23:40:18  <piscisaureus>bnoordhuis: no I mean, when the user instantiates a directory watcher, it has to provide 2 callbacks
23:40:39  <piscisaureus>although returning filename==null is semantically equivalent
23:40:46  <igorzi>piscisaureus: what is the issue exactly? is the caller depending on the order of write callbacks?
23:40:46  <bnoordhuis>piscisaureus: and it would do different things on different platforms?
23:40:48  <igorzi>or?
23:41:00  <piscisaureus>igorzi: well, net_uv depends on the order of callbacks
23:41:06  <igorzi>oh
23:41:39  <igorzi>piscisaureus: how does it depend on it?
23:42:31  <piscisaureus>igorzi: https://github.com/joyent/node/blob/master/lib/net_uv.js#L410-411
23:43:52  * brsonjoined
23:45:24  <piscisaureus>igorzi: let me write a test case
23:45:47  <igorzi>piscisaureus: could we modify net_uv.js to not have this order dependency? i mean, uv api doesn't guarantee any kind of order, right?
23:46:15  <piscisaureus>igorzi: hmm. I think indeed it's best to not guarantee anything.
23:46:22  <piscisaureus>but for writes that may be kind of unexpected
23:46:24  <bnoordhuis>order of writes?
23:46:29  <piscisaureus>yes
23:46:37  <bnoordhuis>should be ordered
23:46:41  <piscisaureus>bnoordhuis: well, the order in which the write callbacks are made
23:46:42  <bnoordhuis>how they come back however
23:46:48  <bnoordhuis>yes, exactly
23:46:56  <piscisaureus>the writes themselves should obviously be ordered
23:47:19  <bnoordhuis>it'd be kind of odd though to order the writes but not the callbacks
23:47:23  <bnoordhuis>not inconceivable, just odd
23:49:24  <ryah>http://nodejs.org/dist/node-v0.4.12.tar.gz <-- please test unix people
23:49:48  * bnoordhuistests
23:49:56  <igorzi>bnoordhuis: right, i don't mean order of writes shouldn't be ordered.. just write callbacks
23:51:08  <ryah>bnoordhuis: please take a look at https://github.com/joyent/node/issues/1720
23:51:15  <ryah>bnoordhuis: i cant reproduce
23:53:15  <bnoordhuis>ryah: wfm
23:54:02  <ryah>bnoordhuis: k
23:54:09  <ryah>bnoordhuis: isaacs is working on a test case
23:55:44  <igorzi>ryah: so, what's your take on this uv_fs_event api mess?
23:57:20  <ryah>sorry i can't weigh in right now
23:59:53  * felixgequit (Quit: felixge)
23:59:58  <ryah>igorzi, bnoordhuis: can we take this discussion async and start an email thread about this