00:14 Ven`` joined 01:03 lucasb left 01:11 Ven`` left 05:12 quotable6 left, bloatable6 left, notable6 left, greppable6 left, shareable6 left, tellable6 left, squashable6 left, bisectable6 left, releasable6 left, benchable6 left, committable6 left, nativecallable6 left, sourceable6 left, coverable6 left, statisfiable6 left, evalable6 left, reportable6 left, linkable6 left, unicodable6 left 05:13 tellable6 joined, bisectable6 joined, nativecallable6 joined, releasable6 joined, reportable6 joined, linkable6 joined, statisfiable6 joined 05:14 greppable6 joined, squashable6 joined, quotable6 joined, sourceable6 joined, bloatable6 joined, benchable6 joined, unicodable6 joined, shareable6 joined 05:15 coverable6 joined, notable6 joined, evalable6 joined, committable6 joined 05:50 patrickb joined 05:56 TreyHarris left 06:08 patrickb45 joined, patrickb left 06:38 jmerelo joined 06:54 domidumont joined 07:39 sivoais left 07:40 sivoais joined 08:14 Altai-man_ joined
lizmat Files=1306, Tests=111292, 213 wallclock secs (28.95 usr 8.23 sys + 2994.54 cusr 276.05 csys = 3307.77 CPU) 08:22
08:26 sena_kun joined 08:28 Altai-man_ left 08:41 finsternis left, finsternis joined 09:34 Ven`` joined
[Tux] Rakudo version 2020.05.1-139-g95f7d34e8 - MoarVM version 2020.05-13-g03c9154e8
csv-ip5xs0.834 - 0.844
csv-ip5xs-208.033 - 8.384
csv-parser25.083 - 25.108
csv-test-xs-200.383 - 0.384
test7.547 - 7.553
test-t1.925 - 1.945
test-t --race0.836 - 0.849
test-t-2030.747 - 31.019
test-t-20 --race8.638 - 8.714
 09:37
10:15 Ven`` left
lizmat I guess it's time to look for another place for asking Raku questions 10:15
I don't understand why this question got closed: stackoverflow.com/questions/618765...r-raku-i-e 10:16
jnthn It's not clear to me which of the reasons for a question being closed that one doesn't meet 10:19
uh, other way around
I put a reopen vote on it. 10:20
patrickb45 I suspect some kind of automated close (spam filter-y)
lizmat no, it was definitely someone who closed it 10:23
they initially said that the answer I gave was insufficient in a comment
then I pointed out that I gave the answer directly addressing the second question in the post 10:24
then pointed out that the unclarity of the first question in the post would be probably be answered by seeing the list of unicode chars
next morning: the comment of this person is gone, and the question is closed by that person 10:25
I've now adapted the question to only show the second question: where is a list
10:25 Altai-man_ joined
lizmat this is the second time in about 2 weeks that SO just closed an, in my eyes, perfectly good question with a perfectly good answer 10:26
10:28 sena_kun left
robertle oh wow, I just ran my benchmarking script against 2020.02 and 2020.05 and these two seem to be significantly faster than the few releases before: github.com/robertlemmen/p6bench 11:46
is this just me, or does that match what you folks are seeing in your own tests?
Altai-man_ robertle, glad to know! 11:47
robertle, well, Rakudo is becoming faster over time. It is different in different areas because there is no single thing which will affect performance of everything (well, technically there might be, but), but there is gradual and steady process. :) 11:49
robertle sure, just wondering whether what I see is also visible in other benchmarks too. it would be disapointing if mine would pick up a single optimization in all 4 parts, and show it that massively. the whole point was to make it less of a micro-benchmark and get a handle on full-app performance instead... 11:53
jnthn If something helped them all, it'd be some kind of cross-cutting improvement. Maybe the derived specializations work in MoarVM, which was aimed at helping larger programs rather than micro-benchmarks. 12:02
jmerelo jnthn: reopened 12:09
12:17 jmerelo left 12:27 sena_kun joined 12:28 Altai-man_ left
MasterDuke robertle: just a quick looks shows there might be a bunch of DateTimes and FatRat created in the first two programs and iirc lizmat made creating both of them faster 12:37
timotimo: github.com/robertlemmen/p6bench/bl...limination and github.com/robertlemmen/p6bench/bl...mandelbrot seem like they might be candidates for your hyperopoptimization 12:39
Geth rakudo: 2a88990b5a | (Elizabeth Mattijsen)++ | 2 files
Make .IO / IO::Path.new about 2x as fast

  - don't use .bless internally, but a private !SET-SELF method
  - set up .new candidates such that IO::Path.new("str") / "str".IO is fast-pathed
  - add an extra Str.IO candidate for fast-pathing
  - remove the !is-absolute method, integrate into !SET-SELF
Having to call &DYNAMIC twice for each IO::Path.new(Str) is now taking more than 50% of CPU needed for this.		 13:07
13:21 Kaiepi left 13:44 patrickb45 left 13:49 patrickb joined 13:54 patrickb left 13:57 patrickb joined
Geth roast: 65131bc741 | (Elizabeth Mattijsen)++ | S32-io/io-spec-unix.t
Fix .curupdir tests

They were too specific. .curupdir should return something that you can call .ACCEPTS on with the name of the directory entry to be checked. That is currently a Junction, but could also be a Block		 13:58
rakudo: 6a0eaabdb2 | (Elizabeth Mattijsen)++ | src/core.c/IO/Spec/Unix.pm6
Make IO::Spec.curupdir about 25% faster

By having it return a Block rather than a Junction. This should make IO::Path.dir a bit faster.		 14:01
14:26 Altai-man_ joined 14:28 sena_kun left
nine I just noticed: the various "missing static code ref for closure" messages I get are always about closures in NQP code. Now this could be a conicidence (as the compiler's simply written in much NQP) but it could also mean that NQP doesn't do everything right yet WRT closures and BEGIN time 14:30
Well, yes. In Perl6::World, things like sub_id_to_cloned_code_objects are part of the shared compilation context while in NQP::World, they are still attributes (i.e. un-shared) 14:40
OTOH I don't see why we would have nested NQP::Worlds... 14:42
14:48 jmerelo joined
tbrowder is there any way to get a raku compiler option to affect grammar actions by sharing a variable? i'm almost sure there is but haven't broken the code yet. 14:54
dogbert17 there seems to be a spectest failure in t/spec/S32-str/utf8-c8.t 15:01
is that old news?
lizmat dogbert17 what is the error and are you on MacOS?
dogbert17 I'm on Linux and the error is 'Unexpected named argument 'bin' passed in block at t/spec/S32-str/utf8-c8.t line 139' 15:02
lizmat checks 15:03
dogbert17 perhaps I'm doing something wrong
his is Rakudo version 2020.05.1-141-g6a0eaab built on MoarVM version 2020.05-10-g5fe4a81 15:04
MasterDuke i thought that's what she fixed a day or two ago. do you have some local changes to your roast checkout preventing it updating?
dogbert17 checks 15:05
strange, git status said everything was ok but git pull retrieved S32-str/utf8-c8.t 15:06
I thought that was done automatically when spectest was run
lizmat it is ? 15:07
dogbert17 I have never had to update roast specifically when running spectest unless my memory has failed totally 15:08
Geth roast: b69a1abac6 | (Elizabeth Mattijsen)++ | S32-str/utf8-c8.t
Skip utf8-c8 tests on MacOS

These have been failing for more than 6 months now, I'm tired of it.
MasterDuke the spectest run with the error should have some output right at the beginning about whether it pulled or not
dogbert17 MasterDuke++
fatal: unable to access 'github.com/perl6/roast.git/': Failed to connect to github.com port 443: Connection timed out
lizmat dogbert17: maybe because Github has been flaky (well for me at least) in the past hours, maybe it timed out on the update and then just went on to spectest
dogbert17 Makefile:146: recipe for target 'spectest_update' failed
make: [spectest_update] Error 1 (ignored) 15:09
lizmat++ everything works now, sorry for the noise
15:59 patrickb left
nine Progress! On a hunch (and lacking any real insight) I unshared the code_object_fixup_list and suddenly I get through compilation without a "missing static code ref for closure"! 16:14
That is, when I don't get the bogus "Semicolon form of 'perl5class' without 'unit' is illegal" error 16:15
But it shows that those were 2 distinct errors and it's just one of them that gets triggered by some kind of hash order issue
16:27 sena_kun joined
nine I should not have recompiled rakudo. Back to Serialization Error: missing static code ref for closure '' (gen/moar/stage2/NQPHLL.nqp:2206) 16:27
16:29 Altai-man_ left
nine Huh...when compiling the setting with --optimize=0 install-core-dist.raku fails with "New type Stash for Method is not a mixin type" 16:36
Needs at least --optimize=2 16:45
timotimo it needs to be at least ... three times more optimized than this! 16:51
MasterDuke the timotimo optimizer for programs that want to run good and do other stuff good too 17:05
timotimo <3 17:06
www.youtube.com/watch?v=4i9Kg8X4j1o (has another video where you can see it being made) 17:13
17:26 MasterDuke left 17:46 domidumont left 18:10 MasterDuke joined 18:26 jmerelo left, Altai-man_ joined 18:28 sena_kun left
Geth rakudo: b5bf1bf478 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Make IO::Part.parts use an nqp::hash internally

So we can more easily check whether it has been initialized yet, and will make it easier to fast-clone an IO::Path object.		 20:04
20:17 timotimo left, timo joined 20:18 timo is now known as Guest71053, Guest71053 is now known as timotimo 20:27 sena_kun joined 20:29 Altai-man_ left 20:40 squashable6 left 20:42 squashable6 joined
Geth roast: 0990abcf14 | (Elizabeth Mattijsen)++ | S32-io/io-path.t
Remove superfluous .IO's

We already have an IO::Pathy object		 20:58
22:26 Altai-man_ joined 22:28 sena_kun left 22:43 donaldh_ left
Geth rakudo: 16d93e260a | (Elizabeth Mattijsen)++ | src/core.c/IO/Spec/Unix.pm6
Make sure IO::Spec.curupdir returns the same thing always

For some reason, IO::Spec.curupdir would return a different Block each time it was called, probably related to some closure issue? Create the Block in the mainline, and return that instead.		 22:56
lizmat sleep& 22:57
23:07 Altai-man_ left

Powered by Cro and the Raku® Programming Language.

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

Thank you!