Xliff . 00:59
\o
Geth roast: df8c13bbb5 | (Elizabeth Mattijsen)++ | S32-array/multislice-6e.t
Add 6.e array multislice fast-path tests

All of the tests so far had an explicit (but potentially false) adverb, which caused always the slow paths to be taken. Which obscured a blatant bug yesterday. This adds tests for the fast code paths of array multislicing.		 09:56
nqp: a02126987f | (Elizabeth Mattijsen)++ | docs/ops.markdown
Fix copypasto
 10:03
lizmat Files=1336, Tests=113904, 222 wallclock secs (28.99 usr 8.59 sys + 3081.45 cusr 299.90 csys = 3418.93 CPU)
Geth nqp: e305b1e1fa | (Elizabeth Mattijsen)++ | docs/ops.markdown
Document nqp::without
 10:16
Geth rakudo: 97d473b9a5 | (Elizabeth Mattijsen)++ | src/core.c/Str.pm6
Make Str.raku about 35% faster

  - don't use multiple nqp::substr and nqp::ordats
  - use an ord-based lookup for common escapes, rather than a char-based one
  - make lookup initialization a setting compile time thing		 12:14
[Tux] Rakudo v2020.10-20-g316902ddd (v6.d) on MoarVM 2020.10-11-g608b90eb1
csv-ip5xs0.853 - 1.041
csv-ip5xs-208.491 - 8.749
csv-parser28.898 - 28.902
csv-test-xs-200.409 - 0.412
test8.489 - 8.807
test-t2.041 - 2.197
test-t --race0.929 - 1.084
test-t-2035.365 - 35.717
test-t-20 --race9.779 - 10.127
 12:21
lizmat [Tux]: could you try reverting b1912d9fcf4d56ddbd459 and see if that gives a better result ? 12:23
linkable6 (2020-10-26) github.com/rakudo/rakudo/commit/b1912d9fcf Replace all simple nqp::if(42,foo,bar) with ternaries (#3957)
[Tux] running 12:27
lizmat [Tux]++
Geth nqp: 7868823383 | (Elizabeth Mattijsen)++ | docs/ops.markdown
Elaborate a bit about nqp::where

And how it is different from nqp::objectid.		 12:33
[Tux] Rakudo v2020.10-21-gdf1a84afb (v6.d) on MoarVM 2020.10-11-g608b90eb1
csv-ip5xs0.902 - 0.960
csv-ip5xs-208.908 - 8.912
csv-parser29.120 - 30.153
csv-test-xs-200.403 - 0.420
test8.416 - 8.478
test-t2.129 - 2.129
test-t --race0.930 - 0.930
test-t-2035.817 - 35.851
test-t-20 --race10.200 - 10.395
 12:44
so not the cause
lizmat ok, so that doesn't make a difference
yup
ok, good to know :-)
Geth rakudo: a541aed81b | (Elizabeth Mattijsen)++ | src/core.c/Parameter.pm6
Make sigils2bit mapper a setting compiler time thing

No further changes		 12:57
lizmat afk for a few hours&
[Coke] lizmat++ 14:54
Geth nqp: 27ad522ff8 | Coke++ | docs/ops.markdown
Documentation cleanup

Remove note about undoc'd opcodes. This is a note for our doc creators, not our doc readers.
Cleanup some headings (VM-specific opcodes noted with the opcode, not at the header.		 15:10
Geth nqp: 9f14b2b6cc | Coke++ | docs/ops.markdown
Add note about HLL to opsdocs
 17:58
nqp: 49bd5b2c1b | Coke++ | docs/ops.markdown
fix some MD formatting
nine Funny....after some large detours due to problems actually unrelated to in-process-precompilation, I get stuck on an issue that seems quite basic. 18:09
lizmat which is ?
nine The situation is: a script using a module "Foo", and a module in a nested name space "Foo::Bar". Foo::Bar contains an our scoped sub with a default value for an argument (just ''). The script calls this sub using the fully qualified name Foo::Bar::baz(). This explodes with a Object of type Str in QAST::WVal, but not in SC 18:11
The object in question is the default value (''). And the error happens when trying to run the compiler stub for the foo sub, i.e. as if it was called during compilation. But actually precompilation of that module was finished and the module loaded which should install the sub in a fully compiled and functional state. 18:13
Oh and Foo::Bar uses Foo as well
I lack a good idea on how to find out why the script is still referencing the compilation stub of the sub instead of the code object loaded from the precomp file 18:18
lizmat I see.. 18:42
Geth rakudo: 0a4eaf3110 | (Elizabeth Mattijsen)++ | src/core.c/Parameter.pm6
Simplify constant hash initialization

And probably also unbreak the JVM build.		 19:38
rakudo: Altai-man assigned to patrickbkr Issue Make the offered Rakudo (Windows) versions consistent github.com/rakudo/rakudo/issues/3996
vrurg++ created pull request #3997: Make auto-generated mixin role be of language revision 'c'
 20:02
[Coke] question about round - the units parameter was, i thought, just supposed to deal with the least significant place, but instead it seems to do a closest modulo. 23:59
m: say round(1000, .01); say round(1000, 23.01)
camelia 1000
989.43

Powered by Cro and the Raku® Programming Language.

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

Thank you!