00:04:57  * travis-cijoined
00:04:58  <travis-ci>[travis-ci] joyent/node#718 (master - 1c88c3b : Bert Belder): The build is still failing.
00:04:58  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/c1f52a1...1c88c3b
00:04:58  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1070845
00:04:58  * travis-cipart
00:06:41  * dylukesjoined
00:07:11  * piscisaureusquit (Ping timeout: 276 seconds)
00:08:36  * piscisaureusjoined
00:08:49  * dylukesquit (Client Quit)
00:08:50  * piscisaureuschanged nick to piscisaureus_
00:14:05  * mikealjoined
00:14:57  <bnoordhuis>isaacs: who moderates nodejs-dev?
00:15:14  <isaacs>bnoordhuis: i do, ryan, maybe some other folks
00:15:18  <isaacs>bnoordhuis: you want admin creds on it?
00:15:27  <bnoordhuis>isaacs: yes please. can you op piscisaureus_ too?
00:15:37  <isaacs>sure
00:17:26  <isaacs>bnoordhuis: are you even on that list?
00:17:43  <bnoordhuis>isaacs: sure am
00:17:48  <isaacs>hm..
00:17:49  <bnoordhuis>just received three new emails :)
00:18:01  <isaacs>hat email address?
00:18:04  <isaacs>*what email address?
00:18:21  <bnoordhuis>isaacs: Delivered-To: info@bnoordhuis.nl
00:19:10  <isaacs>k, you're both managers
00:19:20  <isaacs>couldn't find you via just bnoordhuis, had to use the full address.
00:19:26  <isaacs>google's not so good at searching, these days
00:19:35  <bnoordhuis>search is hard
00:19:39  <bnoordhuis>let's go shopping
00:20:53  <isaacs>omg this make bug is killing me
00:21:06  <isaacs>clean checkout, run `make`
00:21:07  <isaacs>builds fine
00:21:18  <isaacs>run `make test` BUILDS ENTIRE PROJECT AGAIN
00:22:53  * mikealquit (Quit: Leaving.)
00:23:15  <bnoordhuis>annoying isn't it?
00:23:22  <piscisaureus_>hmm. upc is crapping out
00:23:42  <bnoordhuis>every time it happens i curse but i never got around to fixing it :/
00:24:10  <bnoordhuis>piscisaureus_: how so?
00:24:23  <piscisaureus_>very slow and flaky
00:24:37  <piscisaureus_>seems to effect http mostly
00:24:49  <piscisaureus_>I wonder if they are testing their TPB filter :-( :-( :-(
00:24:53  <bnoordhuis>hah
00:26:04  <isaacs>are you guys not seeing this rebuilding craziness?
00:27:29  <bnoordhuis>isaacs: i usually compile with `make -C out BUILDTYPE=Debug|Release`
00:27:36  <bnoordhuis>which neatly sidesteps the issue
00:27:54  <isaacs>bnoordhuis: ok. but that's not really an anser.
00:28:12  <bnoordhuis>isaacs: the answer is 'yes' if i run `make test`
00:28:17  <isaacs>ok
00:28:29  <isaacs>this was not broken on 3ec84a1
00:29:09  <bnoordhuis>it's been broken for the longest time
00:29:14  <isaacs>nuh uh
00:29:21  <bnoordhuis>well, it is for me
00:29:21  <isaacs>it wasn't broken this morning
00:29:38  <isaacs>bnoordhuis: you sure you haven't just been sidestepping a ghost for a while?
00:29:49  <bnoordhuis>hah, no
00:29:56  <bnoordhuis>it happens intermittently
00:30:10  <bnoordhuis>like i said, i curse and plan to investigate - but i never do
00:30:22  <bnoordhuis>there's enough distractions already
00:34:25  <CIA-99>libuv: Ben Noordhuis master * r4741a11 / test/test-fs-event.c : test: disable fs_event_close_in_callback on kqueue-based systems - http://git.io/gpIGGA
00:36:20  * travis-cijoined
00:36:20  <travis-ci>[travis-ci] joyent/libuv#187 (master - 4741a11 : Ben Noordhuis): The build is still failing.
00:36:20  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/2e5e116...4741a11
00:36:20  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1071152
00:36:20  * travis-cipart
00:40:47  * bulatshakirzyanojoined
00:42:19  * perezdquit (Quit: perezd)
00:42:33  <isaacs>bnoordhuis: aa5961a445acbd2b533ef870eb19733be7b7ede5 made this start happening
00:42:45  <isaacs>apparently
00:42:51  <isaacs>thought for the life of me, i don't see why
00:43:42  * mikealjoined
00:43:52  <bnoordhuis>isaacs: you mean that if you revert it, the problem goes away?
00:44:05  <isaacs>no, i mean bisect found that. i'm reverting it and trying now
00:44:18  <isaacs>but i'm not hopeful. it makes no sense
00:44:22  <isaacs>i think this is random.
00:44:55  <isaacs>since that commit does nothing to change any files or build things, unless that error was somehow blocking some kind of bad behavior somewhere
00:45:09  <isaacs>but i wasn't even seeing that error on my machine
00:45:09  * mikealquit (Client Quit)
00:46:20  * orlandovftwquit (Ping timeout: 244 seconds)
00:46:47  <bnoordhuis>yeah... maybe that bug was masking some other bug in gyp
00:47:04  <bnoordhuis>then again, i *have* seen this behavior before
00:48:39  <isaacs>bnoordhuis: yes, reverting that commit fixes it.
00:48:41  * isaacspuzzled.
00:48:53  * isaacstrying again, jsut to tempt the randomness gremlins
00:49:36  <isaacs>yeah, i don't doubt it
00:49:52  <isaacs>i have a lot of disdain for everything that wraps make. gyp is the least terrible.
00:50:09  <isaacs>but it's so easy to screw up the dependency set
00:50:44  * dshaw_quit (Quit: Leaving.)
00:52:49  <isaacs>yeah
00:52:53  <isaacs>that's definitely it
00:53:11  <isaacs>ugh. why does every build system suck so bad?
00:53:32  <bnoordhuis>we should all switch to lisp
00:53:53  <bnoordhuis>you can revert that commit if you want but it's kind of annoying
00:54:42  <isaacs>what does it do?
00:54:51  <isaacs>do you get an error or something?
00:55:12  <bnoordhuis>isaacs: http://groups.google.com/group/gyp-developer/browse_thread/thread/c4e2dd33e6a7a08
00:55:40  <bnoordhuis>i was running into the ARG_MAX limit
00:55:51  * pijewskiquit (Quit: Leaving.)
00:55:57  <bnoordhuis>suppose i'll have to move up the node source tree a couple of directories...
00:56:14  <isaacs>hm. i see
01:04:40  <bnoordhuis>piscisaureus_: ping
01:05:08  <piscisaureus_>bnoordhuis: yes?
01:05:17  <bnoordhuis>piscisaureus_: how is the shutdown_close_tcp test supposed to work?
01:05:30  <bnoordhuis>it creates a shutdown req, then immediately closes the handle
01:05:36  <piscisaureus_>bnoordhuis: yes
01:05:45  <piscisaureus_>bnoordhuis: the shutdown request is supposed to return
01:05:59  <bnoordhuis>piscisaureus_: return what?
01:06:01  <piscisaureus_>bnoordhuis: because the rule is that all requests must always make their callback
01:06:23  <bnoordhuis>piscisaureus_: okay. so what do you do on windows? hold off the close callback for another tick?
01:06:30  <piscisaureus_>bnoordhuis: yes
01:06:33  <bnoordhuis>ah
01:06:40  <bnoordhuis>now it starts to make sense
01:06:40  <piscisaureus_>bnoordhuis: well, we just hold it off until the shutdown callback is made
01:06:47  * bulatshakirzyanoquit (Quit: Computer has gone to sleep.)
01:06:58  <piscisaureus_>bnoordhuis: whenever that may be
01:08:25  <piscisaureus_>bnoordhuis: so what did you think?
01:08:35  <bnoordhuis>piscisaureus_: i think it's time to go to bed
01:08:47  <piscisaureus_>bnoordhuis: what *did* you think?
01:09:10  <bnoordhuis>piscisaureus_: i suspected the idea was to postpone the close cb
01:09:56  <piscisaureus_>bnoordhuis: the idea is *always* to postpone the close cb until all requests and other callbacks related to the handle have flushed out
01:10:18  <bnoordhuis>piscisaureus_: what about write reqs?
01:10:27  <piscisaureus_>bnoordhuis: those too
01:10:45  <piscisaureus_>bnoordhuis: uv-unix doesn't
01:10:46  <piscisaureus_>?
01:10:53  <bnoordhuis>well...
01:11:16  <bnoordhuis>it doesn't - uv_close stops the write watcher
01:11:58  <piscisaureus_>bnoordhuis: so the idea is *not* to complete all the requests successfully
01:12:05  <piscisaureus_>bnoordhuis: but their callbacks should be made
01:12:16  <bnoordhuis>piscisaureus_: right. that happens, with status=-1
01:12:27  <piscisaureus_>bnoordhuis: and if the write or shutdown (or connect or whatever) didn't succeed the status should be -1
01:12:31  <toothr>saghul, ping
01:12:50  <piscisaureus_>(and on windows we always set UV_EINTR as the error code - but that is open for debate)
01:13:10  <bnoordhuis>same on unix
01:13:18  <piscisaureus_>bnoordhuis: ok, so you will see that these tests also pass if the shutdown cb is made with status==-1 :-)
01:16:05  * bulatshakirzyanojoined
01:17:12  <CIA-99>libuv: Bert Belder windows-uptime * rb8cc99c / src/win/util.c : Whitespace - http://git.io/bIdVww
01:17:13  <CIA-99>libuv: Bert Belder windows-uptime * ra80dc92 / include/uv.h : Add UV_EIO error code - http://git.io/6JV6cQ
01:17:13  <CIA-99>libuv: Bert Belder windows-uptime * r2b31d2a / src/win/util.c : Windows: make uv_uptime() more robust - http://git.io/k7RIRA
01:17:24  * pfox___quit (Ping timeout: 265 seconds)
01:18:31  <CIA-99>libuv: Bert Belder master * r6ec330a / include/uv.h : Add UV_EIO error code - http://git.io/3KlQlg
01:18:32  <CIA-99>libuv: Bert Belder master * rfa21584 / src/win/util.c : Whitespace - http://git.io/2PXt9w
01:18:41  <CIA-99>libuv: Bert Belder windows-uptime * r8f2f92c / src/win/util.c : Windows: make uv_uptime() more robust - http://git.io/_BRSFw
01:19:14  * travis-cijoined
01:19:14  <travis-ci>[travis-ci] joyent/libuv#188 (windows-uptime - 2b31d2a : Bert Belder): The build failed.
01:19:14  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b8cc99c^...2b31d2a
01:19:14  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1071307
01:19:14  * travis-cipart
01:19:25  <bnoordhuis>i like how fixing one test breaks five other tests...
01:20:15  * bulatshakirzyanoquit (Client Quit)
01:20:29  * travis-cijoined
01:20:29  <travis-ci>[travis-ci] joyent/libuv#189 (master - 6ec330a : Bert Belder): The build is still failing.
01:20:29  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/4741a11...6ec330a
01:20:29  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1071321
01:20:29  * travis-cipart
01:20:34  <piscisaureus_>saghul: yt?
01:20:49  * travis-cijoined
01:20:49  <travis-ci>[travis-ci] joyent/libuv#190 (windows-uptime - 8f2f92c : Bert Belder): The build is still failing.
01:20:49  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/2b31d2a...8f2f92c
01:20:49  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1071324
01:20:49  * travis-cipart
01:21:00  * mikealjoined
01:23:09  <isaacs>bnoordhuis: ha! i think the issue was that your gyp patch only solved it in one place.
01:23:37  <isaacs>bnoordhuis: there was another part of that same file with another 1000-filename splitting. i set that to match, and now the make test works lovely again.
01:27:00  <piscisaureus_>bnoordhuis: I want to disable ipc-send-recv-pipe on windows
01:27:06  <piscisaureus_>bnoordhuis: because we don't support it
01:31:55  <bnoordhuis>isaacs: oh. very good :)
01:32:05  <bnoordhuis>piscisaureus_: sure
01:32:09  * dapquit (Quit: Leaving.)
01:32:23  <isaacs>bnoordhuis, piscisaureus_: review? https://github.com/isaacs/node/commit/04271a5e9394e6dadf6c5172bcfac1d5f086db8f
01:34:38  <CIA-99>libuv: Bert Belder master * r4f0ff3c / test/test-list.h :
01:34:38  <CIA-99>libuv: Disable ipc_send_recv_pipe test on Windows
01:34:38  <CIA-99>libuv: It's not supported yet - http://git.io/LsSzLA
01:34:57  <piscisaureus_>isaacs: how can I possibly disagree... Does that fix your issues?
01:35:25  <isaacs>piscisaureus_: yes, it does. 100% of affected users reporting!
01:35:39  <piscisaureus_>isaacs: kewl :-)
01:35:57  <CIA-99>node: isaacs master * r04271a5 / tools/gyp/pylib/gyp/generator/make.py :
01:35:57  <CIA-99>node: gyp: Apply 'argument too long' fix in another place
01:35:57  <CIA-99>node: For some reason, aa5961a445acbd2b533ef870eb19733be7b7ede5 caused
01:35:57  <CIA-99>node: 'make test' to rebuild the entire project every time. Applying
01:35:57  <CIA-99>node: the fix to the other place where gyp chops up the argument list
01:35:57  <CIA-99>node: makes it behave properly. - http://git.io/qyOnfA
01:36:05  * xaqjoined
01:36:45  * travis-cijoined
01:36:46  <travis-ci>[travis-ci] joyent/libuv#191 (master - 4f0ff3c : Bert Belder): The build is still failing.
01:36:46  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/6ec330a...4f0ff3c
01:36:46  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1071369
01:36:46  * travis-cipart
01:37:55  * abraxasjoined
01:39:06  * bradleymeckquit (Quit: bradleymeck)
01:41:22  * brsonquit (Quit: leaving)
01:48:34  <CIA-99>libuv: Ben Noordhuis master * ra41016e / src/unix/stream.c : unix: run pending shutdown cb when stream is closed - http://git.io/mqJSGw
01:49:53  <bnoordhuis>okay, off to bed
01:49:57  <bnoordhuis>sleep tight, guys
01:50:32  * travis-cijoined
01:50:32  <travis-ci>[travis-ci] joyent/libuv#192 (master - a41016e : Ben Noordhuis): The build is still failing.
01:50:32  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/4f0ff3c...a41016e
01:50:32  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1071408
01:50:32  * travis-cipart
01:51:03  * travis-cijoined
01:51:03  <travis-ci>[travis-ci] joyent/node#719 (master - 04271a5 : isaacs): The build is still failing.
01:51:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/1c88c3b...04271a5
01:51:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1071378
01:51:03  * travis-cipart
01:57:41  * bnoordhuisquit (Ping timeout: 252 seconds)
02:00:24  * bradleymeckjoined
02:05:01  * mikealquit (Quit: Leaving.)
02:07:21  <CIA-99>libuv: Ben Noordhuis reviewme * r4741a11 / test/test-fs-event.c : test: disable fs_event_close_in_callback on kqueue-based systems - http://git.io/gpIGGA
02:07:22  <CIA-99>libuv: Bert Belder reviewme * rfa21584 / src/win/util.c : Whitespace - http://git.io/2PXt9w
02:07:23  <CIA-99>libuv: Bert Belder reviewme * r6ec330a / include/uv.h : Add UV_EIO error code - http://git.io/3KlQlg
02:07:23  <CIA-99>libuv: Bert Belder reviewme * r4f0ff3c / test/test-list.h :
02:07:23  <CIA-99>libuv: Disable ipc_send_recv_pipe test on Windows
02:07:23  <CIA-99>libuv: It's not supported yet - http://git.io/LsSzLA
02:07:23  <CIA-99>libuv: Bert Belder reviewme * rf049656 / src/win/udp.c :
02:07:24  <CIA-99>libuv: Windows: validate UDP socket options
02:07:24  <CIA-99>libuv: Makes test-udp-options pass on Windows. - http://git.io/7M6I6A
02:08:04  <CIA-99>libuv: Bert Belder reviewme * rf3e3e5b / src/win/udp.c :
02:08:04  <CIA-99>libuv: Windows: validate UDP socket options
02:08:04  <CIA-99>libuv: Makes test-udp-options pass on Windows. - http://git.io/RlwTjg
02:08:21  <piscisaureus_>igorzi: hey
02:08:25  <piscisaureus_>igorzi: can you review git.io/RlwTjg ?
02:09:22  * travis-cijoined
02:09:22  <travis-ci>[travis-ci] joyent/libuv#193 (reviewme - f049656 : Bert Belder): The build is still failing.
02:09:22  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/2e5e116...f049656
02:09:22  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1071494
02:09:22  * travis-cipart
02:09:41  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
02:10:14  * travis-cijoined
02:10:14  <travis-ci>[travis-ci] joyent/libuv#194 (reviewme - f3e3e5b : Bert Belder): The build is still failing.
02:10:14  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f049656...f3e3e5b
02:10:14  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1071500
02:10:14  * travis-cipart
02:15:02  * orlandovftwjoined
02:27:38  * mikealjoined
02:34:45  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:36:37  * mikealquit (Quit: Leaving.)
02:39:39  * trondnquit (Quit: Leaving.)
02:46:49  * orlandovftwquit (Ping timeout: 246 seconds)
02:53:56  * bradleymeckquit (Quit: bradleymeck)
02:54:41  * bradleymeckjoined
02:54:47  * bradleymeckquit (Client Quit)
02:55:43  * igorzi_joined
03:02:28  * igorzi_quit (Quit: Page closed)
03:07:56  * bulatshakirzyanojoined
03:30:12  * mikealjoined
04:02:28  * dshaw_joined
04:06:54  * c4milojoined
04:11:45  * felixgequit (Quit: felixge)
04:15:42  * bulatshakirzyanoquit (Quit: Computer has gone to sleep.)
04:28:01  * c4miloquit (Ping timeout: 260 seconds)
05:03:30  * orlandovftwjoined
05:07:15  * felixgejoined
05:07:15  * felixgequit (Changing host)
05:07:15  * felixgejoined
05:07:22  <felixge>mikeal: ping
05:31:19  * felixgequit (Ping timeout: 246 seconds)
05:41:14  <saghul>toothr pong
05:44:37  * isaacsquit (Remote host closed the connection)
05:48:18  * bulatshakirzyanojoined
06:38:33  * paddybyersjoined
06:41:37  * trondnjoined
06:48:04  * rendarjoined
06:54:17  * stephankquit (Quit: *Poof!*)
07:17:00  * txdv_joined
07:17:03  * txdvquit (Read error: Connection reset by peer)
07:20:41  * xaqquit (Remote host closed the connection)
07:29:01  * felixgejoined
07:29:01  * felixgequit (Changing host)
07:29:01  * felixgejoined
09:13:24  * bulatshakirzyanoquit (Quit: Computer has gone to sleep.)
09:32:18  * orlandovftwquit (Ping timeout: 244 seconds)
09:33:07  * bradleymeckjoined
09:34:44  * bradleymeckquit (Client Quit)
09:38:01  * txdv_quit (Ping timeout: 272 seconds)
10:19:43  * igorziquit (Ping timeout: 245 seconds)
10:25:25  * mmalecki[zzz]changed nick to mmalecki
10:45:59  * abraxasquit
11:04:02  * bnoordhuisjoined
11:24:58  * dshaw_quit (Quit: Leaving.)
11:45:45  * txdvjoined
12:02:37  * c4milojoined
12:37:41  * `3rdEdenjoined
13:01:56  * piscisaureus_joined
13:06:52  <mmalecki>bnoordhuis, piscisaureus_: flying out in 2 hours :)
13:07:01  <mmalecki>or 3, actually
13:07:07  <piscisaureus_>mmalecki: cool
13:07:18  <piscisaureus_>mmalecki: will you have internet in amsterdam?
13:07:24  <mmalecki>piscisaureus_: sure!
13:07:30  <piscisaureus_>mmalecki: we can go out for beers tomorrow although I cannot make it very late
13:07:48  <piscisaureus_>bnoordhuis: you gonna be there?
13:09:23  <CIA-99>libuv: Bert Belder master * rf3e3e5b / src/win/udp.c :
13:09:23  <CIA-99>libuv: Windows: validate UDP socket options
13:09:23  <CIA-99>libuv: Makes test-udp-options pass on Windows. - http://git.io/RlwTjg
13:11:30  * travis-cijoined
13:11:30  <travis-ci>[travis-ci] joyent/libuv#195 (master - f3e3e5b : Bert Belder): The build is still failing.
13:11:30  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/a41016e...f3e3e5b
13:11:30  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1073746
13:11:30  * travis-cipart
13:29:32  * mmaleckichanged nick to mmalecki[plane]
13:32:33  <indutny>piscisaureus_: heya
13:32:45  <piscisaureus_>indutny: fedor!
13:32:53  <piscisaureus_>indutny: why is there indutny_znc ?
13:33:15  <indutny>piscisaureus_: well, that's from another server :)
13:33:21  <piscisaureus_>ah
13:33:22  * milani_joined
13:33:26  <indutny>creationix: tim, I think you can shutdown that account once you'll have time
13:33:36  <indutny>creationix: irccloud works quite fine last days
13:33:45  <indutny>piscisaureus_: so about GetTickCount
13:33:51  <piscisaureus_>indutny:: yes
13:33:55  <milani_>I have a library that runs in a message loop of its own.
13:34:04  <indutny>milani_: cool
13:34:04  <milani_>it allows me to call a function that performs a single iteration of that message loop
13:34:17  <milani_>how can I run and balance this message loop inside a node addon?
13:34:31  <indutny>piscisaureus_: GetTickCount wraps like a hell
13:34:38  <indutny>better answer on github, though
13:34:49  <milani_>I asked at #node.js and piscisaureus_ told me to ask here about uv_timer
13:34:51  <piscisaureus_>indutny: I know, but on systems that support it we could use GetTickCount64()
13:35:18  <piscisaureus_>indutny: so we would not require us to do all that registry crap
13:35:19  <indutny>but it's hard to detect, AFAIK
13:35:24  <piscisaureus_>milani_: I am here
13:35:29  <indutny>piscisaureus_: yeah, it's quite slow
13:35:44  <indutny>piscisaureus_: and it doesn't work in win7
13:35:50  <piscisaureus_>milani_: It's just that I don't want to monitor so many chat windows
13:35:57  <piscisaureus_>indutny: what doesn't work in win7?
13:36:02  <indutny>piscisaureus_: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724411(v=vs.85).aspx
13:36:03  <milani_>piscisaureus_: hi again:)
13:36:03  <indutny>GetTickCount64
13:36:08  <indutny>aah
13:36:11  <indutny>sorry, no
13:36:14  <indutny>it doesn't work on XP
13:36:18  <indutny>:D
13:36:21  * `3rdEdenquit (Quit: Leaving...)
13:36:51  <piscisaureus_>indutny: yeah so I want to use GetTickCount 64 on vista+ and the registry crap on xp
13:37:07  <indutny>piscisaureus_: cool, but I don't have any Windows VM atm
13:37:10  <piscisaureus_>indutny: unless there were also *other* reasons why GetTickCount() was not good
13:37:25  <indutny>piscisaureus_: AFAIK it was only because of wrapping
13:37:37  <indutny>piscisaureus_: don't you have IRC logs?
13:37:51  <indutny>I think we'd discussed that months ago
13:37:58  <piscisaureus_>indutny: ah - right. Well I was not asking you to do it - I was asking @mscdex :-)
13:38:05  <indutny>hahaha :)
13:38:15  <indutny>still sad that you hadn't accepted my PR
13:38:16  <indutny>:(
13:38:32  <piscisaureus_>indutny: but it's a 5-liner so I might do it myself.
13:38:32  <piscisaureus_>indutny: yeah sorry about that.
13:38:57  <piscisaureus_>indutny: you can make it up by reviewing that signals patch on windows :-)
13:39:02  <piscisaureus_>indutny: :-p
13:39:09  <indutny>piscisaureus_: what signals patch?
13:39:43  <piscisaureus_>indutny: no, just kidding. I don't want to activate @runner_mei. His patch is kinda nice but has a lot of rough edges. It'll be faster if I just fix it myself.
13:39:59  * kohaiquit (Remote host closed the connection)
13:40:07  <piscisaureus_>indutny: https://github.com/joyent/libuv/pull/264 <-- that
13:40:34  <indutny>omg
13:40:35  <piscisaureus_>milani_: so how do you want to start / stop CEF the event loop?
13:41:14  <indutny>bnoordhuis: I looked at your branch
13:41:20  <milani_>piscisaureus_: I'm building a gui addont for node with CEF.
13:41:26  <indutny>bnoordhuis: and got to say, it's really hard to get in
13:41:32  <piscisaureus_>milani_: it just runs once you load the extension? Or do you have to do stuff like?
13:41:40  <indutny>bnoordhuis: if only you could give me some point to start from
13:41:48  <indutny>bnoordhuis: like "fix this and this"
13:42:08  <milani_>piscisaureus_: I created bindings the only problem is that when I call CefRunMessageLoop(); it blocks the loop
13:42:12  <piscisaureus_>indutny: bnoordhuis: seems to be not here.
13:42:24  <indutny>ircretary: tell bnoordhuis to ping me
13:42:24  <ircretary>indutny: I'll be sure to tell bnoordhuis
13:42:32  <indutny>piscisaureus_: ok
13:42:40  <milani_>piscisaureus_: no it starts when someone creates a window object. new require('appjs').Window()
13:42:59  <piscisaureus_>milani_: and, when does it stop?
13:43:32  <milani_>I set a handler for destroy event of CEF
13:43:42  <milani_>usually when close button is clicked.
13:43:54  <milani_>void destroy(void) {
13:43:55  <milani_> CefQuitMessageLoop();
13:43:55  <milani_>}
13:44:36  <piscisaureus_>milani_: actually, I can help you get started with uv_timer_t, but maybe it's the easiest for you to start with a binding to CefDoMessageLoopWork
13:45:16  <piscisaureus_>milani_: and then you do setInterval(process.binding('cef').CefDoMessageLoopWork, 1) when you want to start the event loop
13:46:08  <milani_>piscisaureus_: I think the other way is much better. Do you offer me the second solution for ease?
13:46:33  <piscisaureus_>milani_: you mean the uv_timer_t solution? Or the multithreaded solution?
13:46:57  <piscisaureus_>milani_: the uv_timer_t way is basically the same as setInterval but it runs entirely in C land
13:47:32  <milani_>piscisaureus_: Isn't it better to have two threads and two channels for communication?
13:47:41  <piscisaureus_>milani_: that would be better, yes
13:47:56  <piscisaureus_>milani_: in that case, you should just create a thread and run CefRunMessageLoop there
13:48:25  <milani_>piscisaureus_: I tried that for another module,
13:48:32  <piscisaureus_>milani_: and?
13:48:59  <milani_>piscisaureus_: the problem was that when GUI stuff finishes its work ( close button is clicked )
13:49:16  <milani_>it takes about two seconds to see node stops execution.
13:50:27  <piscisaureus_>milani_: hmm. So how did you signal the CEF events back to the main thread? I mean, how did the node thread know that CEF would stop *at all* ?
13:51:13  <milani_>g_signal_connect(G_OBJECT(window), "destroy",
13:51:14  <milani_> G_CALLBACK(gtk_widget_destroyed), &window);
13:51:27  <milani_>its not CEF that calls me. it's GTK.
13:52:15  <milani_>also CEF has many handlers for all events I think. but I don't need them for now.
13:54:10  <milani_>piscisaureus_: CEF is just a webview that I can use it in GTK window.
13:54:36  <wankdanker>does libuv provide a cross platform locking mechanism; ie: calls pthread_mutex_lock on unix and whatever the equivelant is in windows?
13:56:52  <piscisaureus_>milani_: hmm.
13:57:55  <piscisaureus_>milani_: so the problem is usually thread safety ... libuv and v8 typically don't allow you to do stuff from different threads
13:58:37  <piscisaureus_>milani_: so if for example gtk would dispatch an event from another thread, you'd have to send it to the main thread somehow
13:58:43  <piscisaureus_>and have it execute there
13:59:06  <milani_>piscisaureus_: then I need two channels. one to push jobs from gtk thread and run them in node thread later
13:59:18  <piscisaureus_>milani_: yes
13:59:21  <milani_>and one two push jobs from node that gtk thread runs.
13:59:30  <piscisaureus_>milani_: yeah
13:59:43  <milani_>is there any way to do it simply? or I should code it from scratch?:D
14:00:11  <piscisaureus_>milani_: probably you'd have to code it from scratch I am afraid...
14:00:47  <piscisaureus_>milani_: libuv has uv_async_send to wake up the main thread from another thread (so if it's stuck in epoll() or GetQueuedCompletionStatus or whatever, it'll come out)
14:01:14  <piscisaureus_>milani_: but there is no thread-safe queueing mechanism in libuv (I would not mind adding that but I remember ryah and bnoordhuis had some reservations)
14:01:47  <piscisaureus_>milani_: the master branch of libuv/node have cross-platform mutexes and thread functions but it's not in node 0.6
14:02:19  <piscisaureus_>milani_: also, I do not know how to wake up the gtk event loop from the node event loop (but I am sure you can look that up :-)
14:02:39  <piscisaureus_>milani_: I can also think of another trick, but it's unexplored territory
14:03:34  <milani_>piscisaureus_: :-) I'm sure I'm not going to do that but can I ask what it is?
14:04:25  <piscisaureus_>milani_: so you *can* use libuv from multiplet threads, and I think the same is true for v8. So what you could do is have some locking mechanism that unlocks right before libuv's the blocking function
14:04:35  <piscisaureus_>er, right before libuv's blocking poll function
14:04:42  <piscisaureus_>and locks right after
14:04:49  <piscisaureus_>and do the same with the gtk event loop
14:05:19  <piscisaureus_>and only call v8 functions and uv functions that hold the lock
14:05:26  <piscisaureus_>I think that would mostly work
14:05:31  <milani_>piscisaureus_: you know, I'm not good with threading and locking:D
14:05:58  <piscisaureus_>the only thing is that gtk might actually have more restrictions wrt threading - but I don't know about that.
14:06:28  <piscisaureus_>milani_: this is hairy territory :-)
14:06:56  <piscisaureus_>milani_: I think I would go for setInterval() for the time being :-)
14:07:29  <milani_>piscisaureus_: then later I can convert it to two threads and uv_async.
14:07:32  <milani_>yeah?
14:07:43  <piscisaureus_>milani_: yes
14:08:14  <milani_>then please help me with doing it in C not js.
14:08:22  <milani_>I mean uv_timer stuff
14:08:45  <milani_>let me guess, I should call uv_timer_init with a handler and a timer object
14:08:51  <bnoordhuis>indutny: here now
14:08:52  <piscisaureus_>yes
14:09:01  <bnoordhuis>indutny: yeah, there's not much you can do right now
14:09:04  <milani_>but what are those uv_timer_start and end?
14:09:24  <piscisaureus_>milani_: an initialized timer does not do anything except exist.
14:09:37  <piscisaureus_>milani_: with uv_timer_start you can register a callback and a (repeating) timeout
14:09:57  <piscisaureus_>milani_: node will call the callback at the specified interval. So you can use the callback to call DoWork
14:10:22  <milani_>what are timeout and repeat?
14:10:37  <milani_>should I specify how many times it runs?
14:11:37  <piscisaureus_>milani_: timeout is the time (millisecs) after which the callback is called for the first time.
14:11:37  <piscisaureus_>milani_: the repeat is also in millis. After the timer has fired once, it will keep firing every n milliseconds specified by the repeat value
14:11:51  <piscisaureus_>milani_: or, if repeat==0 it doesn't repeat
14:12:14  <piscisaureus_>milani_: you don't specify the number of times. When the timer is done you uv_timer_stop it, or you close the timer
14:12:58  <milani_>oh. so timeout means how much delay execution of cb.
14:13:05  <piscisaureus_>milani_: yes
14:13:12  <piscisaureus_>that's why it is a timer
14:13:15  <piscisaureus_>:-)
14:13:17  <milani_>piscisaureus_: thank you.
14:13:41  <piscisaureus_>milani_: test/test-timer.c might help
14:18:23  <milani_>piscisaureus_: test/test-timer.c:76
14:18:30  <milani_>uv_close((uv_handle_t*)handle, repeat_close_cb);
14:18:43  <milani_>does it work as uv_timer_stop?
14:18:59  * `3rdEdenjoined
14:19:16  * isaacsjoined
14:19:44  <piscisaureus_>milani_: it does, but it does more.
14:20:33  <piscisaureus_>milani_: it will not only stop, but also destroy your timer. It takes a callback, and when the callback is called you can free/recycle the memory you allocated for the timer.
14:21:23  <milani_>piscisaureus_: now I get it. thank you very much.
14:21:30  <indutny>bnoordhuis: ok
14:21:30  <indutny>:)
14:25:57  <creationix>piscisaureus_, is there a way in libuv today to find is there are any pending requests for a uv_handle?
14:26:06  <creationix>I'm not seeing anything in uv.h
14:26:54  <creationix>also I'm seeing that uv_is_active currently always returns 1 for most handle types (I assume that will change in the refactor)
14:35:26  * pfox___joined
14:35:37  <piscisaureus_>creationix: there isn't. We could add that though - uv-win already tracks an internal counter for the number of pending requests, and I guess uv-unix does too.
14:36:01  <piscisaureus_>creationix: I assume a simple counter (or even a boolean) would be enough?
14:37:55  <piscisaureus_>creationix: we could also change the semantics of uv_is_active again so it would report 1 if there are pending requests on the handle too
14:38:00  <piscisaureus_>creationix: I don't think that would hurt
14:38:22  <piscisaureus_>creationix: you should comment on the refcount refactor issue
15:03:09  * mikealquit (Quit: Leaving.)
15:04:07  * mikealjoined
15:09:18  <milani_>piscisaureus_: look at this:
15:09:18  <milani_>void MainWindow::Show () {
15:09:18  <milani_> uv_timer_t timer;
15:09:18  <milani_> uv_timer_init(uv_default_loop(),&timer);
15:09:18  <milani_> uv_timer_start(&timer,Run,1,1);
15:09:18  <milani_>/ CefRunMessageLoop();
15:09:20  <milani_>};
15:09:24  <milani_>void MainWindow::Run (uv_timer_t* handle, int status) {
15:09:26  <milani_> CefDoMessageLoopWork();
15:09:29  <milani_>};
15:09:47  <milani_>how can I pass Run as callback to timer_start?
15:10:23  <piscisaureus_>milani_: first of all, you are allocating uv_timer_t on the stack so it won't work (the memory will be clobbered when MainWindows::show returns)
15:10:50  <milani_>I should define timer somewhere else.
15:10:56  <piscisaureus_>milani_: but you have to define or declare MainWindow::Run as static
15:10:57  <milani_>like a global variable.
15:11:00  * `3rdEdenquit (Quit: Leaving...)
15:11:17  <milani_>but it's not possible to define a static member function in this calss.
15:11:18  <piscisaureus_>milani_: yeah (but then you have to make sure that you don't init the same timer twice)
15:11:25  <piscisaureus_>milani_: oh?
15:11:35  <piscisaureus_>milani_: well then don't make it a member function :-)
15:12:15  <piscisaureus_>milani_: you can store data in the uv_timer_t.data member btw (it's a void pointer - so yo could use it to store a reference to the MainWindow object if that is needed)
15:12:42  <milani_>error: cannot declare member function �static void appjs::MainWindow::Run(uv_timer_t*, int)� to have static linkage [-fpermissive]
15:13:17  <milani_>I'm coding C++ after 2 years!:D forgive me for this stupid questions!
15:13:52  <piscisaureus_>milani_: "static" should be set in your class definition and *not* when you define the function body
15:14:17  <piscisaureus_>milani_: so
15:14:17  <piscisaureus_>class Foo {
15:14:17  <piscisaureus_> static void bar();
15:14:17  <piscisaureus_>}
15:14:17  <piscisaureus_>void Foo::bar() {...}
15:14:39  <milani_>I did like this.
15:14:46  <milani_>oh I added to definition also.
15:14:50  <milani_>It's ok.
15:14:58  <piscisaureus_>milani_: google is your best friend here
15:18:36  <CIA-99>node: Andreas Madsen master * r5b43c63 / (2 files in 2 dirs): child_process: emit error when .kill fails - http://git.io/aV5Alw
15:26:04  <piscisaureus_>where can we find mraleph these days?
15:30:51  * pfox___changed nick to patientfoxheh
15:33:25  * travis-cijoined
15:33:25  <travis-ci>[travis-ci] joyent/node#720 (master - 5b43c63 : Andreas Madsen): The build is still failing.
15:33:25  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/04271a5...5b43c63
15:33:25  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1074563
15:33:25  * travis-cipart
15:34:40  * theColejoined
15:37:27  <CIA-99>libuv: Bert Belder master * r9984d15 / src/win/util.c : Windows: make uv_uptime() more robust - http://git.io/5jZUWw
15:39:40  * travis-cijoined
15:39:40  <travis-ci>[travis-ci] joyent/libuv#196 (master - 9984d15 : Bert Belder): The build is still failing.
15:39:40  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f3e3e5b...9984d15
15:39:40  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1074676
15:39:40  * travis-cipart
15:40:01  <piscisaureus_>bnoordhuis: does the spawn_and_kill_with_std test fail on unix too?
15:43:10  * TooTallNatejoined
15:45:23  * patientfoxhehchanged nick to pfox___
15:47:14  * igorzijoined
15:47:52  * perezdjoined
15:51:05  <bnoordhuis>piscisaureus_: yes
15:51:22  <wankdanker>is there any chance of uv_mutex_* making their way into the node v0.6.x releases?
15:53:31  <TooTallNate>wankdanker: no, sorry, the libuv in v0.6 is API-locked
15:54:16  <wankdanker>TooTallNate: ok. thank you.
15:55:36  <TooTallNate>np
15:58:27  <isaacs>call time
15:59:19  <TooTallNate>bright and early this time, eh isaacs? :D
15:59:32  <piscisaureus_>isaacs: our standup is still running and after that I'll have to reboot my pc
15:59:39  <isaacs>yessir!
15:59:42  <piscisaureus_>isaacs: so I'll be delayed for 10 to 15 minutes
15:59:53  <isaacs>piscisaureus_: k, we can wait for a little bit, that's fine
16:00:12  * isaacschuckles. "Reboot my pc"
16:00:15  <isaacs>heh
16:01:07  <piscisaureus_>isaacs: you know, in fact it's apples fault
16:01:20  <isaacs>oh, really? did someone from apple install windows on your pc?
16:01:22  <isaacs>;P
16:01:29  <isaacs>i hate it when they do that!
16:01:40  <piscisaureus_>isaacs: because apple's thunderbolt driver crashes windows when I disconnect my screen
16:01:43  <isaacs>or are you using quicktime or itunes or something
16:01:49  <isaacs>yeah, apple software on windows kinda blows
16:01:54  <isaacs>it's almost like they *want* it to fail
16:02:37  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
16:08:15  <creationix>would it be possible to make libuv not crash if I free a struct right after calling uv_close?
16:08:21  <creationix>some sort of close without callback
16:08:44  <creationix>I guess not since the handle needs to flush any remaining requests
16:09:20  * c4milochanged nick to c4milo|lunch
16:09:30  <bnoordhuis>creationix: yep
16:10:15  * piscisaureus_joined
16:10:59  <creationix>bnoordhuis, I'm still trying to find a way to auto-close handles when there are no references to it, but most VMs only tell you when it's about to be freed and don't let you cancel
16:12:01  <creationix>I guess what I need is a way for the vm to tell me that my handle is the last one
16:12:15  <creationix>and on vms that don't support that the user just needs to remember to call close
16:12:21  <bnoordhuis>creationix: double indirection? instead of a struct have a pointer to a struct?
16:12:24  <bnoordhuis>brb, call
16:12:54  <pfox___>creationix: does lua have a dtor when GC is about to free an object?
16:13:03  <pfox___>i assume this is in the context of lua..
16:13:38  <creationix>pfox___, it does, and I'm talking about 3 different VMs I'm working on at once
16:13:51  <creationix>they all at least warn when something is about to be freed
16:14:51  <pfox___>and why can't you defer free'ing the struct until uv_close()'s callback, which you would register in the 'about to be freed' callback ..?
16:15:26  <creationix>pfox___, because I'm not using "double indirection" lua is allocating the struct directly and it frees it directly on GC
16:15:28  * stephankjoined
16:15:35  <creationix>I think I need an extra layer
16:15:44  <pfox___>creationix: gotcha.
16:18:02  * orlandovftwjoined
16:18:14  <pfox___>my main vm API experience is with spidermonkey, which doesn't feature such conveniences
16:18:15  * orlandovftwquit (Client Quit)
16:18:22  <pfox___>so, yeah. double indirection all the way, heh.
16:18:33  * orlandovftwjoined
16:21:19  <creationix>yep
16:21:29  <creationix>and in candor I had to have indirection because candor was moving my structs
16:23:20  * pijewskijoined
16:23:45  * trondnquit (Quit: Leaving.)
16:25:19  <milani_>Is there a delay between calling uv_timer_stop and till it really stops working?
16:26:02  * theColequit (Quit: theCole)
16:26:18  <milani_>I run this: uv_timer_stop(&timer); \n aFunction(); this way my app crashes. but when I use uv_close and call aFunction() in callback everything is ok
16:29:15  * dapjoined
16:29:23  <creationix>pfox___, btw, have you seen luvmonkey?
16:29:36  * trondnjoined
16:29:37  <creationix>pfox___, if you ever get time, my sm bindings need some review from someone who knows the API
16:40:37  <bnoordhuis>[% 100|+ 96|- 37]: Done. <- down from 85 failing this morning
16:44:20  * trondnquit (Quit: Leaving.)
16:49:47  <bnoordhuis>piscisaureus_: uv_fs_event_init starts automatically
16:50:09  <bnoordhuis>maybe it needs uv_fs_event_(start|stop) functions
16:50:23  <bnoordhuis>it doesn't quite fit in right now
16:52:30  <piscisaureus_>bnoordhuis: yeah
16:52:35  <piscisaureus_>bnoordhuis: agreed
16:52:43  <pfox___>creationix: i only looked over the readme, tbh. im knee-deep in rust libuv stuff, atm. but ill see if i can check it out more in-depth.
16:52:49  <piscisaureus_>bnoordhuis: we should also have listen_stop
16:53:39  <bnoordhuis>piscisaureus_: have people been asking for that?
16:53:48  <piscisaureus_>bnoordhuis: not really
16:56:10  <creationix>pfox___, I understand, just when you find time it would be greatly appreciated.
17:04:55  * theColejoined
17:05:14  * trondnjoined
17:15:10  <bnoordhuis>https://github.com/bnoordhuis/node/commit/03a4a6f <- review? fixes https://github.com/joyent/node/issues/3096
17:17:04  <isaacs>bnoordhuis: lgtm
17:17:11  <bnoordhuis>cool, thanks
17:17:29  <CIA-99>node: Ben Noordhuis master * r16fca26 / (lib/net.js src/tcp_wrap.cc):
17:17:29  <CIA-99>node: net: honor 'enable' flag in .setNoDelay()
17:17:29  <CIA-99>node: Fixes #3096. - http://git.io/2cvW5Q
17:21:41  * mikealquit (Quit: Leaving.)
17:23:29  <TooTallNate>isaacs: bnoordhuis: that function falls under the boolean API trap, haha, too late to fix it though
17:23:33  * bulatshakirzyanojoined
17:23:58  * bulatshakirzyanoquit (Client Quit)
17:24:28  * mikealjoined
17:24:59  <isaacs>wait, what?
17:25:03  <isaacs>boolean api trap?
17:25:09  * milani_quit (Ping timeout: 240 seconds)
17:25:17  <TooTallNate>http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html
17:25:25  <isaacs>oh, right
17:25:26  <isaacs>meh
17:25:33  <TooTallNate>could have been called setNagle() or something
17:25:33  <isaacs>"setSomeBoolean(value)" is fine
17:25:55  <TooTallNate>ya, its not an issue
17:25:59  <isaacs>setNoDelay({noDelay: false}) is silly
17:26:05  <isaacs>java-esque, even :)
17:26:18  <isaacs>but yeah, a setOptions(true, false, true, true, false, false, true) is hellish
17:26:39  <TooTallNate>in this case i mean a function name where the boolean negates itself
17:26:44  <TooTallNate>like .disabled
17:26:51  <isaacs>oh, haha
17:26:54  <isaacs>i see
17:26:55  <TooTallNate>is usually more understable as .enabled
17:28:07  <isaacs>right
17:28:18  <isaacs>i sometimes do the double-negative thing so that i can have falsey values be the default always
17:28:26  <isaacs>then anything that isn't set is automatically the default
17:28:43  <isaacs>glob/minimatch does that
17:28:44  <bnoordhuis>[% 100|+ 114|- 19]: Done. <- going strong
17:28:59  <TooTallNate>bnoordhuis: that's node?
17:29:33  <bnoordhuis>TooTallNate: no, libuv + refcount refactor
17:29:44  <TooTallNate>oh, nice
17:29:50  <bnoordhuis>the counter was at 85 failing tests this morning
17:29:52  * orlandovftwquit (Ping timeout: 246 seconds)
17:30:06  <TooTallNate>very nice
17:31:15  * travis-cijoined
17:31:16  <travis-ci>[travis-ci] joyent/node#721 (master - 16fca26 : Ben Noordhuis): The build is still failing.
17:31:16  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/5b43c63...16fca26
17:31:16  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1075412
17:31:16  * travis-cipart
17:38:18  * pijewskiquit (Quit: Leaving.)
17:47:00  * pfox___quit (Quit: leaving)
18:00:40  * theColequit (Quit: theCole)
18:06:21  <TooTallNate>piscisaureus_: you see the convo in #node.js?
18:08:14  * brsonjoined
18:08:16  * mikealquit (Quit: Leaving.)
18:09:45  * pijewskijoined
18:13:09  * isaacsquit (Remote host closed the connection)
18:17:59  * mralephjoined
18:25:26  * orlandovftwjoined
18:25:44  * mikealjoined
18:32:18  * josephgquit (Quit: josephg)
18:33:43  * felixgequit (Quit: http://www.debuggable.com/)
18:36:49  * c4milo|lunchchanged nick to c4milo
18:38:28  * dvvjoined
18:38:39  <dvv>Hi!
18:39:46  <dvv>I'm getting uv_write(H) report EBADF, while uv_is_writable(H) is true
18:40:32  <dvv>shouldn't we not report closed fds as writable (and valid in other uv_is_* helpers)?
18:46:26  <mjr_>bnoordhuis: any progress on that stuck TLS core? I've got more cores if you want them.
18:48:43  * pfox___joined
18:49:45  * isaacsjoined
18:52:38  <piscisaureus_>dvv: which function?
18:53:25  <piscisaureus_>dvv: and you probably should not call a function on a closed handle
18:53:51  <dvv>uv_is_writable(&{.fd: -1, .flags: 64}) reports 64 which is truthy
18:54:04  <dvv>while in fact handle is dead
18:55:00  * dshaw_joined
18:55:06  <dvv>by principle of least surprise i believe closed handle should not be reported as writable
18:55:16  <dvv>and as readable
18:55:22  <piscisaureus_>hmm *shrug*
18:55:34  <piscisaureus_>dvv: you are doing it wrong - you should not do that in the first place
18:55:51  <piscisaureus_>dvv: but - fine - I will take patches for that
18:56:35  <piscisaureus_>mraleph: hey
18:57:17  <dvv>hmm, how do we check that uv_write(H, ...) won't fail in sync manner? (fd is wrong, etc) at present
18:58:18  <piscisaureus_>dvv: it returning -1 ?
18:58:38  <piscisaureus_>dvv: but in the general case, we can't
18:58:54  <piscisaureus_>dvv: because we may not attempt to actually write() to the socket
18:59:05  <piscisaureus_>dvv: and we won't make another syscall for it
19:02:26  <dvv>yes, uv_write() returns -1 and sets errno to 9 (EBADF)
19:03:00  <dvv>i guess i shouldn't check if it's writable and just catch EBADF
19:03:13  <piscisaureus_>dvv: well I think you should not write to a closed handle :-)
19:03:36  <dvv>i found no uv_is_closed() :)
19:03:46  <dvv>moreover
19:04:14  <dvv>uv_is_closing() just checks the handle flags, not fd
19:05:26  <indutny>TLS is so ambigous abbr
19:05:29  <dvv>so, one have to snoop into handle private members to know if it's really closed :)
19:09:04  <piscisaureus_>dvv: so how does the fd end up being closed?
19:09:08  <piscisaureus_>dvv: or invalid
19:09:34  <piscisaureus_>dvv: so either you found a bug in libuv, or you closed the fd directly
19:09:46  <dvv>right
19:10:17  <piscisaureus_>dvv: so which one? Did you do uv_close?
19:10:20  <dvv>but i never used anything beyond uv_*() to operate on handles
19:10:33  <dvv>i believe so
19:11:08  <piscisaureus_>dvv: it is not possible to "check" whether an fd is valid or not
19:11:15  <piscisaureus_>dvv: at least not in a safe way
19:11:17  <dvv>but in this case handle flags must be set in accordance to the state -- WRITABLE/READABLE cleared, CLOSED set
19:12:45  <dvv>(am almost sure bug in my code, but it worked fine this libuv dated circa a week/two ago. will investigate further)
19:14:57  <piscisaureus_>mraleph: ?
19:15:25  <piscisaureus_>dvv: maybe the flags got messed up somehow. I think that after uv_close readable and writable should be cleared yeah
19:15:50  <dvv>should i file an issue?
19:16:05  <piscisaureus_>dvv: go ahead
19:16:52  <piscisaureus_>dvv: I am not happy with the territory expansion of these flag functions btw.
19:17:15  <piscisaureus_>dvv: they used to be there mainly to check whether an accepted pipe connection was duplex or directed
19:17:24  <dvv>:)
19:17:49  <dvv>what's an alternative?
19:18:26  <mraleph>piscisaureus_: hi
19:18:35  <mraleph>how can I help you?
19:19:31  <piscisaureus_>mraleph: Are your jsconf slides up somewhere? I hear the talk was very good.
19:19:31  <piscisaureus_>mraleph: Also - http://groups.google.com/group/nodejs/browse_thread/thread/19d1baf7d1815b5d/8a28ff1d9cfc924b#8a28ff1d9cfc924b
19:19:31  <piscisaureus_>Threads-a-gogo is obviously a retarded approach but his statement is true in this case - when he offloads the computation to another isolate it is much faster. But how can it be so much faster?
19:20:16  <mraleph>piscisaureus_: slides won't help you much, s3.mrale.ph/jsconf2012.pdf
19:20:31  <piscisaureus_>dvv: the alternative is have a clear vision on which flags we want and which ones we don't (Ideally we won't expose any implementation details) and think of a good interface to expose them.
19:22:16  <indutny>piscisaureus_: your main-thread VM is dirty
19:22:20  <mraleph>piscisaureus_: very suspicious i would say
19:22:31  <dvv>providing the flag names are normalized among unix/win, i believe macros IS_<FLAGNAME> are good enough
19:22:37  <indutny>mraleph: hell yeah :D
19:23:03  <piscisaureus_>mraleph: I investigated it somewhat - I could not find any obvious flaws
19:23:14  <mraleph>piscisaureus_: I would check if V8 optimizes fib/loop at all when they are run on the "main thread"
19:23:29  <piscisaureus_>mraleph: (like, the "threaded" version does not compute less or something)
19:23:50  <piscisaureus_>mraleph: I did - fib() gets optimized both ways and loop() never gets optimized
19:25:13  <mraleph>I can look tomorrow if I have time
19:25:26  <mraleph>there is definetely some corner case here
19:25:38  <mraleph>runInNewContext perf hints that
19:29:19  <piscisaureus_>mraleph: kewl
19:31:37  * pfox___quit (Quit: leaving)
19:33:36  * mikealquit (Quit: Leaving.)
19:48:39  * toothrquit (Ping timeout: 240 seconds)
19:58:26  * toothrjoined
19:59:02  * mikealjoined
20:01:07  * c4milochanged nick to c4milo|bbl
20:06:46  * dvvquit (Ping timeout: 244 seconds)
20:20:38  * dvvjoined
20:26:00  * mikealquit (Quit: Leaving.)
20:27:36  * mikealjoined
20:30:49  <creationix>TooTallNate, how do I use node-gyp? my node-sdl package doesn't build on 0.6.x anymore, it's still using node-waf
20:31:19  <TooTallNate>creationix: you gotta write a binding.gyp file
20:32:33  <TooTallNate>creationix: check out https://github.com/polotek/libxmljs/blob/master/binding.gyp
20:32:46  <indutny>offtopic: I kinda love how gyp looks into source files and determines which one are dependent on others
20:41:23  * dvvquit (Ping timeout: 244 seconds)
20:46:44  * piscisaureus_quit (Ping timeout: 246 seconds)
20:48:39  * piscisaureus_joined
21:07:44  * mralephquit (Read error: Connection reset by peer)
21:07:46  * mraleph1joined
21:07:57  * mraleph1quit (Remote host closed the connection)
21:09:11  * indutnyquit (Read error: Operation timed out)
21:10:04  * indutnyjoined
21:10:11  * mikealquit (Quit: Leaving.)
21:12:13  * igorziquit (Ping timeout: 245 seconds)
21:12:57  * rendarquit
21:13:03  * Marakquit (Ping timeout: 245 seconds)
21:14:09  * mmalecki[plane]changed nick to mmalecki
21:14:14  * mikealjoined
21:22:41  <creationix>TooTallNate, do I need to add anything in package.json to use binding.gyp
21:22:50  <creationix>and do I need to delete wscript
21:24:31  <tjfontaine>you don't need to, npm will do the RightThing(tm)
21:24:52  <creationix>:)
21:24:52  <tjfontaine>I think there's a priority of bindings.gyp > wscript
21:24:58  <creationix>yep, seems to work
21:25:04  <creationix>node-sdl works again!
21:31:54  <bnoordhuis>mjr_: haven't had time to look into it yet
21:32:17  <bnoordhuis>isaacs: is eric still the program manager for node?
21:33:17  <mmalecki>bnoordhuis: I'm in Amsterdam!
21:33:28  <bnoordhuis>mmalecki: hey. i'm in gouda tonight :)
21:33:35  <mmalecki>sitting with jvduf and doing some hacking
21:33:44  <mmalecki>what's gouda?
21:33:54  <bnoordhuis>the arse end of the world
21:34:08  <bnoordhuis>lots of green though
21:34:16  <bnoordhuis>come over to the c9 office tomorrow
21:35:17  <mmalecki>bnoordhuis: yeah, we can do that :). where is it located?
21:35:35  <bnoordhuis>mmalecki: at the keizersgracht, near the anne frank house
21:35:50  <isaacs>bnoordhuis: no, what's up?
21:36:13  <bnoordhuis>isaacs: i had some questions about invoices
21:36:29  <mmalecki>bnoordhuis: number eleven?
21:36:29  <bnoordhuis>but eric isn't replying it seems :)
21:36:48  <bnoordhuis>mmalecki: no, i think it's 243
21:37:08  <mmalecki>bnoordhuis: ok, jvduf will lead us :)
21:37:17  <bnoordhuis>cool :)
21:38:07  <TooTallNate>creationix: no and no
21:38:17  <mmalecki>bnoordhuis: do you guys have beer there?
21:38:19  <TooTallNate>creationix: but you should remove any "install" or "preinstall" phases
21:38:23  <mmalecki>or should we bring our own?
21:38:31  <bnoordhuis>mmalecki: probably only heineken so bring your own
21:38:36  <TooTallNate>creationix: because npm will automatically detect the wscript/binding.gyp file
21:38:46  <bnoordhuis>mmalecki: i kid, there's a lot of hipster pubs in that area, we'll find something
21:38:49  <mmalecki>bnoordhuis: cool, what flavor do you like?
21:38:57  <mmalecki>Charlie bought Heineken.
21:39:14  <bnoordhuis>i suppose it's a step up from american lagers
21:39:16  <bnoordhuis>still, i'll pass
21:40:05  <mmalecki>yeah, we can totally get something different :)
21:46:28  <bnoordhuis>mjr_: btw, i'll take any cores you have, the more the merrier :)
21:52:47  <CIA-99>node: Aaron Jacobs master * r1444801 / (src/v8_typed_array.cc src/v8_typed_array.h):
21:52:47  <CIA-99>node: typed arrays: unexport SizeOfArrayElementForType()
21:52:47  <CIA-99>node: It isn't used anywhere else, so made it an implementation detail in
21:52:47  <CIA-99>node: v8_typed_array.cc. - http://git.io/ioUp-g
21:54:02  * dapquit (Quit: Leaving.)
21:54:21  * dapjoined
21:55:33  <piscisaureus_>bnoordhuis: hey
21:55:43  <bnoordhuis>piscisaureus_: ho
21:56:15  <bnoordhuis>i'm down to 12 failing libuv tests in the refactor branch, less than what's failing in master
21:57:08  <piscisaureus_>bnoordhuis: if you dlopen() a library on unix, and that library depends on other libraries, is the path searched that contains the library also used when the dependencies of the library are resolved
21:57:11  <piscisaureus_>?
21:57:54  <bnoordhuis>is the path searched that contains the library <- wut?
21:58:09  <bnoordhuis>i think i understand what you mean
21:58:26  <bnoordhuis>yes and no, the dynamic linker looks in fixed places
21:59:06  * c4milo|bblchanged nick to c4milo
21:59:33  <piscisaureus_>bnoordhuis:
21:59:33  <piscisaureus_>ok so, suppose you try to dlopen('/foo/bar.so') and bar.so depends on baz.so
21:59:33  <piscisaureus_>will the linker then try to load '/foo/baz.so' ?
21:59:40  <piscisaureus_>bnoordhuis: is that possible?
22:00:05  <bnoordhuis>piscisaureus_: no. link paths are fixed
22:00:32  <bnoordhuis>it would work if bar.so is linked against /foo/baz.so
22:00:37  <piscisaureus_>bnoordhuis: can we make it work that way?
22:00:38  <piscisaureus_>:-p
22:00:49  <bnoordhuis>why? what are you trying to do?
22:01:11  <piscisaureus_>bnoordhuis: https://github.com/joyent/libuv/issues/377
22:04:05  <bnoordhuis>piscisaureus_: you can't do that (in a portable way), people will have to set LD_LIBRARY_PATH
22:04:33  <piscisaureus_>hmm
22:04:54  <bnoordhuis>i suppose you could hack around it with setenv("LD_LIBRARY_PATH", $PWD), then execve(argv[0])
22:05:10  <bnoordhuis>but that's probably a bad idea
22:07:04  * dylukes_joined
22:07:28  <piscisaureus_>bnoordhuis: hmm that's not what I want...
22:07:46  <piscisaureus_>bnoordhuis: there should be no exec()ing involved, we have to switch the path every time we dlopen()
22:07:49  * travis-cijoined
22:07:49  <travis-ci>[travis-ci] joyent/node#722 (master - 1444801 : Aaron Jacobs): The build is still failing.
22:07:49  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/16fca26...1444801
22:07:49  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1077574
22:07:49  * travis-cipart
22:08:21  * dylukes_changed nick to dylukes
22:09:36  <TooTallNate>piscisaureus_: so we can setenv("LD_LIBRARY_PATH", ...) inside uv_dlopen() i guess
22:10:02  <piscisaureus_>TooTallNate: maybe - I don't know it that works
22:10:33  <piscisaureus_>TooTallNate: also it has a threadsafety problem :-)
22:11:00  <bnoordhuis>TooTallNate: won't work, LD_LIBRARY_PATH needs to be set before the program is loaded
22:11:07  <TooTallNate>ok
22:11:59  <piscisaureus_>bnoordhuis: so, basically, there is no way for a program to look anywhere else but from /lib and /usr/lib ??
22:12:23  <bnoordhuis>piscisaureus_: that's correct
22:12:27  <piscisaureus_>inverse hurray for unix .... /0\
22:13:21  <bnoordhuis>piscisaureus_: i don't think it'll be an issue in practice
22:13:31  <piscisaureus_>bnoordhuis: so, to install something like a sublime plugin you have to crap it in /lib ?
22:13:34  <bnoordhuis>either you link against the system libs or you link statically, problem solved
22:13:38  <bnoordhuis>yes
22:13:51  <bnoordhuis>or /usr/lib or /usr/local/lib or ...
22:15:30  <TooTallNate>bnoordhuis: node-qt is doing something kinda hacky here
22:15:33  <TooTallNate>https://github.com/arturadib/node-qt/blob/master/binding.gyp#L40-42
22:15:38  <TooTallNate>https://github.com/arturadib/node-qt/blob/master/lib/qt.js#L36
22:17:02  <bnoordhuis>TooTallNate: you can dlopen() shared objects from arbitrary directories
22:17:33  <piscisaureus_>bnoordhuis: $ORIGIN
22:17:42  <bnoordhuis>it's that you cannot depend on the dynamic linker to auto-load shared objects from outside the set of ordained library dirs
22:19:01  <bnoordhuis>piscisaureus_: doesn't work with setuid root binaries
22:19:16  <TooTallNate>bnoordhuis: so in this case, he's chdir()ing to oblige to those linker rules
22:19:30  <TooTallNate>bnoordhuis: and those rules don't really play well with node's module system
22:19:55  <TooTallNate>bnoordhuis: i mean you're right though, static linking is the answer
22:20:17  <bnoordhuis>TooTallNate: node-qt is still linking to the system gt libs
22:20:29  <TooTallNate>bnoordhuis: not on OS X
22:20:30  <bnoordhuis>that chdir is so it can load the node bindings
22:20:57  <piscisaureus_>bnoordhuis: well, I don't care. People should not setuid root
22:21:09  <piscisaureus_>bnoordhuis: unless they run a suicidal business
22:21:21  <piscisaureus_>bnoordhuis: I mean, they should not setuid root *node*
22:21:26  <bnoordhuis>piscisaureus_: another issue, not all linkers understand $ORIGIN
22:21:39  <piscisaureus_>bnoordhuis: well, too bad for them
22:21:58  <piscisaureus_>bnoordhuis: the alternative you are proposing is that people install e.g. libpng globally
22:22:12  <piscisaureus_>bnoordhuis: they can always fall back to that if for some reason they cannot use $ORIGIN
22:23:07  <bnoordhuis>TooTallNate: is node-qt linking dynamically? maybe the linker works differently on os x
22:23:46  <TooTallNate>bnoordhuis: yes, dynamically. he chdirs so that $PWD/lib has the libs he needs
22:23:52  <bnoordhuis>piscisaureus_: no :) what i'm suggesting is that you either bundle libpng and link statically or link dynamically against the system libpng
22:24:26  <bnoordhuis>TooTallNate: ah, okay. then it's probably possible on os x but not real unices
22:24:39  <TooTallNate>bnoordhuis: for whatever reason, he wasn't able to get a statically compiled qt
22:25:01  <bnoordhuis>i don't doubt that, qt is a major pain to compile
22:25:31  <piscisaureus_>bnoordhuis: ok well if you say so
22:26:09  <piscisaureus_>bnoordhuis: I guess people can just set -Wl,-rpath,'$ORIGIN' in their config.gyp for compiled addons
22:26:57  <piscisaureus_>bnoordhuis: I will change the windows dlopen feature to look in the so dir as well (because the current state is more retarded: it looks in the cwd first!)
22:27:09  <bnoordhuis>piscisaureus_: sure. it's just that there are many things that can go wrong
22:27:20  * mikealquit (Quit: Leaving.)
22:48:27  <CIA-99>libuv: Bert Belder master * r62a63a3 / src/win/dl.c : Windows: make uv_dlopen() look in the DLL path to resolve recursive dependencies - http://git.io/m7ocuQ
22:48:33  <piscisaureus_>bnoordhuis: spawn_and_kill_with_std <-- does that fail on unix too?
22:50:38  * travis-cijoined
22:50:38  <travis-ci>[travis-ci] joyent/libuv#197 (master - 62a63a3 : Bert Belder): The build is still failing.
22:50:38  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/9984d15...62a63a3
22:50:38  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1077963
22:50:38  * travis-cipart
22:51:10  <piscisaureus_>bnoordhuis: the test seems dumb - I don't get it :-(
23:05:37  <bnoordhuis>piscisaureus_: you asked me that :) yes, it does
23:06:09  <piscisaureus_>bnoordhuis: ok, imma fix it so we get to 0 failures \o/
23:12:44  * toothrquit (Read error: Connection reset by peer)
23:13:12  * dshaw_1joined
23:14:40  * dshaw_quit (Ping timeout: 260 seconds)
23:16:15  * toothrjoined
23:17:24  <toothr>saghul, ping again, sorry if you already ponged-- my box crashed.
23:17:42  <saghul>toothr hey
23:21:10  <piscisaureus_>bnoordhuis: killing with an std is also an unpleasant death I think
23:21:18  <piscisaureus_>(being killed, rather)
23:21:29  <bnoordhuis>heh, i was thinking along similar lines
23:22:14  <toothr>saghul, would you be opposed to allowing setup_libuv.py to somehow use an additional arbitrary patch? (since it downloads libuv, it's not simple to just patch beforehand)
23:22:55  <saghul>what do you mean by "arbitrary patch" ?
23:23:21  <saghul>what do you need exactly?
23:23:25  <toothr>just as in, my own patch..
23:24:24  <saghul>like the one for c-ares I currently have?
23:24:27  <toothr>right
23:24:54  <saghul>you can add arbitrary patches to that list and they'll all be applied
23:25:17  <saghul>ideally patching shouldn't be required though
23:25:21  <toothr>agreed
23:25:34  <isaacs>sweet, now getting just slightly *better* performance in http_simple on the domains-wip branch.
23:25:37  <CIA-99>node: isaacs domains-wip * r7b3fd2e / (14 files): MakeCallback: Consistent symbol usage (+34 more commits...) - http://git.io/ahnw0Q
23:26:00  <saghul>so, would you need any changes to that mechanism to do something?
23:26:21  <isaacs>though i'm totally cheating, because i also updated MakeCallback to take a symbol rather than a string, so there are a lot of cases where we're cutting out a char*->v8::String conversion
23:28:09  * mmaleckichanged nick to mmalecki[brb]
23:29:12  <toothr>saghul, i was just trying to simplify the building for deploying, so someone doesn't have to edit setup_libuv.py...
23:29:53  <toothr>it's not too important (obviously)
23:29:56  <saghul>well, what patches do you need?
23:30:40  <saghul>I don't add stuff there every day, that's why it's as it is
23:31:23  <saghul>toothr feel free to open an issue on GitHUb and we can check it out :-)
23:31:28  <toothr>yeah, it's no big deal, seems pretty trivial/nonsensical now that i'm actually asking about it
23:35:04  <toothr>my thought was a --patch or that it would just listdir on ./patches, but you're right, better to spend effort towards removing the need for a patch
23:35:46  <toothr>if someone can't figure out how to apply my patch and build pyuv they have bigger problems anyways :)
23:36:06  <saghul>what does your patch do btw?
23:36:48  <toothr>allows subtree watching on windows and adjusts a buffer size
23:37:41  <saghul>aha
23:37:56  <saghul>did you submit patches to libuv?
23:39:33  * dylukesquit (Quit: Computer has gone to sleep.)
23:41:36  * travis-cijoined
23:41:36  <travis-ci>[travis-ci] joyent/node#723 (domains-wip - 7b3fd2e : isaacs): The build is still failing.
23:41:36  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/bf7fda2...7b3fd2e
23:41:36  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1078176
23:41:36  * travis-cipart
23:42:21  <toothr>i don't consider the changes to be submitable.. it ignores a couple issues that would need to addressed first, i guess
23:42:35  <toothr>i've been told none of the other platforms support subtree watching either
23:44:10  * c4miloquit (Ping timeout: 260 seconds)
23:45:01  * dylukesjoined
23:58:25  * orlandovftwquit (Ping timeout: 260 seconds)