00:02:12  * mikealjoined
00:11:59  <CIA-155>node: Nathan Rajlich master * r3f69c71 / lib/readline.js : readline: explicitly disable and re-enable "raw mode" on Ctrl+Z - http://git.io/A5T7WQ
00:12:02  <CIA-155>node: Nathan Rajlich master * ra608f65 / lib/repl.js : repl: preserve the cursor when redisplaying the prompt on SIGCONT - http://git.io/CCJH1A
00:12:02  <CIA-155>node: Nathan Rajlich master * r2b9967f / lib/readline.js : readline: move the "setRawMode" logic into a private function - http://git.io/9o6xAw
00:18:45  * mikealquit (Quit: Leaving.)
00:46:07  * Ariajoined
00:51:07  <CIA-155>libuv: Bert Belder cares * r96e8aba / (16 files in 6 dirs): windows, unix: share c-ares glue code - http://git.io/3YXXZg
00:51:07  <CIA-155>libuv: Bert Belder cares * r3e1cadb / test/benchmark-ares.c : Make the gethostbyname benchmark more precise - http://git.io/4ByoOg
00:51:52  <piscisaureus_>^-- bnoordhuis can you review that
00:52:03  <bnoordhuis>piscisaureus_: yes, but not tonight
00:52:08  <piscisaureus_>there is a bug in test/dns-server.c btw
00:52:18  <piscisaureus_>a parser error
00:52:30  <piscisaureus_>but I was unable to track down what exactly goes wrong
00:52:42  <piscisaureus_>bnoordhuis: yeah I am also checking out
00:52:44  <piscisaureus_>time for some R&R
00:52:53  <bnoordhuis>yep, sleep tight
00:52:54  * travis-cijoined
00:52:55  <travis-ci>[travis-ci] joyent/libuv#295 (cares - 3e1cadb : Bert Belder): The build is still failing.
00:52:55  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/07d4d71...3e1cadb
00:52:55  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1395462
00:52:55  * travis-cipart
00:54:34  <piscisaureus_>I will be very happy when we get rid of https://github.com/joyent/libuv/blob/ad279df7c08d01b8c683090e955bf628a8aa3bc1/src/win/cares.c
00:57:37  * bnoordhuisquit (Ping timeout: 246 seconds)
01:01:07  * AlbireoXquit (Ping timeout: 246 seconds)
01:23:31  * pieternquit (Ping timeout: 252 seconds)
01:29:53  * xaqquit (Ping timeout: 245 seconds)
01:37:02  * abraxasjoined
01:37:27  * mmalecki_joined
01:38:08  * mmaleckiquit (Ping timeout: 265 seconds)
01:55:47  * ericktquit (Ping timeout: 244 seconds)
02:00:16  * brsonquit (Quit: leaving)
02:09:53  * ericktjoined
02:18:41  * ericktquit (Quit: erickt)
02:22:42  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:26:02  * iraquit (Quit: Computer has gone to sleep.)
03:00:31  * ericktjoined
03:39:20  * c4miloquit (Remote host closed the connection)
03:40:30  * Ariaquit (Remote host closed the connection)
04:14:17  * mmalecki_quit (Quit: Reconnecting)
04:14:34  * mmaleckijoined
05:14:47  * ericktquit (Quit: erickt)
05:24:05  <deoxxa>hmm where's bnoordhuis
05:24:33  <deoxxa>i have a weird device here that libuv doesn't want to work properly on, and he seemed interested in cases like that
05:26:05  * leifjoined
05:26:09  * ljacksonquit (Read error: Operation timed out)
05:43:52  * AlbireoXjoined
05:56:46  * paddybyersjoined
06:06:30  * avalanche123joined
06:42:25  <deoxxa>yep, uv_fs_event is definitely broken on this device
06:42:30  <deoxxa>time to resort to timers!
06:48:16  <mmalecki>deoxxa: Ben is in the Netherlands, it's 8:47 :)
07:02:09  * abraxasquit (Read error: No route to host)
07:02:26  * abraxasjoined
07:07:17  * avalanch_joined
07:10:42  * avalanch_quit (Client Quit)
07:15:33  * avalanche123quit (Quit: Computer has gone to sleep.)
07:22:17  * rendarjoined
07:24:52  <CIA-155>libuv: Igor Zinkovsky master * rea8fa31 / test/test-fs.c : fix fs_symlink_dir test - http://git.io/USsFIg
07:26:40  * travis-cijoined
07:26:41  <travis-ci>[travis-ci] joyent/libuv#296 (master - ea8fa31 : Igor Zinkovsky): The build is still failing.
07:26:41  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/ad279df...ea8fa31
07:26:41  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1397728
07:26:41  * travis-cipart
07:35:29  <indutny>igorzi__: heya
07:35:36  <indutny>igorzi__: how is it going with stdio stuff for libuv?
08:05:19  * mmaleckiquit (Ping timeout: 260 seconds)
11:22:38  * irajoined
11:27:24  * bnoordhuisjoined
11:42:11  * piscisaureus_joined
11:47:21  <bnoordhuis>piscisaureus_: https://github.com/joyent/libuv/commit/ea8fa31fc0c9865c91a8872c15610d80d5ac93c4#L0R1346 <- why +4?
11:47:38  <piscisaureus_>bnoordhuis: a sec
11:50:37  <piscisaureus_>bnoordhuis: hey
11:50:42  <bnoordhuis>piscisaureus_: ho
11:50:48  <piscisaureus_>bnoordhuis: that's because symlinks start with \\?\ on windows
11:51:06  <piscisaureus_>bnoordhuis: hmm wait
11:51:11  <piscisaureus_>that's odd innit? :-)
11:51:15  <bnoordhuis>quite
11:51:59  <piscisaureus_>what is the value of test_dir?
11:53:09  <piscisaureus_>aah
11:53:11  <piscisaureus_>bnoordhuis: https://github.com/joyent/libuv/blob/ea8fa31fc0c9865c91a8872c15610d80d5ac93c4/test/test-fs.c#L1322-1326
11:53:36  <bnoordhuis>ah, right
11:53:54  <bnoordhuis>shouldn't it check for strlen(test_dir) then?
11:54:06  <bnoordhuis>using a #ifdef _WIN32 is pretty nasty
11:54:48  <piscisaureus_>bnoordhuis: *shrug*
11:54:50  <piscisaureus_>ask igor :-)
11:54:55  <piscisaureus_>i didn't read the code
11:55:02  <bnoordhuis>i will
11:55:21  <bnoordhuis>i guess just a strlen(test_dir) won't work either
11:55:34  <bnoordhuis>it looks like the string is \\?\\test_dir\
11:55:58  <bnoordhuis>your windows is strange and confusing
12:00:09  <piscisaureus_>bnoordhuis: that's because of the code I just linked you
12:13:11  <deoxxa>bnoordhuis: got a device here that doesn't want to play nice with uv_fs_event (pretty sure there's no inotify or similar) - is this of interest to you?
12:13:38  <deoxxa>(you mentioned you'd like to know about systems that don't work properly with libuv)
12:14:09  <bnoordhuis>deoxxa: hrm, somewhat. does libuv compile?
12:14:24  <deoxxa>it's statically linked into the executable
12:14:27  <deoxxa>there's no compiler on the box
12:15:04  <bnoordhuis>deoxxa: okay. if the kernel doesn't support inotify, you're out of luck as far as fs events go
12:15:11  <deoxxa>i've worked around it for now with a timer and polling the file i'm interested in (which afaik is going to be the internal libuv workaround too in future)
12:15:23  <bnoordhuis>there wasn't anything usable before inotify
12:15:38  <deoxxa>mmm
12:15:55  <bnoordhuis>yes, a polling stat - i'll cry sad little tears the day i commit that though
12:15:59  <deoxxa>heh
12:16:13  <deoxxa>everything else seems to work just fine though, i'm quite impressed :)
12:16:55  <deoxxa>i've implemented using libuv in a week what took nearly 6 months for a coworker who doesn't appreciate external libraries
12:17:07  * deoxxa<3
12:17:30  <deoxxa>and with a much nicer interface to boot
12:17:40  <piscisaureus_>bnoordhuis: https://github.com/joyent/libuv/compare/cares
12:18:27  <bnoordhuis>piscisaureus_: what should i be looking at?
12:18:37  <piscisaureus_>bnoordhuis: review
12:18:55  <piscisaureus_>bnoordhuis: it didn't change since last night :-)
12:19:43  <piscisaureus_>bnoordhuis: there's a small error in there, I am curious whether you will catch it :-)
12:19:55  <bnoordhuis>let's find out
12:20:01  <piscisaureus_>(i will fix it even if you don't find it :-))
12:24:19  <piscisaureus_>bnoordhuis: ares_handles_ and ares_timer_ are private fields. I didn't add the postfix underscore
12:24:41  <bnoordhuis>piscisaureus_: i know, but it's still inconsistent
12:26:29  * TheJHjoined
12:27:12  <bnoordhuis>piscisaureus_: uv_timer_again(&loop->ares_timer_) <- should the timer be restarted if status != 0?
12:28:08  <piscisaureus_>bnoordhuis: I don't think it matters
12:29:22  <piscisaureus_>bnoordhuis: re superfluous cast - I am not going to fix the cases where we cast void* to something else
12:29:27  <piscisaureus_>bnoordhuis: don't bother mentioning them
12:29:37  <piscisaureus_>bnoordhuis: except in unix-only code
12:29:38  <bnoordhuis>piscisaureus_: i will, again and again, until you stop doing that :)
12:29:40  * abraxasquit (Remote host closed the connection)
12:30:09  <piscisaureus_>never
12:30:11  <piscisaureus_>NEVER
12:30:15  * abraxasjoined
12:32:10  <piscisaureus_>I wish visual studio could show github comments inline
12:33:48  <bnoordhuis>time for a plugin
12:33:54  <bnoordhuis>anyway, reviewed
12:34:17  <piscisaureus_>thanks
12:34:25  * abraxasquit (Read error: Operation timed out)
12:36:22  * piscisaureus_quit (Read error: No route to host)
12:36:50  * piscisaureus_joined
13:09:53  <CIA-155>libuv: Ben Noordhuis master * r6190cab / src/unix/uv-eio.c : unix: remove outdated comment - http://git.io/hzJfiw
13:10:14  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
13:11:52  * travis-cijoined
13:11:52  <travis-ci>[travis-ci] joyent/libuv#297 (master - 6190cab : Ben Noordhuis): The build is still failing.
13:11:52  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/ea8fa31...6190cab
13:11:52  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1399875
13:11:52  * travis-cipart
13:27:16  * piscisaureus_joined
13:28:30  * abraxasjoined
13:41:11  * c4milojoined
13:45:08  <piscisaureus_>bnoordhuis: uv_ares_task is an internal type, right?
13:52:13  * avalanche123joined
13:56:14  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
13:59:28  <bnoordhuis>pisyes
13:59:34  <bnoordhuis>eh, tab complete fail
13:59:57  <bnoordhuis>ircretary: tell piscisaureus_ yes, uv_ares_task is internal
13:59:58  <ircretary>bnoordhuis: I'll be sure to tell piscisaureus_
14:00:10  * ericktjoined
14:01:57  * piscisaureus_joined
14:02:10  <piscisaureus_>yay
14:02:20  <piscisaureus_>sorry my mac is fucking up again
14:02:26  * piscisaureus_quit (Client Quit)
14:02:46  <bnoordhuis>It Just Works(TM)
14:03:01  <indutny>bnoordhuis: it just works for me
14:03:18  <indutny>well, not always
14:03:19  <indutny>but mostly
14:03:52  <bnoordhuis>not quite as convincing though, It Mostly Works(TM)
14:06:29  <CIA-155>libuv: Ben Noordhuis master * ra478847 / (test/test-list.h uv.gyp test/test-callback-order.c): test: add callback order test - http://git.io/5UdcDA
14:06:33  <CIA-155>libuv: Ben Noordhuis master * r80b5541 / (include/uv-private/uv-unix.h src/unix/core.c src/unix/loop.c): unix: reactive new idle watcher implementation - http://git.io/mo26Vw
14:06:57  * piscisaureus_joined
14:08:17  * travis-cijoined
14:08:17  <travis-ci>[travis-ci] joyent/libuv#298 (master - a478847 : Ben Noordhuis): The build is still failing.
14:08:17  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/6190cab...a478847
14:08:17  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1400299
14:08:17  * travis-cipart
14:09:06  <CIA-155>libuv: Bert Belder cares * r7eb118f / test/benchmark-ares.c : Make the gethostbyname benchmark more precise - http://git.io/95JNUw
14:09:07  <CIA-155>libuv: Bert Belder cares * r75e72dd / (16 files in 6 dirs): windows, unix: share c-ares glue code - http://git.io/qA-fmg
14:09:07  <CIA-155>libuv: Bert Belder cares * r753bf6d / (include/uv.h src/cares.c src/uv-common.c src/uv-common.h): Move shared c-ares glue code from uv-common to cares.c - http://git.io/ru3PTQ
14:09:07  <CIA-155>libuv: Bert Belder cares * r3e7e9ca / (3 files in 2 dirs): Get rid of UV_HANDLE_TYPE_PRIVATE - http://git.io/h6ERxg
14:10:10  <piscisaureus_>bnoordhuis: ^-- any desire to look at the last 2 commits?
14:10:23  <bnoordhuis>piscisaureus_: no, but i'll do it anyway
14:10:32  <tjfontaine>heh
14:11:02  * travis-cijoined
14:11:03  <travis-ci>[travis-ci] joyent/libuv#299 (cares - 3e7e9ca : Bert Belder): The build is still failing.
14:11:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/3e1cadb...3e7e9ca
14:11:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1400321
14:11:03  * travis-cipart
14:11:32  <bnoordhuis>piscisaureus_: lgtm
14:11:37  <piscisaureus_>kewl
14:11:53  <piscisaureus_>bnoordhuis: I also fixed your comments but they are squashed already
14:11:59  <bnoordhuis>good
14:12:01  <bnoordhuis>did i find the bug?
14:12:07  <piscisaureus_>yeah it was the memory leak
14:12:13  <bnoordhuis>yay, go me!
14:12:19  <piscisaureus_>bnoordhuis ++
14:12:19  <kohai>bnoordhuis has 16 beers
14:12:43  <CIA-155>libuv: Bert Belder master * r25316a3 / test/benchmark-ares.c : Make the gethostbyname benchmark more precise - http://git.io/A442qw
14:12:43  <CIA-155>libuv: Bert Belder master * rc06edd4 / (16 files in 6 dirs): windows, unix: share c-ares glue code - http://git.io/J6WWzg
14:12:43  <CIA-155>libuv: Bert Belder master * r58ba2d8 / (include/uv.h src/cares.c src/uv-common.c src/uv-common.h): Move shared c-ares glue code from uv-common to cares.c - http://git.io/lFzS5A
14:12:43  <CIA-155>libuv: Bert Belder master * rd166579 / (3 files in 2 dirs): Get rid of UV_HANDLE_TYPE_PRIVATE - http://git.io/L0hD7w
14:13:08  <piscisaureus_>now to get rid of loop->ares_handles and loop->ares_timer
14:13:18  <piscisaureus_>and we can rip out c-ares
14:13:24  <piscisaureus_>but that will be some other time
14:14:30  <bnoordhuis>i don't understand why simple/test-eio-limit fails every once in a while...
14:14:32  * travis-cijoined
14:14:32  <travis-ci>[travis-ci] joyent/libuv#300 (master - d166579 : Bert Belder): The build is still failing.
14:14:32  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/a478847...d166579
14:14:32  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1400342
14:14:32  * travis-cipart
14:16:03  <deoxxa>bnoordhuis: prejudice against humans - it's the beginning of the machine uprising
14:16:06  <CIA-155>node: Ben Noordhuis master * r0888cdd / test/simple/test-cli-eval.js : test: fix bad comment - http://git.io/X3T6ag
14:16:07  <CIA-155>node: Ben Noordhuis master * r989ae81 / test/simple/test-process-active-wraps.js : test: fix simple/test-process-active-wraps - http://git.io/vE43ZQ
14:16:09  <CIA-155>node: Ben Noordhuis master * r039fac6 / (86 files in 11 dirs): deps: upgrade libuv to a478847 - http://git.io/FW5ZIQ
14:16:26  <bnoordhuis>^ there it is, the refcount refactor
14:16:32  <piscisaureus_>cool
14:16:36  <tjfontaine>dun dun dun
14:17:39  <piscisaureus_>bnoordhuis: do you mind if I remove uv_lean_and_mean?
14:18:00  <bnoordhuis>piscisaureus_: not at all, just make sure you update uv-unix
14:18:05  <piscisaureus_>sure
14:18:16  <bnoordhuis>though i'll miss it when debugging
14:18:34  <piscisaureus_>bnoordhuis: do you have uv_walk already?
14:18:55  <bnoordhuis>piscisaureus_: no. trivial to add though
14:18:55  <piscisaureus_>bnoordhuis: I want to keep active_reqs
14:19:12  <piscisaureus_>bnoordhuis: but not active handles, because I want a list of *all* handles
14:19:21  <bnoordhuis>piscisaureus_: sure, i can live with that
14:19:33  <piscisaureus_>and the active reqs should only contain reqs that are created by users (and not windows internal reqs)
14:20:04  <bnoordhuis>yeah, i discovered uv-unix has one or two of those as well
14:20:21  <bnoordhuis>mostly to prime eio
14:20:29  <piscisaureus_>ah, right
15:11:21  <piscisaureus_>bnoordhuis: hey
15:11:33  <piscisaureus_>bnoordhuis: why should idle run before timer_cb?
15:11:43  <piscisaureus_>bnoordhuis: I think that's not true
15:11:55  <piscisaureus_>not as a general rule, anyway
15:12:19  * mrb_bkquit (Read error: Connection reset by peer)
15:12:19  * Raynosquit (Remote host closed the connection)
15:12:22  * indutnyquit (Remote host closed the connection)
15:12:23  * TooTallNatequit (Read error: Connection reset by peer)
15:13:02  * avalanche123quit (Ping timeout: 248 seconds)
15:14:03  <CIA-155>libuv: Bert Belder master * r0ef7844 / test/test-list.h : Disable test-callback-order - http://git.io/0b4vaw
15:15:20  <bnoordhuis>piscisaureus_: it's what node expects
15:15:26  <piscisaureus_>bnoordhuis: it's not
15:15:30  <bnoordhuis>piscisaureus_: see simple/test-next-tick-ordering2
15:15:41  <piscisaureus_>bnoordhuis: windows doesn't fail that test yet it fails test-callback-ordering
15:15:46  <piscisaureus_>it's also not what libev does
15:15:54  * travis-cijoined
15:15:54  <travis-ci>[travis-ci] joyent/libuv#301 (master - 0ef7844 : Bert Belder): The build is still failing.
15:15:54  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/d166579...0ef7844
15:15:54  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1400838
15:15:54  * travis-cipart
15:16:07  <bnoordhuis>that libuv test is a 1-to-1 translation of the node test
15:16:11  * avalanche123joined
15:16:21  <piscisaureus_>that would surprise me
15:16:28  <piscisaureus_>since node doesn't use uv_idle
15:16:44  <piscisaureus_>it processes nextTick with prepare callbacks
15:16:57  <piscisaureus_>the idle thing is only there to keep the loop alive long enough
15:16:59  <bnoordhuis>piscisaureus_: and tick_spinner
15:17:12  <bnoordhuis>but okay, maybe
15:17:13  <piscisaureus_>yes... but it doesn't make nextTick callbacks from the idle
15:20:49  <piscisaureus_>bnoordhuis: ok... so it *also* calls the tick callback from the Idle but that doesn't mean anything... that code is normally not reached
15:21:20  <piscisaureus_>bnoordhuis: nextTick callbacks are usually invoked from prepare or check
15:21:40  * ericktquit (Quit: erickt)
15:21:58  <piscisaureus_>bnoordhuis: If it is failing for you you may not be calling Prepare/Check when the fd set is empty
15:22:46  <piscisaureus_>but nexttick semantics are insane
15:23:41  * mrb_bkjoined
15:25:52  <creationix>why don't we just run nextTick callback when an event source returns?
15:25:56  <creationix>*callbacks
15:26:02  <piscisaureus_>yeah
15:26:10  <piscisaureus_>I think the concern was that if you do
15:26:19  <creationix>only event sources and other nextTick callbacks can register nextTick callbacks
15:26:31  <piscisaureus_>process.nextTick(function() { process.nextTick(arguments.callee) })
15:26:38  <piscisaureus_>^-- that would starve all other events
15:27:02  <creationix>I'd consider that a feature
15:27:03  <piscisaureus_>but I don't think it would matter much
15:27:29  <creationix>while(true) {} starves other events too
15:28:06  <creationix>of course, then it should probably be called afterTick instead of nextTick
15:28:19  <creationix>but that's usually what a person wants anyway
15:28:27  <piscisaureus_>setImmediate as w3c would call it :-)
15:28:42  <creationix>interesting name
15:28:47  <creationix>I guess to be like setTimeout
15:29:14  <creationix>except it's not "Immediate", it's later, but within this tick
15:29:17  <piscisaureus_>yeah I guess so
15:29:21  <piscisaureus_>setLater
15:29:39  <creationix>emberjs has something like this, but I'm not sure it's exposed to user scripts
15:30:10  <creationix>since they wrap all event sources, there is a loop to handle nextTick-like things when it returns
15:30:33  <creationix>I wonder how much node code would break if we changed nextTick
15:30:41  <piscisaureus_>Not so much probably
15:30:50  <piscisaureus_>node.cc is a mess
15:30:58  * pieternjoined
15:31:35  <piscisaureus_>creationix: but you should probably be happy with this weirdness
15:32:11  <piscisaureus_>creationix: it ensures that we need to define libuv's loop behaviour very precisely
15:33:19  <creationix>I don't use any of the uv_prepare, uc_idle, etc in my projects
15:33:25  <creationix>never understood them or needed them
15:33:46  <piscisaureus_>prepare and check are rather odd
15:33:49  * indutnyjoined
15:33:53  <piscisaureus_>I think node is actually abusing them
15:33:55  <piscisaureus_>idle is nice
15:34:12  <piscisaureus_>suppose you would implement a game
15:34:32  <piscisaureus_>you could process events at normal priority
15:34:39  <piscisaureus_>and in an idle callback you render a frame
15:34:50  <indutny>huh
15:34:53  <indutny>piscisaureus_: sup?
15:35:06  <piscisaureus_>creationix: libuv/libev will just call your idle callback unless it has something else to do
15:35:19  <piscisaureus_>indutny: nothing ?
15:35:25  <indutny>piscisaureus_: looks like :)
15:35:34  <creationix>yeah, I see how they could be useful
15:35:37  <creationix>just never needed them
15:36:35  <creationix>hmm, so quick question on setImmediate and the desired behavior of process.nextTick
15:36:41  <creationix>should it be before or after other queued events?
15:36:53  <creationix>before is much easier to implement and usually what I want
15:36:55  <piscisaureus_>heh
15:36:59  <piscisaureus_>neither I guess
15:37:28  <piscisaureus_>it should run before events that are initiated in current the tick are completed
15:37:29  * TheJHquit (Ping timeout: 245 seconds)
15:37:32  <creationix>by "queued events" I mean other event sources that have already been put in the event queue
15:38:13  <creationix>so if I setTimeout(fn, 10) and then busy loop for 400ms calculating primes, and then nextTick(fn2), should fn2 be before or after fn
15:38:38  <piscisaureus_>before
15:39:00  <piscisaureus_>because setTimeout is called in the same tick as nextTick
15:39:04  <creationix>and if within fn2, I do another nextTick(fn3) should fn3 still be before fn?
15:39:16  <piscisaureus_>no
15:39:19  <creationix>why?
15:39:32  <creationix>it's still the same tick (well right after it I guess)
15:39:44  <piscisaureus_>well, I'm not saying *should*, but that's what it does
15:39:51  <creationix>yes, that's what it does today
15:39:59  <creationix>I personally hate that behavior
15:40:06  <creationix>it causes nasty race conditions
15:40:11  <creationix>and hurts performance
15:40:12  <piscisaureus_>creationix: there are wonky edge cases tho
15:40:57  <creationix>and what would setImmediete do in the fn2, fn3 case?
15:41:13  <creationix>it says it executed after UI stuff, but doesn't mention things like new click events or expired timeouts
15:41:20  <creationix>there is no UI layer in node
15:41:26  <piscisaureus_>function f2() {
15:41:26  <piscisaureus_> process.nextTick(f1c)
15:41:26  <piscisaureus_>}
15:41:26  <piscisaureus_>function f1() {
15:41:26  <piscisaureus_> process.nextTick(f1b);
15:41:26  <piscisaureus_>}
15:41:26  <piscisaureus_>process.nextTick(f1);
15:41:27  <piscisaureus_>process.nextTick(f2);
15:41:33  <piscisaureus_>^-- creationix: what order would you suggest?
15:41:56  <creationix>so when the event source finishes, the queue has [f1, f2]
15:41:58  <piscisaureus_>hmm I meant to say "f2b" and not "f1c"
15:42:33  <creationix>it then executes f1 which puts f2b in the queue [f2, f1b]
15:42:48  <creationix>s/f2b/f2b/
15:42:53  <piscisaureus_>ghe
15:42:56  <piscisaureus_>I see what you mean ?
15:43:00  <piscisaureus_>s/?/!/
15:43:07  * Raynosjoined
15:43:20  <creationix>as long as it's a queue and you only pull from the front, it's very well defined
15:43:25  <creationix>all within the same stack
15:43:48  <piscisaureus_>creationix: true... but you just defined a semantic where nextTick is always called immediately after the current tick
15:44:16  <piscisaureus_>but that breaks as soon as multiple nextTicks are queued within the same tick
15:44:27  <creationix>how does it break?
15:44:34  <creationix>it's single threaded, there is one queue
15:44:41  <creationix>order is well defined
15:44:51  <creationix>callbacks get called in the order they are registered till there are none left
15:45:48  <piscisaureus_>Currently the actual semantics are very odd
15:46:18  <creationix>right, what I want is very simple. The only downside is some current code may busyloop if it depends on infinite recursive nextTicks
15:46:32  <creationix>also what I want shouldn't be called "nextTick"
15:46:39  <piscisaureus_>Every time processTicks is called all the callbacks that are in the queue at that point in time are made, but new nextTick callbacks are put on a new queue and executed on the next processTicks invocation
15:46:46  <piscisaureus_>and a loop looks like this
15:46:59  * avalanche123quit (Ping timeout: 276 seconds)
15:47:04  <piscisaureus_>processTicks -> processTicks -> processTimers -> processIoEvents -> repeat
15:47:15  <creationix>when did that change? I remember node code used to be `while (next = queue.shift()) {next()}
15:47:24  <piscisaureus_>a long long time ago
15:47:49  <piscisaureus_>(the two processTicks in a row is not an oversight)
15:48:31  <creationix>so processTicks is what eats the current queue of nextTick functions?
15:48:37  <piscisaureus_>yep
15:48:50  <creationix>that's really strange
15:48:52  <piscisaureus_>well, it's actually called _tickCallback
15:48:53  <piscisaureus_>but yeah
15:49:00  <creationix>that's going to bite people
15:49:09  <piscisaureus_>probably not
15:49:16  <creationix>the first two time you call it, it's before real events, but not beyond that
15:49:19  <piscisaureus_>the semantics are so weird that nobody will rely on anything
15:49:31  <creationix>also if I re4gister a nextTick in a timer, then I/O events still come in first?
15:49:33  <deoxxa>^^ famous last words
15:49:43  <piscisaureus_>creationix: yep
15:49:45  * avalanche123joined
15:49:54  * TooTallNatejoined
15:50:10  <creationix>ok, how about this, we leave nextTick as it is, but add a simpler one called afterTick or setImmediate that does what I want
15:50:19  <piscisaureus_>creationix: it's easy to test
15:51:12  <creationix>so what is the purpose of nextTick in the first place?
15:51:21  <creationix>I don't think that's clearly defined
15:51:30  <creationix>it's too unreliable in the current form for the things I need it for
15:54:54  <piscisaureus_>creationix: https://gist.github.com/2769922
15:54:54  <piscisaureus_>here's what I get on windows:
15:54:54  <piscisaureus_>timeout
15:54:54  <piscisaureus_>timeout
15:54:54  <piscisaureus_>nexttick set by nexttick
15:54:55  <piscisaureus_>nexttick set by timer
15:54:55  <piscisaureus_>nexttick set by timer
15:54:56  <piscisaureus_>nexttick set by nexttick
15:54:56  <piscisaureus_>// repeat
15:55:56  <piscisaureus_>I wonder where the double timeout comes from btw
15:56:26  * avalanche123quit (Ping timeout: 252 seconds)
15:57:30  <creationix>strange
15:59:23  <piscisaureus_>let's add some busy loop to the tick() function
16:00:03  * avalanche123joined
16:00:04  <piscisaureus_>In unix I get
16:00:05  <piscisaureus_>timeout
16:00:05  <piscisaureus_>nexttick set by nexttick
16:00:05  <piscisaureus_>nexttick set by timer
16:00:05  <piscisaureus_>nexttick set by nexttick
16:00:05  <piscisaureus_>timeout
16:00:12  <piscisaureus_>if I add a busyloop to tick()
16:00:43  <piscisaureus_>the double timer looks like a bug in uv-win to me
16:03:04  * brsonjoined
16:03:16  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
16:13:25  * avalanche123quit (Ping timeout: 252 seconds)
16:16:31  * avalanche123joined
16:16:57  <igorzi__>indutny: hey.. yt?
16:17:03  <indutny>igorzi__: yep
16:17:30  <igorzi__>indutny: has your stdio stuff landed yet?
16:17:41  <indutny>igorzi__: you mean unix part of it?
16:17:57  <indutny>I think no
16:18:46  <igorzi__>indutny: yes, unix part
16:18:54  <igorzi__>indutny: also, you're making changes to the API?
16:19:02  <igorzi__>(to support uv_stream_t)?
16:19:08  <indutny>igorzi__: yes, I did that
16:19:21  <indutny>igorzi__: nothing else changed
16:19:42  <igorzi__>indutny: ok
16:41:51  * AvianFlujoined
16:48:33  <deoxxa>what's the best way to do HTTP with libuv? is there any existing code i can steal from node's core or something?
16:48:37  <deoxxa>specifically to act as a client
16:52:33  <tjfontaine>deoxxa: perhaps with some help from https://github.com/joyent/http-parser
16:52:44  * perezdjoined
16:52:56  <deoxxa>yeah, i'm thinking that looks like a winner for parsing the response
16:53:21  <deoxxa>but i was wondering if there was perhaps some code existing already for doing the request
16:53:32  <deoxxa>i mean, i can just manually construct it, my requests don't change a whole lot
16:53:47  <deoxxa>but it would be neat
16:55:38  * mmaleckijoined
16:55:48  * AvianFluquit (Ping timeout: 240 seconds)
16:56:32  * saghulquit (Ping timeout: 276 seconds)
16:59:10  * saghuljoined
16:59:39  * AvianFlujoined
17:03:02  * brsonquit (Ping timeout: 276 seconds)
17:04:54  * mmaleckiquit (Ping timeout: 260 seconds)
17:09:28  * brsonjoined
17:11:33  * brsonquit (Read error: Connection reset by peer)
17:11:46  * brsonjoined
17:13:55  * mmaleckijoined
17:19:42  * avalanche123quit (Ping timeout: 244 seconds)
17:19:47  * mmaleckiquit (Ping timeout: 252 seconds)
17:21:07  * avalanche123joined
17:26:15  * avalanche123quit (Quit: Computer has gone to sleep.)
17:30:40  * mmaleckijoined
18:05:22  * mikealjoined
18:13:58  * ericktjoined
18:20:51  * avalanche123joined
19:50:12  * isaacsjoined
20:02:50  * piscisaureus_joined
20:03:16  <piscisaureus_>hello
20:03:30  * piscisaureus_quit (Read error: Connection reset by peer)
20:04:03  * perezdquit (Quit: perezd)
20:04:06  * piscisaureus_joined
20:13:04  * perezdjoined
20:14:21  * mikealquit (Quit: Leaving.)
20:17:58  <igorzi__>piscisaureus_: hey.. yt?
20:18:15  <piscisaureus_>igorzi__: yep, I'm here
20:19:18  <igorzi__>piscisaureus_: from what we talked about yesterday (about uv_spawn).. you wanted all new pipes to be duplex by default?
20:20:42  <piscisaureus_>igorzi__: well, I am not sure. Making them all duplex has some merits
20:21:27  <igorzi__>piscisaureus_: well.. we need a system of what the defaults are and how to override defaults
20:22:06  <igorzi__>piscisaureus_: with the api that indutny has right now (https://github.com/joyent/libuv/pull/413) it seems that duplex is not the default (since we have explicit UV_DUPLEX_PIPE)
20:22:36  <igorzi__>piscisaureus_: or do you think we need to change the api and add UV_PIPE_READABLE/UV_PIPE_WRITEABLE?
20:24:48  * piscisaureus_quit (Ping timeout: 240 seconds)
20:24:53  * piscisaureus__joined
20:24:57  * piscisaureus__changed nick to piscisaureus_
20:25:12  <piscisaureus_>igorzi__: sorry, my internet is really flaky atm :-(
20:25:25  <piscisaureus_>[22:20] <piscisaureus_> igorzi__: but at least I'd like to not hard-code that 0 is write-only and 1,2 are read-only (from the parent process' perspective)
20:25:25  <piscisaureus_>[22:21] <piscisaureus_> igorzi__: I think we can just add a flag that specifies the modality of the pipe
20:25:55  <piscisaureus_>igorzi__: re UV_PIPE_READABLE/UV_PIPE_WRITEABLE - I dig that
20:26:02  <piscisaureus_>seems the most reasonable we can do
20:26:47  <piscisaureus_>although you'll have to document clearly whether readable/writable is from the parent's - or from the child's perspective
20:28:03  <igorzi__>piscisaureus_: ok thanks
20:28:19  <igorzi__>indutny: ^
20:28:39  <igorzi__>piscisaureus_: one more thing
20:29:00  <igorzi__>piscisaureus_: junctions.. do you think we need to expose junction as an option in node js api?
20:29:23  <igorzi__>piscisaureus_: or do we just try to be smart and create junctions when possible?
20:29:26  <piscisaureus_>igorzi__: yes
20:29:32  <piscisaureus_>igorzi__: no I think it should be explicity
20:29:35  <piscisaureus_>*explicit
20:29:55  <igorzi__>piscisaureus_: and what do you think should be the default?
20:30:09  <piscisaureus_>igorzi__: default should be symlink to a file imho
20:30:12  <piscisaureus_>as it is now
20:30:29  <igorzi__>piscisaureus_: ok, so don't change the default.. just add another 'junction' option
20:30:35  <piscisaureus_>yep
20:30:42  <igorzi__>piscisaureus_: k.. thx
20:30:51  <piscisaureus_>igorzi__: that's my opinion - but it's bikeshedding to a large extent
20:31:25  <piscisaureus_>isaacs: you have an opinion on this matter? You'll likely be the first user of junctions -)
20:32:11  <igorzi__>piscisaureus_: i don't know :).. i don't use links a lot.. i think the primary reason for this is to enable "npm link", in which case exposing junction in the api should be good
20:34:28  <igorzi__>piscisaureus_: i suppose that we could make it more automatic (like create a junction if the target is dir and it exists), but i don't know if that'll be useful or if that'll confuse people
20:37:00  * TheJHjoined
20:37:18  * piscisaureus_quit (Ping timeout: 240 seconds)
20:41:24  * piscisaureus_joined
20:41:51  * piscisaureus_quit (Read error: Connection reset by peer)
20:42:56  * piscisaureus_joined
20:49:40  <piscisaureus_>igorzi__: we could make it more automatic but it only works if the target exists
20:49:57  <igorzi__>piscisaureus_: right
20:50:08  <piscisaureus_>also it's not nice to switch between junctions and symlinks automatically because they have different semantics
20:50:38  <igorzi__>piscisaureus_: true.. especially if one works when running non-elevated and the other one doesn't
20:50:42  <piscisaureus_>In general I don't like doing automagic unless we can make it *always* work
20:50:54  <piscisaureus_>so let's just go the explicit route
20:51:01  <igorzi__>piscisaureus_: ok, sounds good
20:54:12  * TheJHquit (Read error: Operation timed out)
20:57:09  * avalanche123quit (Quit: Computer has gone to sleep.)
21:01:10  <CIA-155>node: Igor Zinkovsky master * r6e435da / test/simple/test-child-process-fork-exec-argv.js : remove race from test-child-process-fork-exec-argv test - http://git.io/VPZJCw
21:04:06  * avalanche123joined
21:12:22  * mikealjoined
21:17:08  <isaacs>piscisaureus_: igorzi__: as long as there's an easy way to say "make something just like a symlink in unix", and it behaves like one, then i'm all for it.
21:17:18  <isaacs>piscisaureus_: igorzi__: I know that's kind of a vague opinion :)
21:17:52  <isaacs>but, i guess it falls a little more on the "behave the same as unix" side of the fence.
21:17:56  <isaacs>by default, anyway
21:18:14  <isaacs>even if that means slightly more magic
21:18:35  <piscisaureus_>isaacs: well, the problem is we can't do that really :-)
21:18:44  <isaacs>right
21:18:46  <igorzi__>isaacs: we're leaning against magic, and instead make it explicit
21:18:50  <isaacs>sure
21:19:02  <isaacs>the biggest problem is lstat, really
21:19:19  <piscisaureus_>isaacs: aah, lstat and readlink can work automagically :-)
21:19:26  <isaacs>right
21:19:28  <isaacs>readlink already works
21:19:37  <isaacs>but lstat doesn't, and that confuses npm link super badly
21:19:54  <igorzi__>isaacs: you'll just need to pass an extra 'junction' option for symlink on windows
21:19:56  <isaacs>what would be the noticeable effect in the "explicit" approach
21:19:58  <piscisaureus_>isaacs: but for symlinks you'll have to specify whether the target is supposed be a directory or a file
21:20:10  <piscisaureus_>because if you get the type wrong the symlink doesn't work
21:20:24  <isaacs>piscisaureus_: i think right now, I do fs.symlink(f, t, 'dir')
21:20:31  <piscisaureus_>isaacs: and if that fails (because of windows XP, or not admin), you can retry and create a junction
21:20:47  <piscisaureus_>isaacs: but junctions can never point to files
21:20:50  <isaacs>i see
21:20:54  <piscisaureus_>isaacs: and junctions are always an absolute path
21:21:01  <isaacs>eew
21:21:28  <igorzi__>piscisaureus_: i believe we always resolve relative paths to absolute paths in node (for windows anyway)
21:21:30  <piscisaureus_>isaacs: we (or at least, I) don't want to upgrade fs.symlink to auto choose a particular type
21:21:47  <piscisaureus_>igorzi__: not for symlinks I suppose? That would not be good :_)
21:22:20  <igorzi__>https://github.com/joyent/node/blob/master/lib/fs.js#L480
21:22:28  <igorzi__>piscisaureus_: ^
21:23:11  <piscisaureus_>ew
21:23:16  <piscisaureus_>we shouldn't do that for relative paths
21:23:40  <piscisaureus_>the symlink name itself of course
21:23:42  <piscisaureus_>but not the target
21:24:02  <isaacs>yeah, a symbolic link is supposed to be symbolic :)
21:24:43  <igorzi__>piscisaureus_: should we not do that for all fs functions? or just symlink? (not resolve relative path target)
21:25:06  <piscisaureus_>igorzi__: we should generally do it
21:25:16  <piscisaureus_>igorzi__: but specifically *not* for relative symlink targets :-)
21:25:55  <igorzi__>piscisaureus_: ok, i'll include that in the junction change.. i'll make _makeLong return the same path if it's relative
21:26:49  <piscisaureus_>igorzi__:nono
21:26:57  <piscisaureus_>igorzi__: makeLong should absoluteize paths
21:27:19  <piscisaureus_>igorzi__: but we should just not call makelong for the symlink target if that target is relative
21:27:20  * rendarquit
21:27:37  <igorzi__>piscisaureus_: you just said that shouldn't be limited to symlinks :)
21:27:45  <piscisaureus_>umm
21:27:47  <piscisaureus_>I mean
21:27:55  <piscisaureus_>we should generally do it (where it == makeLong)
21:28:04  <piscisaureus_>but specifically *not* for symlink targets
21:28:08  <piscisaureus_>^-- igorzi__
21:28:33  <igorzi__>piscisaureus_: so wouldn't it be cleaner to modify makeLong to do the right thing? (it's already basically a noop on unix)
21:28:39  <piscisaureus_>igorzi__: I just tested it and windows allows symlink targets to exceed 256 characters even when not prefixed with \\?\
21:28:52  <piscisaureus_>igorzi__: well then it no longer works for long relative paths
21:29:37  <piscisaureus_>igorzi__: e.g. fs.open('some-very-long/albeit/relative/...longer-than-256-chars-.../path') will no longer work
21:30:12  <piscisaureus_>igorzi__: I think CreateFile also rejects *relative* paths longer than 256 characters
21:32:26  <igorzi__>piscisaureus_: ok.. so we can't have it both ways then.. let's limit not resolving relative paths to symlink then?
21:33:12  <piscisaureus_>igorzi__: yes, to the symlink *target*
21:33:20  <piscisaureus_>igorzi__: the symlink itself should be makelong'd
21:34:01  <igorzi__>piscisaureus_: right.. but for all other fs functions - we should still make them go through makeLong (which resolves relative to absolute)
21:34:06  <piscisaureus_>igorzi__: yes
21:34:23  <piscisaureus_>igorzi__: that is by far the best thing to do :-)
21:34:29  <igorzi__>piscisaureus_: ok :)
21:34:31  <piscisaureus_>igorzi__: actually, unix should do it too
21:41:12  * avalanche123quit (Quit: Computer has gone to sleep.)
21:44:45  * c4miloquit (Remote host closed the connection)
21:52:09  * isaacsquit (Remote host closed the connection)
21:53:04  * paddybyersquit (Quit: paddybyers)
21:53:36  * avalanche123joined
21:54:11  <igorzi__>piscisaureus_: i wonder if we should add another arg to fs.symlink (for junction) or reuse the same arg as we use for 'dir'?
21:54:31  <igorzi__>piscisaureus_: maybe flags? 'd' or 'j' or 'dj'?
21:54:40  <igorzi__>piscisaureus_: what do you think?
21:54:45  <piscisaureus_>igorzi__: what would be the merits of adding another option?
21:55:07  <piscisaureus_>igorzi__: I think we can just document that "junction" implies that the target has to be a dir
21:56:46  <igorzi__>piscisaureus_: ahh, so 'dir' automatically means junction?
21:56:52  <piscisaureus_>igorzi__: no
21:57:01  <piscisaureus_>"dir" means symlink w/ dir type
21:57:14  <piscisaureus_>"junction" means junction with "dir" target
21:57:20  <piscisaureus_>because junctions cannot point to files
21:57:27  <igorzi__>piscisaureus_: just take 'junction' as type, and that'll automatically mean dir
21:57:53  <igorzi__>piscisaureus_: so type can be 'file', 'dir', or 'junction' ?
21:57:53  <piscisaureus_>yes
21:57:56  <piscisaureus_>ey
21:57:57  <piscisaureus_>yes
21:58:01  <igorzi__>ok, nice
21:58:39  <piscisaureus_>igorzi__: just like mklink actually
21:59:01  <piscisaureus_>igorzi__: except that mklink has no "file" option because that's the default
21:59:35  <igorzi__>piscisaureus_: ok, makes sense
22:03:50  * perezdquit (Quit: perezd)
22:41:09  <piscisaureus_>too hot here
22:44:23  <piscisaureus_>bnoordhuis: when are you coming to 020?
22:47:58  * mikealquit (Quit: Leaving.)
22:54:34  <bnoordhuis>piscisaureus_: thursday
22:55:34  <piscisaureus_>ok
23:00:46  <CIA-155>libuv: Igor Zinkovsky master * r253d718 / src/win/fs.c : report correct error - http://git.io/hizXWg
23:01:33  * mikealjoined
23:02:31  * travis-cijoined
23:02:32  <travis-ci>[travis-ci] joyent/libuv#302 (master - 253d718 : Igor Zinkovsky): The build is still failing.
23:02:32  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/0ef7844...253d718
23:02:32  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1405699
23:02:32  * travis-cipart
23:08:37  * c4milojoined
23:13:12  * avalanche123quit (Quit: Computer has gone to sleep.)
23:33:27  <CIA-155>libuv: Igor Zinkovsky master * r2df8317 / src/win/fs.c : windows: set flags for uv_fs_symlink - http://git.io/QDWhJQ
23:33:45  * AvianFluquit (Quit: Leaving)
23:35:15  * travis-cijoined
23:35:15  <travis-ci>[travis-ci] joyent/libuv#303 (master - 2df8317 : Igor Zinkovsky): The build is still failing.
23:35:15  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/253d718...2df8317
23:35:15  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1405963
23:35:15  * travis-cipart
23:40:16  <igorzi__>piscisaureus_ bnoordhuis: can we upgrade libuv in node?
23:45:38  <piscisaureus_>igorzi__: yep
23:46:11  <piscisaureus_>igorzi__: ben did it earlier today as well; the refcount refactor already landed
23:49:06  <igorzi__>piscisaureus_: yep, saw that. i had several other fixes that i wanted to get into node (to get junctions working)
23:49:21  <piscisaureus_>igorzi__: go ahead :-)
23:49:39  <pfox__>piscisaureus_: it landed? congratulations! is the uv_walk on windows work still needed?
23:50:07  <piscisaureus_>pfox__: yep. Hold off a bit, I am working on it myself
23:50:34  <CIA-155>node: Igor Zinkovsky master * rdff467d / (18 files in 7 dirs): update uv to 2df831723fad25d2d97b824b2e52c65082af2723 - http://git.io/rWec5Q
23:51:18  <CIA-155>libuv: Ben Noordhuis master * r7a64ec4 / test/test-tcp-writealot.c : test: clean up test-tcp-writealot.c - http://git.io/PJ7-aw
23:52:05  <pfox__>piscisaureus_: you are a hero. thank you.
23:53:05  * travis-cijoined
23:53:05  <travis-ci>[travis-ci] joyent/libuv#304 (master - 7a64ec4 : Ben Noordhuis): The build is still failing.
23:53:05  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/2df8317...7a64ec4
23:53:05  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1406144
23:53:05  * travis-cipart
23:56:41  <piscisaureus_>pfox__: It's easy now. But I am getting rid of UV_LEAN_AND_MEAN at the same time.
23:57:04  <pfox__>still my hero.
23:57:38  <pfox__>ill stay tuned then, rust will definitely want to update its libuv submodule soon
23:57:42  <piscisaureus_>igorzi__: hey
23:57:48  <piscisaureus_>igorzi__: you forgot to add src/cares.c
23:57:56  <pfox__>having uv_walk will make our libuv story a lot more straightforward. huzzah, etc.
23:58:23  <piscisaureus_>good to hear that :-)