github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:16 MasterDuke joined, MasterDuke left, MasterDuke joined 03:38 AlexDani` joined 03:42 AlexDaniel left 04:29 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 04:55 bisectable6 left 04:58 bisectable6 joined 04:59 bisectable6 left 05:04 bisectable6 joined 05:18 evalable6 left, committable6 left, bisectable6 left 05:20 bisectable6 joined 05:22 evalable6 joined 05:23 committable6 joined 05:26 bisectable6 left 05:27 bisectable6 joined 05:33 shareable6 left, reportable6 left, reportable6 joined 05:36 shareable6 joined 05:37 AlexDaniel left 05:42 Voldenet left 05:44 Voldenet joined, Voldenet left, Voldenet joined 05:48 AlexDaniel joined 06:55 domidumont joined 08:07 zakharyas joined
nwc10 good *, #moarvm 09:09
jnthn o/ 09:14
nwc10 \o 09:15
I slack at tracking things - t/spec/S02-types/sethash.t now passes. What wonderful person and what change fixed that? 09:16
09:40 brrt joined
brrt \o 09:40
09:49 AlexDaniel left, AlexDaniel joined 09:57 AlexDaniel left, AlexDaniel joined 10:06 AlexDaniel left 10:07 brrt` joined 10:09 brrt left 10:19 brrt` left 10:56 domidumont left 11:09 AlexDaniel joined
lizmat nwc10: I think I'm responsible for that 11:27
Rakudo 1f066d96a28940d3aae812fe5 and following 11:28
nwc10 yes, looks likely 11:29
lizmat a similar situation can still exist with hashes in general
I guess we don't test for that
11:49 zakharyas left 12:02 bloatable6 left, bloatable6 joined 12:04 brrt` joined 12:20 domidumont joined 12:21 domidumont left 12:22 domidumont joined 12:48 zakharyas joined 13:16 lucasb joined
jnthn Aha, think I found the spesh bug that tripped up my handler reduction stuff 13:29
A longer-standing bug that was just hidden
I think I've also uncovered a spectest that passes for completely the wrong reason 13:30
Also, Test.pm does something awful 13:31
Geth MoarVM: c4396d2e50 | (Jonathan Worthington)++ | src/spesh/manipulate.c
Fix inline boundary end annotation motion

It's a frame handler in the sense that it goes into that table, but we need to need to move it like the inline end handler. Otherwise, we can get an off-by-one.		 13:33
13:39 brrt` left 13:40 brrt` joined
Guest16965 jnthn: hacking again, are you going to continue your pea work? 13:57
jnthn Yes, at some point soon :)
Currently doing what I expected might be a small/simple win, only to find that not really :P 14:00
Guest16965 you should go for a simple bug :)
jnthn Down to 2 spectests
And one is 'cus the test was written in such a way to hide the bug 14:01
And we're now smart enough to generate better code and so expose it again
Guest16965 better code is always nice :) 14:04
timotimo yes, yay! 14:11
jnthn m: sub { sub foo($x = return 42) { 70 }; say foo }() 14:20
evalable6
jnthn Notice the lack of output
is-deeply sub { sub foo($x = return 42) { 70 }; say foo }(), 42, 14:21
'can return from parameter defaults';
And how the test is bogus
timotimo huh 14:22
yeah, that'd never return 42, only ever True, right?
oh, or the return is supposed to return from the outer sub actually?
jnthn Well, the problem is that you *can't* currently do `return` in parameter defaults
Well, or it will return from the outer sub, but that's surely a bug also 14:23
timotimo so the test speculates a feature, but it does it wrongly?
jnthn Right
The reason it doesn't work is that the return handler wraps around the sub body
But not the parameter processing code
timotimo mhm
jnthn I guess I could preserve the current behavior for the sake of not dealing with this now 14:24
Argh, got fixes for all the spectests, and now have a failing `make test` again :/ 14:51
Plus it's really annoying that if I don't `make install` then `make test` will fail, seemingly because it picks up on a previous installation (which explains why CI thinks all is well) 14:53
timotimo i'll surely get bitten by that as well 14:54
jnthn Hmm, it was my Test.pm6 change that broked it 14:55
*sigh* Test.pm6 does some really quite evil things 15:03
Hurrah, clean test and spectest 15:20
And big $dayjob project test suite is happy too, which is always a good sign 15:24
masak wait, what evil things does Test.pm6 do? o.O 15:27
15:30 domidumont left 15:34 mgoebel joined
jnthn masak: github.com/rakudo/rakudo/commit/84b0e38048 was the latest fun 15:37
15:48 zakharyas left
masak oh dear :/ 15:49
16:09 domidumont joined 16:10 MasterDuke left 16:12 ggoebel joined 16:13 domidumont left 16:30 Kaiepi left 16:31 Kaiepi joined 16:35 brrt` left
Geth MoarVM: Garland-g++ created pull request #1090:
Add flag for UV_UDP_REUSEADDR		 16:48
MoarVM: 9b1b60f663 | (Jonathan Worthington)++ | src/jit/x64/emit.dasc
Avoid a write barrier when we don't need one

Shrinks the code for the the get-vivify-type-object case.		 17:16
17:16 mgoebel left 19:44 lucasb left 19:59 domidumont joined 20:05 domidumont left 20:35 Kaiepi left, Kaiepi joined 20:37 lucasb joined, Kaiepi left, Kaiepi joined 20:47 ggoebel left 20:59 Kaiepi left 21:01 Kaiepi joined 21:02 Kaiepi left, Kaiepi joined 21:12 ggoebel joined 22:04 Xliff joined
Xliff \o 22:04
What does this error mean. Obtained when running perl6
"Cannot invoke object with invocation handler in this context" 22:05
jnthn Generally, you tried to combine to kinds of invocation that can't be nested due to implementation limitations. 22:06
Most often comes from trying to be too clever... :) 22:07
Xliff HA! That I was.
Checking the "less" clever fix, now.
jnthn One of those "ideally we'd fix this" things
Xliff Yes. The less clever, but more limiting solution did not generate that error. 22:09
Something like: class A { method (&s) { do-sub-in-c(&s) }; multi sub do-sub-in-c(&s (Pointer)) { * }; multi sub do-sub-in-c(&s (Pointer, Pointer)) { * } 22:10
Because &s can have many signatures. I was hoping Perl6 could dispatch based on the signature passed.
Via class A, ala: A.s(-> $ { # This is the single pointer version }) 22:11
timotimo i wonder if there'd be someone willing to give me a microgrant for working in var args support on moarvm with both libffi and dyncall 22:16
that'd let you have a *@foo where C would have a ... in the function signature
perhaps there'd also be an explicit way to say "actually, the ... starts at position X"
so you could have a perl6 signature with proper constraints that still maps to a C signature that has ... in some spot 22:18
though there are subsignatures, of course, you may not actually want that for some reason or other 22:23
Xliff If I had the money, I would. :p

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!