00:45 MasterDuke left 01:28 Guest94360 left 01:45 leont left 03:28 Xliff joined
Xliff jnthn timotimo lizmat: Have subsets made it into RakuAST, yet? 03:29
Thanks.
06:46 maggotbrain left 06:59 maggotbrain joined
Xliff Looks like repository is in a currently unbuildable state. Please see: gist.github.com/Xliff/00018e5ea896...229d53fdbe 07:53
^^ ugexe jnthn timotimo
timotimo bin/nqp-m version 2020.09-3-g30dd003b1 is outdated 08:29
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
lizmat Xliff: there are no subsets in RakuAST yet 09:40
09:41 Altai-man joined 09:44 sena_kun left
lizmat Files=1336, Tests=113604, 222 wallclock secs (32.24 usr 9.40 sys + 3085.65 cusr 289.66 csys = 3416.95 CPU) 10:01
Xliff I thought updating nqp was handled by the build process 10:44
lizmat well, it does if you configure every time, afaik 10:50
but devs generally don't run the whole configure process every time
Xliff Honesly, I thoguht rakudobrew did do that! 10:51
LOL
Adding '--gen-moar --gen-nqp' to config opts does the trick.
Adding '--gen-moar --gen-nqp' to config opts does the trick.git submodule update --init --recursiv 10:52
Oops. Have to back out of that. 10:53
That was moar, not moar-blead
OK, so: 'cd nqp; sh config.status' fixes the problem 10:55
Then mthe rakudobrew command can be executed normally. 10:56
Geth rakudo: 1c08e66b79 | (Elizabeth Mattijsen)++ | src/core.e/hash_slice.pm6
The :kv adverbs should force list return

Otherwise we'd only be looking at the k in case of a single element.		 11:16
rakudo/prefix-pipe-pipe: e6787d77c0 | (Elizabeth Mattijsen)++ | src/Perl6/Actions.nqp
Implement the prefix:<||> operator in postcircumfixes

  - for 6.e and later only
  - described by design.raku.org/S09.html#line_419
  - sort of implemented by Wenzel P.P. Peppmeyer in Slippy::Semilist
  - does not actually add a prefix operator: it's just a double slip
  - manipulates the AST in case of a postcircumfix, to select the ; variant
  - the postcircumfix:<{; }> variant does the right thing for prefix:<||>		 11:28
lizmat gfldex: ^^ :-)
gfldex \o/ 11:29
Geth rakudo: lizmat++ created pull request #3953:
Implement the prefix:<||> operator in postcircumfixes
gfldex will that be in v6.e? 11:30
lizmat well, if the PR is accepted, ytes
*yes
although it's opt-in in 6.e, I decided to make it a PR to allow for discussion 11:31
$ r 'use v6.e.PREVIEW; my %h; dd %h{ || <a b c> } = 42; dd %h' 11:32
Int element = 42
Hash %h = {:a(${:b(${:c(42)})})}
is how you can use it :-) 11:33
gfldex Do we have a mechanism for avoiding `use Module::Name` for a compiler version >v6.d ?
lizmat no, that's the mechanism, although I would be in favour of creating a dedicated statement for it 11:40
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 :)
hmmm.. looks like there are *no* tests whatsoever for multi-level slices for either arrays or hashes :-( 11:47
gfldex lizmat: there are: github.com/gfldex/perl6-rakudo-sli...01-basic.t 11:54
Geth roast: e7aa00c3da | (Christian BartolomƤus)++ | S32-io/out-buffering.t
[JVM] Unfudge passing test
roast: e29717770c | (Christian BartolomƤus)++ | S32-io/out-buffering.t
Clean up explaining comment for test

  ... at least a bit. I'm pretty sure the removed part was wrongly
copied from cb7ec603cc. (I'm not sure if the first sentence makes sense, though.)
lizmat gfldex: thanks for the reminder :-) 11:56
afk for a bit& 11:57
12:02 leont joined
Xliff Do we have manifests for source hut? 12:30
Does someone have a YAML file that uses --configure-opts in rakudobrew? 12:49
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
Xliff Do we have .debs for 2020.09? 14:00
MasterDuke pretty sure El_Che does 14:08
lizmat ack -l 'use v6\.e\.PREVIEW' t/spec # so why are these files not part of normal "make spectest" ? 14:20
Xliff m: sub a { say &?ROUTINE.WHERE }; a() 14:35
camelia 140669184534576
Xliff m: sub a { say &?ROUTINE.WHERE }; sub b { say &?ROUTINE.WHERE }; a; b 14:36
camelia 139656343750704
139656343874424
14:38 unclechu left, djinni` left 14:39 unclechu joined, djinni` joined 14:40 unclechu left
[Tux] Rakudo version 2020.09-35-g8a2d9a612 - MoarVM version 2020.09-8-g60070970c
csv-ip5xs0.822 - 0.863
csv-ip5xs-208.368 - 9.030
csv-parser24.978 - 26.626
csv-test-xs-200.385 - 0.422
test7.640 - 7.840
test-t1.853 - 1.901
test-t --race0.838 - 0.873
test-t-2031.405 - 32.017
test-t-20 --race9.294 - 10.029
 14:43
14:47 Xliff left 14:54 unclechu joined 15:21 domidumont joined 15:27 domidumont left
dogbert17 m: my %h; %h{$_} = "abcdef" for ^1000000; say now - INIT now 16:44
camelia 1.5352052
dogbert17 m: my %h; %h{$_}{$_} = "abcdef" for ^1000000; say now - INIT now
camelia 9.00151639
dogbert17 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:45
*taken 16:46
lizmat dogbert17: the second example needs to create a hash for each iteration ? 17:04
bisectable6: my %h = a => { b => { c => 42 } }; dd %h{*;"b","c"} 17:11
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Ā¦6c (47 commits): Ā«(${:c(42)}, Any)ā¤Ā» 17:12
lizmat, Nothing to bisect!
lizmat m: my %h = a => { b => { c => 42 } }; dd %h{*;"b","c"}
camelia (${:c(42)}, Any)
lizmat that... does not feel right
lizmat feels that should be (42,)
dogbert17 lizmat: i was comparing with a 'similar' language which seems to handle this case better /o\ 17:13
the first example creates on million scalars an on million Int's 17:15
the second creates two million scalars, and one million each of Boothash, Str, Hash, Int, ContainerDescriptor::VivifyHash and ContainerDescriptor::BindHashPos 17:17
but I guess my assumption that it should 'take approximately twice as long to run' might have been erroneous 17:18
lizmat as I said, the second example needs to create a hash for each iteration 17:19
that's where the BOOThash, Hash come from
dogbert17 I get it 17:20
lizmat because of the way it works, that also needs to create a ContainerDescriptor::BibifyHash and BindHashPos as well
*Vivi 17:21
dogbert17 ok, so no easy opts hiding there then :)
lizmat well, perhaps with {|| $_ xx 2}
or right now, with {$_;$_} ? 17:22
nope, that's actually worse 17:23
dogbert17 yeah, my machine is still trying to execute it :)
three times longer than the original 17:24
lizmat 6.d gives 17.5 secs for me, 6.e 16.5 so already slightly better
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{;} :-(
or @[;] :=(
dogbert17 shouldn't gfldex have found that out already :-)
17:41 Altai-man joined 17:44 sena_kun left 17:49 Xliff joined
Xliff Has anyone worked with CI on sourcehut? 17:51
timotimo i've only recently learned of sourcehut
don't even have an account on the official instance yet, nor my own instance
Xliff timotimo: LOL! Same here. Probably learned about it from the same place. 17:52
timotimo from one of the raku channels :)
Xliff gist.github.com/Xliff/70d6fa33dbc2...faea1a6038 17:56
Heh. That was easy.
timotimo that will take 20 minutes for every run? 17:58
you could try to use the nxadm apt repos maybe? 17:59
Xliff Actually, less. 18:00
10 minutes. 18:01
timotimo still, no fun waiting for that long 18:07
18:16 domidumont joined 18:19 domidumont left
vrurg_ . 18:40
18:40 vrurg_ is now known as vrurg
Xliff \o vrurg 18:49
vrurg Xliff: o\ :)
Xliff I think I might have a bug for you. :/ 18:50
vrurg oops... \o
Xliff :)
vrurg Xliff: an issue then? Not sure when I get time for this. :(
Xliff vrurg: I've got this setup here -- github.com/Xliff/p6-GIO/blob/septe...e.pm6#L202 18:51
vrurg: Well, the thing is... I don't KNOW it's a bug yet. 18:52
If it is... I'll report it.
vrurg I'm keeping my eye on github notifications, will try not to skip the one. 18:53
BTW, we eventually got time for a vacation trip, but didn't have time to stop in Washington. 18:55
Xliff vrurg: gist.github.com/Xliff/483080e63294...6a65bc28cc 18:56
vrurg: That's OK. It's not like DC is a tourist destination or anything.
Not with the current dweller in the WH, anyways.
OK, the gist should contain... well... the gist... haha... of the issue. 18:58
BRB
vrurg Xliff: will look at the gist. Otherwise I'm fighting with syadmin tasks lately, like setting up bareos now. :( 19:00
Xliff vrurg: That's all I can ask!
Thanks!!
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.
vrurg Xliff: why do you use BUILD? It's more like a job for TWEAK.
Xliff 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!
vrurg 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/
Xliff Want me to switch it? 19:11
No diff
vrurg Then no more quick ideas. More debugging is needed. 19:15
Xliff OK, then. Will continue to beat my head on this. 19:18
If I can spin something up into a golf, then I will.
Thanks for taking the time!
vrurg 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
Xliff Not at all.
Glad you noticed that!
Almost acting like this bit was skipped: "$file ?? self.bless(:$file) !! Nil;" 19:21
HAH! 19:22
samewith vs self.new_tmp
I switched it to the latter and it worked.
vrurg Xliff: BTW, I was about to advise you against samewith for performance matters. 19:24
Xliff Think that deserves a write-up?
vrurg Sorry, don't get the meaning of 'write-up' in this context. 19:25
Xliff Bug report 19:28
vrurg Ah, no. It's a known issue, non-fixable until the new dispatching is completed (if it would ever be). 19:30
Xliff OK, Thanks!
I seem to be moving along, now. 19:31
vrurg Good! :) I'm back to my damn bareos...
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:34
MasterDuke vrurg: including rakudo build time? because a spectest for me usually takes just a little over two min with 12 jobs 19:38
vrurg MasterDuke: no, build is separate. You probably have threadripper, I guess? 19:40
MasterDuke nope, just 3700x
oh, but i'm not running the Inline::Perl5 tests
vrurg Not sure they take that much. 19:41
How much did the machine cost to you?' 19:42
MasterDuke i just replaced the cpu+mobo+ram, $650 19:44
vrurg 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:49
MasterDuke 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 19:56
vrurg BTW, I was wrong. spectesting takes 90secs. With Inline::Perl5. 20:06
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:08
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/
Altai-man vrurg, what is "whole spectest"? 20:39
vrurg Altai-man: make spectest including Inline::Perl5 20:40
Altai-man 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!
vrurg 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:43
Altai-man vrurg, that's pretty cool, glad for you! 20:45
vrurg Altai-man: thanks! :) 20:49
20:51 Kaiepi left 21:14 Altai-man left
Geth roast: 32c5359a85 | (Elizabeth Mattijsen)++ | S32-hash/multislice-6e.t
Initial batch of %h{;} tests
 21:37
22:52 Kaiepi joined 22:59 Xliff left 23:58 maggotbrain 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!