Geth nqp: softmoth++ created pull request #638:
Fix sprintf() with *-specified negative width argument		 04:05
lizmat Files=1306, Tests=111304, 213 wallclock secs (28.59 usr 8.26 sys + 3001.01 cusr 272.61 csys = 3310.47 CPU) 11:05
Geth nqp: 17fa91b03f | (Tim Smith)++ | 2 files
Fix sprintf() with *-specified negative width argument
 11:10
nqp: bf3fb540ba | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files
Merge pull request #638 from softmoth/sprintf-minus

Fix sprintf() with *-specified negative width argument
Geth rakudo: 5b86436c49 | (Christian Bartolomäus)++ | src/core.c/Rakudo/Iterator.pm6
[JVM] Use typed variant of nqp::shift

  ... because $!dots has been initialized with nqp::list_s().
Make S32-io/dir.t pass again.		 11:27
lizmat bartolin_++ 11:28
Geth roast: 4bf43757c4 | (Elizabeth Mattijsen)++ | S32-io/child-secure.t
Add test file for IO::Path.child(foo, :secure)

Shamelessly transmogrified from the tests of IO::Path::ChildSecure		 12:47
rakudo: dc4fcb0948 | (Elizabeth Mattijsen)++ | 2 files
Add support for :secure in IO::Path.child

  - shamelessly transmogrified the code from IO::Path::ChildSecure
  - added test-file to "make spectest"
So basically, to get the IO::Path::ChildSecure semantics, you will need to pass the ":secure" named parameter to .child as well. The IO::Path.add ... (5 more lines)		 12:51
lizmat since :secure is opt-in, this should not have broken anything in the ecosystem, nor should it have broken IO::Path::ChildSecure 12:53
lizmat .tell timotimo if you want to see an exploding --profile, try running "IO::Spec::Unix.tmpdir for ^10000" 12:56
tellable6 lizmat, I'll pass your message to timotimo
Geth rakudo: 4103a3095e | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Simplify creation of IO::Path::xxx classes

More for maintenance convenience than anything else		 13:18
travis-ci Rakudo build failed. Sylvain Colinet 'Make the 'is' routine in Test not throwing an error on failure when the type can't be stringified, falling back on .raku instead. 13:22
travis-ci.com/Skarsnik/rakudo/builds/167894577 github.com/Skarsnik/rakudo/compare...e94623bccb
Geth ¦ problem-solving: lizmat assigned to jnthn Issue Should IO::Path.child default to :secure semantics github.com/Raku/problem-solving/issues/198 13:36
rakudo: ecd06c9f9a | (Elizabeth Mattijsen)++ | src/core.c/IO/Spec/Win32.pm6
Make IO::Spec::Win32.basename about 1.7x as fast

  - convert to native string in signature
  - use nqp ops		 13:39
Geth rakudo: 6d427d472b | (Elizabeth Mattijsen)++ | src/core.c/IO/Spec/Win32.pm6
Make IO::Spec::Win32.tmpdir about 1.8x as fast

  - use for loop with return instead of first()		 14:28
bartolin_ lizmat: I think I've found something with my "VMArray: Can't shift from an empty array" bug (github.com/rakudo/rakudo/issues/3707). Do you think my reasoning makes sense. 16:48
nine bartolin_: so p6argvmarray on JVM gets the wrong CallsiteDescriptor when called in a nested block? 16:55
bartolin_ nine: yes, that's what I think. But since the code only runs with optimizer=2, it looks fragile to me for MoarVM, too. 16:58
nine Or is it more like that block getting flattened away in QASTCompilerMAST while it doesn't on the JVM?
Oh, so it gets optimized away even earlier?
But why only on MoarVM then? Isn't the optimizer backend agnostic?
bartolin_ I'm pretty sure there are some optimizations that are not possible (or don't work) on the JVM backend. I've seen other differences there in the past. 17:00
nine I find only a few about spesh plugins 17:01
bartolin_ hmm, the test file S16-io/put.t works with --optimize=1 on MoarVM, too. 17:02
Geth nqp: andreoss++ created pull request #639:
[jvm] Put all @Override in place
bartolin_ has to run (dinner), will be back later
bartolin_ m: use nqp; class Foo { has $.a = True; method foo(|) { if $.a { nqp::shift(nqp::p6argvmarray) } } }; say Foo.new.foo(42, 43) 17:23
camelia Foo.new(a => Bool::True)
Geth rakudo: a616fe579e | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Implement R:It.native_s/i/n for iterating native lists

  - can be used for nqp::list_s/i/n as well as str/int/num arrays
  - are PredictiveIterators, rather than the ones in native_array
  - to be used in the core where they make sense
bartolin_ nine: this does not work with '--optimize=1' on MoarVM. So I guess there is a more general problem with the structure. 17:24
Geth rakudo: e645ff6a76 | (Elizabeth Mattijsen)++ | 2 files
Let native arrays use the new R:It.native_s/i/n iterators
 17:25
nine On MoarVM it accesses the current call frame's arguments. Which doesn't really mean "the current subroutine's"
lizmat so using nqp::p6argvmarray can only be used in the same frame as the sub ?
nine bartolin_: I'm more and more convinced that your patch is actually correct and one just has to be very careful when using p6argvmarray
lizmat bartolin_ nine will take care of patches related to nqp::p6argvmarray 17:28
bartolin_ nine: regarding the optimizer: if I'm not mistaken this is one place where it works differently on the JVM backend: github.com/rakudo/rakudo/blob/7b4d...8874-L8879 (picked from github.com/rakudo/rakudo/issues/2810) 17:29
lizmat++
bartolin_ is always happy if looking at the JVM backend leads to an improvement/fix for MoarVM, too 17:34
lizmat looks like the IO::Handle work I did recently, was the only case where nqp::p6argvmarray was not called in the frame of the sub
bartolin_++ # keeping on keeping on the JVM backane 17:35
*backend
Geth rakudo: 1464b35e48 | (Elizabeth Mattijsen)++ | src/core.c/IO/Handle.pm6
Fix JVM backend (and MoarVM as well)

Turns out nqp::p6argvmarray can only be used in the same *frame* as the routine it wants the arguments from. This apparently was covered up on MoarVM by the static optimizer, but not so on the JVM which uncovered the issue.
  bartolin++ for following up and finding the cause of breakage on JVM		 17:50
lizmat dinner&
lizmat hmmm... is there a reason why nqp::split does not create a nqp::list_s, but an nqp::list ? 18:56
it can only create strings ?
nine nqp::split doesn't create a BOOTArray, but an hll->slurpy_array_type 19:16
So theoretically it could be something HLL specific. In practice it's always a VMArray 19:18
lizmat but why is it not a BOOTStrArray ? 19:28
I'm surprised that it doesn't, as it can only ever produce strings
nine because there's simply no slot for a string array type in hll 19:32
lizmat hmmm... feels like a lost opportunity... perhaps an nqp::split_s would be nice to have then 19:33
nine Question is: what would it gain us?
lizmat it could make Str.split('x') a lot faster 19:34
nine why?
or rather how?
lizmat because there's now iterators in core that can iterate over native lists 19:35
and it would prevent a lot of boxing? 19:36
nine Yeah, that makes sense 19:37
Adding a string_array_type to hll seems kinda trivial. It's just some book keeping work 19:38
lizmat let's see what jnthn has to say :-) 19:40
jnthn No objections from me. 19:43
nine Wow...I'm just experiencing this...moment of clarity. Where the error messages I get are starting to make sense and I get this feeling of finally understanding how nested BEGIN time compilation must work.
And the first step that got me there was documenting these obscure nqp ops freshcoderef, markcodestatic, markcodestub and scsetcode 19:48
lizmat jnthn: so, is that an ok for an nqp::split_s or a nqp::split that creates a list_s 19:51
the latter with possible ecosystem consequences
nine I'd be pretty surprised about ecosystem fallout 19:52
Geth rakudo: 84ff64cf90 | (Elizabeth Mattijsen)++ | src/core.c/Buf.pm6
Make Blob.join between 4% and 11% faster

  - presize the result array back to 0
  - use push_s instead of bindpos_s
  - use an nqp::while instead of a while		 19:57
jnthn I'd also not expect fallout 20:02
Though list_s may be easier in so far as not having to go and update NQP also 20:03
MasterDuke greppable6: nqp::split 20:08
greppable6 MasterDuke, 1 line, 1 module: gist.github.com/0d0a67494461c84087...14c8654c73
nine That ^^^ would be ok 20:10
A list_s is still a list after all
lizmat jnthn: perhaps nqp could benefit from an update performance wise ? 20:21
jnthn Perhaps, yes 20:26
lizmat meh, probably not 20:31
and if so, probably best manually migrated to split_s
timotimo i wonder how to optimize rakudo's compiler bits without making the code unreadable / unmaintainable 21:10
there's probably also not terribly many places that stand out from a time-wastage perspective?
Geth rakudo: b55667ef42 | (Elizabeth Mattijsen)++ | src/core.c/Buf.pm6
Make Blob.gist about 2x as fast

  - use a low-level lookup map for translation, so no conditionals anymore
  - also join the final result in nqp, rather than using ~
MasterDuke timotimo: did i send you that profile of compiling core.c? 21:16
lizmat timotimo: in nqp definitely not, in some places in Raku, most notable Str.split, it could be useful 21:23
but please, I was just surprised to finally realize that nqp::split does not create an nqp::list_s 21:24
timotimo i was more talking about in general 21:25
Geth rakudo: 4a728f2ad5 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/QuantHash.pm6
Speedup some QuantHash internals a bit

  - pre-size the result_s back to 0
  - use push_s to set up the result, so we don't need an index or bindpos_s		 21:37
lizmat is off for some sleep& 22:11

Powered by Cro and the Raku® Programming Language.

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

Thank you!