🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
04:17 kjp left 04:18 kjp joined 04:24 kjp left, kjp joined
nine yes 06:57
[Tux] Rakudo v2025.03-102-g44c365513 (v6.d) on MoarVM 2025.03-9-g5f399c640
csv-ip5xs0.265 - 0.267
csv-ip5xs-201.097 - 1.122
csv-parser1.103 - 1.111
csv-test-xs-200.138 - 0.139
test1.855 - 1.879
test-t0.409 - 0.416
test-t --race0.274 - 0.281
test-t-204.995 - 5.055
test-t-20 --race1.221 - 1.245
 07:03
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
Geth nqp/main: b51dfc5696 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get various MasterDuke++ fixes
 07:56
rakudo/main: a3841c2618 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for various MasterdDuke++ fixes on MoarVM
 08:33
08:56 sena_kun joined
lizmat nine: looking at method IMPL-QAST-PSEUDO-PACKAGE-LOOKUP in ast/name 10:15
nine I'm sorry! 10:16
lizmat is there a reason why CORE is handled differently there ?
is that an optimization?
nine The commit message explains it. Rakudo commit 0e79b375eb1
linkable6 (2023-06-17) github.com/rakudo/rakudo/commit/0e79b375eb RakuAST: fix BEGIN time CORE:: lookup
nine I should probably put such information more often into comments rather than commit messages :/ 10:17
Flip side is, git blame on my code is often quite educating
lizmat aha, but in that case: why not go a step further and *not* create a "permanent" PseudoStash object at all, but do the lookup and make *that* a WVal ? 10:18
case in point: BEGIN &CORE::prompt; (golfed from why the Prompt module won't precomp under RakuAST 10:19
)
nine Yeah, that would make sense
lizmat ok, will take that on then 10:20
nine In theory it's wrong as Raku does allow for replacing CORE:: symbols. E.g. my &get-prompt := BEGIN -> { &CORE::prompt }; CORE::<&prompt> := -> { say "no" }; get-prompt()() 10:21
lizmat also in the case of precomp ?
nine But I'm inclined to say that this is just horrible and if you really think you need this combination of features, you should overthink your life choices anyway 10:22
lizmat yeah, and also: that's why we have .wrap ?
m: BEGIN &max.wrap({ say "no" }); say max 10:25
camelia no
True
lizmat hmmm.. I guess the .wrap wouldn't work either then
nine Again...life choices 10:26
lizmat nine: maybe another approach would be better: how about putting the nqp::ctx of CORE:: into nqp::bindhllsym key ?
so we wouldn't need to go looking for a specific key each time we do CORE:: 10:27
so the PseudoStash CORE handling would just need to do a nqp::gethllsym?
also: in that commit, the phrase: "But these dynamically compiled frames won't be serialized anyway" appears to be incorrect 10:29
nine I think so, too
lizmat would the bindhllsym idea be feasible ? 10:31
to handle the "At BEGIN time, we don't have the setting as an outer frame for PseudoStash to find." case ? 10:32
nine Worth a shot I guess 10:38
lizmat ok, will give that a shot after having done some necessary legal administrativia 10:49
afk& 10:57
11:08 JimmyZhuo joined
Geth rakudo: zhuomingliang++ created pull request #5838:
s/:=/=:=/ in elsif condition		 11:14
nine I'm re-visiting List.Capture, specifically this statement: 11:16
nqp::istype(($v := nqp::atpos($!reified, $i)),Pair) ?? nqp::bindkey($hash, $v.key.Str, $v.value) !! nqp::push($list,$v) while nqp::islt_i(++$i,$elems);
My original "fix" was to not sink the body of statements with a while/until modifier. But that violates a spec test that requires a sunk warning and rightly so. 11:17
I think I finally understand the reason why the old frontend doesn't generate a p6sink here. It's not the loop. It's that a ternary expression itself is not sinkable, i.e. there's no sink($cond ?? $foo !! $bar). Instead, the operator propagates sink context to its branches. So it's $cond ?? sink($foo) !! sink($bar) 11:19
But the branch in this case is an NQP op and those are never sunk.
12:09 finanalyst joined 13:34 JimmyZhuo left 13:56 sena_kun left, sena_kun joined
[Coke] SmokeMachine: will try again to get Red working in Blin 13:59
It would be great if someone wanted to curate a list of "important" modules so I can verify they are getting tested in Blin and not skipped for some reason.
Is our best indicator of those modules right now the # of stars on a repo? 14:07
(maybe combined with a dependency matrix) 14:08
Geth rakudo/main: 17 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/a...fb1395deea		 14:10
nine Oh my....17 commits to do proper reporting of sink context. At least according to this one spectest file 14:11
14:16 sena_kun left 14:17 sena_kun joined 14:18 Geth left, Geth joined
Geth rakudo/main: 17 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/a...fb1395deea		 14:19
lizmat oops, that one already got notified :-)
SmokeMachine [Coke]: thanks! I have done some fixes on that… I hope it helps. Please let me know if I can help… 14:21
14:23 sena_kun left 14:24 sena_kun joined
[Coke] c: say 3 14:57
committable6 [Coke], Seems like you forgot to specify a revision (will use “v6.c” instead of “say”)
[Coke] c: HEAD say 3
committable6 [Coke], ¦HEAD(a3841c2): «3␤»
[Coke], ¦v6.c (89 commits): «3␤» 14:58
[Coke] (checking whateverable gist history, the oldest gist is 9 years old) 15:00
.ask AlexDaniel - any need to cleanup old whateverable gists? It has 500+ and the oldest is 9 years old. Guessing it's fine as is. 15:05
tellable6 [Coke], I'll pass your message to AlexDaniel
[Coke] SmokeMachine: gist.github.com/coke/9f577f87dbda4...eaa7a3d716 - so testing red, there are 8 other failures blocking it now. 15:17
gist.githubusercontent.com/coke/0a.../data.json has the json data from that run; anything without a status: OK needs to be reviewed. (surely several of these are blocked by a dep that is failing) 15:20
(removed all the status OK and repushed) 15:23
rerunning just with License::SPDX.... 15:32
I suspect this is a blin bug that thinks JSON::Class is already installed when it's really the "other" one. 15:33
15:39 finanalyst left
[Coke] c: d6fb1395deeaa16e2357ec0401d0c64710cd0d34 say 3 15:54
committable6 [Coke], ¦d6fb139: «3␤»
[Coke] (json class) which sounds very familiar from previous investigation that I dropped. :) 15:55
ugexe: is there a zef API or CLI way to say "does this module satisfy this requirement"? 16:01
team: blin claims to support pakku which itself has, I think, been replaced, and I don't think anyone is using it or the replacement, only zef. OK to remove support for it from Blin?
s/anyone is/many are/ 16:02
ugexe: or a way to turn all the various requirements for a module into a list of things to install. (so that I could figure out in advance that all my json::classes require the other one) 16:03
Geth Blin: 8497e679aa | (Will Coleda)++ | bin/blin.p6
Bug is fixed, no need to skip
 16:11
[Coke] I see in the JSON::Class failure, that it thinks it's going after version 0.0.21, but in the output, Found: JSON::Class:ver<0.0.6>:auth<zef:vrurg>:api<1.0.5>, which in turn then depends on Test::Async, but blin doesn't have it available, presumably because v0.0.21 didn't require it. 16:19
SmokeMachine [Coke]: is there a way I can see the error gotten when installing Red? 16:28
[Coke] ... it's not a Red error 16:32
the dependencies aren't available.
Looks like the root cause is the two packages with the same name. Trying to figure out how to fix blin so it can deal with that. 16:33
SmokeMachine if that's related to Red depending on META6 that depends on JSON::Class that tries to use the wrong one, this should fix it (I think...) but wasn't released yet because it breaks on windows: github.com/jonathanstowe/META6/pull/32
[Coke] blin doesn't re-install the dependencies each module, it orders the tests so that by the time it gets to Red, all the dependenices should be available... but the previous JSON::Class issue derails anything that depends on either version, it seems. 16:34
SmokeMachine It seems Red depends on Test::Meta that starts the dependency to JSON::Class... maybe if I remove the dependency on that and the test that uses that, it may be fixed? 16:36
I think I'll remove that (at least for now)... It just tests the META6 file... I think, for now, being able to let blin to let me know when I need to change something because of a new rakudo version broke it (that already happened a few times) is more important... 16:41
[Coke] adds github.com/Raku/Blin/issues/39 16:42
SmokeMachine: Depend on what you need. Blin has a bug 16:43
For red specifically, we can do a separate test pre-release outside of blin with a compiled HEAD version
... assuming I can't fix this issue by .04 16:44
SmokeMachine one point on the issue: I don't think Red depends on both JSON::Class... I think it depends only on JSON::Class:auth<zef:jonathanstowe>... 16:47
but I may be wrong, are you sure about that? 16:48
[Coke] Red doesn't depend on both 16:49
it has two downstream dependencies on jonathan's at different versions (but those end up in the same dist)
but blin is pulling in the other one for testing and failing.
SmokeMachine ah, ok, thanks sorry... my english is not very good...
[Coke] no worries.
er, upstream. water direction is confusing. :) 16:53
SmokeMachine I'm only concerned because I already had to add these 2 exceptions on Red for problems blin did not let me know before Rakudo release: github.com/FCO/Red/blob/master/lib...od#L47-L56 16:56
[Coke] I will mention here when Blin is fixed on this issue, but in the meantime, yes, please double check your module regularly against HEAD 16:59
(And I will try to make sure it's tested manually around the time of the last Blin run as well) 17:00
(until Blin is fixed)
I am glad that those are most recent issue was from 2024.03 17:19
er, that was two different sentences I broke apart and put together in the middle.
ugexe the META6 pr should fix the issue i believe, although a new release of that module needs to be made 17:37
[Coke] github.com/jonathanstowe/META6/pulls ? 17:59
ugexe: I think will still die even if everyone is specifically using jonathan's version because zef look is recommending vrurgs. 18:01
er, zef info
which then causes some confusion when blin is testing
ugexe because the depends section just asks for JSON::Class 18:02
or did
and will until a new release is made
[Coke] I did a test just with License::SPDX and it still failed, and that has no deps on META6 18:04
the problem as I understand it: something depends on JSON::Class:ver<0.0.14+> - blin checks and makes sure all the deps for that are tested and installed... and then it tries to check out 'zef info JSON::Class' which isn't the right project, doesn't have the deps available, so that fails, then when we get back to the thing that depending on JSON::Class, JSON::Class isn't installed. 18:05
blin isn't installing all the deps at the time of testing module X, it got *all* the deps ever needed for the run up front and ordered the tests so things would work.
s/check out/ build, test, install / 18:06
and even if we fixed zef info to report on the json class we happen to need, it's just hiding the issue (and would break testing of anything depending on vrurg's version, probably) 18:07
jdv is that a blin issue or a zef issue or a author issue? 18:08
[Coke] blin
blin assumes that everyting named "JSON::Class" is the same thing
ugexe if something depends on "JSON::Class:ver<0.0.14+>" and somehow tied that into `zef info` i'd expect it to use `zef info "JSON::Class:ver<0.0.14+>"` not `zef info JSON::Class`
[Coke] ugexe: It's *blin* 18:09
the fact that zef is recommending the other one is triggering the issue, but it's blin's issue.
jdv how is it blin. the dist asked for Foo and Foo is there. if it needs Foo:auth<Bar> it should have been more specific, no? 18:10
[Coke] *sigh* 18:11
I have already explained it here 2x and in the ticket once. :)
Foo is NOT there.
jdv i'll look at the ticket
its on blin?
[Coke] github.com/Raku/Blin/issues/39
ugexe where does it call `zef info JSON::Class`? seems like it just needs to use the full dependency string 18:13
[Coke] I am pretty sure blin is getting the deps, then doing stuff on module.name rather than the full module (presumably to avoid having to track v0.0.14 vs. v0.0.20, etc.)
ugexe presumably that is available wherever blin calls it
[Coke] "just". 18:14
ugexe thats why i'm interested to see where zef info is called 18:15
[Coke] It's not literally zef info, it's using the zef modules.
ugexe ah
github.com/Raku/Blin/blob/8497e679...in.p6#L231 18:18
that seems like it just takes whatever one was added to that hash field last
[Coke] Thank you. 18:41
21:59 sena_kun left 22:28 rakkable left, rakkable 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!