[00:06] *** reportable6 left [00:07] *** reportable6 joined [03:06] *** frost joined [04:57] *** bisectable6 left [04:57] *** benchable6 left [04:57] *** releasable6 left [04:57] *** committable6 left [04:57] *** quotable6 left [04:57] *** statisfiable6 left [04:57] *** bloatable6 left [04:57] *** greppable6 left [04:57] *** evalable6 left [04:57] *** unicodable6 left [04:57] *** sourceable6 left [04:57] *** tellable6 left [04:57] *** shareable6 left [04:57] *** coverable6 left [04:57] *** squashable6 left [04:57] *** notable6 left [04:57] *** nativecallable6 left [04:57] *** reportable6 left [04:57] *** linkable6 left [04:58] *** greppable6 joined [04:58] *** bisectable6 joined [04:58] *** bloatable6 joined [04:59] *** quotable6 joined [04:59] *** tellable6 joined [04:59] *** coverable6 joined [05:00] *** reportable6 joined [05:58] *** unicodable6 joined [05:58] *** squashable6 joined [05:58] *** nativecallable6 joined [05:59] *** evalable6 joined [05:59] *** committable6 joined [06:00] *** releasable6 joined [06:00] *** notable6 joined [06:00] *** statisfiable6 joined [06:07] *** reportable6 left [06:07] *** reportable6 joined [06:56] good *, * [07:00] *** shareable6 joined [07:31] morning. i think https://github.com/MoarVM/MoarVM/pull/1673 is good to go, anybody got a couple min to take a look? [08:59] *** linkable6 joined [10:00] *** benchable6 joined [11:00] *** sourceable6 joined [12:06] *** reportable6 left [12:07] *** reportable6 joined [13:30] *** linkable6 left [13:30] *** evalable6 left [13:33] *** linkable6 joined [13:33] *** evalable6 joined [13:52] *** frost left [14:17] Stage parse : 914.717 [14:17] I feared it would be worse :D [14:26] that's with what? [14:27] https://build.opensuse.org/project/monitor/devel:languages:perl6?arch_riscv64=1&blocked=1&broken=1&building=1&defaults=0&deleting=1&dispatching=1&failed=1&finished=1&locked=1&repo_openSUSE_Factory_RISCV=1&scheduled=1&signing=1&succeeded=1&unresolvable=1 [14:28] 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:30] Holy cow that's slow. Is that normal for RiscV, or are they using a very low-spec box? [14:31] Actually I think it's emulated: https://build.opensuse.org/monitor [14:34] *phew* [14:35] Native aarch64 took ~16 minutes to build https://build.opensuse.org/package/live_build_log/devel:languages:perl6/rakudo/openSUSE_Leap_15.3/aarch64 with stage parse of 265s [14:37] *** squashable6 left [14:57] *** cognominal_ joined [14:57] *** cognominal left [14:58] aarch64 seems similar to what I see on the GCC compile farm [15:40] *** squashable6 joined [16:39] hmmm.... I just had a weird one-off [16:39] $ zef install . [16:39] No such private method 'SET-SELF' on Map [16:39] unrepeatable :-( [16:46] lizmat: https://github.com/rakudo/rakudo/issues/4655 [16:47] It's one of those "this really needs fixing at some point but I'm also really dreading it" issues... [16:48] right .. ok, well, just confirmation it's still there [16:52] 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:53] hysterical raisins ? [16:54] 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:56] Given the list of supported platforms on https://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:59] Fair enough. [17:25] *** cognominal_ left [17:31] I don't remember. I assume that jnthnwrthngtn knew once. [17:33] Seems like I just can't get one successful build on s390x :/ https://build.opensuse.org/package/live_build_log/devel:languages:perl6/rakudo/openSUSE_Leap_15.3/s390x [17:33] 15-gh_1202.t and repl.t fail most of the time [18:02] libdyncall's build story on Windows was, at the time, significantly easier [18:03] and you wanted to *bundle* one of the two? [18:03] so picked the one that was easier to bundle and make work? [18:04] 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. [18:04] So was the clear path of least resistence at the time [18:06] I think libffi is probably more actively developed today [18:06] *** reportable6 left [18:06] And maybe it's less of a pain or we've more time to deal with the pain :) [18:06] dyncall seems to have stalled, despite acknowledging that it has structural bugs with handling unsigned 16 bit parameters on some platforms [18:06] and I think 8 [18:07] 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] 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. [18:07] (And maybe 64) [18:07] well, they have an open bug for PPC [18:07] and it's the same bug evident on Sparc [18:07] libffi doesn't fall into it [18:08] 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. [18:08] I dunno how libffi's license is and how that goes with bundling. [18:08] 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 [18:09] (I should go AFK for a bit) [18:16] yeah, afk for dinner [18:21] 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:45] 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: https://github.com/libffi/libffi/blob/master/LICENSE [18:45] So no problem with bundling libffi [18:48] <[Coke]> writing a powershell script to do my reinstalls so if I can make this go faster. :| [18:55] <[Coke]> it is surprisingly pleasant, given I have to google everything. :) [19:06] *** linkable6 left [19:06] *** evalable6 left [19:28] <[Coke]> https://gist.github.com/coke/5c1ed95ab82323ad6c949eac6ccbb706 # analogous to zoffix's old bash script. [19:29] <[Coke]> If anyone else wants to use it, I can try to make it slightly more config'able. [19:57] i suspect i would like powershell a lot if i'd come to it before already being very used to bash/linux [19:58] <[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. [20:08] *** evalable6 joined [20:08] *** linkable6 joined [20:42] timo: how difficult would it be to make the profile `race` safe (i.e., not give crazy numbers)? [20:47] i thought running under valgrind might actually keep the numbers sane, but they were the same [20:50] 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.` [21:08] *** reportable6 joined [21:31] 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] *** Kaiepi left [21:40] *** Kaiepi joined [22:03] *** squashable6 left [22:05] *** squashable6 joined [22:28] *** [Coke] left [22:40] *** [Coke] joined