00:02 sena_kun joined 00:04 Altai-man_ left 02:01 Altai-man_ joined 02:04 sena_kun left 04:02 sena_kun joined 04:04 Altai-man_ left 04:16 softmoth joined 04:18 Xliff left 06:01 Altai-man_ joined 06:04 sena_kun left 06:05 stoned75 left 06:07 stoned75 joined 06:38 softmoth left
Altai-man_ lizmat, gist.github.com/Altai-man/9f03261b...e19e14665e 07:45
08:03 sena_kun joined 08:04 Altai-man_ left
[Tux] Rakudo version 2020.06-16-gc7c18c214 - MoarVM version 2020.06-20-g187b4564e
csv-ip5xs0.817 - 0.915
csv-ip5xs-208.027 - 9.141
csv-parser28.648 - 29.266
csv-test-xs-200.394 - 0.460
test7.844 - 9.455
test-t1.910 - 2.349
test-t --race0.923 - 0.942
test-t-2031.761 - 35.645
test-t-20 --race9.843 - 9.968
 08:30
lizmat decides to abandon the match-refactor branch for now 09:32
the wins to be had, have become to small to warrant the potential ecosystem breakage 09:33
if any optimizations are possible, they should be started from the ground up, aka in NQP 09:34
either that, or rewrite the regex engine in Raku
in any case, this has caused me enough aggrevation 09:36
for now, anyway 09:38
sena_kun lizmat, the research and efforts are admirable anyway. 09:47
lizmat ah, yes, I learned a lot about that part of the internals :-) 09:48
sadly, also that it is still very much in the state of "making it work" :-(
sena_kun lizmat, maybe picking up some bugs on the easier side can light the mood up? :) 09:49
lizmat perhaps... 09:51
had something in mind?
sena_kun Not really, just thinking we have a lot of plain "something doesn't work here" type of bugs and from my experience, taking something and resolving it gives some "Oh, cool, I did it" satisfaction, especially when you spent a lot of time into something which is hard. 09:53
10:01 Altai-man_ joined 10:04 sena_kun left
gfldex how does Rakudo tell if a sinkee is actually a sinkee and how does it decide to sink? 10:24
I link the the code in question would be really nice. I need that for my next blog post. 10:25
s/I link the/A link to/ 10:26
gfldex seeks coffee
lizmat gfldex: I think you need to look for WANTED annotations in the grammar 10:44
12:02 sena_kun joined 12:04 Altai-man_ left
Geth rakudo: 1a91af8cd2 | (Elizabeth Mattijsen)++ | 2 files
Give Supply.tail its own candidate
 12:35
rakudo: 9ccfc90edb | (Elizabeth Mattijsen)++ | src/core.c/Supply-coercers.pm6
Add support for Supply.tail(*) and .tail(Inf)

These appear to have been forgotten before.		 12:53
rakudo: eaa72afa15 | (Elizabeth Mattijsen)++ | src/core.c/Supply-coercers.pm6
Add support for Supply.tail(*-3)

Apparently this was also forgotten before		 12:58
roast: f18782f5ae | (Elizabeth Mattijsen)++ | S17-supply/tail.t
Add Supply.tail tests for new features
 13:01
13:05 linkable6 joined 13:07 evalable6 joined 13:23 lucasb joined
gfldex Is there any way to set an attribute without a public write accessor? I'm willing to decent into nqp-land. 13:45
sena_kun gfldex, MOP 13:46
gfldex I tried that and failed. Any pointers? 13:47
Well, what I actually need is Proc::Async.w to be writeable, at least until .start is called.
sena_kun m: class A { has $!a = 50; method a { say $!a } }; my $a = A.new; my $attr = $a.^attributes[0]; $attr.set_value($a, 42); $a.a; 13:48
camelia 42
gfldex The proper way does not work because .start_internal is calling native-descriptor and a custom IO::Handle does not have one.
sena_kun Remember I did not show you this
gfldex sena_kun: thanks a lot
sena_kun gfldex, maybe it's better to defer the Proc::Async creation until you know for sure the value of w you want? 13:49
I assume using this for Proc::Async can cause serious problems, because you are likely break assumptions of setup and such.
gfldex I can't really do that because I want to let the user handle Proc::Async by hand. 13:50
sena_kun Hmm, pseudo-code?
gfldex it only checks for it in start_internal and then sets up a callback. 13:51
I tried to follow docs.raku.org/type/IO::Handle#Crea...om_Handles to feed an array into a Proc::Async.
sena_kun Then this changes next release and it explodes like fireworks. :( 13:52
Hmmmm.
gfldex As soon as I $proc.bind-stdin with that custom Handle, it tried to hand over a native file descriptor over to Moar-land.
A custom IO::Handle doesn't got a native descriptor. 13:53
So there is a Rakudobug somewhere. I'm fine with a workaround for now.
sena_kun Not sure I can be of any help here. I'd still suggest to ask for problem A first unless you done that already.
14:02 Altai-man_ joined 14:05 sena_kun left
gfldex Workaround works. :) 14:15
14:58 softmoth joined 15:20 softmoth left 16:02 sena_kun joined 16:04 Altai-man_ left
gfldex raku: class E is Exception { method message { "E" } }; CATCH { when E { say .message; .resume } }; E.new.throw; 16:26
evalable6 (exit code 1) E
Cannot find method 'sink' on 'BOOTException': no method cache and no .^find_method
in block <unit> at /tmp/W5hVcpkAn6 line 1
gfldex roast seams not to test .resume outside of CONTROL 16:28
is that intentional?
lizmat probably an oversight 16:34
16:54 JJMerelo joined
gfldex raku: say $*RAKU.compiler.version; 17:12
evalable6 v2020.06.19.geaa.72.afa.1
gfldex files as #3777 17:16
Geth rakudo: 5c8c7324e6 | (Elizabeth Mattijsen)++ | src/core.c/Supply-coercers.pm6
Fix Supply.head(*-3)

  - makes it consistent with List.head(*-3)
  - fixes R#3746		 17:43
linkable6 R#3746 [open]: github.com/rakudo/rakudo/issues/3746 difference of behavior for List.head and Supply.head
Geth roast: c4e8458bb6 | (Elizabeth Mattijsen)++ | S17-supply/head.t
Adapt Supply.head(*-3) tests to correct semantics

Because of fixing R#3746		 17:44
18:02 Altai-man_ joined 18:05 sena_kun left 18:15 maggotbrain joined 19:03 softmoth joined
Geth rakudo: 70e5cfb982 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Make sure that Any:U.head/tail work

This seems to be implied by Any:U.skip working, and a recent change broke a spectest about that. Now, this breaks tests for Supply:U.head and Supply:U.tail, but given the discussion about Any:U.skip in R#1384, it looks to me that those tests are in error.		 19:04
linkable6 R#1384 [closed]: github.com/rakudo/rakudo/issues/1384 Any.skip fails when trying to use a WhateverCode
Geth roast: 307d40846b | (Elizabeth Mattijsen)++ | 2 files
Remove tests given discussion in R#1384

After the change in github.com/rakudo/rakudo/commit/70e5cfb982		 19:05
rakudo: 056d6a4e9d | (Elizabeth Mattijsen)++ | src/core.c/Str.pm6
Add Str.naive-word-wrapper (implementation detail)

  - to be used internally when texts need to be wrapped for a given length
  - specifically intended for Exception.message output
  - but may have other uses internally		 19:09
19:20 stoned75 left 19:22 stoned75 joined
gfldex raku: class Sinker { method FALLBACK($name, |c) { say "$name can not be sink" } }; Sinker.new 19:37
evalable6
gfldex This is either an ENODOC or a Rakudobug. I'm undecided which it is. 19:38
moritz in terms of optimizability, I vote for ENODOC 19:39
gfldex good point 19:40
lizmat m: dd Mu.can("sink") 19:42
camelia (method sink (Mu: *%_ --> Nil) { #`(Method|68300528) ... },)
lizmat so, not sure how that is ever going to call FALLBACK ?
gfldex that Mu.^methods shadows FALLBACK is also an ENODOC 19:43
well, it is implicit but implicit docs aint nice 19:44
lizmat gfldex: perhaps modules.raku.org/dist/InterceptAll...:ELIZABETH is what you want / need ? 19:45
gfldex I don't really need FALLBACK right now. Just asking so I can update my private versions of the docs. 19:46
dogbert17 m: <a b c d>.permutations for ^3000; say now - INIT now 19:50
camelia 4.774243
dogbert17 m: <a b c d>.permutations for ^6000; say now - INIT now
camelia 13.091292
dogbert17 lizmat: any theories as to why this is happening? 19:51
lizmat that is indeed... odd
timotimo is it holding on to all the results?
moritz increased GC pressure? But that shouldn't make such a difference
dogbert17 if I run with ^9000 I'm sure it will timeout 19:52
timotimo the memory usage goes up when you increase the amount
dogbert17 rss goes up at the very least
lizmat ooo...the --profile on <a b c d>.permutations for ^1000 is *yuck* 19:53
dogbert17 which means ...
lizmat it's weird 19:54
permutations is like the 20th entry 19:56
dogbert17 heh
lizmat with .5% exclusive CPU usage
wtf ?
dogbert17 so something fishy is going on
lizmat publish_method_cache for *each* call 19:57
43x add_method for each call
2x compute_mro for each call
dogbert17 sounds a bit overkill :)
moritz sounds like a 'but' or 'does' inix op
*infix
timotimo i'm looking at the thing in the heap analyzer 19:58
lizmat delegate-iterator-opt-methods ?? 19:59
dogbert17 combinations behaves more like I would expect when I increase the number of iterations 20:00
timotimo there's boatloads of frames of Metamodel's "specialize", NQPCORE's "protect", an <anon> at Metamodel.nqp:3268, and specialize_with (Metamodel.nqp:3308) and specialize (Metamodel.nqp:3507) have fewer instances of them 20:01
moritz could this be related to role punning?
timotimo gist.github.com/timo/0bf3d722979ef...25eaa98746 - this look interesting to you at all? 20:02
lizmat since <a b c d> produces a PredictiveIterator, it does this: nqp::istype(a,PredictiveIterator)
?? b.^mixin(DelegateCountOnly[a])
!! b
20:02 sena_kun joined
lizmat and then goes into metamodelland 20:03
fortunately, permutations is the only place where it's used 20:04
20:04 Altai-man_ left
timotimo so this fixup list thing has about 1.7k entries that are all Block objects 20:08
dogbert17 according to valgrind the 'still reachable' category increases if the iteration count is increased 20:10
lizmat ok, interesting conundrum: taking out that optimization, makes combinations much, much faster 20:21
but alas, it fails the count-only test in t/08-performance
dogbert17 so removing an 'optimization' made things much faster 20:23
lizmat *except* the count-only case 20:24
dogbert17 true 20:25
I suspect the speedup was quite noticable though 20:27
lizmat for the count-only case, yes, the difference between providing a result, or waiting to the heat death of the universe 20:29
dogbert17 a conundrum indeed 20:30
lizmat nah, just needs to be optimized differently
dogbert17 I still find it a bit odd that it didn't scale linearly 20:31
lizmat that's because it leaked like hell 20:34
dogbert17 aha, so it's not only slow but buggy as well then 20:35
lizmat well, the bug is in the ^mixin logic, I'd say
dogbert17 sounds like you have an idea as to where the problem is hiding :) 20:36
timotimo .^mixin is supposed to go through the cache, right? 20:38
lizmat timotimo: guess so, but it's not caching
look at the profile of this: <a b c d>.permutations for ^500 20:39
timotimo i see it hold on to boatloads of closures in this FixupList thing
lizmat it's orange and red all over
timotimo is there a decont missing somewhere perhaps?
so it's using the identity of a scalar instead of the value inside it or whatever?
lizmat haz no clue 20:40
permutations fix coming up 20:46
dogbert17 ++lizmat 20:48
lizmat let's see if this fix spectests ok 20:52
21:00 softmoth left
lizmat looks like the fix borks combinations 21:06
hmmm
sena_kun releasable6, status 21:22
releasable6 sena_kun, Next release in ā‰ˆ13 days and ā‰ˆ21 hours. There are no known blockers. Changelog for this release was not started yet
sena_kun, Details: gist.github.com/9e0b4c2b4cd1139a80...4145ff8418
Geth rakudo: 682a4d4f59 | (Elizabeth Mattijsen)++ | 2 files
Make <a b c d>.permutations between 23 and 85x faster

When running that code 2000x.
Turns out that an optimization that mixed in a role into the given iterator (in case of a PredictiveIterator) somehow had *very* adverse efficiency effects. The goal of the optimization was to provide a ... (11 more lines)		 21:26
lizmat dogbert17 ^^
dogbert17 lizmat++ very cool 21:32
Geth roast: 88c61eba77 | (Elizabeth Mattijsen)++ | MISC/bug-coverage.t
Fix erroneous test

Not sure what was intended, but this feels what it should be.
Problem was uncovered after:
   github.com/rakudo/rakudo/commit/682a4d4f59		 21:33
dogbert17 impressive improvement 21:35
21:46 Xliff joined
Xliff I have an old rakudo repo I've recently revived. How can I reset the repo to get the right version number for rakudo? 21:46
lizmat Xliff: not sure I understand ? 21:49
Geth rakudo: eb589c031d | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Word-wrap X::SecurityPolicy::Eval message
 21:50
21:52 softmoth joined
Xliff liz: raku's version number is wrong. How can I reset it? 21:53
I just updated the repository, yet --version is returnning something from 2020.02
lizmat m: dd $*RAKU.compiler.version
camelia v2020.06.23.g.682.a.4.d.4.f.5
lizmat Xliff: good question 21:54
Xliff Rakudo version 2020.02.1-723-g056d6a4e9 built on MoarVM version 2020.06-14-g5832b2628
lizmat feels more like a git issue, that moritz timotimo jnthn would be able to help you with better ?
Xliff I'm thinking my last "stash apply" may have kept some kruft.
k 21:55
jnthn sena_kun timotimo: How can I reset the version number of the raku executable?
dogbert17 m: say sum(1,2,3,4,5,6,7,8,9) 21:59
camelia 45
dogbert17 m: say (1,2,3,4,5,6,7,8,9).sum
camelia 45
dogbert17 are these two equivalent?
because there seems to be a bit a perf. difference here 22:00
*of
lizmat how much? 22:01
dogbert17 m: (1,2,3,4,5,6,7,8,9).sum for ^1000000; say now - INIT now
camelia 1.0506641
dogbert17 m: sum(1,2,3,4,5,6,7,8,9) for ^1000000; say now - INIT now
camelia 9.6384852
dogbert17 like so :)
22:01 Altai-man_ joined
dogbert17 perhaps that's ok but it's not obvious to me why the difference should be that large 22:02
lizmat that's basically the slurpy overhead in sub sum() and then calling List.sum ? 22:03
you *are* doing it 1M times
22:04 sena_kun left
dogbert17 yes :) 22:04
I might have made a mistake here 22:05
m: sum((1,2,3,4,5,6,7,8,9)) for ^1000000; say now - INIT now # this is better
camelia 1.0405195
dogbert17 now the times matches a lot better 22:06
Xliff ./gen/moar/rakudo.nqp:6: $config<version> := '2020.02.1-723-g056d6a4e9';
Where is $config populating $config<version> ?
lizmat perl Configure.pl --gen-moar ?
Xliff lizmat: LOL! That was the first thing I did! 22:09
lizmat then I haz no idea 22:10
Xliff ROFLMAO
I use "haz" alot, too! :)
Geth rakudo: 1b84e03626 | (Elizabeth Mattijsen)++ | 2 files
Wordwrap X::Method::NotFound message

Also tweak related Pair.ACCEPTS wording.		 22:15
lizmat m: for ^100 { my $a = 42; $a but False } # mixin code bloat golfed jnthn timotimo 22:26
camelia ( no output )
Geth rakudo: 3cb29a03bd | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Wordwrap X::Buf::AsStr message
 22:28
lizmat and that concludes my hacking for today&
dogbert17 good night lizmat 22:33
MasterDuke Xliff: did you `git pull --tags`? 23:06
23:26 vrurg left 23:27 vrurg joined
Xliff MasterDuke: No. I didn't know I had to. 23:41
"Already up to date" 23:42
oooh...
I had to "git pull --tags upstream"
"upstream" being the rakudo repo
Getting some weird emits from the Grammar: 23:50
" Use of Nil in string context in any statement_control at /home/cbwood/Projects/rakudo-precomp-nolock2/install/share/perl6/lib/Perl6/Grammar.moarvm line 1"
"Type check failed in binding to parameter '$repo-id'; expected Str but got Nil (Nil)
at /home/cbwood/Projects/p6-GLib/lib/GLib/Raw/Structs.pm6 (GLib::Raw::Structs):4"

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!