Geth nqp/JJ-patch-2: 21c199266b | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | README.pod
Minor corrections

Here and there.		 08:46
lizmat m: m: my int8 @a = ^10; dd @a[^3]; dd @a[0,1,2] 10:19
camelia array[int8].new(0, 1, 2)
(0, 1, 2)
lizmat apparently nativearray[Range] is handled differently 10:20
feels that either they should both return the same native type, or both should return List 10:21
the latter breaks some spectests though :-(
Geth rakudo/faster-slice-access: 6df0b4e160 | (Elizabeth Mattijsen)++ | src/core.c/native_array.pm6
Remove specific nativearray[Range] candidate

It's falling back to the POSITIONS sub, which will be removed.
This breaks some spectests that expect an array of the same native type to be returned. On the other hand, without this specific candidate, slicing a native array is marginally faster.		 11:06
rakudo/faster-slice-access: dd57a29c81 | (Elizabeth Mattijsen)++ | 7 files
Remove the no longer needed internal POSITIONS sub
 11:39
brrt happy new year #raku-dev 11:54
lizmat brrt best wishes to you too! 11:57
Geth rakudo/faster-slice-access: 39 commits pushed by (Elizabeth Mattijsen)++
review: github.com/rakudo/rakudo/compare/d...1586054965		 12:00
lizmat rebase
Geth rakudo/faster-slice-access: ce6724289c | (Elizabeth Mattijsen)++ | 4 files
Mark generated classes as implementation detail
 12:18
Geth rakudo/faster-slice-access: cbdc32bbc6 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals/PostcircumfixAdverbs.pm6
Address exploding on the JVM backend
 12:24
lizmat bisectable6: my str @a = <a b c d e f g h i j>; dd @a[*-4 .. *-2] 12:38
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/f131fe569bf3e0ed1d...5190a39320
lizmat, Bisecting by exit code (old=2020.11 new=2020.12). Old exit code: 0
lizmat, bisect log: gist.github.com/65abf27c249c5eed68...f0175cd24f
lizmat, (2020-12-04) github.com/rakudo/rakudo/commit/70...69c6feed6b
lizmat, Bisecting by output (old=2018.04.1 new=2018.05) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/eae393eed7ebc7ec16...74e9b5bbd8 12:39
lizmat, (2018-05-08) github.com/rakudo/rakudo/commit/67...143612dcf3
lizmat, Bisecting by exit code (old=2016.02 new=2016.03). Old exit code: 1
lizmat, bisect log: gist.github.com/b0d21b004d24d136c7...c1135157ca
lizmat, (2016-03-17) github.com/rakudo/rakudo/commit/ee...f405d8f3cd
lizmat, Output on all releases and bisected commits: gist.github.com/f80ac00e16b89c5782...0bcdeb5305
lizmat m: my str @a = <a b c d e f g h i j>; dd @a[*-4 .. *-2] 12:40
camelia Too few positionals passed; expected 2 arguments but got 1
in block <unit> at <tmp> line 1
lizmat bisectable6: my str @a = <a b c d e f g h i j>; dd @a[1,2,*] 12:43
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/962b121a6003d1369b...96791f97f4
lizmat, Bisecting by exit code (old=2020.11 new=2020.12). Old exit code: 0
lizmat, bisect log: gist.github.com/85f451c16600968f91...c715a8e5a7
lizmat, (2020-12-04) github.com/rakudo/rakudo/commit/70...69c6feed6b
lizmat, Bisecting by output (old=2018.04.1 new=2018.05) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/59711e908c66a95a6f...dff5af2f6a
lizmat, (2018-05-08) github.com/rakudo/rakudo/commit/67...143612dcf3
lizmat, Bisecting by exit code (old=2016.02 new=2016.03). Old exit code: 1 12:44
lizmat, bisect log: gist.github.com/8ef6ecebdd0ae7f9c0...4a62b3d0b0
lizmat, (2016-03-17) github.com/rakudo/rakudo/commit/ee...f405d8f3cd
lizmat, Output on all releases and bisected commits: gist.github.com/511ed6e0a8e3666935...3f53bd59e4
nine Interesting: there's an NQP_FLAGS_EXTRA in tools/templates/js/Makefile.in but it's never used anywhere 12:52
Geth rakudo/faster-slice-access: f12508bfbd | (Elizabeth Mattijsen)++ | src/core.c/native_array.pm6
Restore native @a[Range] candidate

Turns out it was needed after all. Just without a call to POSITIONS!		 13:23
gfldex I got an individual multi candidate. Is there any way to start the MMD from that point? 15:14
m: multi sub f() {}; my &main = multi sub f(1) {}; dd &main; 15:15
camelia Sub &main = multi sub f (1) { #`(Sub|86992448) ... }
gfldex I only got the &main and can't get a reference to the other candidate.
Geth rakudo/faster-slice-access: 462c7a6e7c | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals/PostcircumfixAdverbs.pm6
Better fix for problems on JVM backend
 16:06
patrickb o/ 17:25
nwc10 \o 17:26
patrickb I'm currently trying out github.com/Raku/nqp/pull/691 and wonder about the JVM failure (dev.azure.com/jjmerelo0004/jjmerel...&l=57) 17:28
Do I possibly need a rebootstrap or something like that? (Respective changes for MoarVM interestingly didn't require a rebootstrap.) 17:30
nwc10 sensible question - I don 17:45
t know
patrickb rebooting. Back in a bit... 17:48
Geth rakudo: 8150a2864c | (Elizabeth Mattijsen)++ | 2 files
Allow native @a[*-4 .. *..2] to work

This was apparently broken a little while ago, and nobody noticed. Basically, Callable candidates must handle Callables that take more than a single argument, and that may return something else than an Int.		 17:54
tbrowder ugexe: having a problem with zef. just released a new module PDF::Writer with a bin file executable name "pdfwriter". I execute "zef install PDF::Writer" and it finds it on cpan and proceeds to test and install. It reports "1 bin/ script [pdf-rewriter.raku] installed to /home/tbrowde/.raku/bin" and I don't know where that executable is coming from. 18:39
the script works fine when installed from the local host and the local source of the module's repo. 18:40
module was released to cpan by mi6 18:41
tbrowder ok, i see the *.raku script was from a module dependenc... 19:29
bartolin patrickb: I'm pretty sure changing the arguments for spawnprocasync needs a bootstrap for the JVM backend 19:42
lizmat: is the faster-slice-access supposed to pass all spectests? It compiles on the JVM and I could give it a try ... 19:50
*faster-slice-access branch
lizmat bartolin: the faster-slice-access branch breaks a few spectests 21:31
1. because some error messages have become more specific
2. because a lazy iterator for positions no longer means a lazy result
the latter behaviour was deemed "experimental" 21:34
patrickb What's the correct procedure for doing a rebootstrap for JVM? One of the changes is in src/core/testing.nqp. With that change the stage 1 build fails, without stage 2 fails. 23:30
What might work: Build a stage 1 (with the change in src/core/testing.nqp excluded). Copy stage 1 to 0. Do a fresh run with that new stage 0 (and all changes applied) and then copy stage 2 to 0. 23:35
That's not what the docs say, though.

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!