|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
02:32
evalable6 left,
linkable6 left
02:33
evalable6 joined
02:34
linkable6 joined
03:17
Kaiepi left
03:29
leont left
05:16
sourceable6 left,
coverable6 left,
shareable6 left,
benchable6 left,
releasable6 left,
nativecallable6 left,
bisectable6 left,
notable6 left,
evalable6 left,
quotable6 left,
squashable6 left,
greppable6 left,
tellable6 left,
committable6 left,
linkable6 left,
bloatable6 left,
statisfiable6 left,
unicodable6 left,
squashable6 joined,
committable6 joined
05:17
tellable6 joined,
notable6 joined,
quotable6 joined,
greppable6 joined,
benchable6 joined,
releasable6 joined,
statisfiable6 joined,
coverable6 joined
05:18
unicodable6 joined,
nativecallable6 joined,
shareable6 joined,
bisectable6 joined
05:19
sourceable6 joined,
linkable6 joined,
bloatable6 joined,
evalable6 joined
05:29
frost-lab joined
08:42
sena_kun joined
09:07
Altai-man joined
09:10
sena_kun left
09:33
Kaiepi joined
12:28
frost-lab left
13:01
leont joined
13:07
sena_kun joined
13:09
Altai-man left
15:28
vesper11 left
15:33
vesper11 joined
15:38
cog left
15:41
cog joined
15:43
cog_ joined,
cog left
16:43
sena_kun left
|
|||
| timotimo | nine: does that already get handled with rakuast being interpretable completely without a compilation step, and rakuast being serializable without trouble? | 18:45 | |
| that'll also save us the parsing, at the very least | 18:48 | ||
|
18:56
zakharyas joined
|
|||
| nwc10 | jnthn: were you assuming that I should merge github.com/MoarVM/MoarVM/pull/1360 ? | 19:38 | |
| MasterDuke | i'd say now is a good time. two weeks before a release, Blin is giving a clean report... | 19:39 | |
| lizmat | I could do the NQP / Rakudo bumping if nobody beats me to it | 19:40 | |
|
19:55
cog joined
19:56
cognominal left
|
|||
| bartolin | lizmat: I've noticed failing tests on the JVM backend (S09-typed-arrays/native-int.t, S09-typed-arrays/native-shape1-int.t and the num and str variants). The problem seems to be (again) the use of native arrays introduced with github.com/rakudo/rakudo/commit/4304e25059. The failure mode is the same as described in github.com/rakudo/rakudo/issues/1666 -- 'my num @res' comes out as VMArrayInstance instead of VMArrayInstance_n. | 20:49 | |
| lizmat: Since I don't know how to fix the underlying problem, I'm considering to leave out the candidates like 'multi sub postcircumfix:<[ ]>(array::numarray \SELF, Iterable:D $pos) is raw { }' on the JVM backend. (Putting them into '#?if !jvm ... #?endif) | 20:52 | ||
| lizmat: (but I've seen that you did more work in that area earlier today. I didn't have time to look closer, but probably the new candidates won't work either.) Do you have an idea what could be the least ugly way to work around this problem? | 20:56 | ||
| on a different note: on FreeBSD with MoarVM t/spec/integration/advent2012-day21.t seems to hang. It was still passing on master on 2020-12-01 (don't have the exact commit unfortunately). Has anyone else seen this in the last days? | 21:02 | ||
| MasterDuke | bartolin: that was just fixed, i think yesterday | 21:04 | |
| oh, hm. maybe not | 21:05 | ||
| nope, was fixed | |||
| bartolin | oh, great. (my last build was from Friday evening) | ||
| I probably missed the issue and the fix. Thanks for confirming! | 21:07 | ||
| MasterDuke | np | ||
| jnthn | nwc10: Well, there's the one comment that I couldn't figure out what was trying to tell me, which may want to be dropped or tweaked, but yes. | 21:29 | |
|
21:36
zakharyas left
21:37
lucasb joined
|
|||
| lizmat | bartolin: just exclude these candidates on the JVM backend for now: they're all for performance | 22:38 | |
| bartolin: I will make sure they will be excluded on the jvm backend | 22:39 | ||
| MasterDuke | has anyone else looked at the output of running scan-build (the clang static analyzer)? | 23:59 | |