|
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:05 | |
|
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 |
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 |
|||
|
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. |
11:27 | |
| 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 |
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 | |
|
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:18 | |
|
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 |
13:39 | ||
|
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:28 | |
|
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 |
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 | |||
|
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 |
17:50 | |
| 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 |
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 | |
|
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 |
21:37 | |
| 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
|
|||