|
🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
| Geth | rakudo/main: 612dd255a6 | (Daniel Green)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp Make progress on unbreaking the JVM build I was a bit too hasty with my earlier commits. It's still broken after this, but gets farther. |
01:49 | |
|
05:06
MasterDuke joined
|
|||
| MasterDuke | lizmat: any idea about the current jmv error? gist.github.com/MasterDuke17/95bf7...abda6ac228 | 05:53 | |
| *jvm | 06:05 | ||
| i wondered if the line count was off and tried the diff included in that gist, but it didn't change anything | 06:06 | ||
|
06:32
MasterDuke left
09:08
sena_kun joined
|
|||
| lizmat | .tell MasterDuke no idea :-( | 09:33 | |
| tellable6 | lizmat, I'll pass your message to MasterDuke | ||
|
09:53
sena_kun left
|
|||
| Geth | rakudo/liz-Possible: b91cea9adb | (Elizabeth Mattijsen)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp Make Routine $!dispatcher a scalarless attribute As it's only used internally |
10:02 | |
|
12:53
MasterDuke joined
|
|||
| MasterDuke | lizmat: fwiw, it looks like github.com/rakudo/rakudo/commit/99...a7715f9a06 is the commit that broke the jvm build | 12:56 | |
| tellable6 | 2024-03-08T09:33:23Z #raku-dev <lizmat> MasterDuke no idea :-( | ||
| MasterDuke | lizmat: in the new version there's no equivalent of `$param := nqp::hllizefor($param, 'Raku')` (and then later in the code there are comparisons against $param's type). obviously the new code builds and passes a spectest on moarvm, so i wonder if it's a bug in the jvm implementation? | 13:11 | |
| lizmat | MasterDuke: that is probably it... | 13:12 | |
| perhaps add it conditionally on the non-MoarVM backend ? | |||
| MasterDuke | but the new code does seem quite a bit different, i.e., are you sure the different checks are the same? | ||
| lizmat | pretty sure they do... at least passes all test and spectest | 13:13 | |
| fwiw, I thought I'd maybe mixed up the DEFINED/UNDEFINED check, but no: if I switch that, the spectest breakage is impressive :-) | 13:14 | ||
| MasterDuke | it's this line github.com/rakudo/rakudo/commit/99...d3c53L3865 that i'm wondering about | 13:15 | |
| because that seems it would matter when it gets down to github.com/rakudo/rakudo/commit/99...3874-L3876 | 13:16 | ||
| lizmat | github.com/rakudo/rakudo/commit/99...d3c53R3863 | ||
| later on, only the type is checked, so I thought it make it clearer to make it the type object there already | 13:18 | ||
| it also allowed the if structure to become a ternary | |||
| MasterDuke | hm. i guess .WHAT is doing the equivalent... | ||
| lizmat | well, perhaps not: I'd suggest doing the HLLize there to see if it fixes that | ||
| MasterDuke | hm. i could put all the old code back in an `#?if !moar` block, but maybe i can figure out a smaller change... | 13:24 | |
| lizmat | did you try putting the hllize on github.com/rakudo/rakudo/commit/99...d3c53R3863 ?? | 13:27 | |
| MasterDuke | trying `my $type := nqp::hllizefor($arg, 'Raku').WHAT;` now. however, it takes about 800s to fail, so have to wait a bit to see | 13:29 | |
| lizmat | yeah... it just takes too long on the JVM :-( | 13:35 | |
| MasterDuke | this branch i'm working on is a bit faster, but it's still pretty slow. it seems to be the rakuast stuff. '+++ Generating    gen/jvm/ast.nqp' is where half the total time is going (~450s on my branch). stage parse for core.c is only ~90s (compared to 45s for moarvm) | 13:39 | |
| on main '+++ Generating    gen/jvm/ast.nqp' takes ~1400s | |||
| (i just found out about gnomon and am loving it, makes figuring out these timings so easy) | 13:40 | ||
| heh. now the build dies in a different way, but i think later and maybe because of my branch. now i get to test the *long* build on main... | 13:49 | ||
| lizmat | meh... ok, if I push another micro opt in the mean time? | ||
| MasterDuke | sure | ||
| Geth | rakudo/main: fda0d13209 | (Elizabeth Mattijsen)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp Don't bother checking natives if no typecheck requested |
13:51 | |
| MasterDuke | heh. '+++ Generating    gen/moar/ast.nqp' is only 12s...i wonder why the jvm is *so* much worse, it's not usually 100x slower | 14:25 | |
|
14:28
[Tux] left
|
|||
| MasterDuke | hm. don't think that change was right. now it's dying with `Ambiguous call to Bool` | 14:29 | |
| ab5tract | I’ve said it before but maybe it’s time to put the JVM implementation out to pasture | 14:30 | |
|
14:31
[Tux] joined
|
|||
| ab5tract | I don’t really like that we advertise a backend that is mostly unused, often broken, and without parity. | 14:31 | |
| It doesn’t help that when people read that Raku runs on the JVM, they imagine that it interoperates with other JVM languages, which it doesn’t | 14:33 | ||
| I don’t mean that to discount your valiant efforts MasterDuke! | |||
| lizmat | or bartolin's | 14:34 | |
| Geth | rakudo/main: 3e476241be | (Elizabeth Mattijsen)++ | 2 files Cache dispatch info on Routine object The dispatch order logic basically stores a list of hashes with condensed information about each dispatchee. And this is kept with the proto, to allow for faster "find_best_dispatchee" logic. However, the condensed information about a candidate was re-created ... (10 more lines) |
19:29 | |
| japhb | Nice win, lizmat++ | 21:41 | |
|
22:08
sena_kun joined
22:12
MasterDuke left
22:45
MasterDuke joined
23:36
sena_kun left
|
|||
| MasterDuke | i agree that the jvm backend is not all that it could be. but generally it doesn't take too much effort to keep it working | 23:52 | |
| i really wish someone else knew truffle well enough to help out on that branch. even in it's very incomplete state it showed lots of promise | 23:53 | ||
| unfortunately i don't really understand it and pmurias hasn't been able to work on it for a while now | |||