| 25 Nov 2022 | |||
| MasterDuke | i just noticed it happened and took advantage of it years ago, hadn't thought about it again until just now | 01:57 | |
| vrurg | Ok, it explains. | ||
| Anyway, I'm working on drifting away from that mechanism and trying to get use of $*CURRENT-FILE in the context of current compunit compilation. | 01:58 | ||
| MasterDuke | cool | 02:00 | |
| nine: with the patch as is and default MoarVM Configure.pl settings, there's no easily noticeable decrease in CORE.e compile time. if i build MoarVM with `--no-mimalloc`, then the patch does seem to improve CORE.e compile times, from ~3.5s down to ~3.3s (both of which are slower than when using mimalloc) | 02:16 | ||
| so admittedly, not the most impactful of changes. i do think reducing allocs is good in general, but i guess amdahl strikes again | 02:22 | ||
| 27 Nov 2022 | |||
| timo | ctrl-c-ing pretty much anywhere inside moar's Configure.pl doesn't reach the configure process which maybe it should | 15:29 | |
| i ctrl-c'd it while "updating submodules" because wifi had just gone down, and it continued thinking everything was fine | |||
| and then of course "make" complained that something in some submodule was missing | 15:30 | ||
| so i was looking into validate_static_frame again and had it do a bit of measuring. i found a bunch of static frames that were small but took suspiciously long to run. however, running them a second time was faster by a big factor, so i'll have to assume it's due to some intermittent work, like maybe mimalloc doing something? | 19:03 | ||
| pro tip: i get much better results from perf record -g when i also supply --call-graph dwarf,4096 | 19:32 | ||
| lizmat | NQP stopped building for me. Steps to reproduce: | 20:30 | |
| git clone github.com/raku/nqp.git | 20:31 | ||
| cd nqp | |||
| perl Configure.pl --gen-moar && make && make test | |||
| all is fine | |||
| update tools/templates/MOAR_REVISION | |||
| perl Configure.pl --gen-moar && make && make test | |||
| after rebuilding MoarVM successfully: | 20:32 | ||
| +++ Preparing MOAR build directories | |||
| ++++++ Building MOAR backend | |||
| +++ Generatinggen/moar/stage1/nqpmo.nqp | |||
| +++ Compilinggen/moar/stage1/nqpmo.moarvm | |||
| make: *** [gen/moar/stage1/nqpmo.moarvm] Killed: 9 | |||
| taking the steps: | 20:36 | ||
| git clone github.com/raku/nqp.git | 20:37 | ||
| cd nqp | |||
| update tools/templates/MOAR_REVISION | |||
| perl Configure.pl --gen-moar && make && make test | |||
| and all is fine | |||
| There is *defintely* something in the current config process borked :-( | |||
| MasterDuke | lizmat: fwiw, i've never run into the problem you're seeing. my setup is three separate repos with a common --prefix | 21:13 | |
| timo: i always use --call-graph=dwarf, but don't know what that `,4096` does | |||
| ugexe: could zef searching be made case insensitive by default? i just search for `mi6` and got 0 hits, then for `app::mi6` and still 0 | 21:27 | ||
| heh, especially since the script it installs is `mi6` | 21:29 | ||
| Guest45 | Hi all | 22:01 | |
| I was watching a presentation about GraalVM, it seemed similar to Parrotvm. Their goals were the same right? | 22:06 | ||
| MasterDuke | i would say similar, not exactly the same though | 22:07 | |
| the goal of enabling polyglot programming is pretty similar, but i don't remember parrot having the goal of enabling compilation to native executables (though i was never involved in parrot, this is just from what i remember reading about it) | 22:09 | ||
| Guest45 | wow | ||
| this is what I was thinking, it didn't produce native exes. | 22:10 | ||
| MasterDuke | huh. i just was testing a patch that made a very small change to implement MVM_recalloc using mi_rezalloc, and it causes an `MoarVM panic: Register types do not match between value and node` early when building nqp. i guess that means somewhere we're MVM_recallocing some memory that wasn't allocated by one of the mimalloc zero-initializing | 22:15 | |
| functions | |||
| hm, a search doesn't find any obvious such cases. | 22:25 | ||
| 28 Nov 2022 | |||
| ugexe | MasterDuke: it used to be, but it lead to confusing outcomes, paticilarky with depends. Generally, zef aims to do whatever a raku use statement would understand | 00:35 | |
| MasterDuke | that makes sense for install, but for searching it seem like i already have to know the exact name to find it, which sort of defeats the purpose | 01:10 | |
| ugexe | For zef search it is supposed to do a less strict search | 01:29 | |
| 29 Nov 2022 | |||
| MasterDuke | ugexe: `zef search mi6` returns 0 results. `zef search Mi6` returns 69 results. `zef search app::mi6` returns 0 results. `zef search App::Mi6` returns 48 results. i would expect both the lowercase versions to return the same number of results as the ones with uppercase (or maybe make a 'did you mean <...>?' suggestion) | 01:47 | |
| ugexe | yeah i agree | 02:04 | |
| the .contains here -- github.com/ugexe/zef/blob/d1fb6176...kumod#L159 -- should be case insensitive | 02:05 | ||
| MasterDuke | i don't know what .contains candidate is being used, but a bunch of them have a `:i(ignorecase)` flag available | 02:08 | |
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/11/29/2022-...assy-core/ | 14:05 | |
| leont | \o/ | 14:42 | |