| 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
| * mmalecki | quit (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
| * mikeal | quit (Quit: Leaving.) |
| 00:58:00
| * mikeal | joined |
| 01:24:32
| * pietern | quit (Quit: pietern) |
| 01:26:23
| * erickt | quit (Ping timeout: 265 seconds) |
| 01:38:38
| * mikeal | quit (Quit: Leaving.) |
| 01:47:35
| * brson | quit (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-ci | joined |
| 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-ci | part |
| 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
| * pietern | joined |
| 02:12:50
| * avalanche123 | joined |
| 02:26:50
| * mattstevens | joined |
| 02:28:17
| * mjr_ | quit (Quit: mjr_) |
| 02:43:19
| * bnoordhuis | quit (Ping timeout: 245 seconds) |
| 02:52:20
| * pietern | quit (Quit: pietern) |
| 03:14:24
| * ira | quit (Quit: Computer has gone to sleep.) |
| 03:21:16
| * mattstevens | quit (Quit: mattstevens) |
| 03:34:40
| * AlbireoX | changed nick to AlbireoX`Away |
| 03:35:43
| * perezd | joined |
| 03:56:16
| * c4milo | quit (Remote host closed the connection) |
| 04:00:56
| * pietern | joined |
| 04:10:00
| * erickt | joined |
| 05:37:56
| * erickt | quit (Quit: erickt) |
| 05:52:18
| * pietern | quit (Quit: pietern) |
| 06:09:18
| * avalanche123 | quit (Ping timeout: 240 seconds) |
| 06:21:31
| * mikeal | joined |
| 06:43:30
| * paddybyers | joined |
| 06:47:50
| * avalanche123 | joined |
| 06:47:57
| * avalanche123 | quit (Client Quit) |
| 06:55:37
| * rendar | joined |
| 07:03:29
| * paddybyers | quit (Ping timeout: 276 seconds) |
| 07:27:26
| * mmalecki | joined |
| 07:53:04
| * paddybyers | joined |
| 09:23:13
| * indexzero | joined |
| 09:59:58
| * TheJH | joined |
| 10:22:42
| * TheJH | quit (Ping timeout: 244 seconds) |
| 10:32:09
| * bnoordhuis | joined |
| 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-ci | joined |
| 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-ci | part |
| 11:14:24
| * piscisaureus_ | joined |
| 11:26:33
| * ira | joined |
| 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-ci | joined |
| 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-ci | part |
| 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
| * c4milo | joined |
| 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
| * TheJH | joined |
| 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
| * c4milo | quit (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
| * abraxas | quit (Remote host closed the connection) |
| 13:20:07
| * abraxas | joined |
| 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
| * TheJH | quit (Ping timeout: 248 seconds) |
| 13:21:14
| * c4milo | joined |
| 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
| * abraxas | quit (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-ci | joined |
| 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-ci | part |
| 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
| * bnoordhuis | is 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
| * ibc | quit (Remote host closed the connection) |
| 14:13:39
| * TheJH | joined |
| 14:14:59
| <piscisaureus_> | I wonder if there would be any benefit in using aio_write for socket writes on solaris |
| 14:19:11
| * erickt | joined |
| 14:55:44
| * isaacs | joined |
| 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
| * pietern | joined |
| 15:04:19
| * erickt | quit (Quit: erickt) |
| 15:21:37
| * TheJH | quit (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
| * TheJH | joined |
| 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
| * ibc | joined |
| 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
| * TheJH | quit (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
| * avalanche123 | joined |
| 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
| * erickt | joined |
| 16:29:22
| * perezd | quit (Quit: perezd) |
| 16:57:46
| * ibc | quit (Remote host closed the connection) |
| 17:16:04
| * brson | joined |
| 17:18:29
| * erickt | quit (Quit: erickt) |
| 17:23:29
| * perezd | joined |
| 17:24:23
| * brson_ | joined |
| 17:24:24
| * brson | quit (Quit: leaving) |
| 17:24:39
| * AvianFlu | joined |
| 17:30:17
| * TheJH | joined |
| 17:30:56
| * TheJH | quit (Read error: Connection reset by peer) |
| 17:33:09
| * TheJH | joined |
| 17:41:04
| * avalanche123 | quit (Quit: Computer has gone to sleep.) |
| 17:53:55
| * brson_ | quit (Quit: leaving) |
| 17:54:10
| * brson | joined |
| 17:54:22
| * erickt | joined |
| 18:07:20
| * pietern_ | joined |
| 18:09:05
| * pietern | quit (Ping timeout: 276 seconds) |
| 18:09:06
| * pietern_ | changed nick to pietern |
| 18:23:29
| * perezd | quit (Quit: perezd) |
| 18:24:04
| * AlbireoX`Away | changed nick to AlbireoX |
| 18:24:18
| * perezd | joined |
| 18:25:40
| * mjr_ | joined |
| 18:25:43
| * indexzero | quit (Quit: indexzero) |
| 18:27:42
| * TheJH | quit (Ping timeout: 248 seconds) |
| 18:33:50
| * TheJH | joined |
| 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
| * indexzero | joined |
| 18:37:09
| <bnoordhuis> | mmalecki: https://github.com/joyent/libuv/issues/426#issuecomment-5873824 <- how does that work? |
| 18:37:44
| * TheJH | quit (Read error: Operation timed out) |
| 18:38:02
| * travis-ci | joined |
| 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-ci | part |
| 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
| * avalanche123 | joined |
| 18:41:30
| * brson | quit (Quit: leaving) |
| 18:41:44
| * brson | joined |
| 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
| * mikeal | quit (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
| * mikeal | joined |
| 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-ci | joined |
| 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-ci | part |
| 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-ci | joined |
| 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-ci | part |
| 18:57:38
| * pietern | quit (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-ci | joined |
| 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-ci | part |
| 19:10:43
| * AvianFlu | quit (Read error: Operation timed out) |
| 19:11:52
| * pietern | joined |
| 19:15:35
| * AvianFlu | joined |
| 19:16:06
| * bulatshakirzyano | joined |
| 19:16:19
| * avalanche123 | quit (Ping timeout: 256 seconds) |
| 19:16:20
| * bulatshakirzyano | changed nick to avalanche123 |
| 19:18:53
| * avalanche123 | quit (Client Quit) |
| 19:20:16
| * avalanche123 | joined |
| 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-ci | joined |
| 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-ci | part |
| 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
| * TheJH | joined |
| 19:29:11
| * avalanche123 | quit (Quit: Computer has gone to sleep.) |
| 19:36:07
| * avalanche123 | joined |
| 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
| * avalanche123 | quit (Quit: Computer has gone to sleep.) |
| 19:46:35
| * kohai | quit (Remote host closed the connection) |
| 19:49:05
| * avalanche123 | joined |
| 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
| * indexzero | quit (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
| * indexzero | joined |
| 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-ci | joined |
| 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-ci | part |
| 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
| * loladiro | joined |
| 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
| * paddybyers | quit (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
| * pietern | quit (Read error: Connection reset by peer) |
| 21:45:36
| * pietern | joined |
| 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-ci | joined |
| 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-ci | part |
| 22:06:46
| * mmalecki | quit (Quit: leaving) |
| 22:07:55
| * AvianFlu | quit (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
| * rendar | quit |
| 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
| * c4milo | quit (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
| * avalanche123 | quit (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
| * TheJH | quit (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
| * ira | quit (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
| * benvie | quit |
| 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
| * mikeal | quit (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
| * ryah | quit (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
| * mikeal | joined |
| 23:59:03
| * piscisaureus_ | quit (Read error: Connection reset by peer) |
| 23:59:51
| * piscisaureus_ | joined |