|
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
|
|||