🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:00 linkable6 left, evalable6 left 00:01 evalable6 joined, linkable6 joined 00:02 reportable6 left 00:03 reportable6 joined
japhb My rebuild-everything script has had module install issues with the latest couple Rakudo commits. After some abortive debugging, I rewrote part of my script to give better information about exactly what failed in the module installs. Result: 00:50
===> Searching for: Crypt::SodiumPasswordHash
Type Str does not support associative indexing.
"zef" unexpectedly returned exit value 1
It doesn't look like Crypt::SodiumPasswordHash has had any commits in months, so I assume either a problem with Rakudo or zef (though zef was having no problems installing lots of other modules, so it would have to be hitting an edge case if it's zef). I'll try to narrow down the rakudo commit range 00:52
01:03 linkable6 left 01:05 linkable6 joined 01:14 Voldenet left 01:19 Voldenet joined
raydiak I'm not sure that the way Sodium::PasswordHash is declaring dependencies in its META6.json is valid. I suspect zef is choking on that. changing it eliminates the error 01:36
02:15 Voldenet left 02:21 Voldenet joined
raydiak it's not entirely clear from my reading whether the adjustment should be to that META6 or to zef. in the syns and docs, almost everywhere which has dependencies split into build/test/runtime also splits each of those into requires/recommends...EXCEPT design.raku.org/S22.html#line_339 . I can't find a statement which is explicitly clear on this point 02:24
japhb Everything built successfully at v2021.06-47-g1e6d93c29, so at the very least, something has changed during the last few commits (even if the META6 *also* needs a fix) 02:57
(Rakudo commits, I mean) 02:58
raydiak there is a lot of map and grep in github.com/ugexe/zef/blob/master/l...#L154-L163 so I would suspect the recent changes in those areas 03:01
though it could be that it should have been failing all along, not sure if it's necessarily a "regression" or not 03:03
lizmat: ^^
bisectable6: [""].grep(*.<foo>).grep(*.defined).say 03:06
bisectable6 raydiak, Will bisect the whole range automagically because no endpoints were provided, hang tight
raydiak, Output on all releases: gist.github.com/5cb9e9d49ef6a5800e...db80d34b8a 03:07
raydiak, Bisecting by exit code (old=2021.06 new=265888c). Old exit code: 0
raydiak, bisect log: gist.github.com/fe4012f6fc43f2fed2...02b078a7a3
raydiak, (2021-07-10) github.com/rakudo/rakudo/commit/bb...4dffbe798c
raydiak, Output on all releases and bisected commits: gist.github.com/306cd21f7bc3ec349a...f38f0ff284
raydiak that used to put the failure into the array being mapped, and then grep it out. now it throws immedieately 03:08
well, not into the array. into the output from map. you know what I mean
ugexe modules.raku.org/dist/Crypt::Sodiu...6.json#L22 03:09
that is missing 'requires' section of 'test' 03:10
ah you already mentioned that
raydiak I also didn't find an authoratative answer as to whether that should be valid or invalid, as I found one example in the syns which also doesn't have the 'requires' section 03:11
and nothing anywhere explicitly says you have to have it if you use the hash form of depends
ugexe well the authoratative answer is if you use the hash form you need to have the 'requires' section 03:12
raydiak can you cite your source? 03:13
ugexe the actual implementation i guess, which we came up with at a PTS 03:14
raydiak I guess design.raku.org/S22.html#line_339 should be adjusted, then 03:15
ugexe the lack of 'requires' in s22 was just a mistake when that page was updated
well those documents dont really reflect reality anyway
raydiak I know. I just couldn't find an actual specific answer to this question anywhere, so I was looking for what the intention originally was 03:16
if you tell me that's the communities agreed-apon stance, I'll go with it, but we should probably doc is somewhere, and add it to roast 03:17
*doc it somewhere
ugexe what part of rakudo consumes that?
the answer is nothing
so it kinda feels weird to put it in the roast
especially because parsing it is such a PITA
raydiak roast was supposed to be the specification test suite. are we saying that META6.json is not part of the raku specification? 03:18
ugexe muliple formats (depends:[] vs depends:{}) and multiple spec formats ("Foo:ver<1>" and {"name":"Foo","ver":1}) and the only-one-of-these parsing (["This","Or","That"])
well certainly not every part of META6.json is part of raku specification 03:19
if raku had a mechanism built in for parsing that depends stuff, then having tests in roast would feel more appropriate
but it doesnt 03:20
raydiak right, I do see what you're saying. but then what is it? just a loosely defined collection of stuff that zef and other tools happen to agree apon?
ugexe for better or worse thats the only purpose it needs to serve up until now 03:25
theoretically the core could understand it along with parsing names like "Foo:ver<1>" but it'll be harder and less elegant than you think, to the point it probably wont feel like a good idea without thinking about it more which just makes you even more worried and yeah 03:26
if it was just one of "depends":[] or "depends":{} along with just {"name":"Foo"} type dependencies it would be quite sane 03:27
raydiak I understand. I started to attempt to add support for :ver<> forms to panda's command line forever ago, and I do recall it quickly becoming more complicated than was immediately obvious 03:28
ugexe github.com/ugexe/zef/blob/master/t...-parsing.t this is probably the best source for what dependency formats work 03:31
raydiak from the sound of things, seems like centralizing support for all that complexity in rakudo and exposing it in a way which could be used by zef and other tools might not be a bad idea. rakudo already does care about other parts of META6.json anyway, e.g. "provides" 03:32
japhb Hmmm, got a lockup installing Cro::Webapp under rakudo-moar-2021.06-51-ga5d813539 -- trying again at same Rakudo rev in case that was a flake.
This time Cro::Webapp testing spit out some warnings, but it seemed to install anyway. :-? 04:03
... and now complete install at rakudo-moar-2021.06-51-ga5d813539 04:07
Same at v2021.06-53-g7a1b729bf 04:49
05:01 [TuxCM] left, [TuxCM] joined 05:06 gfldex left, rba left, gfldex joined 05:07 rba_ joined, rba_ is now known as rba 05:11 leont left, SmokeMachine left, kawaii_ left 05:12 kawaii_ joined, SmokeMachine joined, leont joined
japhb Same at v2021.06-54-g52ffc1255 05:36
06:02 reportable6 left 06:04 reportable6 joined
lizmat raydiak: will look at it 06:04
raydiak ++lizmat 06:06
in case you didn't read the whole backlog, the behavior which changed can be reduced to `[""].grep(*.<foo>).grep(*.defined).say`. seems like where a failure would have previously flown from the map to the grep, it now throws immediately 06:07
japhb Got a weird error late in the process building on v2021.06-55-g0761d4b2d, but it's possible it was a red herring -- trying that one again. 06:16
Gah, early test failure at: t/01-sanity/55-use-trace.t ...................................... Dubious, test returned 1 (wstat 256, 0x100) 06:30
Trying yet again
07:10 patrickb joined
japhb Flakiness aside, v2021.06-55-g0761d4b2d built successfully on the fourth try. 07:10
07:23 Geth left, Geth joined 07:32 patrickb left 07:33 patrickb joined
patrickb o/ 07:33
Geth rakudo: 71f6bada9e | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Make sure we don't sink values in .grep(Callable)

bb09bbb8581364f7323ff1f17a caused a regression because the value returned from the Callable was being sunk, when it wasn't before. This would cause Failures that were returned, to be thrown instead of just being passed along.
  raydiak++ for golfing		 07:34
lizmat raydiak ^^
raydiak thanks lizmat++ :) 07:38
good catch japhb++ 07:42
japhb lizmat++, I'll run a full rebuild against head 07:58
... but I'll have to give the results on the morrow, because Zzzzzzzzz .... 07:59
lizmat sleep well!
japhb thx & 08:01
08:49 |Tux| joined 09:30 Kaiepi left 10:24 Kaiepi joined 10:29 sena_kun joined 10:55 RakuIRCLogger left, RakuIRCLogger joined 11:12 frost joined 12:02 reportable6 left 12:03 reportable6 joined
lizmat afk for a few hours& 12:21
12:37 frost left
|Tux| Rakudo v2021.06-60-g71f6bada9 (v6.d) on MoarVM 2021.06-16-g74e828f0a
csv-ip5xs0.948 - 1.055
csv-ip5xs-209.216 - 9.740
csv-parser29.740 - 30.771
csv-test-xs-200.382 - 0.403
test7.734 - 8.525
test-t2.056 - 2.086
test-t --race1.059 - 1.111
test-t-2035.462 - 38.429
test-t-20 --race11.212 - 12.592
 12:56
ugexe raydiak: yes that would be ideal. altough i've never been sure how all that would look when put in the core e.g. some odd-ball utility functions? extend the Distribution interface? add new META6 interface? 13:17
patrickb ugexe, nine: github.com/rakudo/rakudo.org/issue...-878055922 13:22
ugexe well he had sufficient permissions for the source files to be installed to site 13:24
patrickb The MSI installer he is testing requires Admin to install to C:\Program Files\ 13:25
ah 13:26
you mean during install of the module
so you think rakudo bug?
ugexe yeah, at least i think that is the case. installing the source files happens before precomp, although i guess its possible the repo lock is accessed earlier
13:27 sena_kun left
ugexe ah yeah i was wrong 13:27
github.com/rakudo/rakudo/blob/99e4...#L150-L159 13:28
however the previous line shows they should have write access
my $path = self!writeable-path or die "No writeable path found, $.prefix not writeable";
my $lock = $.prefix.add('repo.lock').open(:create, :w);
patrickb ugexe: Thanks for the quick response. My gut feeling points toward some Windows specific Rakudo bug. If noone beats me to it, I'll try to reproduce this tomorrow evening. 13:34
ugexe: Do I remember correctly, that the idea is to install to the home dir repo if site install isn't writable? (or fails?) 13:36
ugexe yes 13:37
github.com/ugexe/zef/blob/602c54f1...1220-L1227 13:38
github.com/ugexe/zef/blob/602c54f1...ig.json#L6
patrickb Thanks! ugexe++ 13:41
13:44 sena_kun joined
Geth nqp/new-disp: 318a9f04d1 | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Switch `with` code-gen to emit a dispatch op
 14:56
lizmat notable6: weeklly 15:03
notable6 lizmat, No notes for “weeklly”
lizmat notable6: weekly 15:04
notable6 lizmat, 2 notes: 2021-07-05T18:43:23Z <CIAvash>: github.com/CIAvash/qutebrowser-userscripts ; 2021-07-05T18:43:39Z <CIAvash>: www.ciavash.name/blog/2021/07/05/r...d-my-blog/
15:04 MasterDuke joined
Geth nqp/new-disp: 85cac6e744 | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Compile loop block invocations to a dispatch op

And also remove a little redundant code.		 15:15
rakudo/new-disp: ae622053e8 | (Jonathan Worthington)++ | src/vm/moar/Perl6/Ops.nqp
Emit a dispatch op in p6store

In place of the findmethod/invoke instructions.		 15:20
Kaiepi m: role Foo { proto method level() {*}; multi method level(::?ROLE: --> 0) { } }; role Bar does Foo { multi method level(::?ROLE: --> 1) { } }; say Bar.level 15:34
camelia 1
Kaiepi m: role Foo { proto method level() {*}; multi method level(::?ROLE: --> 0) { } }; role Bar does Foo { say $?ROLE.HOW.^name; multi method level(::?ROLE: --> 1) { } }; Bar.^pun 15:35
camelia Perl6::Metamodel::ParametricRoleHOW
Kaiepi m: role Foo { proto method level() {*}; multi method level(::?ROLE: --> 0) { } }; role Bar does Foo { say $?ROLE.HOW.^name; multi method level(::?ROLE: --> 1) { } }; Bar.^find_method('level').dispatchees[1].signature.params[0].say 15:40
camelia Perl6::Metamodel::ParametricRoleHOW
No such method 'dispatchees' for invocant of type 'ForeignCode'
in block <unit> at <tmp> line 1
Kaiepi m: role Foo { proto method level() {*}; multi method level(::?ROLE: --> 0) { } }; role Bar does Foo { say $?ROLE.HOW.^name; multi method level(::?ROLE: --> 1) { } }; Bar.^pun.^find_method('level').dispatchees[1].signature.params[0].say
camelia Perl6::Metamodel::ParametricRoleHOW
Foo $
Kaiepi m: role Foo { proto method level() {*}; multi method level(::?ROLE: --> 0) { } }; role Bar does Foo { say $?ROLE.HOW.^name; multi method level(::?ROLE: --> 1) { } }; Bar.^pun.^find_method('level').dispatchees.map({ .signature.params[0] }).say 15:41
camelia Perl6::Metamodel::ParametricRoleHOW
(Bar $ Foo $)
Kaiepi m: role Foo { proto method level() {*}; multi method level(::?ROLE: --> 0) { } }; role Bar does Foo { say $?ROLE.HOW.^name; multi method level(::?ROLE: --> 1) { } }; Bar.^pun.^find_method('level').dispatchees.map({ .signature.params[0].HOW.^name }).say 15:42
camelia Perl6::Metamodel::ParametricRoleHOW
(Perl6::Metamodel::ClassHOW Perl6::Metamodel::ClassHOW)
Kaiepi wat
m: role Foo { proto method level() {*}; multi method level(::?ROLE: --> 0) { } }; role Bar does Foo { say $?ROLE.HOW.^name; multi method level(::?ROLE: --> 1) { } }; Bar.^method_table('level').dispatchees.map({ .signature.params[0].HOW.^name }).say 15:54
camelia No such method 'method_table' for invocant of type
'Perl6::Metamodel::ParametricRoleGroupHOW'
in block <unit> at <tmp> line 1
Kaiepi m: role Foo { proto method level() {*}; multi method level(::?ROLE: --> 0) { } }; role Bar does Foo { say $?ROLE.HOW.^name; multi method level(::?ROLE: --> 1) { } }; Bar.^candidates[0].^method_table('level').dispatchees.map({ .signature.params[0].HOW.^name }).say
camelia Too many positionals passed; expected 2 arguments but got 3
in block <unit> at <tmp> line 1
Kaiepi m: role Foo { proto method level() {*}; multi method level(::?ROLE: --> 0) { } }; role Bar does Foo { say $?ROLE.HOW.^name; multi method level(::?ROLE: --> 1) { } }; Bar.^candidates[0].^method_table<level>.dispatchees.map({ .signature.params[0].HOW.^name }).say 15:55
camelia No such method 'dispatchees' for invocant of type 'Any'
in block <unit> at <tmp> line 1
Kaiepi m: role Foo { proto method level() {*}; multi method level(::?ROLE: --> 0) { } }; role Bar does Foo { say $?ROLE.HOW.^name; multi method level(::?ROLE: --> 1) { } }; say Bar.^candidates[0] ~~ Foo.^candidates[0] 15:58
camelia True
Kaiepi there we go, problem typecheck
(locally) 15:59
16:04 linkable6 left, evalable6 left 16:05 evalable6 joined 16:06 linkable6 joined 16:33 MasterDuke left
Geth rakudo/new-disp: 9da4d1fe21 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Throw proper no matching candidates exception
 16:35
rakudo/new-disp: 3e6aab202a | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Junction auto-thread failover in multi dispatch

With the new dispatcher we can avoid an extra level of closure wrapping and argument slurping/flattening compared to the current implementation.
With the new dispatcher we can avoid an extra level of closure wrapping and argument slurping/flattening compared to the current implementation.		 17:26
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2021-07-12T17:27:27Z”
17:33 linkable6 left, evalable6 left 17:35 evalable6 joined 17:36 linkable6 joined 17:38 sena_kun left 18:02 reportable6 left 18:04 MasterDuke joined 18:05 reportable6 joined
japhb lizmat: Full rebuild successful at v2021.06-60-g71f6bada9 18:16
lizmat *phew*
18:18 melezhik joined
melezhik AlexDaniel whateverable works now, thanks ! 18:18
tellable6 2021-07-11T19:20:53Z #raku-dev <AlexDaniel> melezhik: try again?
AlexDaniel cool
ping me if it does that again
melezhik yeah, for sure
lizmat And another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/07/12/2021-...splitting/ 18:50
19:18 evalable6 left, linkable6 left, evalable6 joined 19:20 linkable6 joined 19:24 melezhik left 19:36 patrickb left
[Coke] I think the community agreed format of META6.json should be on the doc site. 20:05
(even if it's not officially spec)
japhb [Coke]: Definitely agreed. I've found myself confused about the details and unsure of what was recommended more than once. 20:12
[Coke] Might also be nice to have a verifier that we could plug in to something like Blin 20:13
gfldex We already got that with raku.land/cpan:JSTOWE/Test::META 20:15
[Coke] oh, if it's already use zef for testing, maybe that'd have an option. 20:16
but +1 if we can get blin to check that as well. 20:17
gfldex I'm trying to sneak t/meta.t into every project I send a PR to. :-> 20:18
ugexe if i were using it i'd put it in xt/meta.t and rely on a explicit CI test line like `prove -r xt/` in addition to running the tests in t/ 20:21
github.com/ugexe/Perl6-App--OpenAP...6Validator 20:23
i also did this awhile back trying to specific it all in OpenAPI
although its just a proof of concept
gfldex jnthn would like to see Test::META in "test-depends" but I disagree. If the META6.json is broken it can be impossible to even fetch the source. Pretty hard to run tests in this case.
ugexe if the bad meta data is in the ecosystem its already too late 20:24
there is no need for a test to tell end users about it
the test is an authoring issue
so yes it goes in test-depends but i'd put the actual test in xt/
even if theoretically there should be a xt-test-depends or something
gfldex The author might forget to run the test if extra steps are needed. 20:25
ugexe author can forget any number of things
gfldex If you want other ppl do stuff, make it as simple as possible.
[Coke] make fez reject a submission with a bad one?
ugexe yeah ecosystems ar ea good place to handle that 20:26
gfldex I make a release on github before I push to the ecosystem. So for me that check would be to late.
But having that check in fez would not hurt for sure. 20:27
ugexe why wouldnt you just have your CI catch it?
[Coke] opens github.com/tony-o/raku-fez/issues/43
ugexe zef has xt/ tests that get run for authoring purposes... it would be insane to have every user run those
it would indeed be slightly easier for me to not do that, but the separation makes logical sense 20:28
[Coke] agreed. I think encouraging authors to adopt xt/ is better than having every user run those cycles.
gfldex How well does META6.json age? Is there a failure mode where changes to the ecosystem/Rakudo can be caught by checking META6.json at install time? 20:31
tonyo [Coke]: fez already warns you that your meta is not looking good 20:38
tellable6 2021-07-11T18:07:20Z #raku <melezhik> tonyo fez works for me as a charm, thanks a lot for your work - gist.github.com/melezhik/7cda94dc4...4d64c3962a
ugexe gfldex: i dont follow
gfldex A while back a change to Test::META was made that showed a problem with a META6.json of one of my modules at install time. I would not have noticed otherwise (maybe much later). 20:41
ugexe why install time? test time is the appropriate time to catch that, be it unit or author tests 20:45
gfldex `zef install` kindly ran the test and told me about the problem because I used Test::META in t/meta.t . 20:46
Test::META was younger then the module I wanted to install. 20:47
ugexe a happy coincidence, but im not sure that justifies everyone validating the same data structure 20:49
japhb tonyo: ISTR that the tests fez runs are somewhat incomplete. (That said, `fez checkbuild` is part of my standard release run-up now, so clearly it's helping.) 21:02
21:07 MasterDuke left
raydiak a few notes about the META6 situation: (1) the offending module which led to that conversation does use Test::META, which doesn't catch that particular error. (2) neither zef nor fez appear to use Test::META nor META6, both of which we link to from docs.rakulang.site/language/module...META6.json 22:06
(3) while these community modules do exist, the idea of putting the functionality into core is that we would have an actual centralized, authoratative point for these things. something this important and far-reaching shouldn't be under the maintenance and authority of one person's github repo. and since it is a nontrivial thing to get completely right, it makes sense from an abstraction standpoint as well,
to not require every package manager, authoring tool, and ecosystem to reimplement these things or pick from a variety of modules to do it...not to mention the fact that these modules themselves use META6.json and have to be installed by something, creating a bit of a metacircularity issue
22:07 evalable6 left, linkable6 left 22:08 linkable6 joined 22:09 evalable6 joined
japhb raydiak: Generally agree, with a nit: github.com/raku-community-modules exists, so we don't need to worry as much about small bus number for a module considered generally important (some of the modules there came from loss of original maintainer, or maintainer unable to continue work on them). 22:16
raydiak for those reasons, my personal stance is basically that letting fez/zef be the central point is bad, and if we want to use Test::META and/or META6 or whatever similar things, or pull those parts out of zef and fez into a separate module, then cool, but whatever we decide to use should go into core, in rakudo's lib/, alongside e.g. Test, NativeCall, Pod::To::Text, etc, with an agreed-upon API for accessing
tonyo #3++
raydiak that functionality, and be covered by roast
japhb Is Test tested by roast or by `make test`? 22:17
Geth rakudo/new-disp: e5c5bd765f | (Jonathan Worthington)++ | 2 files
Remove now-unused dispatcher extops on MoarVM

While other backends will use these for now, they are no longer needed on MoarVM, which uses new-disp going forward.
raydiak heh I have no idea what tests Test, good question :)
from github.com/Raku/roast/tree/master/S24-testing and github.com/rakudo/rakudo/blob/mast...st-basic.t it appears that often, Test tests Test. which at least ensures that it is internally consistent, even if it doesn't really guarantee that it is doing what it should. I also see some of github.com/Raku/roast/tree/master/...st-Helpers being used in places 22:28
so the answer to the question seems to be mostly that Test is tested in roast. it was part of the syns, after all. I have the same feeling about where META functionality testing should go. I'd like to allow as much as possible for a future when we may again have multiple compilers, and they should provide this same functionality and be compatible with the same modules/ecosystems, so I don't see it as a 22:38
rakudo-specific thing, but part of the spec
anyway, I slept about 2 hours and need a nap. just wanted to drop in and contribute my 2 cents when I saw the backlog 22:52
[Coke] tonyo++ 22:58
I don't think the meta validation should be in core. 22:59
Because then the format is locked to that release.
and we need to be able to update what is valid META even if someone has an old rakudo
(and I don't want to have dual-life modules) 23:04
23:09 linkable6 left, evalable6 left 23:10 linkable6 joined 23:12 evalable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!