00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:02  * avalanche123joined
00:00:09  * ircretaryjoined
00:23:42  * thlorenz_quit (Remote host closed the connection)
00:25:49  * AlexisMochaquit (Ping timeout: 265 seconds)
00:25:49  * AlexisMocha_joined
00:32:45  * rendarquit
00:33:10  * thlorenz_joined
00:36:44  <nathan7>Anyone want to give me a quick run-through of how the node IPC mechanism works?
00:37:46  * thlorenz_quit (Ping timeout: 256 seconds)
00:45:42  * avalanche123quit (Remote host closed the connection)
00:46:24  * inolenquit (Quit: Leaving.)
00:47:12  * inolenjoined
00:47:19  * inolenquit (Client Quit)
00:47:21  * avalanche123joined
00:52:05  * avalanche123quit (Ping timeout: 256 seconds)
00:52:15  * jgiquit (Quit: jgi)
00:58:07  * tylerantonquit (Quit: tyleranton)
00:58:54  * tylerantonjoined
01:13:35  * warehouse13joined
01:14:05  * inolenjoined
01:16:07  * Left_Turnquit (Ping timeout: 245 seconds)
01:16:22  * Ralithquit (Ping timeout: 240 seconds)
01:24:32  * thlorenz_joined
01:29:13  * thlorenz_quit (Ping timeout: 264 seconds)
01:29:48  * jgijoined
01:31:04  * brsonquit (Quit: leaving)
01:31:10  * jgiquit (Client Quit)
01:31:32  * brsonjoined
01:41:16  * Ralithjoined
01:46:40  * Tux64changed nick to Tux64_
01:50:44  * inolenquit (Quit: Leaving.)
01:51:28  * zjuquit (Read error: Connection reset by peer)
01:55:09  * inolenjoined
02:06:13  * dap_quit (Quit: Leaving.)
02:13:58  * inolenquit (Ping timeout: 252 seconds)
02:22:11  * brsonquit (Quit: leaving)
02:25:22  * thlorenz_joined
02:30:31  * thlorenz_quit (Ping timeout: 265 seconds)
02:43:32  * jgijoined
02:45:05  * jgiquit (Client Quit)
02:45:45  * inolenjoined
02:58:41  * avalanche123joined
03:05:02  * tylerantonquit (Quit: tyleranton)
03:05:33  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
03:16:33  * jgijoined
03:18:52  * thlorenz_joined
03:23:09  * octetcloudquit (Ping timeout: 245 seconds)
03:25:00  * jgiquit (Quit: jgi)
03:27:14  * avalanche123quit (Remote host closed the connection)
03:29:26  * thlorenz_quit (Remote host closed the connection)
03:34:19  * jgijoined
03:35:45  * inolenquit (Quit: Leaving.)
03:44:28  * thlorenz_joined
03:44:28  * jgiquit (Quit: jgi)
03:49:23  * thlorenz_quit (Ping timeout: 264 seconds)
03:49:23  * avalanche123joined
03:51:30  * jgijoined
03:52:00  * thlorenz_joined
03:52:36  * inolenjoined
03:52:54  * thlorenz_quit (Remote host closed the connection)
03:58:39  * avalanche123quit (Remote host closed the connection)
04:01:22  * avalanche123joined
04:04:49  * warehouse13quit (Remote host closed the connection)
04:09:18  * thlorenz_joined
04:13:43  * thlorenz_quit (Ping timeout: 252 seconds)
04:27:50  * inolenquit (Ping timeout: 256 seconds)
04:37:37  * imzyxwvujoined
04:41:00  * avalanche123quit (Remote host closed the connection)
04:44:44  * imzyxwvuquit (Ping timeout: 272 seconds)
04:53:29  * AlexisMocha_quit (Read error: Connection reset by peer)
05:07:23  * Ralith_joined
05:08:28  * miloj_joined
05:09:20  * milojquit (Quit: ZNC - http://znc.sourceforge.net)
05:09:21  * Ralithquit (Ping timeout: 240 seconds)
05:25:19  * Ralith_changed nick to Ralith
05:36:54  * AlexisMochajoined
05:37:16  <AlexisMocha>jgi: pong
05:38:27  * jgiquit (Quit: jgi)
05:41:25  * avalanche123joined
05:43:23  <Ralith>are uv_async events guaranteed to be delivered in order?
05:46:41  * avalanche123quit (Ping timeout: 246 seconds)
05:50:14  * Wraithanquit (Quit: WeeChat 1.0-dev)
05:50:47  * Wraithanjoined
06:16:12  * jgijoined
06:20:44  <jgi>AlexisMocha: I’d like to get your opinion on https://github.com/joyent/node/pull/9179#issuecomment-78386204
06:20:59  <jgi>AlexisMocha: also do you know if https://github.com/libuv/libuv/pull/238 will make it in before libuv 1.5.0?
06:22:41  <jgi>AlexisMocha: I’m going to sleep, but please leave a comment if you have some time!
06:22:46  <jgi>AlexisMocha: thank you and have a great day :)
06:22:51  <AlexisMocha>jgi: yes I am +1 for landing it with the extra floating patch, as it seems like the fastest way
06:22:51  * AvianFluquit (Remote host closed the connection)
06:22:52  <AlexisMocha>ok
06:23:01  <jgi>AlexisMocha: awesome
06:23:12  * Wraithanchanged nick to Wra1than
06:23:23  <AlexisMocha>jgi: have a good night!
06:23:28  <jgi>thanks!
06:23:34  <AlexisMocha>also do you know if https://github.com/libuv/libuv/pull/238 will make it in before libuv 1.5.0?
06:24:01  * Wra1thanchanged nick to Wraithan
06:24:06  <AlexisMocha>^ for this question, we'd have to ask saghul
06:28:29  * jgiquit (Quit: jgi)
06:36:04  * rmgquit (Remote host closed the connection)
06:44:03  * AlexisMochaquit (Read error: Connection reset by peer)
06:57:39  * bajtosjoined
07:07:49  * SergeiRNDjoined
07:36:52  * rmgjoined
07:41:22  * rmgquit (Ping timeout: 240 seconds)
07:59:05  * zjujoined
07:59:35  * ircretaryquit (Ping timeout: 252 seconds)
08:33:09  * daviddiasjoined
08:33:24  * daviddiasquit (Client Quit)
08:47:30  * kevinsimperjoined
08:52:18  <saghul>nathan7: sill want the IPC thing?
08:52:38  <saghul>Ralith: you mean calls to uv_async_send? No, because they are coalesced
08:53:07  <saghul>Ralith: see the warning here: http://docs.libuv.org/en/v1.x/async.html#c.uv_async_send
08:53:13  <saghul>trevnorris: norry, timezones...
09:22:37  * kevinsimperquit (Remote host closed the connection)
09:58:07  * kevinsimperjoined
10:00:05  * rendarjoined
10:00:17  * seishunjoined
10:09:30  * Left_Turnjoined
10:23:44  * chris_99joined
10:32:15  * bajtosquit (Quit: bajtos)
10:35:48  * kevinsimperquit
10:46:22  * Left_Turnquit (Ping timeout: 272 seconds)
10:47:36  * SergeiRNDquit (Quit: Leaving.)
10:51:45  * zju3joined
10:51:47  * zju4joined
10:53:10  * zjuquit (Ping timeout: 256 seconds)
10:53:40  * zju1quit (Ping timeout: 265 seconds)
11:24:42  * SergeiRNDjoined
11:30:46  * nickleeflyjoined
11:37:16  * Left_Turnjoined
12:24:26  * bajtosjoined
12:26:19  * Kanaliajoined
12:26:22  <Kanalia>hi guys
12:27:16  <Kanalia>I'm looking into using a RPC library which depends on libuv
12:27:28  <Kanalia>does libuv currently support mac os x or iOS as a build target?
12:28:14  <Kanalia>ah sorry, I see on the official github page that Mac OS X is supported already, what about iOS or Android?
12:29:09  <Kanalia>ok, I see Android also on said page, iOS isn't mentioned, should I assume that if it compiles OK for OS X that libuv should also play nice on iOS devices?
12:33:24  <Kanalia>OK, I've looked through more deeply through github and now I see that cross-compiling to iOS is supported
12:34:19  <saghul>Kanalia: iOS and Android are both supported
12:35:50  * AvianFlujoined
12:38:13  <Kanalia>cool, thanks saghul
12:58:22  * bajtosquit (Quit: bajtos)
13:05:05  * lance|afkchanged nick to lanceball
13:14:25  * toothrotquit (Ping timeout: 256 seconds)
13:34:50  * nickleeflyquit (Quit: Connection closed for inactivity)
13:50:56  * thlorenz_joined
14:00:55  * inolenjoined
14:12:03  * Fishrock123joined
14:17:18  * benjamingrquit (Quit: Connection closed for inactivity)
14:24:32  * AlexisMochajoined
14:44:31  <nathan7>saghul: yeah
14:44:41  <nathan7>saghul: I have to get my ass to work, but yes
14:58:07  * seishunquit (Remote host closed the connection)
15:02:22  * avalanche123joined
15:03:01  <txdv>Kanalia: what rpc library?
15:07:48  <Kanalia>txdv: https://github.com/w359405949/libmaid
15:10:15  * SergeiRNDquit (Quit: Leaving.)
15:12:31  * rmgjoined
15:20:01  * thlorenz_changed nick to thlorenz
15:20:37  <txdv>that nickname
15:20:53  <txdv>who does that
15:23:52  <Kanalia>txdv: I dunno, crazy dev it seems :)
15:25:29  * seishunjoined
15:27:35  * jgijoined
15:31:56  <Ralith>saghul: I mean calls to uv_async_send on different uv_async_ts from the same thread
15:40:28  <Ralith>(and targeting the same event loop, on a different thread(
15:41:24  <trevnorris>saghul: finished the interface in libnub to queue callbacks to be run on the event loop thread, from a spawned thread, and wanted some feedback if your game.
15:45:50  * lanceballchanged nick to lance|afk
15:53:39  * bajtosjoined
15:54:25  * dap_joined
15:55:53  * octetcloudjoined
15:59:24  * Kanaliaquit
16:00:04  * Damn3dquit (Ping timeout: 252 seconds)
16:01:08  <srl295>tjfontaine: jgi: on another call but will switch over shortly
16:01:15  <jgi>srl295: ok
16:02:20  <tjfontaine>https://plus.google.com/hangouts/_/nodejs.org/weekly-status
16:04:07  * Damn3djoined
16:14:35  * brsonjoined
16:15:48  <txdv>trevnorris: an example would be nice?
16:16:16  <txdv>tjfontaine: can i join the call to listen what you are discussing?
16:18:08  <jgi>txdv: yep
16:18:08  <trevnorris>txdv: sure. should be abje to jump in.
16:24:28  * bajtosquit (Quit: bajtos)
16:25:32  * thlorenzquit (Remote host closed the connection)
16:29:27  * thlorenzjoined
16:32:15  * papajuansjoined
16:32:20  * inolenquit (Quit: Leaving.)
16:40:23  * thlorenzquit (Remote host closed the connection)
16:40:59  * thlorenzjoined
16:45:13  * thlorenzquit (Ping timeout: 256 seconds)
16:45:57  * thlorenzjoined
16:47:22  * tparjoined
16:47:54  <tpar>on my libuv application exit I'm seeing valgrind errors like this when I run with --track-fds=yes:
16:48:09  <tpar>==14465== at 0x55763E9: syscall (syscall.S:38)
16:48:09  <tpar>==14465== by 0x5869A2D: uv__pipe2 (linux-syscalls.c:377)
16:48:09  <tpar>==14465== by 0x585C3A4: uv__make_pipe (process.c:158)
16:48:09  <tpar>==14465== by 0x585E831: uv__signal_loop_once_init (signal.c:218)
16:48:09  <tpar>==14465== by 0x585E95C: uv_signal_init (signal.c:260)
16:48:11  <tpar>==14465== by 0x585AD65: uv__loop_init (loop.c:137)
16:48:14  <tpar>==14465== by 0x585A966: uv_loop_init (loop.c:50)
16:48:42  <tpar>as a part of application shutdown I call uv_loop_close() which I had expected to free all libuv resources
16:48:48  <tpar>am I missing something?
16:50:33  <trevnorris>tpar: you running uv_close() on all handles before running uv_loop_close()?
16:50:47  <tpar>trevnorris: I believe so, yes
16:50:53  * Ralithquit (Ping timeout: 250 seconds)
16:50:59  <trevnorris>check uv_loop_alive() before running uv_loop_close()
16:52:39  <trevnorris>txdv: it's nub_loop_enqueue(thread, work, cb), where work is a struct of nub_work_t.
16:54:28  <tpar>trevnorris: ack, thanks, that does suggest I've still got something active
16:54:34  <trevnorris>:)
16:55:11  <tpar>what's that pithy phrase about assumptions again...? ;-)
16:58:05  <nathan7>saghul: given our TZ differences I should probably save the IPC thing for tomorrow or this weekend
17:03:19  * inolenjoined
17:03:49  * papajuansquit
17:09:13  * qard_joined
17:10:37  * miles1joined
17:11:52  <tpar>trevnorris: hmm, so I fixed my code such that I really am closing all my handles prior to calling uv_stop on the loop
17:12:07  <tpar>and now uv_loop_alive() returns 0, as does uv_loop_close()
17:12:16  <tpar>so I think I'm now doing the right thing
17:12:30  <tpar>but! I still have the fd leak around uv__pipe2
17:13:10  <miles1>hi, could anyone tell me here if i can basically use libuv (under ***windows***, not linux) to send ICMP packets and receive them (basically a ping functionnality). i dont see any 'raw socket' functions in libuv, only udp and tcp. or can i just use the udp funcs to do it?
17:14:25  * jgiquit (Quit: jgi)
17:21:14  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
17:24:12  * Kanaliajoined
17:27:35  * Ralithjoined
17:30:20  <tpar>I dug a little more into my fd leak and I believe valgrind is pointing me at src/unix/signal.c:uv__signal_lock_pipefd
17:30:38  <tpar>which is created at init via uv__signal_global_init, but never torn down
17:31:21  <tpar>I added some code locally in uv__signal_loop_cleanup to close the pipefd pair on loop close, and now my application doesn't report the valgrind leaks
17:31:52  <trevnorris>awesome.
17:32:10  <tpar>well, yes, I'm happy :-)
17:32:47  <tpar>should I submit a patch somehow?
17:33:30  <trevnorris>yes. I would create a PR and submit it.
17:33:41  <tpar>cool, thanks
17:34:11  <trevnorris>miles1: https://github.com/joyent/libuv/issues/777
17:34:33  <trevnorris>and depending on what version of windows you're running, I believe it might not support raw sockets.
17:36:27  <trevnorris>miles1: https://msdn.microsoft.com/en-us/library/windows/desktop/ms740548%28v=vs.85%29.aspx#Limitations_on_Raw_Sockets
17:40:56  <miles1>oh alright, yep, i was aware under win raw sockets need administrator access, just wanted to be sure i could still use them with libuv, which seems the case
17:41:00  <miles1>thanks!
17:41:39  <trevnorris>np
17:42:09  * SergeiRNDjoined
17:43:15  * lance|afkchanged nick to lanceball
17:43:35  * jgijoined
17:47:19  * thlorenzquit (Remote host closed the connection)
17:47:48  * thlorenzjoined
17:48:57  * seishunquit (Ping timeout: 250 seconds)
17:52:58  <tpar>hmm, I've thought more about uv__signal_lock_pipefd and I'm not entirely sure how to close it nicely
17:53:18  <tpar>it is a truely global resource, in that it's in the application's signal handler
17:53:39  <tpar>hence its lifetime needs to start with the first uv loop, and end with the last
17:54:10  <tpar>but so far as I can see libuv doesn't know how many loops exist
17:54:43  <trevnorris>tpar: jump into #io.js and ask bnoordhuis.
17:54:44  <tpar>clearly its not right to simply say "I'll close uv__signal_lock_pipefd on loop close" as my initial naive patch did :-/
17:54:58  <tpar>trevnorris: thanks, will do
18:00:38  * seishunjoined
18:01:43  * SergeiRNDquit (Quit: Leaving.)
18:18:48  * piscisaureusjoined
18:23:50  * Tux64_changed nick to Tux64
18:40:20  * SergeiRNDjoined
18:48:57  * inolenquit (Quit: Leaving.)
18:49:59  * SergeiRNDquit (Quit: Leaving.)
19:07:14  * inolenjoined
19:16:53  * dinamic_quit (Quit: Leaving)
19:31:39  * roxlujoined
19:44:29  <jgi>txdv: just a heads up to let you know that all meetings’ minutes are posted here: https://www.nodejs.org/about/core-team/meetings/
19:44:39  * inolenquit (Quit: Leaving.)
19:57:58  * jgiquit (Quit: jgi)
20:02:36  <saghul>trevnorris: mind dropping an email? saghul at gmail, I'll gladly take a look!
20:15:05  * tparquit (Ping timeout: 246 seconds)
20:17:34  <trevnorris>saghul: awesome. thanks :)
20:42:45  * sblomjoined
20:50:11  * thlorenzquit (Remote host closed the connection)
20:50:41  * jgijoined
20:52:12  * thlorenz_joined
20:55:42  * sblomquit (Read error: Connection reset by peer)
20:58:58  * thlorenz_quit (Remote host closed the connection)
20:59:17  * thlorenzjoined
21:08:32  * FROGGS[mobile]joined
21:11:30  * imzyxwvujoined
21:17:44  * thlorenzquit (Remote host closed the connection)
21:25:09  * seishunquit (Ping timeout: 256 seconds)
22:00:56  * seishunjoined
22:18:33  * thlorenzjoined
22:19:58  * toothrotjoined
22:23:32  * thlorenzquit (Ping timeout: 246 seconds)
22:29:32  * Fishrock123quit (Quit: Leaving...)
22:30:04  * miles1part
22:45:01  * inolenjoined
22:47:44  * imzyxwvuquit (Ping timeout: 272 seconds)
22:48:23  * octetcloudquit (Ping timeout: 252 seconds)
22:49:16  * warehouse13joined
22:51:54  * lanceballchanged nick to lance|afk
22:52:25  * Left_Turnquit (Ping timeout: 256 seconds)
22:53:45  * inolenquit (Quit: Leaving.)
22:54:01  * seishunquit (Ping timeout: 250 seconds)
22:56:08  * AvianFluquit (Remote host closed the connection)
22:59:48  * mkrufkyjoined
23:01:52  <mkrufky>hello all. i am working on a project for fun, where i am converting a mpeg2 TS parser that I originally wrote in c, into js and c++ bindings. its main purpose is... well, really just for fun.
23:02:23  * tylerantonjoined
23:03:00  <mkrufky>anyway, in this project, i am building objects in a worker thread, and i convert them into v8 objects in a callback that wakes the main thread, but i would much rather create my objects in the worker thread... but of course, cant use v8 anywhere other than the main thread
23:03:18  <nathan7>such is life, unfortunately
23:03:37  <mkrufky>i was thinking of using some other library to make temporary json objects and then convert them into v8 json objectsin my main thread callback
23:03:56  <mkrufky>but i dont think that will buy me much of any performance
23:03:56  <nathan7>have you profiled your code, though? is that actually a bottleneck?
23:03:58  <mkrufky>might actually COST me
23:04:11  <mkrufky>no, not really. im scratching an itch, really
23:04:18  <mkrufky>i should profile it - thats a good point
23:04:27  * octetcloudjoined
23:04:38  * chris_99quit (Quit: Ex-Chat)
23:04:53  <mkrufky>anyway, i thought i'd ask in here, that maybe another developer may have had some similar need in the past and have better ideas?
23:11:22  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:25:48  * avalanche123quit (Remote host closed the connection)
23:28:14  * mitsuhikojoined
23:31:04  * inolenjoined
23:32:37  * avalanche123joined
23:36:34  * Kanaliaquit
23:42:47  * avalanche123quit (Remote host closed the connection)
23:47:54  * avalanche123joined
23:50:53  <othiym23>jgi and / or anybody who might know: is there a plan in motion to put out a 0.12.1 soonish?
23:51:20  <othiym23>(I want to update https://github.com/npm/npm/issues/7349, so I'd like to know what to say about Node.js)
23:51:25  <jgi>othiym23: there is a plan, but a limit amount of resources to execute on that plan, so no ETA currently
23:51:42  <othiym23>jgi: k, thanks for the update
23:54:18  <jgi>othiym23: also, this is what the 0.12.1 milestone looks like currently: https://github.com/joyent/node/milestones/0.12.1
23:54:33  <jgi>othiym23: I started adding issues to https://github.com/joyent/node/milestones/0.12.2 to prevent 0.12.1 from growing indefinitely
23:54:44  <jgi>othiym23: so the goal is definitely to converge asap
23:55:03  <othiym23>ah thanks, that's the thing I was looking for earlier, and I didn't think to check for milestones