[03:20] *** evalable6 left [03:20] *** linkable6 left [03:22] *** linkable6 joined [03:23] *** evalable6 joined [06:32] *** frost-lab joined [07:53] *** evalable6 left [07:53] *** linkable6 left [07:55] *** linkable6 joined [07:56] *** evalable6 joined [08:08] *** Altai-man joined [09:09] *** sena_kun joined [09:10] *** Altai-man left [09:18] *** dumarchie joined [09:19] Hi MasterDuke, I got the following error in gmake: [09:19] 2020-11-05T18:40:28Z #moarvm dumarchie please check out if https://github.com/MoarVM/MoarVM/pull/1377 fixes build on MinGW [09:19] Found C:\raku\rakudo\install\bin\moar.exe version 2020.11-47-g1c7358004, which is too old. Wanted at least 2020.11-85-g82a34e25a at C:/raku/rakudo/nqp/3rdparty/nqp-configure/lib/NQP/Config.pm line 192. [09:19] Should I just remove the whole install directory? [09:30] dumarchie: i think if you have a new enough rakudo there's a `--force-rebuild` option [09:32] Ah, I will try to remember that for next time. I removed the install directory already and am now rebuilding everything from scratch. [09:33] that'll work too. looks like --force-rebuild was added end of last month [09:33] (y) [09:37] Usually the message is simply correct though [09:39] Hmm, `gmake test` failed because there was no plan found in the TAP output of t\04-nativecall\17-libnames.t [09:40] So it crashed before even putting out a test plan [09:40] I'll `gmake install` anyway [09:44] Offline life is calling me. I'll check in again later today. [09:45] Offline life? I seem to vaguely remember that... [09:45] =D [09:45] *** dumarchie left [13:08] *** Altai-man joined [13:10] *** sena_kun left [13:43] *** brrt joined [13:44] good *, brrt [13:46] good * nwc10 [13:51] *** MasterDuke left [13:51] *** lucasb joined [14:20] *** MasterDuke joined [14:21] brrt: picked up an apple m1 yet? [14:24] didn't, couldn't justify the expense [14:25] and $work needs far more than the 8gb that apple ships [14:25] I might get a raspberry pi 400 though [14:25] ah, too bad [14:25] that stuff is awesome [14:25] yeah, those are pretty cool though [14:28] how generic would an aarch64 port of the jit be? i assume it would work on both the rpi4 and the m1? [14:28] it depends on the call convention I guess [14:29] we don't do any specialization on the x86-64 version for cpu capabilities, right? e.g., sse3 vs avx [14:30] I think in the basic opcode set there's very little specialization you can do [14:30] all the special stuff, as far as I know anyway, is vector/simd processing [14:31] and you need a bunch of analysis to prove that's necessary or even useful [14:31] I imagine that a hypothetical port to aarch64 will mean a major refactor as well [14:32] runtime analysis? [14:33] not sure I parse correctly, but you'd need to analyze the code-under-optimization, at runtime, to prove that the code benefits from vectorization, I'm actually not sure the JIT is the right place for it [14:33] the spesh IR is much more powerful [14:40] *** sxmx left [14:41] interesting [14:44] *** sxmx joined [14:46] the raspberry pi 400 has less RAM than the bare-bones 8GB Pi (well, d'oh!) [14:47] and last night's discovery is that I can build Rakudo 32bit on a 2GB Mips machine, but not 64bit on the same 2GB Mips machine [14:47] so 4GB likely is enough for aarch64 64 bit [14:47] (I have the hardware - I could test this if I rewrite an SD card) [14:47] but I'm not sure how much of a squeeze it is [14:47] on the other hand, the raspberry pi 400 is far more cute [14:48] I believe that we're doing better than PyPy [16:15] *** dumarchie joined [16:17] MasterDuke, I added a nice backtrace to #1237. Can you let me know if you think if it's useful to try again with `MVM_JIT_DISABLE=1` and/or `MVM_SPESH_DISABLE=1`? [16:34] dumarchie: definitely always helps :-) [16:40] Okay, I'll try and trigger the panic again with both disabled. [16:48] Still panic. I added the `gdb` output to https://github.com/MoarVM/MoarVM/issues/1237 [16:51] It looks like the panic is triggered by `prefix:<⚛>`, but what do I know?=# [16:56] Let me know it there's anything else I can do. [16:58] *** zakharyas joined [17:09] *** sena_kun joined [17:10] *** Altai-man left [17:13] *** brrt left [17:35] *** leont joined [17:35] Looking at https://github.com/MoarVM/MoarVM/blob/master/src/strings/windows1252.c#L75 [17:36] wouldn't it make sense to change the < 0 condition to < 160 ? [17:36] so it can bypass the large switch statement because in the end it would end up in the default anyway ? [17:40] hmmm.. I guess not: /* If it's within ASCII just pass it through */ [17:40] if (0 <= codepoint && codepoint <= 127) { [19:00] *** vesper11 left [21:08] *** Altai-man joined [21:09] ¦ MoarVM/modern-raku-script-extensions: 16 commits pushed by (Elizabeth Mattijsen)++ [21:09] ¦ MoarVM/modern-raku-script-extensions: review: https://github.com/MoarVM/MoarVM/compare/da5babd48fea^...11e9877c4b6a [21:10] ¦ MoarVM: lizmat++ created pull request #1401: Modern raku script extensions [21:10] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1401 [21:11] *** sena_kun left [21:51] *** patrickb joined [22:15] *** zakharyas left [22:41] *** Altai-man left [22:42] *** patrickb left [22:53] *** dumarchie left