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.
00:08 reportable6 left 00:29 ggoebel joined 02:10 reportable6 joined 02:34 harrow left 02:57 harrow joined 03:57 linkable6 left, evalable6 left 03:59 linkable6 joined, evalable6 joined 04:04 Geth left, TempIRCLogger__ left, RakuIRCLogger left 04:06 lizmat left 04:07 lizmat joined 05:53 quotable6 left, statisfiable6 left, nativecallable6 left, benchable6 left, coverable6 left, evalable6 left, sourceable6 left, unicodable6 left, bisectable6 left, linkable6 left, reportable6 left, releasable6 left, notable6 left, committable6 left, bloatable6 left, greppable6 left, squashable6 left, shareable6 left, evalable6 joined 05:54 bisectable6 joined, releasable6 joined 05:55 shareable6 joined, greppable6 joined, nativecallable6 joined, committable6 joined 05:56 benchable6 joined, sourceable6 joined, quotable6 joined, coverable6 joined 06:10 reportable6 joined 06:54 unicodable6 joined, bloatable6 joined, squashable6 joined 06:56 notable6 joined 07:00 lizmat left, lizmat joined, Geth joined 07:04 RakuIRCLogger left, RakuIRCLogger joined 07:08 RakuIRCLogger left, RakuIRCLogger joined 07:12 TempIRCLogger joined 07:13 RakuIRCLogger left, RakuIRCLogger joined 07:15 CaCode joined 07:17 TempIRCLogger left, TempIRCLogger joined
nine There are up-to-date openSUSE packages for rakudo on s390x. 07:31
07:57 [Coke] left
lizmat nine: I've not been able to find them on software.opensuse.org ... link? 08:35
nine download.opensuse.org/repositories...5.3/s390x/ 08:44
The repository (for openSUSE Leap 15.3)is download.opensuse.org/repositories...perl6.repo
08:46 [Coke] joined
nine I do not yet build s390x for openSUSE_Factory (the rolling distro). I could - it's just one click to enable that arch, but I don't know if its worth the additional ressource usage 08:46
08:56 statisfiable6 joined
nine And finally got it to build on Fedora :) 09:00
Module packages need a tweak as well. Have submitted a PR for module2rpm with the fix 09:01
09:53 linkable6 joined 10:00 CaCode_ joined 10:03 CaCode left 10:56 CaCode- joined 10:59 CaCode_ left 11:06 TempIRCLogger left
dogbert11 nine: thx for the information wrt github.com/rakudo/rakudo/issues/1920 12:04
I saw that you had merged some fix that seemed related and thought that it might have been fixed 12:05
12:08 reportable6 left 12:10 reportable6 joined
lizmat thinks she has a fix for #1920 12:44
dogbert11 thinks lizmat deserves +++ :) 12:53
lizmat meh... too early 12:54
at least it isn't always a segfault anymore
12:55 CaCode_ joined, CaCode_ left
dogbert11 small steps are better than no steps :) 12:55
lizmat I had replaced the (require ::($module)) by "lib/$module.rakumod".IO.slurp.EVAL 12:56
that pointed to a stale has access in Rakudo::Internals.EXPORT_SYMBOL
12:58 CaCode- left
lizmat github.com/rakudo/rakudo/commit/f4cba21c67 12:58
12:59 linkable6 left 13:02 linkable6 joined 14:00 [Coke]_ joined 14:02 [Coke] left 14:03 ggoebel left 14:15 discord-raku-bot left, discord-raku-bot joined
dogbert11 perhaps there are more to it than this 14:37
lizmat yes, I'd say so 14:39
dogbert11 I'm looking through some old stuff in order to see if things have been fixed 14:54
ugexe āÆ raku -e '(1..Inf).race(:batch(1)).map({ require "/Users/ugexe/.rakubrew/versions/moar-blead/lib/Test.rakumod" })'
[1] 31277 segmentation fault raku -e 14:55
and doing the IO.slurp.EVAL gives a error that wasn't present in 2021.12 gist.github.com/ugexe/2d623df785f8...c202c200b0 14:59
i kind of question if anything was fixed or if it was just slowed down enough to make the problem slightly more difficult to shake out 15:01
dogbert11 .seen MasterDuke 15:06
nine There are multiple issues that affect parallel module loading both in MoarVM and Rakudo. 15:22
dogbert11 it seems as if this SEGV har made a comeback: perl6 --profile -e'say "127.0.0.1" ~~ /^ [ <{ 0 .. 255 }> ]**4 % \. $/; say now - INIT now' 15:25
s/har/has/
15:37 discord-raku-bot left, discord-raku-bot joined
dogbert11 updated github.com/rakudo/rakudo/issues/2013 with my findings 15:41
there are lots of strange things happening all of a sudden 16:12
for example running valgrind on any program, when moarvm has been built with --no-optimize, makes valgrind complain like crazy with lots of 'Conditional jump or move depends on uninitialised value(s)' 16:14
16:15 ggoebel joined 16:30 ggoebel left, ggoebel joined 17:05 [Coke]_ is now known as [Coke]
nine Could be that we lost memory alignment with the move to mimalloc 17:13
17:15 sena_kun left 17:16 sena_kun joined
lizmat re Rakudo on s390: www.reddit.com/r/rakulang/comments...h/i2bq93l/ 17:25
looks like libffi is too modern?
nine Sounds like they were trying to install openSUSE packages on RHEL. That can work with luck, but it can also run into issues like different versions of libraries being available. 17:29
dogbert11 nine: dunno if it's correct but valgrind seems to think that the problem originates here: 'Uninitialised value was created by a stack allocation at 0x4B696D5: emit_capture_guards (program.c:2241)'
that would be here, github.com/MoarVM/MoarVM/blob/mast...am.c#L2241 17:31
18:07 reportable6 left 18:45 sena_kun left 18:46 sena_kun joined 19:24 lizmat_ joined 19:25 lizmat left 19:26 TempIRCLogger joined
lizmat_ wonders whether this isn't a potential race condition ? 19:41
github.com/rakudo/rakudo/blob/mast...ORTHOW.nqp
19:41 lizmat_ left 19:42 lizmat joined
nine What would be the race? 19:44
lizmat multiple requires doing the $?PACKAGE.WHO assignment ? 19:45
like the script of #1920 ?
nine If this code is run multiple times, wouldn't it be a different module object each time? 19:54
20:39 discord-raku-bot left 20:40 discord-raku-bot joined 20:45 discord-raku-bot left, discord-raku-bot joined 20:49 linkable6 left, sena_kun left 20:51 sena_kun joined
lizmat it runs several times during module install 20:58
MasterDuke nine, dogbert11: i think that valgrind warning about uninitialized value is correct. if you search for `MVM_VECTOR_.*\(cs->ops`, you'll see that it's PUSHed to, but is never MVM_VECTOR_INITed. so MVM_recalloc is being called without there having first been an MVM_calloc 21:27
oh wait, there's a mix of `cs.ops` and `cs->ops`. ok, `MVM_VECTOR_.*\(cs(->|\.)ops` does show an INIT for `cs.ops` 22:09
23:26 TempIRCLogger left 23:55 [Coke] left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!