|
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. |
|||
| MasterDuke | these are the diffs, think i should go ahead and PR them? | 00:12 | |
| gist.github.com/MasterDuke17/e0de6...74ed02e4b5 | |||
|
07:26
sena_kun joined
07:38
sena_kun left
08:56
MasterDuke left
|
|||
| timo | does `if !nqp::isnull($fates)` generate different code from `unless nqp::isnull($fates)`? do we do nothing with $fates after the while loop, so that there is no difference between assigning $EMPTY to $fates or using "last" to jump out of the loop? | 09:44 | |
| also, i'm wondering if it would be feasible to reuse one array for the return value of nfa.run over multiple consecutive runs, and if there's any win to be had there | 09:46 | ||
| that requires a simple change in the moar portions of the nfa code (switch first argument to read instead of write), then take an array as input, and put new fates in it. but the code in nqp (and maybe something in rakudo) to really take advantage of it would be more tricky | 09:55 | ||
| any potential wins may be insignificant, however | 10:28 | ||
| nine | I have an rr recording of a segfault because we try to change a VMArray's type to Block when repossessing | 11:10 | |
| But I think that's not useful. This crash is just a result of b0rked precomp files, presumably due to non-reproducible builds. | 11:13 | ||
| timo | is there something we're not putting in the hash that makes the precomp file's identity that changed? | 11:37 | |
| could this be related to having to run Configure.pl in moar so that nqp's Configure sees that the revision is new enough? | 11:38 | ||
| nine | I think it's rather that we generate some things in random order | 11:39 | |
| i.e. hash randomization | 11:40 | ||
| lizmat | fwiw, I taught myself to nuke the install dir every time I run Configure.pl in rakudo | ||
| not doing that just means a big chance of things mysteriously crashing | 11:41 | ||
| timo | this is not simply about serializing hashes into our serialized blobs, right? this is about order of doing stuff inside the compiler being based on randomized hash order? | ||
| lizmat | at a later, more inconvenient time | ||
| nine | timo: yes | 11:46 | |
|
14:13
coleman left
14:21
coleman joined
|
|||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/08/19/2024-...ing-ahead/ | 14:51 | |
|
16:40
sena_kun joined
16:50
lizmat left
16:51
lizmat joined
|
|||
| lizmat | is there a way to find out if an exception is resumable *before* trying to .resume it ? | 19:08 | |
| ab5tract | I encountered that same scenario recently. It’s an HLL solution but I ended up with try .resume, with an optional orelse | 19:17 | |
| Though that only applies works if the plan is to .resume it if it can resume | 19:19 | ||
|
21:47
sena_kun left
23:01
MasterDuke joined
|
|||