[00:45] *** MasterDuke left [01:28] *** Guest94360 left [01:45] *** leont left [03:28] *** Xliff joined [03:29] jnthn timotimo lizmat: Have subsets made it into RakuAST, yet? [03:29] Thanks. [06:46] *** maggotbrain left [06:59] *** maggotbrain joined [07:53] Looks like repository is in a currently unbuildable state. Please see: https://gist.github.com/Xliff/00018e5ea896904e3ab7a0229d53fdbe [07:53] ^^ ugexe jnthn timotimo [08:29] bin/nqp-m version 2020.09-3-g30dd003b1 is outdated [08:41] Xliff: you need to update your nqp in case that isn't clear :) [08:41] which i guess it isn't clear enough, it kind of gets lost in a huge error message with long paths and such [08:59] *** sena_kun joined [09:19] *** MasterDuke joined [09:40] Xliff: there are no subsets in RakuAST yet [09:41] *** Altai-man joined [09:44] *** sena_kun left [10:01] Files=1336, Tests=113604, 222 wallclock secs (32.24 usr 9.40 sys + 3085.65 cusr 289.66 csys = 3416.95 CPU) [10:44] I thought updating nqp was handled by the build process [10:50] well, it does if you configure every time, afaik [10:50] but devs generally don't run the whole configure process every time [10:51] Honesly, I thoguht rakudobrew did do that! [10:51] LOL [10:51] Adding '--gen-moar --gen-nqp' to config opts does the trick. [10:52] Adding '--gen-moar --gen-nqp' to config opts does the trick.git submodule update --init --recursiv [10:53] Oops. Have to back out of that. [10:53] That was moar, not moar-blead [10:55] OK, so: 'cd nqp; sh config.status' fixes the problem [10:56] Then mthe rakudobrew command can be executed normally. [11:16] ¦ rakudo: 1c08e66b79 | (Elizabeth Mattijsen)++ | src/core.e/hash_slice.pm6 [11:16] ¦ rakudo: The :kv adverbs should force list return [11:16] ¦ rakudo: [11:16] ¦ rakudo: Otherwise we'd only be looking at the k in case of a single element. [11:16] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/1c08e66b79 [11:28] ¦ rakudo/prefix-pipe-pipe: e6787d77c0 | (Elizabeth Mattijsen)++ | src/Perl6/Actions.nqp [11:28] ¦ rakudo/prefix-pipe-pipe: Implement the prefix:<||> operator in postcircumfixes [11:28] ¦ rakudo/prefix-pipe-pipe: [11:28] ¦ rakudo/prefix-pipe-pipe: - for 6.e and later only [11:28] ¦ rakudo/prefix-pipe-pipe: - described by https://design.raku.org/S09.html#line_419 [11:28] ¦ rakudo/prefix-pipe-pipe: - sort of implemented by Wenzel P.P. Peppmeyer in Slippy::Semilist [11:28] ¦ rakudo/prefix-pipe-pipe: - does not actually add a prefix operator: it's just a double slip [11:28] ¦ rakudo/prefix-pipe-pipe: - manipulates the AST in case of a postcircumfix, to select the ; variant [11:28] ¦ rakudo/prefix-pipe-pipe: - the postcircumfix:<{; }> variant does the right thing for prefix:<||> [11:28] ¦ rakudo/prefix-pipe-pipe: review: https://github.com/rakudo/rakudo/commit/e6787d77c0 [11:28] gfldex: ^^ :-) [11:29] \o/ [11:29] ¦ rakudo: lizmat++ created pull request #3953: Implement the prefix:<||> operator in postcircumfixes [11:29] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3953 [11:30] will that be in v6.e? [11:30] well, if the PR is accepted, ytes [11:30] *yes [11:31] although it's opt-in in 6.e, I decided to make it a PR to allow for discussion [11:32] $ r 'use v6.e.PREVIEW; my %h; dd %h{ || } = 42; dd %h' [11:32] Int element = 42 [11:32] Hash %h = {:a(${:b(${:c(42)})})} [11:33] is how you can use it :-) [11:33] Do we have a mechanism for avoiding `use Module::Name` for a compiler version >v6.d ? [11:40] no, that's the mechanism, although I would be in favour of creating a dedicated statement for it [11:41] even in Perl I found the use of "use" for version control to be confusing [11:41] even though in Raku you could argue, it *is* using the load module mechanism to load a setting :) [11:47] hmmm.. looks like there are *no* tests whatsoever for multi-level slices for either arrays or hashes :-( [11:54] lizmat: there are: https://github.com/gfldex/perl6-rakudo-slippy-semilists/blob/master/t/01-basic.t [11:54] ¦ roast: e7aa00c3da | (Christian Bartolomäus)++ | S32-io/out-buffering.t [11:54] ¦ roast: [JVM] Unfudge passing test [11:54] ¦ roast: review: https://github.com/Raku/roast/commit/e7aa00c3da [11:54] ¦ roast: e29717770c | (Christian Bartolomäus)++ | S32-io/out-buffering.t [11:54] ¦ roast: Clean up explaining comment for test [11:54] ¦ roast: [11:54] ¦ roast: ... at least a bit. I'm pretty sure the removed part was wrongly [11:54] ¦ roast: copied from cb7ec603cc. (I'm not sure if the first sentence makes [11:54] ¦ roast: sense, though.) [11:54] ¦ roast: review: https://github.com/Raku/roast/commit/e29717770c [11:56] gfldex: thanks for the reminder :-) [11:57] afk for a bit& [12:02] *** leont joined [12:30] Do we have manifests for source hut? [12:49] Does someone have a YAML file that uses --configure-opts in rakudobrew? [13:01] *** vrurg joined [13:02] *** vrurg_ left [13:16] *** vrurg_ joined [13:18] *** vrurg left [13:42] *** sena_kun joined [13:44] *** Altai-man left [14:00] Do we have .debs for 2020.09? [14:08] pretty sure El_Che does [14:20] ack -l 'use v6\.e\.PREVIEW' t/spec # so why are these files not part of normal "make spectest" ? [14:35] m: sub a { say &?ROUTINE.WHERE }; a() [14:35] rakudo-moar 85847d2f1: OUTPUT: «140669184534576␤» [14:36] m: sub a { say &?ROUTINE.WHERE }; sub b { say &?ROUTINE.WHERE }; a; b [14:36] rakudo-moar 85847d2f1: OUTPUT: «139656343750704␤139656343874424␤» [14:38] *** unclechu left [14:38] *** djinni` left [14:39] *** unclechu joined [14:39] *** djinni` joined [14:40] *** unclechu left [14:43] <[Tux]> Rakudo version 2020.09-35-g8a2d9a612 - MoarVM version 2020.09-8-g60070970c [14:43] <[Tux]> csv-test-xs-20 0.385 - 0.422 [14:43] <[Tux]> csv-ip5xs 0.822 - 0.863 [14:43] <[Tux]> test-t --race 0.838 - 0.873 [14:43] <[Tux]> test-t 1.853 - 1.901 [14:43] <[Tux]> test 7.640 - 7.840 [14:43] <[Tux]> csv-ip5xs-20 8.368 - 9.030 [14:43] <[Tux]> test-t-20 --race 9.294 - 10.029 [14:43] <[Tux]> csv-parser 24.978 - 26.626 [14:43] <[Tux]> test-t-20 31.405 - 32.017 [14:47] *** Xliff left [14:54] *** unclechu joined [15:21] *** domidumont joined [15:27] *** domidumont left [16:44] m: my %h; %h{$_} = "abcdef" for ^1000000; say now - INIT now [16:44] rakudo-moar 85847d2f1: OUTPUT: «1.5352052␤» [16:44] m: my %h; %h{$_}{$_} = "abcdef" for ^1000000; say now - INIT now [16:44] rakudo-moar 85847d2f1: OUTPUT: «9.00151639␤» [16:45] is there a reason why the second example is so much slower than the first, i.e. shouldn't it have take approximately twice the amount of time? [16:46] *taken [17:04] dogbert17: the second example needs to create a hash for each iteration ? [17:11] bisectable6: my %h = a => { b => { c => 42 } }; dd %h{*;"b","c"} [17:11] lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight [17:12] lizmat, ¦6c (47 commits): «(${:c(42)}, Any)␤» [17:12] lizmat, Nothing to bisect! [17:12] m: my %h = a => { b => { c => 42 } }; dd %h{*;"b","c"} [17:12] rakudo-moar 85847d2f1: OUTPUT: «(${:c(42)}, Any)␤» [17:12] that... does not feel right [17:12] * lizmat feels that should be (42,) [17:13] lizmat: i was comparing with a 'similar' language which seems to handle this case better /o\ [17:15] the first example creates on million scalars an on million Int's [17:17] the second creates two million scalars, and one million each of Boothash, Str, Hash, Int, ContainerDescriptor::VivifyHash and ContainerDescriptor::BindHashPos [17:18] but I guess my assumption that it should 'take approximately twice as long to run' might have been erroneous [17:19] as I said, the second example needs to create a hash for each iteration [17:19] that's where the BOOThash, Hash come from [17:20] I get it [17:20] because of the way it works, that also needs to create a ContainerDescriptor::BibifyHash and BindHashPos as well [17:21] *Vivi [17:21] ok, so no easy opts hiding there then :) [17:21] well, perhaps with {|| $_ xx 2} [17:22] or right now, with {$_;$_} ? [17:23] nope, that's actually worse [17:23] yeah, my machine is still trying to execute it :) [17:24] three times longer than the original [17:24] 6.d gives 17.5 secs for me, 6.e 16.5 so already slightly better [17:25] I'm trying to make it work atm, no further thoughts on optimizing that yet [17:25] it's just that there are no spectests whatsoever for %h{;} :-( [17:25] or @[;] :=( [17:25] shouldn't gfldex have found that out already :-) [17:41] *** Altai-man joined [17:44] *** sena_kun left [17:49] *** Xliff joined [17:51] Has anyone worked with CI on sourcehut? [17:51] i've only recently learned of sourcehut [17:51] don't even have an account on the official instance yet, nor my own instance [17:52] timotimo: LOL! Same here. Probably learned about it from the same place. [17:52] from one of the raku channels :) [17:56] https://gist.github.com/Xliff/70d6fa33dbc293a1d776fcfaea1a6038 [17:56] Heh. That was easy. [17:58] that will take 20 minutes for every run? [17:59] you could try to use the nxadm apt repos maybe? [18:00] Actually, less. [18:01] 10 minutes. [18:07] still, no fun waiting for that long [18:16] *** domidumont joined [18:19] *** domidumont left [18:40] . [18:40] *** vrurg_ is now known as vrurg [18:49] \o vrurg [18:49] Xliff: o\ :) [18:50] I think I might have a bug for you. :/ [18:50] oops... \o [18:50] :) [18:50] Xliff: an issue then? Not sure when I get time for this. :( [18:51] vrurg: I've got this setup here -- https://github.com/Xliff/p6-GIO/blob/september-refactor-review/lib/GIO/Roles/GFile.pm6#L202 [18:52] vrurg: Well, the thing is... I don't KNOW it's a bug yet. [18:52] If it is... I'll report it. [18:53] I'm keeping my eye on github notifications, will try not to skip the one. [18:55] BTW, we eventually got time for a vacation trip, but didn't have time to stop in Washington. [18:56] vrurg: https://gist.github.com/Xliff/483080e6329425240a8fa86a65bc28cc [18:56] vrurg: That's OK. It's not like DC is a tourist destination or anything. [18:56] Not with the current dweller in the WH, anyways. [18:58] OK, the gist should contain... well... the gist... haha... of the issue. [18:58] BRB [19:00] Xliff: will look at the gist. Otherwise I'm fighting with syadmin tasks lately, like setting up bareos now. :( [19:00] vrurg: That's all I can ask! [19:00] Thanks!! [19:08] My main concern is that .new_tmp is NOT passing throguh GIO::File.BUILD, but .new_for_path IS. [19:08] And there doesn't look to be a reason. [19:08] Xliff: why do you use BUILD? It's more like a job for TWEAK. [19:09] I suspect either would yield the same results. [19:09] I'm using BUILD for this because that's what's worked for over 450,000 lines of code! [19:10] TWEAK is more robust in many aspects. I would event remove most of the references to BUILD in the documentation and replace it with TWEAK, leaving BUILD mentioned in a few specific locations. [19:10] s/event/even/ [19:11] Want me to switch it? [19:11] No diff [19:15] Then no more quick ideas. More debugging is needed. [19:18] OK, then. Will continue to beat my head on this. [19:18] If I can spin something up into a golf, then I will. [19:18] Thanks for taking the time! [19:20] Xliff: what is confusing me is that you invoked new_tmp on GIO::File but you get GIO::Roles::File back. Is it something expected? [19:20] Not at all. [19:20] Glad you noticed that! [19:21] Almost acting like this bit was skipped: "$file ?? self.bless(:$file) !! Nil;" [19:22] HAH! [19:22] samewith vs self.new_tmp [19:22] I switched it to the latter and it worked. [19:24] Xliff: BTW, I was about to advise you against samewith for performance matters. [19:24] Think that deserves a write-up? [19:25] Sorry, don't get the meaning of 'write-up' in this context. [19:28] Bug report [19:30] Ah, no. It's a known issue, non-fixable until the new dispatching is completed (if it would ever be). [19:30] OK, Thanks! [19:31] I seem to be moving along, now. [19:31] Good! :) I'm back to my damn bareos... [19:34] I can't help but brag: got 28 core/128GB workstation recently. The whole spectest now takes a little more than 5mins now with 100 parallel jobs allowed! [19:38] vrurg: including rakudo build time? because a spectest for me usually takes just a little over two min with 12 jobs [19:40] MasterDuke: no, build is separate. You probably have threadripper, I guess? [19:40] nope, just 3700x [19:40] oh, but i'm not running the Inline::Perl5 tests [19:41] Not sure they take that much. [19:42] How much did the machine cost to you?' [19:44] i just replaced the cpu+mobo+ram, $650 [19:49] Ok, then it looks fair. I needed a new one for virtualization and developing. 64GB is ~2k on Amazon and mine is $1600. But AMD done really impressive breakthrough! [19:56] yeah, i wanted 64gb, but couldn't justify it, so only have 32gb right now. and yeah, zen3 is looking even better. waiting for their radeon announcement to decide on a new video card, but i suspect that'll be a tougher choice [20:06] BTW, I was wrong. spectesting takes 90secs. With Inline::Perl5. [20:08] So, the old horse is still strong enough. :) Comparing to 10min on my MBP I'm more than happy about the time it's going to spare for me. [20:09] MasterDuke: will see the benchmarks when they release it. My trust in them was never that high. Intel looks like and old slow fart now. :) [20:09] s/and/an/ [20:39] vrurg, what is "whole spectest"? [20:40] Altai-man: make spectest including Inline::Perl5 [20:41] Ah, seeing rest of the conversation. Was surprised to see 5 minutes for a spec/test, but I have 3900X. I imagine 28 cores would really boast in virtualization. [20:41] s!spec/test!spectest! [20:43] Altai-man: they do. I had too many cases of testing rakudo on openbsd/freebsd/centos/windows in the past. Now I can do them in parallel when necessary. :) [20:45] vrurg, that's pretty cool, glad for you! [20:49] Altai-man: thanks! :) [20:51] *** Kaiepi left [21:14] *** Altai-man left [21:37] ¦ roast: 32c5359a85 | (Elizabeth Mattijsen)++ | S32-hash/multislice-6e.t [21:37] ¦ roast: Initial batch of %h{;} tests [21:37] ¦ roast: review: https://github.com/Raku/roast/commit/32c5359a85 [22:52] *** Kaiepi joined [22:59] *** Xliff left [23:58] *** maggotbrain left