00:11:13  * rmgjoined
00:16:12  * rmgquit (Ping timeout: 268 seconds)
01:57:49  * Ruyijoined
03:54:02  * tunniclmquit (Ping timeout: 264 seconds)
07:18:30  * seishunjoined
07:56:37  * thefourtheyejoined
08:31:43  * seishunquit (Ping timeout: 245 seconds)
08:46:05  * rmgjoined
08:50:38  * rmgquit (Ping timeout: 258 seconds)
09:13:14  * rmgjoined
09:17:51  * rmgquit (Ping timeout: 258 seconds)
09:24:51  * dainis_quit (Quit: see ya!)
09:25:22  * dainisjoined
09:40:21  * rmgjoined
09:45:23  * rmgquit (Ping timeout: 268 seconds)
10:31:58  * Morn_quit (Quit: ZNC - http://znc.in)
11:25:09  * thealphanerdquit (Quit: farewell for now)
11:25:40  * thealphanerdjoined
12:24:05  * rendarjoined
13:53:57  * tunniclmjoined
14:11:05  * evanluca_joined
14:12:55  * evanluca_quit (Client Quit)
15:05:28  * rmgjoined
15:10:22  * rmgquit (Ping timeout: 268 seconds)
15:32:40  * rmgjoined
15:37:30  * rmgquit (Ping timeout: 268 seconds)
15:59:50  * rmgjoined
16:04:38  * rmgquit (Ping timeout: 268 seconds)
16:24:44  * thefourtheyequit (Quit: Connection closed for inactivity)
16:26:51  * rmgjoined
16:31:24  * rmgquit (Ping timeout: 258 seconds)
16:36:43  * regregjoined
17:00:23  * seishunjoined
17:47:57  * rmgjoined
17:52:40  * rmgquit (Ping timeout: 258 seconds)
18:01:48  * Ralith_quit (Ping timeout: 268 seconds)
18:15:03  * rmgjoined
18:19:30  * rmgquit (Ping timeout: 258 seconds)
18:58:23  * Ralith_joined
19:08:53  * rmgjoined
19:13:57  * rmgquit (Ping timeout: 268 seconds)
19:36:32  * rmgjoined
19:41:05  * rmgquit (Ping timeout: 268 seconds)
20:03:38  * rmgjoined
20:07:59  * rmgquit (Ping timeout: 258 seconds)
21:13:02  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
21:24:20  * brsonjoined
21:42:32  <Cheery>How javascript is using libuv?
21:43:01  <Cheery>asking because I just wrote rpython bindings for libuv, and about to try if I can integrate it into lever programming language.
21:51:05  <indutny>heya
21:51:30  <indutny>we have some sort of initialization phase in node.js
21:51:35  <indutny>where javascript is initially invoked
21:51:41  <indutny>and is allowed to queue stuff on event loop
21:51:48  <indutny>and then we just `uv_run()`
21:51:57  <indutny>and invoke js functions from C callbacks
21:52:00  <indutny>nothing fancy
21:56:14  <Cheery>how do you handle gc pointers to those js functions?
21:56:30  <indutny>Persistent handles
21:56:36  <indutny>that's how they are called in v8
21:56:49  <Cheery>they stay as long as you keep them alive?
21:56:55  <indutny>basically we store pointers to js functions in async libuv reqs
21:56:58  <indutny>yep
21:57:14  <Cheery>do you recycle them when they become needless, or just dealloc?
21:57:30  <indutny>dealloc
21:58:29  <Cheery>that probably would work for me too. But I need to write little bit of wrapper code in C to get/set userdata field.
21:58:42  <indutny>yeah
21:58:52  <Cheery>also got to figure out what's the equivalent in pypy for persistent handle.
21:59:06  <indutny>is pypy's GC non-moving?
21:59:18  <Cheery>as far I've understood, it is both.
21:59:30  <Cheery>and depends on the GC you pick.
21:59:34  <indutny>yeah
21:59:41  <indutny>then you need Persistent handles
22:02:08  <Cheery>one thing yet. Does libuv asynchronously write into its stack?
22:02:35  <indutny>I don't get the question, sorry
22:02:40  <Cheery>it probably isn't copied away because it's the topmost stacklet
22:03:01  <Cheery>but my language is using continuations/stacklets
22:03:53  <indutny>I see
22:04:08  <indutny>libuv may use its stack and write to it
22:04:12  <indutny>if I understood your question right
22:04:26  <indutny>it is a C library
22:04:30  <indutny>so it has some stack variables
22:04:36  <indutny>as usual
22:06:55  <Cheery>it doesn't allocate stuff into stack and then pass a reference to callback?
22:14:33  <Cheery>indutny: is there clear points when the handle can be deallocated?
22:20:20  <indutny>Cheery: that's up to you
22:20:28  <indutny>usually we deallocate it when it is not needed
22:22:20  <indutny>wait
22:22:21  <indutny>handle as uv handle?
22:22:28  <indutny>it is safe to deallocate them on close_cb
22:22:40  <indutny>sorry, v8 has handles too so I got confused
22:22:45  <Cheery>ok.
22:30:27  <Cheery>I guess I know how I do it now.
22:31:05  <Cheery>I use one or bunch of hash tables.
22:31:55  <Cheery>I suspect if I did otherwise I might have the eventloop lose a stack handle, stack handle then has everything else in it.
22:32:06  <Cheery>and flush down it goes.
22:32:27  <Cheery>There's actually one equally interesting thing.
22:32:50  <Cheery>if I'm multithreading, can I move ownership of a handle?
22:33:51  <Cheery>or should I somehow plug that into existing eventloop and have the eventloop signal the other thread when it's done?
22:34:26  <indutny>libuv is not thread safe
22:34:31  <indutny>except for uv_async_send()
22:34:48  <Cheery>so I have to account for that somehow.
22:35:05  <Cheery>for example by disallowing I/O with handles a thread hasn't allocated itself.
22:35:59  <Cheery>but then.. now my TTY is async
22:57:08  * seishunquit (Ping timeout: 245 seconds)
23:17:01  * jbergstroemjoined
23:17:45  <jbergstroem>yo! we just introduced fedora25 at ci.nodejs.org (released ~1mo ago). 22 was eol'ed in july; do you still want to test against it? the node.js strategy is probably to retire it and keep rolling with 23/24/25.
23:17:57  <jbergstroem>ah, no one here :]
23:38:44  <indutny>cool!
23:38:48  <indutny>jbergstroem: good news!
23:40:09  * rmgjoined
23:40:42  <jbergstroem>indutny: i'll add it to your jobs now
23:40:49  <indutny>thanks
23:41:27  <jbergstroem>didn't seem to be testing against 24 either
23:41:29  <jbergstroem>added both
23:42:14  <jbergstroem>might be missing some packages
23:42:31  <jbergstroem>nope : https://ci.nodejs.org/job/libuv-test-commit-linux/217/nodes=fedora25-x64/console
23:43:24  <jbergstroem>indutny: adding smarots15/16 too
23:44:34  * rmgquit (Ping timeout: 258 seconds)
23:54:39  * Cannonjoined
23:54:42  * Cannonpart ("Rockin....rockin and rollin'...down to the beach I'm strollin'....")