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:06 reportable6 left 00:07 reportable6 joined 03:06 frost joined 04:57 bisectable6 left, benchable6 left, releasable6 left, committable6 left, quotable6 left, statisfiable6 left, bloatable6 left, greppable6 left, evalable6 left, unicodable6 left, sourceable6 left, tellable6 left, shareable6 left, coverable6 left, squashable6 left, notable6 left, nativecallable6 left, reportable6 left, linkable6 left 04:58 greppable6 joined, bisectable6 joined, bloatable6 joined 04:59 quotable6 joined, tellable6 joined, coverable6 joined 05:00 reportable6 joined 05:58 unicodable6 joined, squashable6 joined, nativecallable6 joined 05:59 evalable6 joined, committable6 joined 06:00 releasable6 joined, notable6 joined, statisfiable6 joined 06:07 reportable6 left, reportable6 joined
Nicholas good *, * 06:56
07:00 shareable6 joined
MasterDuke morning. i think github.com/MoarVM/MoarVM/pull/1673 is good to go, anybody got a couple min to take a look? 07:31
08:59 linkable6 joined 10:00 benchable6 joined 11:00 sourceable6 joined 12:06 reportable6 left 12:07 reportable6 joined 13:30 linkable6 left, evalable6 left 13:33 linkable6 joined, evalable6 joined 13:52 frost left
nine Stage parse : 914.717 14:17
I feared it would be worse :D
Nicholas that's with what? 14:26
nine build.opensuse.org/project/monitor...solvable=1 14:27
If you've got a RiscV system lying around, you can spare yourself the hour long rakudo build time and get the openSUSE package instead :) 14:28
japhb Holy cow that's slow. Is that normal for RiscV, or are they using a very low-spec box? 14:30
nine Actually I think it's emulated: build.opensuse.org/monitor 14:31
japhb *phew* 14:34
nine Native aarch64 took ~16 minutes to build build.opensuse.org/package/live_bu....3/aarch64 with stage parse of 265s 14:35
14:37 squashable6 left 14:57 cognominal_ joined, cognominal left
Nicholas aarch64 seems similar to what I see on the GCC compile farm 14:58
15:40 squashable6 joined
lizmat hmmm.... I just had a weird one-off 16:39
$ zef install .
No such private method 'SET-SELF' on Map
unrepeatable :-(
nine lizmat: github.com/rakudo/rakudo/issues/4655 16:46
It's one of those "this really needs fixing at some point but I'm also really dreading it" issues... 16:47
lizmat right .. ok, well, just confirmation it's still there 16:48
nine Different topic: openSUSE packages now use libffi on all architectures to get rid of the bundled libdyncall. Since libffi seems to support more architectures than dyncall anyway, why do we support - let alone default to - the latter anyway? 16:52
lizmat hysterical raisins ? 16:53
japhb I think this was brought up before, and sadly I don't remember the reasoning back then. WAG: Something to do with Windows, MacOS, or BSD support? 16:54
nine Given the list of supported platforms on sourceware.org/libffi/ and that libffi is used by the Python standard library, I'd be surprised if libffi would prevent us from running anywhere 16:56
japhb Fair enough. 16:59
17:25 cognominal_ left
Nicholas I don't remember. I assume that jnthnwrthngtn knew once. 17:31
nine Seems like I just can't get one successful build on s390x :/ build.opensuse.org/package/live_bu...15.3/s390x 17:33
15-gh_1202.t and repl.t fail most of the time
jnthnwrthngtn libdyncall's build story on Windows was, at the time, significantly easier 18:02
Nicholas and you wanted to *bundle* one of the two? 18:03
so picked the one that was easier to bundle and make work?
jnthnwrthngtn Right. Remember that when MoarVM started it was all "make things work". If a dep was going to be a pain build wise, there wasn't time for that. 18:04
dyncall was decently doc'd, at the time actively developed, and easy to build and bundle.
So was the clear path of least resistence at the time
I think libffi is probably more actively developed today 18:06
18:06 reportable6 left
jnthnwrthngtn And maybe it's less of a pain or we've more time to deal with the pain :) 18:06
Nicholas dyncall seems to have stalled, despite acknowledging that it has structural bugs with handling unsigned 16 bit parameters on some platforms
and I think 8
jnthnwrthngtn Didn't know about the latter bit, but "stalled" is my feeling about it too. Back when I adopted it, it seemed the more active of the two projects. 18:07
Nicholas it's to do with sign extension (for signed values) vs no sign extension (for unsigned values) for 16 and 8 bit values on CPUs with 32 bit registers.
(And maybe 64)
well, they have an open bug for PPC
and it's the same bug evident on Sparc
libffi doesn't fall into it
but I think as a side effect of writing parameters out to memory before then reading them back. 18:08
I don't remember exactly.
jnthnwrthngtn I dunno how libffi's license is and how that goes with bundling.
Nicholas but the open bug is from some years ago. And they know why there is a problem. But (I might have missed an update) it didn't get addressed
(I should go AFK for a bit) 18:09
jnthnwrthngtn yeah, afk for dinner 18:16
japhb OK, so there's the build story (was pro, now ?), the development activity (was pro, now con), and the correctness bugs on some platforms (con). Sounds like a net win for libffi at the current moment. Any performance difference that would argue in favor of libdyncall being used for particular platforms? 18:21
nine sourceware.org/libffi/ says "libffi is Free Software. It has a very liberal license. 18:45
According to the openSUSE package it's MIT, and the license is certainly very liberal: github.com/libffi/libffi/blob/master/LICENSE
So no problem with bundling libffi
[Coke] writing a powershell script to do my reinstalls so if I can make this go faster. :| 18:48
it is surprisingly pleasant, given I have to google everything. :) 18:55
19:06 linkable6 left, evalable6 left
[Coke] gist.github.com/coke/5c1ed95ab8232...ac6ccbb706 # analogous to zoffix's old bash script. 19:28
If anyone else wants to use it, I can try to make it slightly more config'able. 19:29
MasterDuke i suspect i would like powershell a lot if i'd come to it before already being very used to bash/linux 19:57
[Coke] it seems nifty, but yah, it's like the 4th thing in my list of things to reach for when trying to automate something. didn't pick raku here because... well. 19:58
20:08 evalable6 joined, linkable6 joined
MasterDuke timo: how difficult would it be to make the profile `race` safe (i.e., not give crazy numbers)? 20:42
i thought running under valgrind might actually keep the numbers sane, but they were the same 20:47
huh. i just tried to build moarvm with `--tsan` and get `probing the size of pointers ....................... Probe gave nonsensical answer '', so something it badly wrong at build/probe.pm line 941.` 20:50
21:08 reportable6 joined
MasterDuke oh, might need to reboot into my updated kernel or something like that, since i can't seem to build with --tsan at any checkout, when i know i did successfully before 21:31
21:31 Kaiepi left 21:40 Kaiepi joined 22:03 squashable6 left 22:05 squashable6 joined 22:28 [Coke] left 22:40 [Coke] joined