00:04:56  <bnoordhuis>check out https://encrypted.google.com/
00:11:04  <piscisaureus_>yes?
00:11:24  <piscisaureus_>ah the sound thing is cool
00:11:36  * mmaleckiquit (Quit: leaving)
00:12:10  <piscisaureus_>why encrypted btw?
00:12:23  <bnoordhuis>piscisaureus_: why not?
00:12:29  <piscisaureus_>I don't mind
00:12:37  <piscisaureus_>but google.com is always encrypted for me
00:12:59  <bnoordhuis>you're always logged into your google account?
00:13:41  <piscisaureus_>hmm, apparently :-)
00:20:55  <piscisaureus_>I go
00:23:16  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:23:42  <bnoordhuis>he went
00:56:22  * mikealquit (Quit: Leaving.)
00:58:00  * mikealjoined
01:24:32  * pieternquit (Quit: pietern)
01:26:23  * ericktquit (Ping timeout: 265 seconds)
01:38:38  * mikealquit (Quit: Leaving.)
01:47:35  * brsonquit (Ping timeout: 244 seconds)
01:58:16  <CIA-155>libuv: Ben Noordhuis master * r5b9c451 / (3 files in 2 dirs): unix: fold uv__io_cb into ev_io struct - http://git.io/RKzvCw
01:58:17  <CIA-155>libuv: Ben Noordhuis master * r3bc9707 / (10 files in 3 dirs): unix: replace ev_io with uv__io_t - http://git.io/a2zYfw
02:00:09  * travis-cijoined
02:00:10  <travis-ci>[travis-ci] joyent/libuv#305 (master - 5b9c451 : Ben Noordhuis): The build is still failing.
02:00:10  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/7a64ec4...5b9c451
02:00:10  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1406925
02:00:10  * travis-cipart
02:05:22  <CIA-155>node: Ben Noordhuis master * r1358bac / (12 files in 5 dirs): deps: upgrade libuv to 5b9c451 - http://git.io/MkPXqg
02:05:23  <CIA-155>node: Jeroen Janssen master * rf079c0b / doc/api/process.markdown : doc: process get/setuid and get/setgid are POSIX only - http://git.io/hTLHlQ
02:05:23  <CIA-155>node: Mathias Bynens master * ra2fcc47 / doc/api/punycode.markdown : doc: add punycode.js documentation - http://git.io/OvPWgA
02:07:43  <bnoordhuis>^ flemish/dutch party
02:07:54  <tjfontaine>punycode oh man
02:08:23  <bnoordhuis>it's been in node a long time, just wasn't documented
02:09:26  <tjfontaine>ya, it just gives me a visceral response when ever I think about it :)
02:11:40  * pieternjoined
02:12:50  * avalanche123joined
02:26:50  * mattstevensjoined
02:28:17  * mjr_quit (Quit: mjr_)
02:43:19  * bnoordhuisquit (Ping timeout: 245 seconds)
02:52:20  * pieternquit (Quit: pietern)
03:14:24  * iraquit (Quit: Computer has gone to sleep.)
03:21:16  * mattstevensquit (Quit: mattstevens)
03:34:40  * AlbireoXchanged nick to AlbireoX`Away
03:35:43  * perezdjoined
03:56:16  * c4miloquit (Remote host closed the connection)
04:00:56  * pieternjoined
04:10:00  * ericktjoined
05:37:56  * ericktquit (Quit: erickt)
05:52:18  * pieternquit (Quit: pietern)
06:09:18  * avalanche123quit (Ping timeout: 240 seconds)
06:21:31  * mikealjoined
06:43:30  * paddybyersjoined
06:47:50  * avalanche123joined
06:47:57  * avalanche123quit (Client Quit)
06:55:37  * rendarjoined
07:03:29  * paddybyersquit (Ping timeout: 276 seconds)
07:27:26  * mmaleckijoined
07:53:04  * paddybyersjoined
09:23:13  * indexzerojoined
09:59:58  * TheJHjoined
10:22:42  * TheJHquit (Ping timeout: 244 seconds)
10:32:09  * bnoordhuisjoined
10:37:31  <bnoordhuis>saghul: https://github.com/joyent/libuv/issues/424 <- was that with the latest master or?
10:37:51  <saghul>bnoordhuis yep
10:38:14  <saghul>maybe it was not 100% but just not reacting to write events, I can test it if you need it
10:39:26  <bnoordhuis>okay. i ask because i landed that change only yesterday
10:41:06  <saghul>well, internally same thing is happening, right? ev_io_set is called with the io thing being started already
10:41:21  <saghul>i'll do a quick check just in case
10:42:12  <bnoordhuis>saghul: that means you're calling uv_poll_start() twice, right?
10:42:19  <saghul>yep
10:42:30  <saghul>according to docs that's the way to update the event mask
10:43:15  <bnoordhuis>oh, right. well, that was broken before yesterday too, then :)
10:43:27  <saghul>bnoordhuis heh :-)
10:45:17  <saghul>bnoordhuis I just run a quick test: CPU doesn't spike but event mask update has no effect
10:48:32  <bnoordhuis>saghul: https://gist.github.com/f718b66db49494be394d <- does that fix it?
10:50:10  <saghul>recompiling now
10:51:39  <saghul>bnoordhuis works perfect :-)
10:52:04  <bnoordhuis>saghul: nice, i'll merge it
10:55:14  <saghul>bnoordhuis ++
10:55:15  <kohai>bnoordhuis has 17 beers
10:56:05  <CIA-155>libuv: Ben Noordhuis master * rb19a713 / test/test-fs.c : test: fix unused variable warning - http://git.io/xVg2hw
10:56:05  <CIA-155>libuv: Ben Noordhuis master * r2e3e658 / src/unix/poll.c : unix: fix uv_poll CPU usage spike - http://git.io/1zEo2w
10:58:02  * travis-cijoined
10:58:03  <travis-ci>[travis-ci] joyent/libuv#306 (master - 2e3e658 : Ben Noordhuis): The build is still failing.
10:58:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/5b9c451...2e3e658
10:58:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1409892
10:58:03  * travis-cipart
11:14:24  * piscisaureus_joined
11:26:33  * irajoined
11:38:16  <einaros>is it common practice for package managers to setup the node binary as 'nodejs'?
11:39:44  <bnoordhuis>einaros: no, that's a debian/ubuntu thing
11:40:48  <einaros>terribly annoying when WS tries to fire the post-install script from package.json such as 'node install.js'
11:43:06  <bnoordhuis>einaros: vote to oust the node package
11:43:24  <indutny>oh crap, why is maintainer doing that?
11:43:48  <bnoordhuis>iirc the 'other' node is a ham radio proglet
11:44:12  <bnoordhuis>that no one uses >:(
11:44:22  <einaros>ugh
11:46:35  <einaros>would it be outrageous for npm to replace a token for the node binary in the package.json scripts declaration?
11:46:58  <einaros>such as "$NODE meh.js"
11:49:58  <bnoordhuis>einaros: don't know, ask isaacs. could be it already exists
11:50:20  <indutny>I think "meh.js" should work
11:50:47  <indutny>because there're no other way to execute .js file, other than with node.js
11:50:59  <indutny>though, not sure if npm does it
11:51:47  <bnoordhuis>indutny: you forget about smjs, the spidermonkey shell
11:52:07  <indutny>bnoordhuis: well, if you're using npm - you probably want .js files in package.json to be executed with node
11:52:15  <indutny>otherwise you should specify exact binary to call
11:52:35  <einaros>npm will just try to launch the js file
11:52:41  <indutny>einaros: indeed
11:52:45  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
11:52:50  <indutny>einaros: why are people putting "node file.js" then?
11:53:19  <einaros>no, launch as in use the instructed interpreter
11:53:33  <einaros>without an interpreter declaration in the top of the file, the execution will fail
11:54:03  * piscisaureus_joined
11:55:24  <indutny>einaros: fail
11:55:55  <einaros>yep
11:55:57  <indutny>ircretary: tell isaacs that npm is a fail
11:55:57  <ircretary>indutny: I'll be sure to tell isaacs
11:56:01  <indutny>lol :D
11:56:14  <indutny>ircretary: don't forget to tell isaacs that this is a joke
11:56:14  <ircretary>indutny: I'll be sure to tell isaacs
11:56:22  <indutny>ircretary: thanks
11:56:23  <ircretary>indutny: You're welcome :)
11:56:47  <einaros>I can't rely on an env variable either, since the interpolation will be different between platforms
11:57:35  <einaros>washbucket: why can't you do cool stuff like ircretary?
11:57:35  <indutny>$NODE looks hacky
11:57:41  <einaros>indutny: it does
11:57:42  <washbucket>einaros: I don't have a boyfriend.
11:58:12  <einaros>washbucket: you're the most useless bot ever
11:58:17  <washbucket>einaros: I'm not a robot.
11:59:11  <bnoordhuis>that's what everybody says
11:59:20  <bnoordhuis>ask deckard
12:01:44  <indutny>bnoordhuis: ask Gödel
12:02:01  <bnoordhuis>indutny: i did but he was undecided
12:03:48  <indutny>still we're incomplete
12:08:03  <CIA-155>libuv: Ben Noordhuis master * r3604b8d / (src/unix/pipe.c test/test-pipe-bind-error.c): unix: don't unlink UNIX socket on EADDRINUSE - http://git.io/_UgzMw
12:08:08  <bnoordhuis>^ for better or worse...
12:08:22  <bnoordhuis>no, not worse - it was a daft idea in the first place
12:08:23  <indutny>and how is that supposed to wrk?
12:08:37  <indutny>aaah, UNIX socket
12:09:53  * travis-cijoined
12:09:54  <travis-ci>[travis-ci] joyent/libuv#307 (master - 3604b8d : Ben Noordhuis): The build was fixed.
12:09:54  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/2e3e658...3604b8d
12:09:54  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1410262
12:09:54  * travis-cipart
12:10:12  <bnoordhuis>yay, fixed for the very first time!
12:10:47  <bnoordhuis>i like that the refcount refactor is finally done, it was blocking lots of things
12:10:52  <bnoordhuis>it's a better model too, of course
12:13:31  <bnoordhuis>mmalecki: http://travis-ci.org/#!/joyent/libuv/builds/1410262
12:19:01  * c4milojoined
12:23:53  <pfox__>bnoordhuis: congrats on landing that
12:24:10  <bnoordhuis>pfox__: thanks :)
12:24:19  <pfox__>just landed high-level tcp bindings for rust
12:24:23  <pfox__>like, last night
12:24:32  <pfox__>hopefully we can upgrade the libuv submodule soon.
12:25:14  * TheJHjoined
12:25:16  <bnoordhuis>is there anything in rust besides your code that uses libuv?
12:26:03  <pfox__>in the library? no, i've done just about all of the work.
12:26:06  <pfox__>this is all being used in servo, though.
12:26:26  <pfox__>the only "high-level" apis out there, currently, are some blocking timer stuff and the newly landed tcp bindings
12:26:42  <pfox__>the timers are already being used in the servo codebase. the tcp stuff will be in use shortly
12:27:42  * c4miloquit (Remote host closed the connection)
12:27:44  <pfox__>hopefully we'll sit down soon and hash out a stream API. then i'll probably refactor/rework the tcp stuff in that direction.
12:34:06  <saghul>first time I see "build status: passing" for libuv! nice :-)
12:44:12  <mmalecki>bnoordhuis: ++ :)
12:44:14  <kohai>bnoordhuis has 18 beers
13:03:27  * ibc_joined
13:03:38  * ibc_changed nick to ibc
13:05:03  <ibc>hi, in UV master, how to check the number of active handles? I can check whether there are or not active handles with ngx_queue_empty(&uv_default_loop()->active_handles), but I would like to know the number of active handles
13:11:53  <piscisaureus_>ibc: active_handles is actually not a public api
13:12:13  <ibc>I know :)
13:12:27  <piscisaureus_>ibc: meaning that within a week it will be removed
13:12:52  <piscisaureus_>ibc: but for the time being you can compile libuv with UV_LEAN_AND_MEAN defined
13:13:00  <piscisaureus_>then active_handles is a counter and not a queue :-)
13:13:27  <ibc>I compile uv master and it seems that by default it defines UV_LEAN_AND_MEAN
13:13:37  <piscisaureus_>it doesn't
13:13:46  <ibc>humm, so I must check...
13:14:10  <piscisaureus_>but UV_LEAN_AND_MEAN will also go byebye within the week
13:15:35  <bnoordhuis>UV_LEAN_AND_MEAN is not the default
13:15:39  <bnoordhuis>and it's probably broken right now
13:15:50  <ibc>I just run make in UV master, then I check #ifdef UV_LEAN_AND_MEAN and I get true, sure
13:16:04  <ibc>in fact I'm using ngx_queue_empty(&uv_default_loop()->active_handles with no problems
13:16:16  <ibc>just "make" (Linux)
13:16:51  <bnoordhuis>active_handles will be removed soon
13:17:54  <ibc>ok, good to know :)
13:18:18  <ibc>so any way to check the number of active handles? I need it for testing/developming purposes (an assert somewhere in my caode)
13:18:27  <ibc>"code"
13:19:30  * abraxasquit (Remote host closed the connection)
13:20:07  * abraxasjoined
13:20:07  <bnoordhuis>ibc: you can use active_handles for now, just keep in mind that it will disappear :)
13:20:16  <bnoordhuis>we're replacing it with a queue of *all* handles
13:20:30  * TheJHquit (Ping timeout: 248 seconds)
13:21:14  * c4milojoined
13:21:20  <ibc>right, but as said before, when I compile UV with "make" I get UV_LEAN_AND_MEAN defined, so my loop->active_handles is a ngx_queue_t rather than a int
13:22:00  <CIA-155>libuv: Ben Noordhuis next-tick * r8143d76 / (test/test-callback-order.c test/test-list.h): test: fix up test-callback-order.c - http://git.io/rQcC-A
13:22:13  <bnoordhuis>piscisaureus_: you should review that ^
13:22:21  <bnoordhuis>and tell me why it works in libuv but not in node
13:22:41  <ibc>ok, forget me please
13:22:52  <ibc>UV_LEAN_AND_MEAN is NOT defined ;)
13:22:55  <bnoordhuis>ibc: you can use ngx_queue_foreach(q, &loop->active_handles) to walk over (and therefore count) the handles
13:22:56  <ibc>sorry
13:22:59  <bnoordhuis>np :)
13:23:19  <ibc>my assert worked because active_handles returns 1 :)
13:23:24  <ibc>sorry again
13:24:34  <pfox__>so i assume all of this active_handles is leading up to the fact that uv_walk is THE FUTURE
13:24:37  * abraxasquit (Ping timeout: 265 seconds)
13:24:44  <pfox__>all of this actives_handles stuff
13:25:09  <pfox__>well 1) it'll be replaced with a queue of all handles, etc etc
13:25:11  <pfox__>2) ???
13:25:12  <bnoordhuis>pfox__: yes, if only because it makes debugging for us easier :)
13:25:14  <pfox__>3) profit
13:26:20  <pfox__>how will one ascertain the activity status of handles?
13:26:32  <bnoordhuis>pfox__: uv_is_active(handle)
13:26:45  <piscisaureus_>and uv_is_closing()
13:26:45  <bnoordhuis>well... uv_is_active || uv_is_closing
13:26:50  <pfox__>god, you guys are so smart. thank thank.
13:26:51  <piscisaureus_>yes
13:26:56  <pfox__>thank you thank you thank you.
13:27:14  <bnoordhuis>haha, happy to help
13:27:58  <pfox__>ill be doing a rework of the rust libuv infrastructure soon, with this stuff in mind.
13:27:59  * travis-cijoined
13:28:00  <travis-ci>[travis-ci] joyent/libuv#308 (next-tick - 8143d76 : Ben Noordhuis): The build failed.
13:28:00  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/8143d76
13:28:00  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1410829
13:28:00  * travis-cipart
13:28:04  <pfox__>it'll make things a lot more interesting..
13:28:19  <pfox__>being able to use uv_walk to arbitrarily tear down the loop will make most of our safety issues go away
13:28:47  <piscisaureus_>graceful teardown was just a missing piece
13:29:17  <piscisaureus_>Hopefully it will also help tim do his handle garbage collection
13:29:29  <pfox__>indeed!
13:29:39  <piscisaureus_>and let the julia guys do their crazy gc introspection stuff
13:29:45  <piscisaureus_>then i'm happy :-)
13:30:12  <pfox__>for rust, we get our jimmies in a rustle for being able to clearly defining lifetimes.. especially if it means tying it to some stack-based value that, when it leaves scope, gives me a chance to gracefully shut down the loop
13:30:13  <piscisaureus_>bnoordhuis: well callback_order passes for me
13:30:29  <pfox__>so this is really, really cool.
13:30:30  <bnoordhuis>yeah, for me too - that's the problem
13:30:42  <piscisaureus_>bnoordhuis: lemme think about it deeply :-)
13:31:17  <bnoordhuis>piscisaureus_: you do that while i go get some groceries :)
13:31:24  <bnoordhuis>and some ice cream!
13:31:29  <piscisaureus_>oh my
13:31:33  <piscisaureus_>the office is so hot now
13:31:41  <bnoordhuis>yeah, i suspected as much
13:31:41  <piscisaureus_>you should come tomorrow btw
13:31:53  <piscisaureus_>beer in amsterdam is awesome with these temperatures
13:32:07  <bnoordhuis>you mean heineken?
13:32:17  <bnoordhuis>at these temperatures it tastes more likes the stuff it's derived from
13:32:18  <piscisaureus_>yeah hot heineken
13:32:49  <piscisaureus_>no bubble
13:32:50  <piscisaureus_>s
13:33:55  <piscisaureus_>bnoordhuis: did you try to start the timer from a prepare instead of a check ?
13:34:20  <piscisaureus_>umm I mean the other way round... <-- bnoordhuis
13:34:30  <bnoordhuis>no
13:34:49  <bnoordhuis>i *think* this is the order that node uses in simple/test-next-tick-ordering2
13:35:15  <bnoordhuis>then again... src/node.js may insert a couple of nextTicks() itself, of course
13:35:27  <piscisaureus_>I don't think it does
13:35:46  <bnoordhuis>i'll think about it some more while i get some ice cream
13:35:49  <piscisaureus_>so the main code runs on the first tick
13:35:56  <piscisaureus_>then nextTick runs in a prepare
13:36:05  <piscisaureus_>hmmm
13:36:36  <piscisaureus_>bnoordhuis: maybe you should insert some work
13:36:48  * bnoordhuisis off to the ice saloon
13:37:12  <piscisaureus_>bnoordhuis: It could be that the timer is fuzzed a little bit by libev so it doesn't expire immediately (in the libuv test)
13:48:25  * ibcquit (Remote host closed the connection)
14:13:39  * TheJHjoined
14:14:59  <piscisaureus_>I wonder if there would be any benefit in using aio_write for socket writes on solaris
14:19:11  * ericktjoined
14:55:44  * isaacsjoined
14:58:56  <isaacs>indutny: npm was a joke fail? what?
14:59:19  <indutny>isaacs: hahahahahaha
14:59:21  <indutny>isaacs: gtg
14:59:23  <indutny>ttyl
14:59:26  <isaacs>k, have fun :)
15:02:05  * pieternjoined
15:04:19  * ericktquit (Quit: erickt)
15:21:37  * TheJHquit (Ping timeout: 252 seconds)
15:33:01  <isaacs>do you think we should care about simple/test-next-tick-ordering2?
15:34:50  <piscisaureus_>we should cut a decision :-)
15:34:50  <piscisaureus_>the current nextTick semantics are kind of insane
15:34:50  <piscisaureus_>but if we say there are defined semantics at all, we should make the tests pass :-)
15:35:04  * TheJHjoined
15:35:29  <piscisaureus_>we can also make it much simpler by calling nextTicks after every v8 invocation
15:35:47  <piscisaureus_>and allow next-tick-starvation to fail
15:35:54  <isaacs>hm.
15:35:55  <isaacs>yeah
15:36:01  <isaacs>so, nextTick would really be endOfTick or somethign
15:36:22  <piscisaureus_>Immediately after the current tick
15:36:37  <piscisaureus_>but "tick" does not really exist as a concept :-)
15:36:52  <piscisaureus_>unless you say that every invocation of v8 from c++ is a tick
15:37:14  <isaacs>it was a libev-ism originally, i believe
15:37:23  <piscisaureus_>I don't think so
15:37:29  <piscisaureus_>libev has no concept of "tick" either
15:37:42  <piscisaureus_>is has "event loop iterations" like libuv
15:38:28  <piscisaureus_>but, depending on the backend, many io operations can be processed in a single iteration
15:48:36  <isaacs>right
15:49:35  <isaacs>i'd rather not change the semantics dramatically for v0.8
15:50:10  <isaacs>but it'd be nice to just call nextTicks at the end of each v8 invocation
15:50:26  <isaacs>it'd be faster for what you really want to use nextTick for most of the time, which is "do all your stuff, then do this thing"
15:50:37  <isaacs>but before any IO happens
15:51:08  <isaacs>what about making the semantics undefined for v0.8, and then making them defined to be that in v0.9? thoughts?
15:52:48  * ibcjoined
15:53:32  <ibc>hi, IMHO it could be useful that a function exactly like uv__run (note the double "_") would be public
15:54:19  <ibc>i.e. I want to stop UV iterating if: 1) UV has no more active handles/reqs, 2) if I've set a custom variable do_stop=1
15:56:52  * TheJHquit (Ping timeout: 244 seconds)
15:58:10  <ibc>it would be really easy, just modify the current public uv_run_once() which now looks like:
15:58:17  <ibc>int uv_run_once(uv_loop_t* loop) {
15:58:17  <ibc> uv__run(loop);
15:58:17  <ibc> return 0;
15:58:17  <ibc>}
15:58:21  <ibc>to:
15:58:30  <ibc>int uv_run_once(uv_loop_t* loop) {
15:58:30  <ibc> uv__run(loop);
15:58:30  <ibc>}
15:58:47  <ibc>so I can use the return value to know whether I must iterate more or not
16:00:23  <tjfontaine>you missed a return in there
16:01:24  <ibc>right: return uv__run(loop);
16:01:43  * avalanche123joined
16:01:59  <avalanche123>hi peeps, question about uv_pipe_open
16:02:42  <avalanche123>it accepts a file descriptor, but should I create the pipe file myself using mknod?
16:04:02  <avalanche123>bnoordhuis ping
16:07:02  <ibc>I've reported it in Github: https://github.com/joyent/libuv/issues/427
16:08:10  <avalanche123>piscisaureus_ ping
16:09:30  * ericktjoined
16:29:22  * perezdquit (Quit: perezd)
16:57:46  * ibcquit (Remote host closed the connection)
17:16:04  * brsonjoined
17:18:29  * ericktquit (Quit: erickt)
17:23:29  * perezdjoined
17:24:23  * brson_joined
17:24:24  * brsonquit (Quit: leaving)
17:24:39  * AvianFlujoined
17:30:17  * TheJHjoined
17:30:56  * TheJHquit (Read error: Connection reset by peer)
17:33:09  * TheJHjoined
17:41:04  * avalanche123quit (Quit: Computer has gone to sleep.)
17:53:55  * brson_quit (Quit: leaving)
17:54:10  * brsonjoined
17:54:22  * ericktjoined
18:07:20  * pietern_joined
18:09:05  * pieternquit (Ping timeout: 276 seconds)
18:09:06  * pietern_changed nick to pietern
18:23:29  * perezdquit (Quit: perezd)
18:24:04  * AlbireoX`Awaychanged nick to AlbireoX
18:24:18  * perezdjoined
18:25:40  * mjr_joined
18:25:43  * indexzeroquit (Quit: indexzero)
18:27:42  * TheJHquit (Ping timeout: 248 seconds)
18:33:50  * TheJHjoined
18:34:11  <CIA-155>libuv: Ben Noordhuis issue427 * rc9b590f / (6 files in 5 dirs): unix, windows: make uv_run_once() return a bool - http://git.io/ASL0DQ
18:34:26  <bnoordhuis>piscisaureus_: can you review the windows side? ^
18:34:27  * indexzerojoined
18:37:09  <bnoordhuis>mmalecki: https://github.com/joyent/libuv/issues/426#issuecomment-5873824 <- how does that work?
18:37:44  * TheJHquit (Read error: Operation timed out)
18:38:02  * travis-cijoined
18:38:02  <travis-ci>[travis-ci] joyent/libuv#309 (issue427 - c9b590f : Ben Noordhuis): The build failed.
18:38:02  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/c9b590f
18:38:02  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1414260
18:38:02  * travis-cipart
18:39:19  <mmalecki>bnoordhuis: travis has a github bot which responds to pull requests
18:39:27  <mmalecki>bnoordhuis: I think it can do automatic merging too
18:39:42  <bnoordhuis>indutny: http://travis-ci.org/#!/joyent/libuv/builds/1414260 <- eio_overflow fails regularly
18:39:57  <bnoordhuis>mmalecki: automatic merging? i think not
18:39:58  <mmalecki>bnoordhuis: but it's still in beta and you need to donate to have it enabled on your repo, afaik
18:40:10  <bnoordhuis>ah, okay
18:40:22  * avalanche123joined
18:41:30  * brsonquit (Quit: leaving)
18:41:44  * brsonjoined
18:42:42  <piscisaureus_>bnoordhuis: re issue427 -> mostly lgtm
18:42:55  <piscisaureus_>bnoordhuis: the only thing is, your patch makes it look stupid
18:43:33  <piscisaureus_>the purpose of the UV_LOOP macro was to move the `if (pGetQueuedCompletionStatusEx)` conditional out of the hot path
18:43:46  <piscisaureus_>iirc
18:43:49  * mikealquit (Quit: Leaving.)
18:43:59  <bnoordhuis>in that case you should use it :)
18:44:14  <piscisaureus_>bnoordhuis: you removed the UV_LOOP macro
18:44:18  * mikealjoined
18:44:35  <bnoordhuis>piscisaureus_: because it wasn't used
18:44:39  <bnoordhuis>dead code is dead
18:45:08  <piscisaureus_>bnoordhuis: https://github.com/joyent/libuv/commit/c9b590fe004d46fc6943abe5a496f43d08d9c700#commitcomment-1367760
18:45:22  <piscisaureus_>bnoordhuis: of course its dead when you remove the call :-(
18:46:11  <bnoordhuis>oh, like that - i can put it back :)
18:47:07  <bnoordhuis>does it really make a difference?
18:47:21  <piscisaureus_>bnoordhuis: to be honest, I doubt it
18:47:27  <piscisaureus_>:-p
18:47:46  <bnoordhuis>well, just say the word
18:48:04  <bnoordhuis>(the word is 'pretty please')
18:48:06  <piscisaureus_>bnoordhuis: but I just verified that the compiler doesn't move the if( outside of the loop
18:48:31  <piscisaureus_>bnoordhuis: the changes to uv_run and the removal of UV_LOOP were not necessary. Just remove those parts of the commit
18:49:30  <piscisaureus_>git gui ftw
18:49:34  <piscisaureus_>bnoordhuis: lgtm otherwise
18:50:03  <CIA-155>libuv: Ben Noordhuis issue427 * r7c8313b / (6 files in 5 dirs): unix, windows: make uv_run_once() return a bool - http://git.io/XJbQkA
18:50:08  <bnoordhuis>^ there you og
18:50:15  <bnoordhuis>s/og/go/
18:50:19  <piscisaureus_>og og og
18:51:15  <piscisaureus_>We should have a benchmark that counts the number of iterations a loop can do per second
18:51:34  <piscisaureus_>like, a loop with only an idle callback
18:51:39  <piscisaureus_>and one timer
18:51:48  <bnoordhuis>piscisaureus_: that's easy, go for it
18:51:53  * travis-cijoined
18:51:53  <travis-ci>[travis-ci] joyent/libuv#310 (issue427 - 7c8313b : Ben Noordhuis): The build was fixed.
18:51:53  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/c9b590f...7c8313b
18:51:53  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1414387
18:51:53  * travis-cipart
18:52:03  <bnoordhuis>you know, i'll write one
18:52:11  <bnoordhuis>i like easy
18:52:15  <piscisaureus_>hehe
18:52:22  <piscisaureus_>I am doing tu delft stuff atm
18:52:26  <piscisaureus_>will be over tomorrow
18:52:35  <piscisaureus_>btw
18:52:53  <piscisaureus_>I think libuv is passing 100% on windows and linux
18:52:55  <piscisaureus_>\o/
18:53:10  <piscisaureus_>(windows 7, that is)
18:53:17  <CIA-155>libuv: Ben Noordhuis master * r7c8313b / (6 files in 5 dirs): unix, windows: make uv_run_once() return a bool - http://git.io/XJbQkA
18:53:18  <bnoordhuis>yay!
18:53:43  <piscisaureus_>now to keep it that way
18:54:58  * travis-cijoined
18:54:59  <travis-ci>[travis-ci] joyent/libuv#311 (master - 7c8313b : Ben Noordhuis): The build was broken.
18:54:59  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/3604b8d...7c8313b
18:54:59  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1414414
18:54:59  * travis-cipart
18:57:38  * pieternquit (Quit: pietern)
19:04:17  <igorzi__>piscisaureus_: hey
19:04:29  <igorzi__>piscisaureus_: review pls - https://github.com/igorzi/node/commit/0e74b6783945d6d5eca8159b147f0bbe38d96ae4
19:07:06  <CIA-155>libuv: Ben Noordhuis master * rcd2a9b4 / (test/benchmark-list.h uv.gyp test/benchmark-loop-count.c): bench: measure ticks per second of idle event loop - http://git.io/blgwYw
19:07:09  <bnoordhuis>piscisaureus_: ^
19:09:03  * travis-cijoined
19:09:03  <travis-ci>[travis-ci] joyent/libuv#312 (master - cd2a9b4 : Ben Noordhuis): The build was fixed.
19:09:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/7c8313b...cd2a9b4
19:09:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1414490
19:09:03  * travis-cipart
19:10:43  * AvianFluquit (Read error: Operation timed out)
19:11:52  * pieternjoined
19:15:35  * AvianFlujoined
19:16:06  * bulatshakirzyanojoined
19:16:19  * avalanche123quit (Ping timeout: 256 seconds)
19:16:20  * bulatshakirzyanochanged nick to avalanche123
19:18:53  * avalanche123quit (Client Quit)
19:20:16  * avalanche123joined
19:20:40  <piscisaureus_>bnoordhuis: so what do you get?
19:20:53  <CIA-155>libuv: Ben Noordhuis master * r2b09cc2 / src/unix/udp.c : unix: fix up asserts in udp.c - http://git.io/l-SJwA
19:20:54  <CIA-155>libuv: Ben Noordhuis master * r2609e43 / src/unix/udp.c : unix: remove unnecessary functions in udp.c - http://git.io/1sL10w
19:20:54  <CIA-155>libuv: Ben Noordhuis master * rb69f8ef / test/test-ipc-send-recv.c : test: remove stale socket in ipc_send_recv_pipe - http://git.io/uUd34g
19:21:01  <bnoordhuis>piscisaureus_: about 385-390K ticks/s
19:21:21  <mjr_>That's a lot.
19:22:01  <mjr_>It'd be nice if there were some way to measure the average rate of the event loop and expose it to JS somehow.
19:22:11  <piscisaureus_>bnoordhuis: ha!
19:22:13  <bnoordhuis>mjr_: it's really nothing more than a fancy busy loop
19:22:18  <piscisaureus_>bnoordhuis: on my mac, 707468
19:22:29  <bnoordhuis>piscisaureus_: per second or total?
19:22:33  <piscisaureus_>per second
19:22:39  <piscisaureus_>bnoordhuis: that's on windows btw
19:22:41  * travis-cijoined
19:22:41  <travis-ci>[travis-ci] joyent/libuv#313 (master - b69f8ef : Ben Noordhuis): The build passed.
19:22:41  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/cd2a9b4...b69f8ef
19:22:41  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1414632
19:22:41  * travis-cipart
19:23:11  <bnoordhuis>piscisaureus_: just wait until the linux backend is ready :)
19:23:23  <piscisaureus_>bnoordhuis: /me waits
19:23:48  <bnoordhuis>i guess i should test it on my macbook, that's more comparable
19:23:51  <bnoordhuis>my laptop is pretty old
19:24:06  <piscisaureus_>yes I think we both have an i7 @ 2ghz right?
19:24:21  <bnoordhuis>i think so
19:24:30  <bnoordhuis>tomorrow
19:24:39  <piscisaureus_>bnoordhuis: when are you coming?
19:24:51  <bnoordhuis>around noon, give or take an hour
19:25:06  <bnoordhuis>probably take
19:25:11  <piscisaureus_>take 1 or 2 hour :-)
19:25:34  * TheJHjoined
19:29:11  * avalanche123quit (Quit: Computer has gone to sleep.)
19:36:07  * avalanche123joined
19:37:52  <avalanche123>did anything changed with check handle?
19:38:04  <avalanche123>doesn't seem to be triggered anymore for me
19:38:08  <avalanche123>in my test
19:38:28  <tjfontaine>well, refcount refactor landed
19:40:19  <avalanche123>so now check handle is not triggered if there are no outstanding tasks in the loop
19:40:24  <avalanche123>I assume that is correct?
19:44:50  * piscisaureus_quit (Ping timeout: 244 seconds)
19:45:41  * avalanche123quit (Quit: Computer has gone to sleep.)
19:46:35  * kohaiquit (Remote host closed the connection)
19:49:05  * avalanche123joined
19:54:28  <bnoordhuis>avalanche123: yes
19:54:37  <avalanche123>bnoordhuis thanks
19:54:44  <avalanche123>this has been fixed recently right?
19:54:53  <bnoordhuis>avalanche123: yes
19:55:01  <avalanche123>cool
19:55:29  <avalanche123>I'm writing a set of functional tests to serve as a documentation source here - https://github.com/avalanche123/uvrb/tree/master/features
19:55:33  <avalanche123>that's how I noticed
19:57:52  * indexzeroquit (Quit: indexzero)
20:05:20  * piscisaureus_joined
20:08:43  <igorzi__>piscisaureus_: review? https://github.com/igorzi/node/commit/0e74b6783945d6d5eca8159b147f0bbe38d96ae4
20:09:43  <piscisaureus_>igorzi__: looks good, but I have one question
20:10:00  <piscisaureus_>igorzi__: what happens if I stick a relative path in fs.symlink ?
20:10:09  <piscisaureus_>and try to create a junction
20:13:06  <igorzi__>piscisaureus_: error
20:13:48  <igorzi__>piscisaureus_: https://github.com/joyent/libuv/blob/master/src/win/fs.c#L858
20:14:12  <piscisaureus_>igorzi__: should we run the symlink destination through makelong (for junctions only), and document that junctions are always absolute?
20:16:07  <igorzi__>piscisaureus_: hmm, yeah i think that should be good
20:17:18  <piscisaureus_>ok
20:17:25  <igorzi__>piscisaureus_: i'll get that in
20:18:30  <avalanche123>another question - how hard would it be to add building of .so or .dylib to makefile?
20:18:36  <piscisaureus_>igorzi__: the other thing is that I thing we should throw if the user specifies an illegal "type" argument
20:18:49  <piscisaureus_>igorzi__: otherwise it looks good
20:18:54  <avalanche123>I need a shared library but being a c noob that I am I can't figure out a good cross-platform way of doing it
20:19:27  <igorzi__>piscisaureus_: ok, thx
20:19:38  <avalanche123>I'm running libtool -dynamic -framework CoreServices -o uv.dylib uv.a -lc on my mac and it works
20:19:56  <piscisaureus_>avalanche123: not that hard I suppose
20:19:57  <avalanche123>but travis env complains libtool: unrecognized option `-dynamic'
20:20:20  <avalanche123>piscisaureus_ any resource you could refer me to so I don't interrupt your work with this?
20:20:41  <piscisaureus_>avalanche123: umm I think you should start with the gyp build
20:20:52  <piscisaureus_>avalanche123: so read the gyp documentation
20:21:01  <avalanche123>so don't use makefile
20:21:23  <piscisaureus_>avalanche123: well the makefile should be able to do it too (although there is no makefile for msvc, only for mingw on windows)
20:21:52  <piscisaureus_>avalanche123: but to be honest, I don't know either. I think I would start looking at the makefile for another project, e.g. openssl or something
20:22:03  <piscisaureus_>hmm wait that's probably automake'd
20:22:18  <piscisaureus_>or ask bnoordhuis or any unix experts in here :-)
20:22:24  <avalanche123>:)
20:22:28  <avalanche123>thanks piscisaureus_
20:22:57  <piscisaureus_>avalanche123: I would still start with gyp -> http://code.google.com/p/gyp/wiki/GypLanguageSpecification
20:23:13  <avalanche123>piscisaureus_ will do
20:28:36  <bnoordhuis>avalanche123: s/static_library/shared_libary/ in gyp_uv probably goes a long way
20:28:55  <avalanche123>bnoordhuis you mean adding it there?
20:33:03  <bnoordhuis>avalanche123: changing it
20:33:22  <avalanche123>so that it always builds .so and not .a?
20:33:41  <bnoordhuis>avalanche123: yes
20:33:55  <bnoordhuis>as a quick hack, that is
20:33:59  <avalanche123>ah
20:34:04  <avalanche123>what about long term?
20:34:04  <avalanche123>bnoordhuis zeromq does both for example
20:34:15  <avalanche123>static and shared
20:34:53  <avalanche123>bnoordhuis you're referring to these lines right:
20:34:53  <avalanche123> args.append('-Dcomponent=static_library')
20:34:53  <avalanche123> args.append('-Dlibrary=static_library')
20:35:59  <bnoordhuis>avalanche123: yes
20:36:17  <bnoordhuis>middle/long-term we could add a switch to gyp_uv
20:37:07  <bnoordhuis>or rather, i have no need for a .so myself - i think i'll let it depend on outside contributions :)
20:37:20  <avalanche123>bnoordhuis but you don't want to build both right, any specific reason?
20:37:36  <avalanche123>I was thinking about contributing a change to build both
20:37:46  <bnoordhuis>avalanche123: reason == node doesn't need it
20:37:55  <avalanche123>since I need it and hopefully there more bindings are written for libuv the more useful it will be
20:38:32  * indexzerojoined
20:40:15  <bnoordhuis>avalanche123: oh, patches are welcome
20:40:28  <avalanche123>bnoordhuis awesome
20:40:34  <bnoordhuis>it's that you shouldn't hold your breath if you want *us* to do it :)
20:43:14  <isaacs>bnoordhuis: how do you feel about making the timeout/nextTick ordering less defined?
20:43:35  <bnoordhuis>isaacs: it would make my life easier :)
20:44:15  <bnoordhuis>i wonder if people are depending on the order
20:44:35  <isaacs>bnoordhuis: so, what i'm thinking is, for v0.8, we document the fact that sometimes nextTick is not necessarily going to happen before setTimeout, and then for v0.9 and up, we simplify it and say that nextTick happens at the end of the current tick, and not worry about the nexttick-starvation test
20:44:36  <tjfontaine>I would hope not on purpose
20:44:59  <mjr_>I'm sure people depend on the order whether they realize it or not.
20:45:16  <tjfontaine>mjr_: indeed that's what I meant
20:46:23  <bnoordhuis>isaacs: sounds good
20:46:39  <isaacs>k
20:46:49  <bnoordhuis>mjr_: that's kind of what i'm afraid of
20:47:02  <bnoordhuis>it's the kind of bug that's hell to debug
20:47:15  <isaacs>mjr_: if they depend on ordering, then they probably don't depend on nextTick starvation
20:47:26  <ryah>it might be worthwhile to git log that test file and see if there are any issues
20:47:42  <isaacs>ryah: hey there :)
20:47:43  <ryah>i forget but it seems like there was some reason for making it..
20:47:50  <isaacs>ryah: how was europe?
20:47:58  <ryah>europey :)
20:48:06  <mjr_>I guess if we didn't have all of those uses of nextTick inside of node itself, then it probably matters less.
20:48:11  <bnoordhuis>you never rang :(
20:48:26  <ryah>europe tastes a bit like hairspray
20:48:55  <mjr_>ryah: Were the warning signs not in your language? Apparently you aren't supposed to eat it.
20:49:12  <isaacs>mjr_: actually, this is a pretty common issue with the uses of nextTick in node itself.
20:49:38  <isaacs>mjr_: we really would be better off making nextTick's semantics "run immediately at the end of this tick"
20:50:45  <bnoordhuis>isaacs: at the end of this tick or at the start of the next tick?
20:50:46  <ryah>"Test provided by Matt Ranney" in git log test/simple/test-next-tick-ordering.js
20:51:02  <isaacs>bnoordhuis: at the end of this one.
20:51:09  <bnoordhuis>simple/test-next-tick-ordering passes, it's simple/test-next-tick-ordering2 that's problematic
20:51:47  <isaacs>bnoordhuis: when we use nextTick in node, it's to give the user a chance to assign event handlers before taking some actions, but we always expect nextTick to happen before any IO has a chance to occur.
20:51:52  <isaacs>but in practice, it doesn't always.
20:52:08  <isaacs>that's the source of some of the problems that we were seeing in the http client
20:52:12  <isaacs>*http agent
20:52:21  <mjr_>My dear friend http agent.
20:52:30  <isaacs>or at least, it made them a lot harder to track down and debug than they should've been.
20:52:49  <ryah>the problem is when people add more nextTicks in their nextTick
20:53:08  <ryah>then you spin in at the end of tick
20:53:08  <CIA-155>libuv: Ben Noordhuis master * r5fd2c40 / (src/unix/core.c src/unix/stream.c): unix: fix up asserts in core.c and stream.c - http://git.io/43U0GQ
20:53:09  <CIA-155>libuv: Ben Noordhuis master * re71495c / (4 files in 2 dirs): unix: turn field stream->blocking into a flag - http://git.io/F9cpPA
20:53:20  <isaacs>ryah: right, so then you have the choice to either end up with starvation, or delay those until the next tick
20:53:27  <isaacs>ryah: but i mean, it's pretty easy to work around, right?
20:53:50  <isaacs>ryah: we just say that nextTicks added in the end-of-tick phase are not processed immediately
20:53:57  <avalanche123>bnoordhuis https://gist.github.com/e84988e93a427a10c535 when I run gyp with shared_library
20:54:09  <avalanche123>bnoordhuis ideas?
20:54:10  <ryah>but what if the i/o multiplexer call blocks?
20:54:15  <isaacs>pluck the array off, put a new array there, process the one you plucked off
20:54:17  <avalanche123>brb
20:54:34  <ryah>then the nexttick doens't happen for a while
20:54:40  <ryah>until something wakes up epoll
20:54:58  * travis-cijoined
20:54:59  <travis-ci>[travis-ci] joyent/libuv#314 (master - e71495c : Ben Noordhuis): The build passed.
20:54:59  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b69f8ef...e71495c
20:54:59  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1415732
20:54:59  * travis-cipart
20:55:07  <ryah>*shrug*
20:55:07  <isaacs>or we just say, fuck it, next ticks can starve the event loop, don't do that.
20:55:12  <bnoordhuis>avalanche123: probably means you need to link against the proper lib in uv.gyp
20:55:33  <mjr_>I think you can starve the event loop in so many ways already, so who cares.
20:55:33  <isaacs>but what we have now is a little bit too complicated i think
20:55:39  <ryah>isaacs: normally i'd agree with you - but i think there might be valid reasons for having a nextTick in your nextTick
20:55:46  <isaacs>yeah, i mean, it's no worse than a while(true), right?
20:55:54  <ryah>(so you can postpone while you postpone)
20:55:57  <isaacs>there are definitely valid reasons for a nextTick in a nextTick
20:56:02  <mjr_>It would be excellent if nextTick was guaranteed to run before any more IO could happen.
20:56:18  <bnoordhuis>mjr_: how so?
20:56:36  <mjr_>To give people a chance to set up event handlers and not miss anything.
20:56:36  <isaacs>but in those cases, you actually want to get in before any IO
20:57:17  <isaacs>this should work: net.createServer(function (sock) { process.nextTick(function () { socket.on('data', handler) }) })
20:57:21  <isaacs>and not miss any chunks ever.
20:57:24  <mjr_>This is why we use nextTick in our code, and I'm not sure how else to reliably do that.
20:57:50  <isaacs>as it stands, you mostly miss zero chunks, until you miss one
20:58:08  <isaacs>if it always was too slow, or always reliable, either would be fine.
20:58:21  <isaacs>ie, setTimeout pretty much will always miss a chunk
20:58:42  <isaacs>but nextTick *mostly* works there, which is really bad, because it's not 100%
20:58:52  <mjr_>setTimeout can have no rules IMO. Nobody ever made any promises about that.
20:59:04  <isaacs>mjr_: we actually guarantee at least 1ms or something now
20:59:07  <isaacs>just like web browsers.
20:59:13  <isaacs>so, it *always* delays
20:59:17  <mjr_>Or your money back.
20:59:23  <isaacs>yep. 100% refund :)
20:59:33  <AvianFlu>refunds available at /dev/null 24 hours a day
21:00:21  <mjr_>Could occasionally missing a data event explain these "Parse Errors" that we get all the time?
21:00:24  <avalanche123>bnoordhuis static library is building fine, just but shared gives that error from above
21:01:01  <bnoordhuis>avalanche123: you may have to add -fPIC to cflags and ldlfags
21:01:13  <mjr_>isaacs: these Parse Errors come from http parser, and they started happening after all of the parser leak fixes.
21:01:23  <avalanche123>ah, thanks
21:01:39  <isaacs>mjr_: is that still happening in 0.6.18?
21:01:42  <mjr_>oh yes
21:02:09  <isaacs>mjr_: do you know if the parse error is a client or server?
21:02:52  <mjr_>server
21:03:02  <isaacs>mjr_: well, that's fascinating.
21:03:16  <isaacs>mjr_: because the memleak fixes were 100% client.
21:03:20  <isaacs>mjr_: But! your clients are node.
21:03:41  <isaacs>mjr_: so, i wonder if the memleak fixes cause the node clients to shut down sockets a bit more roughly, perhaps?
21:03:50  <mjr_>hard to say
21:04:34  <mmalecki>we were getting "Parse Errors" too, but 0.6.18 fixed them
21:04:54  <mjr_>https://skitch.com/mranney/8hf41/search-search-splunk-4.3beta
21:05:48  <mjr_>mmalecki: Parse Error from the server?
21:05:50  <ryah>wow! splunk looks awesome
21:06:10  <mjr_>Splunk is pretty fantastic.
21:06:14  <ryah>how long does it take to perform that query?
21:06:19  <mjr_>Just a few seconds.
21:06:25  <mmalecki>mjr_: yeah, from the server
21:06:35  <mjr_>Results are delivered progressively, so it's a very pleasant experience.
21:21:26  <isaacs>mjr_: do you know where the results are coming from? are they another node server?
21:21:42  <mjr_>isaacs: impossible to say, unfortunately.
21:22:05  <isaacs>mjr_: i'd be surprised if they were coming from somewhere else, and new since 0.6.18
21:22:12  <isaacs>mjr_: since we didn't change the server.
21:22:14  <mjr_>I guess I could stash a flag from each request on the socket or something.
21:23:12  <mjr_>Unless you can think of anything obvious, I'm content to just let these simmer in their own juices until we can move to 0.7.
21:36:28  * loladirojoined
21:36:47  <isaacs>mjr_: i cannot think of anything obvious
21:36:54  <isaacs>mjr_: but the juices will simmer until 0.9, i'm afraid.
21:37:07  <isaacs>mjr_: 0.8 is a few weeks away only
21:37:15  <mjr_>excellent
21:37:32  <mjr_>If it's still happening on 0.8, perhaps we can dig into it then.
21:37:34  <isaacs>mjr_: and this recent experience with lib/http.js has left me convinced that http needs a major housecleaning
21:37:39  <isaacs>mjr_: it's so so grimy
21:37:43  * paddybyersquit (Quit: paddybyers)
21:37:47  <mjr_>Yeah, client and server are not the same.
21:37:57  <isaacs>right
21:38:02  <mjr_>In spite of the fact that it sounds sooo convenient to make them the same.
21:38:19  <isaacs>http is the land of failed dreams.
21:40:36  <mmalecki>hm, we've seen another interesting crash on our load balancers
21:40:58  <mmalecki>seems like it's a race condition of some kind, it's hard to reproduce
21:41:17  <mjr_>That sounds familiar.
21:41:32  <mmalecki>basically, req.connection.remoteAddress sometimes shows up as undefined
21:42:06  <mjr_>on incoming https?
21:42:43  <mmalecki>probably, we're not logging that
21:43:17  <mjr_>Do we still have this req.socket.socket.remoteAddress business with incoming https?
21:43:18  <mmalecki>although I was able to reproduce with websocket connection on http
21:45:00  * pieternquit (Read error: Connection reset by peer)
21:45:36  * pieternjoined
21:48:08  * ira_joined
21:48:26  <CIA-155>libuv: Ben Noordhuis master * rcff2221 / (4 files in 2 dirs): unix: split up loop.c - http://git.io/5wFcdw
21:50:16  * travis-cijoined
21:50:16  <travis-ci>[travis-ci] joyent/libuv#315 (master - cff2221 : Ben Noordhuis): The build passed.
21:50:16  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/890d443...cff2221
21:50:16  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1416297
21:50:16  * travis-cipart
22:06:46  * mmaleckiquit (Quit: leaving)
22:07:55  * AvianFluquit (Quit: Leaving)
22:08:54  <piscisaureus_>bnoordhuis: I like how uv-unix is starting to look like uv-win more and more
22:09:08  <piscisaureus_>bnoordhuis: who knows, we might be able to share uv_run once :-)
22:09:38  <avalanche123>piscisaureus_ bnoordhuis btw would be cool if you could add cross-platform way of creating named pipes to libuv
22:09:55  <piscisaureus_>ummmmmmmmmmm
22:10:07  <piscisaureus_>there already is, right :-)
22:10:24  <avalanche123>there is mkfifo on unix and CreateFile on win right
22:10:45  <avalanche123>I can open it once I have a file descriptor using libuv but I need to get it somewhere
22:11:01  <piscisaureus_>avalanche123: oh, does it matter for you that the pipe is actually an unix socket?
22:11:06  <piscisaureus_>and bidirectional?
22:11:39  <avalanche123>that's fine, I love that part
22:11:47  <avalanche123>but why is there uv_pipe_open?
22:12:01  <piscisaureus_>avalanche123: in the case that stdin or stdout is a pipe
22:12:06  <piscisaureus_>we need to wrap it in a pipe handle
22:12:06  <avalanche123>ah
22:12:19  <piscisaureus_>avalanche123: but you can do the same as with tcp
22:13:02  <piscisaureus_>e.g. uv_pipe_init(pipe1), uv_pipe_bind(pipe1, name_), uv_listen(pipe1) <-- there you go, a pipe server
22:14:27  <avalanche123>piscisaureus_ right, I have that part working :)
22:14:43  <avalanche123>so open is just for stdio
22:14:46  <avalanche123>?
22:14:49  <piscisaureus_>ye
22:14:50  <piscisaureus_>s
22:15:10  <piscisaureus_>avalanche123: to connect to a named pipe you use the same riddle but connect instead of listen
22:15:34  <avalanche123>yeah, makes sense
22:16:33  <avalanche123>in the bindings I'm writing I didn't like boolean ipc in uv_pipe_init, so I split up domain sockets into IPC and named pipes into Pipe classes
22:16:35  <avalanche123>https://github.com/avalanche123/uvrb/blob/master/features/pipe.feature
22:16:41  <avalanche123>https://github.com/avalanche123/uvrb/blob/master/features/ipc.feature
22:17:14  <avalanche123>to emphasize the unidirectionality of communication in case of latter and bi-directionality in case of former
22:17:41  <piscisaureus_>avalanche123: in
22:17:51  <piscisaureus_>avalanche123: I think they are bidi in all cases
22:18:13  <avalanche123>oh, I should try that, I though you could either write or read on a pipe
22:18:17  * rendarquit
22:18:24  <piscisaureus_>avalanche123: well, that's true on some unices
22:18:36  <piscisaureus_>avalanche123: and on windows, depending on the settings you created the pipe with
22:18:58  <piscisaureus_>avalanche123: but libuv actually creates a unix sockets which are bidi
22:19:19  <avalanche123>piscisaureus_ what is ipc option for in uv_pipe_init?
22:19:25  <piscisaureus_>avalanche123: and on windows we use bidi pipes (unless you're *connecting* to an existing pipe that's unidirectional)
22:19:41  <piscisaureus_>avalanche123: the ability to send handles to another process
22:19:56  * mjr_quit (Quit: mjr_)
22:20:01  <avalanche123>like using a fork?
22:20:05  <piscisaureus_>avalanche123: so 2 processes can share a tcp server handle
22:20:08  <piscisaureus_>avalanche123: yes
22:20:11  <avalanche123>oh
22:20:19  <avalanche123>I totally misunderstood that part
22:20:23  <piscisaureus_>avalanche123: on unix this uses unix sockets and SCM_RIGHTS messages
22:20:51  <piscisaureus_>avalanche123: on windows it's a special protocol that only libuv understands... so you probably want IPC *off* unless you really know what you're doing
22:21:00  <avalanche123>I see
22:21:01  <avalanche123>what happens if I don't specify that option and bind to the same file from a different process?
22:21:13  <avalanche123>or rather specify that option as false/0
22:21:27  * c4miloquit (Remote host closed the connection)
22:21:39  <piscisaureus_>what do you mean?
22:22:13  <avalanche123>well I uv_pipe_init(loop, handle, 0), uv_pipe_bind(handle, '/tmp/file.ipc')
22:22:29  <avalanche123>from two processes in parallel
22:22:37  <piscisaureus_>you'll get EADDRINUSE
22:22:41  <avalanche123>gotcha
22:22:51  <avalanche123>but with ipc that will work?
22:22:55  <piscisaureus_>no
22:23:07  <avalanche123>so only using fork()?
22:23:13  <piscisaureus_>with ipc you can create a tcp_t handle and listen etc
22:23:28  <piscisaureus_>then you can uv_tcp_write2 to send a message *and* the handle to the other process
22:23:57  <piscisaureus_>so uv_write2(ipc_handle. "hi, here's a tcp server that we can share", tcp_handle)
22:24:23  <avalanche123>and they both bind on that tcp handle transparently?
22:24:58  <piscisaureus_>avalanche123: well you have to do the bind() in one of the processes before you send it to the other process
22:25:04  <avalanche123>right
22:25:09  <piscisaureus_>and then you can do uv_listen(tcp_handle) in *both* processes
22:25:26  <avalanche123>and kernel will do balancing?
22:25:27  <piscisaureus_>and incoming connections will be distributed over those two processes
22:25:29  <piscisaureus_>yes
22:25:32  <avalanche123>wow
22:25:36  <avalanche123>this is really cool
22:27:09  <avalanche123>so this is done by the kernel itself or inside libuv?
22:28:12  <ryah>avalanche123: kernel
22:28:27  <avalanche123>this is so cool :)
22:28:40  <avalanche123>does node use this?
22:28:46  <ryah>yes
22:29:00  <ryah>require('cluster')
22:29:01  <avalanche123>some kind of process pooling?
22:29:04  <avalanche123>ah
22:29:04  <avalanche123>right
22:29:06  <avalanche123>hot
22:32:18  <bnoordhuis>piscisaureus_: that reminds me, what's the status on that relaxed accept patch?
22:32:24  <bnoordhuis>you were going to test it, right?
22:33:52  * avalanche123quit (Quit: Computer has gone to sleep.)
22:34:02  <piscisaureus_>bnoordhuis: it's running in production at cloud9. Seems to work just fine
22:34:28  <bnoordhuis>piscisaureus_: okay. so what's next? merge into node?
22:35:05  <piscisaureus_>hmm it's not running in production it seems
22:35:14  <piscisaureus_>but zef told me it is working fine
22:35:47  <piscisaureus_>bnoordhuis: it will be put life in a week or so then - so maybe we can put it off until then
22:35:58  <piscisaureus_>bnoordhuis: but I really don't dig the env flag
22:36:20  <piscisaureus_>bnoordhuis: we should just have something like socket.setRelaxedAccept(true)
22:36:37  <piscisaureus_>and have cluster enable that by default
22:38:50  <bnoordhuis>i don't want to have it on by default, it's got a pretty dramatic impact on the throughput
22:39:24  <piscisaureus_>like, how much?
22:39:25  * TheJHquit (Ping timeout: 252 seconds)
22:39:49  <bnoordhuis>piscisaureus_: i saw a 15% drop-off on the clustered http_simple benchmark
22:40:08  <piscisaureus_>bnoordhuis: that would much surprise me
22:40:40  <piscisaureus_>I suppose that is because that one doesnt doe much io
22:40:45  <piscisaureus_>s/doe/do/
22:40:56  <bnoordhuis>try it for yourself
22:42:53  <piscisaureus_>bnoordhuis: can we then use an option on the Server object ?
22:43:10  <piscisaureus_>I suppose that's not so easy since the status of that flag needs to be propagated to all processes
22:43:15  <bnoordhuis>http://www.groklaw.net/article.php?story=20120523125023818 - "Today’s jury verdict that Android does not infringe Oracle’s patents was a victory not just for Google but the entire Android ecosystem."
22:43:39  <bnoordhuis>piscisaureus_: yeah. that's why the env var is so darn convenient :)
22:44:06  <piscisaureus_>yeah but that's also what makes it near unusable for people who actually deploy node server
22:44:22  <bnoordhuis>why?
22:45:32  <piscisaureus_>because if you run some sort of service manager a la forever, or if you have a paas provider that lets you do git deploy...
22:45:43  <piscisaureus_>there usually is no easy way to specify that
22:46:16  <piscisaureus_>if it is a function call then you can just add that to your code
22:46:58  <piscisaureus_>bnoordhuis: I will look into it. The 15% dropoff surprises me a lot, there must be an explanation for that
22:47:32  <piscisaureus_>bnoordhuis: you just told me your event loop can do 300k rounds per second, so having 1 extra iteration per connection should definitely to cause such a steep dropoff
22:48:15  <piscisaureus_>bnoordhuis: I am not sure, but it could also be that epoll doesn't suffer from this issue as much as event ports do
22:48:41  <piscisaureus_>where "this issue" == poor load balancing
22:48:52  <bnoordhuis>that wouldn't surprise me :)
22:50:02  <piscisaureus_>bnoordhuis: let's try at that umcats thing isaacs provided tomorrow
22:50:35  <bnoordhuis>piscisaureus_: wut?
22:50:51  <piscisaureus_>bnoordhuis: that smartmachine
22:50:59  <bnoordhuis>oh, like that
22:51:16  <bnoordhuis>'provided tomorrow'
22:51:25  <piscisaureus_>insert comma
23:00:05  * iraquit (Disconnected by services)
23:00:05  * ira_changed nick to ira
23:12:47  <piscisaureus_>design question:
23:12:47  <piscisaureus_>#define UV_SIGTERM everywhere?
23:12:47  <piscisaureus_>or #define SIGTERM (SIGSEGV + 1) on windows ?
23:12:50  <piscisaureus_>I like neither
23:12:59  <bnoordhuis>me too
23:13:19  <bnoordhuis>what are you trying to do?
23:13:40  <piscisaureus_>bnoordhuis: fixup runner-mei's uv_signal patch
23:13:47  <piscisaureus_>and get it landed at some point :-)
23:13:54  <bnoordhuis>software archeology!
23:14:02  <piscisaureus_>yes
23:14:28  <piscisaureus_>but i like to get this in
23:14:40  <piscisaureus_>so process.on('SIGINT') no longer crashes node :-)
23:15:54  <piscisaureus_>Error: No such module
23:15:54  <piscisaureus_> at EventEmitter.<anonymous> (node.js:392:27)
23:16:30  <piscisaureus_>bnoordhuis: now suppose that you are in guantanamo bay and while being water boarded this agent asks you this question
23:16:39  <piscisaureus_>what would you answer?
23:17:00  <bnoordhuis>'definitely maybe'
23:17:51  <bnoordhuis>or if i was feeling cheeky: 'thank you, sir! may i have another?'
23:18:02  <piscisaureus_>No he did't ask you which movie you were watching yesterday
23:18:43  <piscisaureus_>bnoordhuis: ok that means that I will pick one
23:19:05  <bnoordhuis>piscisaureus_: #ifndef SIGTERM #define SIGTERM 15 #endif
23:19:20  <piscisaureus_>bnoordhuis: why 15?
23:19:29  <bnoordhuis>because it's always 15
23:19:40  <piscisaureus_>oh, that helps :-0
23:19:44  <piscisaureus_>really?
23:19:47  <bnoordhuis>yes
23:19:55  <piscisaureus_>_O_EXCL is always something else it seems :-/
23:20:14  <piscisaureus_>that is probably a windows-ism. I mean O_EXLC
23:20:14  <bnoordhuis>almost everything is different across unices
23:20:17  <bnoordhuis>but not SIGTERM
23:20:23  <piscisaureus_>other signals?
23:20:26  <piscisaureus_>SIGWINCH ?
23:20:52  <bnoordhuis>no, that varies quite a bit
23:21:04  <bnoordhuis>SIGINT is probably always 2
23:21:17  <bnoordhuis>and SIGKILL probably always 9
23:21:29  <ryah>signals are the worst thing about unix
23:21:54  <piscisaureus_>bnoordhuis: so that doesn't work. I have to define a couple of those
23:22:01  <piscisaureus_>ryah: you're alive :-0
23:22:08  <ryah>mildly
23:22:23  <piscisaureus_>ryah: what's up?
23:23:49  <ryah>nothing
23:24:16  <ryah>back from europe. i like london. i might move there.
23:25:23  <bnoordhuis>eh, london
23:25:26  <piscisaureus_>ryah: another city every month
23:25:28  <bnoordhuis>i guess it's nice but it's no gouda
23:28:52  <piscisaureus_>ryah: so are you doing anything interesting these days?
23:30:19  * benviequit
23:31:20  <ryah>but they have gouda in london
23:31:24  <ryah>so that makes up for it
23:31:42  <ryah>piscisaureus_: no
23:32:14  <piscisaureus_>ryah: is that deliberate or it just didn't happen?
23:32:33  * mikealquit (Quit: Leaving.)
23:33:07  <piscisaureus_>ryah: I had expected that you'd be bored after a couple of months of not doing anything interesting but apparently you have great stamina
23:33:11  <ryah>just happened
23:34:30  <piscisaureus_>sad
23:34:41  <piscisaureus_>you're supposed to come up with something mind blowing
23:35:58  <bnoordhuis>i would like a self-driving car
23:36:20  <bnoordhuis>i'll settle for cheap teleportation
23:37:17  <isaacs>ryah: you should write a language that compiles to JS
23:37:51  <isaacs>not because we need one of those, but it'd be funny.
23:38:01  <isaacs>entertainment driven development
23:38:28  <bnoordhuis>or the other way around
23:38:33  <bnoordhuis>a js-to-coffeescript compiler
23:38:43  <isaacs>bnoordhuis: there's already one of those
23:38:53  <isaacs>bnoordhuis: its primary use case is github trolling
23:39:07  <bnoordhuis>hah, now that you mention it
23:42:45  <piscisaureus_>you should do a benchmark that shows that coffeescript is 2x as fast as javascript
23:43:15  * ryahquit (Ping timeout: 250 seconds)
23:43:52  <isaacs>HAhahah
23:43:53  <isaacs>that'd be great
23:44:23  <isaacs>maybe start off by saying "These aren't rigorous benchmark numbers, so don't read much into them" and then finish with "I think the numbers pretty much speak for themselves."
23:44:55  <bnoordhuis>i sense a little grudge :)
23:46:58  <piscisaureus_>maybe you should write a vm for io language
23:47:05  <piscisaureus_>because I like io language
23:47:53  <bnoordhuis>interesting question, what's missing in today's languages?
23:48:08  <piscisaureus_>but id is too slow
23:49:11  <isaacs>yes
23:49:18  <piscisaureus_>they are not made for the 128 core processor age
23:49:32  <isaacs>i think js is pretty good for doing streaming/async io, but it could be a lot better.
23:57:54  * mikealjoined
23:59:03  * piscisaureus_quit (Read error: Connection reset by peer)
23:59:51  * piscisaureus_joined