Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-11-07

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:24 ilmari[m] joined #moarvm
01:50 unicodable6 joined #moarvm
02:56 ilbot3 joined #moarvm
02:56 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:23 colomon joined #moarvm
04:03 evalable6 joined #moarvm
05:36 quotable6 joined #moarvm
05:36 evalable6 joined #moarvm
05:36 nativecallable6 joined #moarvm
05:36 coverable6 joined #moarvm
05:36 committable6 joined #moarvm
05:36 bloatable6 joined #moarvm
05:36 greppable6 joined #moarvm
05:36 bisectable6 joined #moarvm
05:36 releasable6 joined #moarvm
05:36 unicodable6 joined #moarvm
05:36 benchable6 joined #moarvm
05:36 squashable6 joined #moarvm
05:36 statisfiable6 joined #moarvm
06:42 brrt joined #moarvm
06:47 brrt good * #moarvm
07:16 nwc10 good *, brrt
07:18 brrt it was cold this morning
07:19 nwc10 but laptops with busy CPUs are warm and toasty?
07:19 brrt fortunately
07:20 brrt that's why we're working on perl6
07:20 brrt actually...
07:35 domidumont joined #moarvm
07:54 domidumont joined #moarvm
08:49 brrt joined #moarvm
08:52 brrt i may have the ADD CONST -> ADDR resolved
09:21 robertle joined #moarvm
09:55 jnthn morning o/
10:13 brrt morning
10:13 brrt getarg_i and stuff, are those new ops
10:15 jnthn Think so, I'm not sure what getarg_i is doing yet, though
10:15 brrt hehe
10:15 brrt okay
10:16 brrt well, i know to update then
10:16 nine jnthn: arg_i puts something into the args buffer, getarg_i reads it from there
10:16 jnthn huh?
10:16 jnthn That's what .param is for, no?
10:16 jnthn *param_*, I mean
10:16 nine Yes, but param requires a new callframe which nativeinvoke* doesn't set up
10:17 jnthn Why would it need to take something out of the args buffer, though?
10:17 nine IOW param_* is from perspective of the callee while getarg_* is from the caller
10:17 nine rw args
10:17 jnthn But rw-ness is handled by containers?
10:18 domidumont joined #moarvm
10:19 nine Well I never claimed to understand this stuff :)
10:20 jnthn :)
10:20 nine I did find out that rw args involve LexicalRefs, but failed to actually recognize the design behind them, i.e. the why.
10:20 jnthn Well, native refs in general
10:20 jnthn Could be an attr ref too, or a positional ref
10:20 jnthn These are all managed references to a native value stored somewhere
10:21 jnthn That is, they keep alive both the container and allow the value to be retrieved inside of it
10:25 jnthn The point being that we can pass them around as first-class objects, just as we can with Scalar
10:26 jnthn And the reason for pushing this down to the VM level being so that we can later optimize them out over call boundaries when inlining happens
10:30 nine So taking a step back: how is the process of getting a native rw argument's value into the VM and the new value out and back to the caller?
10:32 jnthn For an int, it'd most easily be done as a decont_i and an assign_i
10:33 jnthn We can't really pass a pointer directly into the data structure holding the value itself, since if the code in question does a callback and we GC, the thing could move
10:34 jnthn I now see why you added getarg_i though: using the args buffer as a place the JITted nativecall can write a result back
10:34 nine exactly
10:34 jnthn I guess it'll work out OK
10:35 jnthn I just hope we'll not see use of it beyond the JIT :)
10:36 nine I create a QAST::Var:scope<local>:decl<param>, a QAST::Var:scope<lexicalref>:decl<var>, bind the param to the var, decont it into a QAST::Var:scope<local>:decl<var> and pass that to nativeinvoke. Afterwards I assign_i the value I get from getarg_i to the lexicalref
10:36 jnthn OK, that'll work
10:40 nine Just feels a bit roundabout with all those variables :)
10:41 jnthn True, though I'd assume the EXPR JIT will be able to eliminate some of the copying :)
10:41 brrt wow, uppercases :-)
10:41 brrt yeagh
10:41 jnthn haha
10:42 jnthn Too much EXPR from the Perl 6 grammar :P
10:42 brrt making a version of the nativecall JIT that outputs an expr tree is somehwere on the radar
10:42 brrt as are a billion other things
10:46 domidumont joined #moarvm
11:23 Geth ¦ MoarVM/jit-expr-optimizer: 8 commits pushed by (Bart Wiegmans)++
11:23 Geth ¦ MoarVM/jit-expr-optimizer: 380b30a370 | Add expression tree equivalence function
11:23 Geth ¦ MoarVM/jit-expr-optimizer: 16daedcc0f | [JIT] Simple tree-rewriting optimizer
11:23 Geth ¦ MoarVM/jit-expr-optimizer: ebf87d5768 | [JIT] Add adhoc template application
11:23 Geth ¦ MoarVM/jit-expr-optimizer: 373ab7233d | [JIT] Optimize multiple loads to a COPY
11:23 Geth ¦ MoarVM/jit-expr-optimizer: 5ea4618cf9 | Remove op_info pointer
11:23 Geth ¦ MoarVM/jit-expr-optimizer: e03f1ee77c | Fix C89 compatibility
11:23 Geth ¦ MoarVM/jit-expr-optimizer: 46946363d1 | Document the conditional dependency check
11:23 Geth ¦ MoarVM/jit-expr-optimizer: f33a949bc2 | Optimize ADD of CONST to ADDR
11:23 Geth ¦ MoarVM/jit-expr-optimizer: review: https://github.com/MoarVM/MoarVM/compare/8d0bdb4b68...f33a949bc2
11:26 cog_ joined #moarvm
11:31 zakharyas joined #moarvm
11:32 Geth ¦ MoarVM/jit-expr-optimizer: f1306806cc | (Bart Wiegmans)++ | src/jit/optimize.c
11:32 Geth ¦ MoarVM/jit-expr-optimizer: Eliminate COPY of CONST
11:32 Geth ¦ MoarVM/jit-expr-optimizer:
11:32 Geth ¦ MoarVM/jit-expr-optimizer: COPY is opaque for tiling, so the COPY of CONST values disables tiles
11:32 Geth ¦ MoarVM/jit-expr-optimizer: that operate on a const directly. This allows us to use the CONST
11:32 Geth ¦ MoarVM/jit-expr-optimizer: value directly which should help us pick better tiles.
11:32 Geth ¦ MoarVM/jit-expr-optimizer: review: https://github.com/MoarVM/MoarVM/commit/f1306806cc
11:33 brrt we should have some way to measure the effects
12:25 nine /win 10
12:25 buggable nine, Thank you for entering Accidental /win Lottery! The next draw will happen in 3 weeks, 2 days, 11 hours, 34 minutes, and 25 seconds
12:26 nwc10 do we ever get to see the /winner ?
12:26 nine nwc10: https://irclog.perlgeek.de/moarvm/2017-11-01#i_15383996
12:27 nwc10 ooh, thanks, I wasn't aware that it really had a proper ceremony
12:28 ilmari «The next draw will happen in -1 weeks, 6 days, 23 hours, 27 minutes, and 22 seconds» - buggyble?
12:28 nwc10 yes, that
12:28 nwc10 that was awesome
12:28 nwc10 https://irclog.perlgeek.de/moarvm/2017-11-01#i_15384127
12:28 nwc10 had that ready to paste
12:28 nwc10 it's almost enough to be worth staying up for, to see if it's been fixed
12:30 * ilmari looks at the logs for 2017-10-01 and 09-01, and sees the logging bot has had at least two different character encoding bugs
12:33 lizmat ilmari: from what I undertand, irclog runs on Perl 5 with a mod_perl / old MySQL backend
12:34 lizmat and a database that goes back to the days when DBD::mysql's support for utf-8 was, eh...  not optimal
12:37 ilmari yeah, I guess it got altered to utf8mb4 sometime in the last month
12:39 nwc10 and when running something persisent on Rakudo would have leaked memory like the Jumblies preferred maritime transport
13:02 brrt joined #moarvm
13:06 lizmat joined #moarvm
13:58 lizmat jnthn: if Thread.start fails for some reason, is it correct that it doesn't return ?
13:59 jnthn I'd expect an exception if it's a failure the VM can recover from
14:02 lizmat ah, it never reaches the code after the Thread.start because of the exception: duh!
14:03 jnthn Yeah, the thread that tried and failed to start another one is the one where we'd report it.
14:08 lizmat it would be nice if we could stop one short of actually using the last thread
14:08 lizmat hmmm... unless...
14:08 lizmat signals, do they run on the general workers, jnthn?
14:08 jnthn We can't know.
14:08 jnthn Yes.
14:09 lizmat perhaps it's an idea to run them on affinity workers or timer workers ?
14:09 jnthn Why?
14:09 lizmat so that *if* all threads are in use, we can still safely control-c out of it ?
14:10 lizmat and with the snapper, perhaps find out what was going on ?
14:10 jnthn An affinity thread can be every bit as in use as a general one
14:10 jnthn Timer ones I guess we do advise people not to do long-running things on, but we can't prevent them from doing that
14:11 jnthn I guess we could view signals as kind of "urgent" though and scheduler them on the timer thread.
14:11 lizmat perhaps we need a seperate thread for handling signals, apart from all of the other ones >
14:11 jnthn *schedule
14:11 jnthn That just moves the problem :)
14:11 jnthn And means yet more kinds of worker
14:11 jnthn Which isn't really that ideal
14:12 jnthn If you only have 4 cores, and we have 4 types of worker, then the most you're going to then get without triggering the heuristic deadlock detection is one of each
14:12 lizmat hmmm... maybe I should look a little deeper into how signals are actually hooked up again
14:12 jnthn Doing them on the timer thread could be a decent compromise, though
14:12 jnthn I don't think it can make things worse, and for some cases it may make them better.
14:12 lizmat I mean, yes, you want signals to be delivered in time, so, that in a way makes sense
14:13 lizmat jnthn: I'll make the change...
14:18 lizmat yeah, that improves things
15:06 lizmat joined #moarvm
15:31 brrt joined #moarvm
15:41 brrt joined #moarvm
16:28 brrt joined #moarvm
16:47 lizmat joined #moarvm
17:19 zakharyas joined #moarvm
17:50 domidumont joined #moarvm
20:04 domidumont joined #moarvm
20:12 zakharyas joined #moarvm
20:53 unicodable6 joined #moarvm
21:07 zakharyas joined #moarvm
21:22 MasterDuke joined #moarvm
22:24 brrt joined #moarvm
22:56 colomon joined #moarvm
23:10 ugexe libuv has exposed a uv_os_getppid in the last version bump... should we use it for a MVM_proc_getppid so child processes can tell when their parent process has exited?
23:14 MasterDuke oh, there's also something about ttys: `* unix, windows: map ENOTTY errno (Ben Noordhuis)`
23:15 MasterDuke there's been a bunch of work recently related to detecting TTYs i think, maybe that'll help
23:17 timotimo hm, that sounds more like getting the proper error message when some only-tty-action is used on a non-tty file descriptor?
23:17 ugexe one just exposes constant ENOTTY and the other is for win7 i believe. any other ones we should already have from the last version bump.
23:50 lizmat joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary