00:26 Altai-man_ joined 00:29 sena_kun left 01:08 wildtrees left, guifa2 left 01:53 Kaiepi left 01:59 Kaiepi joined 02:01 guifa2 joined 02:27 sena_kun joined 02:29 Altai-man_ left
Geth nqp: softmoth++ created pull request #638:
Fix sprintf() with *-specified negative width argument
04:26 Altai-man_ joined 04:29 sena_kun left 06:27 sena_kun joined 06:29 Altai-man_ left 08:26 Altai-man_ joined 08:29 sena_kun left 09:02 Kaiepi left 09:04 Kaiepi joined 10:28 sena_kun joined 10:29 Altai-man_ left
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
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
11:17 MasterDuke left
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.
lizmat bartolin_++ 11:28
11:29 ShimmerFairy left 11:30 ShimmerFairy joined 12:22 MasterDuke joined 12:26 Altai-man_ joined 12:29 sena_kun left
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
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)
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
12:56 patrickb joined
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
13:02 Voldenet left 13:08 Voldenet joined, Voldenet left, Voldenet joined
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:22 travis-ci joined
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
13:22 travis-ci left
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
14:23 rypervenche left, patrickb left 14:27 sena_kun joined
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:29 Altai-man_ left 14:38 rypervenche joined 15:52 Kaiepi left 15:53 Kaiepi joined 15:56 Kaiepi left, Kaiepi joined 15:57 domidumont joined 16:02 Kaiepi left 16:05 Kaiepi joined 16:26 Altai-man_ joined 16:29 sena_kun left
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
17:16 lichtkind joined
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
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
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
17:41 domidumont left
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
lizmat dinner&
18:06 guifa2 left, guifa2 joined 18:07 guifa2 left 18:21 guifa2 joined 18:27 sena_kun joined 18:29 Altai-man_ left 18:45 guifa2 left
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
19:20 lucasb joined
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
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
20:27 Altai-man_ joined 20:29 sena_kun left
lizmat meh, probably not 20:31
and if so, probably best manually migrated to split_s
20:47 rypervenche left
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
21:19 rypervenche joined
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
lizmat is off for some sleep& 22:11
22:27 sena_kun joined 22:29 Altai-man_ left 23:34 Kaiepi left 23:35 Kaiepi joined 23:39 tyilanmenyn joined, tyil left, tyilanmenyn is now known as tyil