16:45:08  <piscisaureus>tes
16:51:05  * saghulquit (Ping timeout: 252 seconds)
16:51:11  * calvinfoquit (Quit: Leaving.)
16:51:11  * avalanche123joined
16:52:46  * c4milojoined
16:57:37  * avalanche123quit (Remote host closed the connection)
16:58:04  * avalanche123joined
16:59:43  * Left_Turnjoined
17:00:31  * brsonjoined
17:01:15  * avalanch_joined
17:01:39  * avalanche123quit (Read error: Connection reset by peer)
17:04:22  * Ralithquit (Ping timeout: 240 seconds)
17:06:18  * hzjoined
17:06:50  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:08:10  <chrisdickinson>morning all
17:13:32  * quijotequit (Ping timeout: 245 seconds)
17:14:25  * saghuljoined
17:16:25  * quijotejoined
17:16:43  * daviddiasjoined
17:17:37  * djosephjoined
17:20:12  * hueniversequit (Ping timeout: 245 seconds)
17:21:10  * calvinfojoined
17:23:32  * rendarquit (Ping timeout: 245 seconds)
17:24:33  * daviddiasquit (Ping timeout: 240 seconds)
17:25:40  * c4miloquit (Remote host closed the connection)
17:29:12  * c4milojoined
17:29:38  * rendarjoined
17:34:36  <djoseph>it looks like signal watching in libuv is implemented by using signal handlers (via sigaction) + pipes - just curious, what was the motivation behind doing that vs something like kqueue with EVFILT_SIGNAL (freebsd) or signalfd (linux)?
17:35:15  * quijotequit (Ping timeout: 255 seconds)
17:43:33  * stagasquit (Ping timeout: 240 seconds)
17:43:41  * sblomjoined
17:44:47  * Ralithjoined
17:45:12  <saghul>djoseph: I didn't write it myself, but it could have been kernel support
17:47:02  * quijotejoined
17:49:03  * mrvisserjoined
17:53:30  <djoseph>saghul: could you elaborate? what do you mean by kernel support?
17:54:29  <saghul>djoseph: sigfd is only available in kernels >= 2.6.22, I believe we support older
17:54:55  <saghul>and there is SunOS
17:55:35  <bradleymeck>and OSX
17:55:39  <saghul>so far there was no need for a faster implementation, apparently :-)
17:56:00  <djoseph>Ah
17:56:22  * quijotequit (Ping timeout: 240 seconds)
17:56:24  <saghul>bradleymeck: on OSX kqueue's EVFILT_SIGNAL would do, I think
17:57:22  <bradleymeck>saghul: but then you have to do a if/else tree
17:58:01  <saghul>yep, well, we are a platform abstraction library, so the if-else tree is part of the business I guess xD
17:58:36  * ryancolejoined
17:58:56  * bajtosquit (Quit: bajtos)
18:04:44  <piscisaureus>ircretary: when tjfontaine
18:04:44  <ircretary>piscisaureus: tjfontaine was last seen at 2014-06-16T15:44:56.833Z, in #libuv saying but I'm in a better place now
18:07:15  * hzquit (Disconnected by services)
18:07:20  * hzjoined
18:07:48  * quijotejoined
18:15:07  * daviddiasjoined
18:15:11  * quijotequit (Ping timeout: 272 seconds)
18:19:53  <MI6>joyent/libuv: Saúl Ibarra Corretgé v0.10 * 12bb46c : windows: fix handling closed socket while poll handle is closing - http://git.io/WwFb5g
18:20:12  * c4miloquit (Remote host closed the connection)
18:25:18  <djoseph>There's no real way to add a kqueue/kevent to a libuv loop, is there? I assume not since that seems too specific for an abstracted library, but just checking…didn't see something I could use in uv.h
18:26:35  <djoseph>I wouldn't be able to use uv_poll (I'm on OSX), as I don't have signalfd (trying to watch a signal)
18:28:28  * yunongjoined
18:31:57  * a_lequit
18:38:35  * stagasjoined
18:38:47  <saghul>djoseph: you could try to create another kqueue and add it to the libuv loop using a uv_poll handle
18:38:56  <saghul>I haven't tried it myself though
18:40:46  * quijotejoined
18:41:55  * daviddiasquit (Ping timeout: 252 seconds)
18:45:12  * quijotequit (Ping timeout: 245 seconds)
18:50:21  * quijotejoined
18:50:25  <djoseph>hmm, might try that - thanks
18:53:20  * hzquit (Disconnected by services)
18:53:25  * hzjoined
18:56:59  * ryancolequit
19:11:36  * c4milojoined
19:15:37  <tjfontaine>piscisaureus: did you not get my email?
19:16:02  * quijotequit (Ping timeout: 245 seconds)
19:19:17  <piscisaureus>tjfontaine: somehow, no
19:19:25  <piscisaureus>tjfontaine: when did you send it?
19:20:50  <tjfontaine>my this morning
19:20:58  <tjfontaine>to your @gmail
19:21:17  <tjfontaine>it was 8:12 CDT
19:26:49  * calvinfoquit (Quit: Leaving.)
19:30:07  * a_lejoined
19:30:25  * mrvisserquit (Remote host closed the connection)
19:37:53  * daviddiasjoined
19:41:55  * daviddiasquit (Ping timeout: 240 seconds)
19:43:56  * daviddiasjoined
19:48:28  * daviddiasquit (Ping timeout: 260 seconds)
20:01:31  * c4miloquit (Remote host closed the connection)
20:06:36  * calvinfo1joined
20:08:25  * calvinfo1part
20:13:30  * quijotejoined
20:17:52  * quijotequit (Ping timeout: 240 seconds)
20:19:11  * seldo_quit (*.net *.split)
20:19:11  * djosephquit (*.net *.split)
20:19:11  * LOUDBOTquit (*.net *.split)
20:19:12  * seldoquit (*.net *.split)
20:19:12  * WalrusPony1quit (*.net *.split)
20:19:12  * CAPSLOCKBOTquit (*.net *.split)
20:19:12  * rjequit (*.net *.split)
20:19:12  * petka_quit (*.net *.split)
20:19:12  * shrubberyquit (*.net *.split)
20:19:12  * prettyrobotsquit (*.net *.split)
20:19:12  * guilleiguaran_quit (*.net *.split)
20:19:12  * jirwinquit (*.net *.split)
20:19:12  * pquernaquit (*.net *.split)
20:19:12  * brett19quit (*.net *.split)
20:19:13  * MI6quit (*.net *.split)
20:19:13  * rphillipsquit (*.net *.split)
20:19:13  * vigithquit (*.net *.split)
20:20:14  * djosephjoined
20:20:14  * seldo_joined
20:20:14  * LOUDBOTjoined
20:20:14  * petka_joined
20:20:14  * seldojoined
20:20:14  * WalrusPony1joined
20:20:14  * CAPSLOCKBOTjoined
20:20:14  * shrubberyjoined
20:20:14  * rjejoined
20:20:14  * prettyrobotsjoined
20:20:14  * vigithjoined
20:20:14  * rphillipsjoined
20:20:14  * MI6joined
20:20:14  * brett19joined
20:20:14  * pquernajoined
20:20:14  * jirwinjoined
20:20:14  * guilleiguaran_joined
20:24:43  * a_lequit (*.net *.split)
20:24:43  * rendarquit (*.net *.split)
20:24:43  * saghulquit (*.net *.split)
20:24:43  * avalanch_quit (*.net *.split)
20:24:43  * piscisaureusquit (*.net *.split)
20:24:43  * brucemquit (*.net *.split)
20:28:55  <kellabyte_>any tips on what I should look for with the multi-accept bug not working on windows but working on unix? I've spent a bunch of time trying to debug the code but still not sure what's wrong. I'm missing something. Any help would be great! I logged it here: https://github.com/joyent/libuv/issues/1302
20:29:43  <kellabyte_>any tips on what I should look for with the multi-accept bug not working on windows but working on unix? I've spent a bunch of time trying to debug the code but still not sure what's wrong. I'm missing something. Any help would be great! I logged it here: https://github.com/joyent/libuv/issues/1302
20:33:14  * daviddiasjoined
20:33:23  * saghuljoined
20:33:47  <kellabyte_>oops, sorry irccloud sent that twice lol
20:36:30  * a_lejoined
20:36:30  * rendarjoined
20:36:30  * avalanch_joined
20:36:30  * piscisaureusjoined
20:36:30  * brucemjoined
20:36:45  * avalanch_quit (Remote host closed the connection)
20:37:16  * avalanche123joined
20:41:22  * mrvisserjoined
20:41:33  * avalanche123quit (Ping timeout: 240 seconds)
20:45:55  * mrvisserquit (Ping timeout: 272 seconds)
20:46:00  * avalanche123joined
20:46:36  <bradleymeck>anyone know what release is multi-isolated targetted for
20:49:16  * dap_1joined
20:52:53  * dap_quit (Ping timeout: 272 seconds)
20:54:42  * avalanche123quit (Remote host closed the connection)
20:54:50  * c4milojoined
20:55:13  * avalanche123joined
21:01:20  * c4miloquit (Remote host closed the connection)
21:01:36  * c4milojoined
21:04:43  * piscisaureusquit (Ping timeout: 244 seconds)
21:14:23  * quijotejoined
21:16:06  <indutny>bradleymeck: ?
21:16:26  <bradleymeck>indutny: seen multi-isolates come up a few times in recent weeks
21:16:34  <bradleymeck>just wondering who/what is going on
21:16:44  <indutny>I don't think that there is much work on it
21:19:29  * quijotequit (Ping timeout: 272 seconds)
21:20:56  * a_lequit (Remote host closed the connection)
21:21:13  * a_lejoined
21:22:56  * a_le_joined
21:23:04  * a_lequit (Read error: Connection reset by peer)
21:28:39  <indutny>trevnorris
21:30:04  * rendarquit
21:34:19  * wolfeidaujoined
21:37:44  * wolfeidauquit (Remote host closed the connection)
21:38:04  * wolfeidaujoined
21:55:41  * quijotejoined
21:57:11  * wolfeidauquit (Remote host closed the connection)
22:00:28  * quijotequit (Ping timeout: 264 seconds)
22:00:54  * wolfeidaujoined
22:03:15  * ryancolejoined
22:05:42  * wolfeidauquit (Ping timeout: 255 seconds)
22:11:56  * hzquit
22:15:09  * Kakeraquit (Ping timeout: 255 seconds)
22:33:28  * ryancolequit (Ping timeout: 264 seconds)
22:34:42  * ryancolejoined
22:36:05  * daviddiasquit (Remote host closed the connection)
22:37:33  * stagasquit (Ping timeout: 240 seconds)
22:40:58  * ryancolequit
22:46:02  * avalanche123quit (Remote host closed the connection)
22:46:29  * avalanche123joined
22:48:52  * avalanche123quit (Read error: Connection reset by peer)
22:49:08  * avalanche123joined
22:56:38  * quijotejoined
22:56:42  * c4milo_joined
22:56:45  <trevnorris>bradleymeck: sup dude
22:56:50  * c4miloquit (Ping timeout: 244 seconds)
22:57:04  <bradleymeck>nm, you had questions about debugging multi-isolate stuff?
22:57:48  <trevnorris>not how to debug, more specifically how to build a debugger for an app that runs multiple scripts in different threads.
22:57:58  <trevnorris>1 app, many JS script
22:58:11  <bradleymeck>oh, well let me dig something up for ya
22:58:43  <trevnorris>like, you can halt and debug a single running script, but what about a more advanced debugger that would allow showing data flow between all the different threads.
23:01:03  * quijotequit (Ping timeout: 255 seconds)
23:01:08  <bradleymeck>trevnorris: https://gist.github.com/bmeck/e1577262267e064e0a84 gets you pausing each isolate, then you need to do some seriously fancy stuff via AccessControl + hooks ontop of uv's binding layer
23:01:48  <bradleymeck>trevnorris: out of band hijacking would be even better, but I don't want to implement GDB
23:03:10  <trevnorris>bradleymeck: i was using gdb's ability to step through and what not more as an example
23:03:24  <trevnorris>definitely don't want to tie this to gdb
23:04:33  <bradleymeck>well we can cleanly say things like, the isolate started processing ticks again, we should break. but we can't really say where the data it got came from w/o C++ API/libuv hooks
23:05:18  <trevnorris>yeah. figured writing something for this would be a beast.
23:05:44  <bradleymeck>well the origin yea, but its the same workflow actually as chromium is doing w/ async listeners
23:05:53  <bradleymeck>just instead of ticks, it is between threads
23:09:48  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * a098ac6 : unix, windows: return system error on EAI_SYSTEM - http://git.io/jdwXTA
23:10:08  <bradleymeck>s/async listeners/async stacktraces/
23:15:30  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * 6ffb82e : unix: don't run i/o callbacks after prepare callbacks - http://git.io/KFcHkw
23:15:50  <bradleymeck>trevnorris: on the plus side, it would be amazingly easy to do if whenever we do build an isolate bridge we just tack on the original isolate
23:16:03  <bradleymeck>less beastly, less powerful though
23:18:12  * mrvisserjoined
23:24:49  <trevnorris>bradleymeck: take the idea for a moment that there is no "original isolate". that, say, one isolate could spawn several others than bring itself down.
23:25:20  <trevnorris>or that you could initialize the application w/ several scripts, instead of just one.
23:30:04  * calvinfojoined
23:38:26  * janjongboomjoined
23:45:05  * piscisaureusjoined
23:47:48  * TooTallNatejoined
23:52:31  * wolfeidaujoined
23:57:08  * quijotejoined