Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
Nicholas good *, #moarvm 06:57
MasterDuke ugh, i thought this radix change would be pretty trivial. i don't know if it's because i've only been working on it pretty late, or i underestimated the difficulty, but i expected to be at the benchmarking stage right now, not the `say (:3<120>).WHAT` prints `(Rat)` stage... 08:17
Nicholas m: say (:3<120>).WHAT 08:35
camelia (Int)
MasterDuke i don't even know why it's doing it 08:37
Nicholas (me neither) but I think technically it's true, as rational numbers are a superset of integers. But this isn't helpful... 08:38
timo MasterDuke: have you tried using the MVM_COVERAGE_LOG to find the code path? 09:33
MasterDuke hm, good idea 09:36
MasterDuke huh, didn't really help. it's happening at compile time, so i tried putting it in an EVAL, but still can't find it (in the coverage log) 10:13
timo tried --optiimze=0? 10:14
or =off
(on the rakudo commandline)
MasterDuke oh, tried that before, but not with the coverage log 10:17
why don't i see any of Grammar.pm6 or Actions.pm6 in the log? 10:18
s/pm6/nqp/g
timo good question 10:19
MasterDuke oh, i do in a full log, but not when i used nqp::coveragecontrol to only turn it on in the EVAL
ok, looks like it's a problem with rad_number 10:38
ok, this is blowing my mind 10:40
look at these lines in this patch gist.github.com/MasterDuke17/cbf7f...ch-L38-L39 10:41
two prints, one right after the other 10:42
and this is the output when i run `say :3<122>`
i: 122
17 3 3
0 1 2
wants Rat: 51 3
17
where is the "f: <...>"!?!?!? 10:43
timo the ?? eats it 10:45
MasterDuke retracts the question and looks for a way to purge the chat logs 10:46
timo happens to the best of us 10:51
wanna implement a tiny little optimizer pass that warns about this? for example, a non-empty string concatenated with any variable will always evaluate to True 10:52
MasterDuke can look into that after i figure this out 10:56
ah, figured out what's going on, now to see if there's an easy fix 10:57
m: use nqp; say nqp::radix_I(3, ".0", 1, 4, Int)
camelia (0 1 2)
MasterDuke i'm getting the same result locally, which is the problem, it should be (0, 0, 2) 10:58
since i then raise radix to the power of the second element to get what was the value before 10:59
timo but anything raised to the power of 0 is 1, isn't it? or does that refer to the 1 after the ".0"? 11:03
MasterDuke yeah. the problem is that currently i'm counting the trailing 0 as being a parsed character, when in this case it shouldn't be 11:06
m: use nqp; say nqp::radix_I(3, ".0", 1, 0, Int)
camelia (0 3 2)
MasterDuke i was trying to be a little too clever, but now all spectests pass 11:15
time to see if this is a net positive improvement now
timo glad to hear 11:16
MasterDuke timo: btw, any chance you can generate some more app images? they're convenient to test with when i make changes over the whole moarvm/nqp/rakudo stack (i.e., i can't just quickly `git stash` a change in moarvm and rebuilt just it) 11:40
timo i'll have to spend a bit of time figuring out github actions or whatever it is that we replaced travis-ci with 11:41
jdv this is the recent blin run - github.com/rakudo/rakudo/issues/4667 16:27
sena_kun jdv, o/ 16:28
jdv, thanks for doing it. November is the eternal false positive, so it should be filtered out before posting. 16:29
TCP::LowLevel has a PR with a fix, so that too. 16:30
jdv ah, thanks. 16:31
sena_kun I'd vote for putting it into ignored modules in Blin, unless you have time and passion to actually investigate what on earth is happening with this module (it's a bug in blin, zef, rakudo or whatever in between).
nine jdv: NativeHelpers::Callback is weird in that it didn't appear in the github.com/rakudo/rakudo/issues/4643 Blin run but the commits the bisection points to have already been present then 16:32
That's also the only module where I see action needed by me 16:33
sena_kun right, others want some attention from codesections I think.
nine jdv: I cannot reproduce the NativeHelpers::Callback issue 16:39
jdv nine: doesn't Algorithm::Evolutionary::Simple bisects to a commit of yours as well?
nine jdv: yes it does. But the commit itself is innocent. It merely exposed the huge number of issues surrounding native unsigned integers that affect all parts of the stack and which I've worked on cleaning up for the past 2 weeks. But as I said in my initial assessment, this is not gonna be a quick fix but rather a month long project - optimistically speaking. 16:41
The only reason Algorithm::Evolutionary::Simple sort of worked before is another rakudo bug. 16:42
Does blin run tests in parallel?
MasterDuke i think so
jdv yes it does 16:43
i can repro NativeHelpers::Callback outside of blin on head
so do we just ignore the Algorithm::Evolutionary::Simple failure then? i'm new here... 16:44
nine With only one test running at a time?
jdv yes, gist.github.com/jdv/9d13d434463971...14d7b9bda1
nine jdv: I see no other choice for Algorithm::Evolutionary::Simple. Fix is in the works, but I wouldn't even promise that it can make it into the release after the upcoming one. Unfortunately it looks like the only way to fix this one issue is to basically fix all of them. 16:46
And disabling the (in this particular case) bogus error message causes spec test failures.
jdv: still no joy in reproducing locally :/ Seems like I won't be able to debug this 16:50
dogbert11 FWIW, I can repro the test failures in NativeHelpers::Callback 16:52
nine: on my system valgrind is quite upset with 01-basic.t 16:53
1..8 16:57
==668293== Conditional jump or move depends on uninitialised value(s)
==668293== at 0x4A8841C: MVM_intcache_get (intcache.c:42)
==668293== by 0x4AB34FA: MVM_repr_box_int (reprconv.c:656)
==668293== by 0x4A82111: nativecall_cast (nativecall.c:527)
==668293== by 0x4A5F761: MVM_interp_run (interp.c:4072)
nine Why are suddenly all my problems about ints?! :D 17:00
dogbert11 they like you :) 17:01
nine Maybe its because I watch all those Numberphile Youtube videos when cooking...
dogbert11 perhaps the valgrind report is bogus? 17:03
nine Nah, it's too close to be coincidence 17:04
Actually I get a ton of "Conditional jump or move depends on uninitialised value" errors with valgrind 17:07
dogbert11 yeah, I only posted the first in the list 17:11
hopefully there's only one problem ...
dogbert11 is struggling with part two of todays AoC problem 17:12
[Coke] needs to catch up again! 17:25
nine I'm starting to suspect that the valgrind output might be bogus after all. But then we're back at square 1 again. 17:33
And I still can't reproduce the actual failure.
Or no, valgrind is right indeed! 17:35
What does the test do? It calls make_a_thing which allocates some memory but doesn't initialize it: github.com/CurtTilmes/raku-nativeh...back.c#L15 17:36
Then it calls NativeHelpers::Callback.id on the pointer it got back: github.com/CurtTilmes/raku-nativeh...asic.t#L36 17:37
This just casts the thing it got to int64: github.com/CurtTilmes/raku-nativeh...rakumod#L8
The purpose is probably to use the pointer value as a hash key. But nativecallcast actually dereferences the pointer it got and creates the number from the dereferenced memory location! github.com/MoarVM/MoarVM/blob/mast...all.c#L561 17:38
But remember: that is uninitialized memory
jdv: but in the module! ^^^ 17:40
dogbert11 looks like you're off the hook 17:46
jdv cool. i'll note that stuff. 17:47
jdv is github.com/rakudo/rakudo/issues/46...-993892953 suggesting add those as blockers? 20:39
Geth MoarVM: MasterDuke17++ created pull request #1619:
Change nqp::radix(_I)? to return # chars converted		 20:56
japhb MasterDuke: Did you already do the performance tests on those changes? Or is that waiting for the other PRs? 21:01
MasterDuke i've done some, i was going to put the numbers in the rakudo PR
jdv nine: libXML's issues may be from the nativecall stuff. seems to bisect to the same spot NativeHelpers::Callback does. 21:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!