|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
03:20
evalable6 left,
linkable6 left
03:22
linkable6 joined
03:23
evalable6 joined
06:32
frost-lab joined
07:53
evalable6 left,
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
|
|||
| dumarchie | Hi MasterDuke, I got the following error in gmake: | 09:19 | |
| tellable6 | 2020-11-05T18:40:28Z #moarvm <timotimo> dumarchie please check out if github.com/MoarVM/MoarVM/pull/1377 fixes build on MinGW | ||
| dumarchie | 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. | ||
| Should I just remove the whole install directory? | |||
| MasterDuke | dumarchie: i think if you have a new enough rakudo there's a `--force-rebuild` option | 09:30 | |
| dumarchie | Ah, I will try to remember that for next time. I removed the install directory already and am now rebuilding everything from scratch. | 09:32 | |
| MasterDuke | that'll work too. looks like --force-rebuild was added end of last month | 09:33 | |
| dumarchie | (y) | ||
| nine | Usually the message is simply correct though | 09:37 | |
| dumarchie | Hmm, `gmake test` failed because there was no plan found in the TAP output of t\04-nativecall\17-libnames.t | 09:39 | |
| nine | So it crashed before even putting out a test plan | 09:40 | |
| dumarchie | I'll `gmake install` anyway | ||
| Offline life is calling me. I'll check in again later today. | 09:44 | ||
| nine | Offline life? I seem to vaguely remember that... | 09:45 | |
| dumarchie | =D | ||
|
09:45
dumarchie left
13:08
Altai-man joined
13:10
sena_kun left
13:43
brrt joined
|
|||
| nwc10 | good *, brrt | 13:44 | |
| brrt | good * nwc10 | 13:46 | |
|
13:51
MasterDuke left,
lucasb joined
14:20
MasterDuke joined
|
|||
| MasterDuke | brrt: picked up an apple m1 yet? | 14:21 | |
| brrt | didn't, couldn't justify the expense | 14:24 | |
| and $work needs far more than the 8gb that apple ships | 14:25 | ||
| I might get a raspberry pi 400 though | |||
| MasterDuke | ah, too bad | ||
| brrt | that stuff is awesome | ||
| MasterDuke | yeah, those are pretty cool though | ||
| how generic would an aarch64 port of the jit be? i assume it would work on both the rpi4 and the m1? | 14:28 | ||
| brrt | it depends on the call convention I guess | ||
| MasterDuke | we don't do any specialization on the x86-64 version for cpu capabilities, right? e.g., sse3 vs avx | 14:29 | |
| brrt | 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 | |||
| 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 | |||
| MasterDuke | runtime analysis? | 14:32 | |
| brrt | 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
|
|||
| MasterDuke | interesting | 14:41 | |
|
14:44
sxmx joined
|
|||
| nwc10 | the raspberry pi 400 has less RAM than the bare-bones 8GB Pi (well, d'oh!) | 14:46 | |
| 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 | |||
| (I have the hardware - I could test this if I rewrite an SD card) | |||
| but I'm not sure how much of a squeeze it is | |||
| on the other hand, the raspberry pi 400 is far more cute | |||
| I believe that we're doing better than PyPy | 14:48 | ||
|
16:15
dumarchie joined
|
|||
| dumarchie | 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:17 | |
| brrt | dumarchie: definitely always helps :-) | 16:34 | |
| dumarchie | Okay, I'll try and trigger the panic again with both disabled. | 16:40 | |
| Still panic. I added the `gdb` output to github.com/MoarVM/MoarVM/issues/1237 | 16:48 | ||
| It looks like the panic is triggered by `prefix:<⚛>`, but what do I know?=# | 16:51 | ||
| Let me know it there's anything else I can do. | 16:56 | ||
|
16:58
zakharyas joined
17:09
sena_kun joined
17:10
Altai-man left
17:13
brrt left
17:35
leont joined
|
|||
| lizmat | Looking at github.com/MoarVM/MoarVM/blob/mast...1252.c#L75 | 17:35 | |
| 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 ? | |||
| 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
|
|||
| Geth | MoarVM/modern-raku-script-extensions: 16 commits pushed by (Elizabeth Mattijsen)++ review: github.com/MoarVM/MoarVM/compare/d...e9877c4b6a |
21:09 | |
| MoarVM: lizmat++ created pull request #1401: Modern raku script extensions |
21:10 | ||
|
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
|
|||