🦋 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.
JimmyZhuo CORE.c.setting.moarvm 28.5MB VS 23.3MB(rakuast) 02:20
jdv is back compat really a big issue? unless raku gets super popular i'd think prio'ing "improvements" over back compat makes more sense, no? 02:30
JimmyZhuo rakudo-m -Ilib t\spec\S03-operators\set_equality.t 05:20
===SORRY!===
Cannot resolve caller MAKE_REGEX(Regex:D, Bool:D, Bool:D, Int:D, PseudoStash:D); none of these signatures matches:
(Regex \arg, $, $, int \monkey, $)
(Match::CachedCompiledRegex \arg, $, $, int \monkey, $)
(\arg, \i, \m, int \monkey, \context)rakudo-m -Ilib t\spec\S03-operators\set_equality.t
===SORRY!===
Cannot resolve caller MAKE_REGEX(Regex:D, Bool:D, Bool:D, Int:D, PseudoStash:D); none of these signatures matches:
(Regex \arg, $, $, int \monkey, $)
(Match::CachedCompiledRegex \arg, $, $, int \monkey, $)
(\arg, \i, \m, int \monkey, \context)
seems I can't run test in bootstrap-rakuast branch
JimmyZhuo m: sub a() {my int $a = "ss";} 11:35
camelia ( no output )
JimmyZhuo m: my int $a = "ss"; 11:36
camelia This type cannot unbox to a native integer: P6opaque, Str
in block <unit> at <tmp> line 1
JimmyZhuo m: sub a(int $a = 'ss') {}
camelia ( no output )
JimmyZhuo m: sub foo(Int $x = "omg") { } 11:37
camelia ===SORRY!=== Error while compiling <tmp>
Default value 'omg' will never bind to a parameter of type Int
at <tmp>:1
------> sub foo(Int $x = "omg"<HERE>) { }
expecting any of:
constraint
JimmyZhuo m: sub a(int $a = 'ss') {}; a();
camelia This type cannot unbox to a native integer: P6opaque, Str
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
JimmyZhuo m: sub foo(Int $x = +"omg") { } 11:39
camelia ( no output )
JimmyZhuo these are inconsistency? 11:41
nine Yes, there's not much of a visible system 11:46
[Coke] huh. logged into the azure box this morning and the blin run is done already?? 12:21
That's jdv speeds, not coke speeds.
gist.github.com/coke/9d9afd2e8eb70...11d21d67a4 - that's the full output from this run, I don't have time to make a ticket 12:23
looks like the .assuming broke some stuff 12:24
SmokeMachine: Red – AlwaysFail 12:30
It doesn't look like blin is saving output from alwaysfail, only the ones that switch 12:32
added "overview" output to that gist which has the status of each individual module.
SmokeMachine That’s odd, the tests pass, at least locally… 12:33
And it seem that pass on GH too: github.com/FCO/Red/actions 12:34
[Coke] Yah, I thought I'd get lucky with the full run, but guess I have to run it by hand again - give me a day or two to get that sorted.
SmokeMachine: I've only been doing the blin runs for a few months, and it took some effort to get it running, I've probably missed something in the setup on this azure box. 12:35
SmokeMachine It seems the modules depending on Red are also working: github.com/FCO/Red/actions/runs/13...2#step:6:1 12:39
[Coke]: sure, I don’t mean to say that’s your fault nor something like that. I’m sorry if I passed that impression. 12:40
JimmyZhuo nine: just make spectest, my pr has no regressions, I think it's safe to merge 12:41
nine JimmyZhuo: with or without RAKUDO_RAKUAST=1? 12:42
tellable6 nine, I'll pass your message to JimmyZhuo
[Coke] SmokeMachine: no worries. *I* was the one who was suggesting it. :) 12:43
Definitely want the blin runs to be reliable.
SmokeMachine I don’t know if that helps, but I’m sure blin have already run Red… it has even found releases problems while running it more than once… 12:45
[Coke] Yes, that was with jdv running it on his box.
afk - will try to get the red failure tracked in the next few days. 12:47
I'm sure it's a setup issue on this box.
cheers.
SmokeMachine Thanks! And I’ll add the missing dependencies on my META6.json as soon as possible 12:48
JimmyZhuo nine: main branch with RAKUDO_RAKUAST=1 12:55
tellable6 2025-03-13T12:42:32Z #raku-dev <nine> JimmyZhuo: with or without RAKUDO_RAKUAST=1?
nine JimmyZhuo: how did you check? I'm surprised because I'm pretty sure that when I tested it did regress 12:56
JimmyZhuo nine: these colabti.org/ircloggy/raku-dev/2025-03-12#l92? 12:58
nine probably, yes 13:00
My usual testing procedure is: make && TEST_JOBS=32 RAKUDO_RAKUAST=1 nice make spectest | grep '\. ok' | sort | tee $(git describe).pure.tests | wc -l 13:01
I do that before my change. Then commit my change. Then run again and vimdiff the two resulting .pure.tests files
I hear that you're running tests :D 13:04
JimmyZhuo haha 13:05
nine: I tried again, it's same 1274 13:07
nine Ok, then everything is indeed fine :) 13:08
Geth rakudo/main: 1d0829631e | (Jimmy Zhuo)++ | src/Raku/ast/scoping.rakumod
add redeclaration exception of placeholder parameter
 13:09
rakudo/main: 0ab88eec76 | niner++ (committed using GitHub Web editor) | src/Raku/ast/scoping.rakumod
Merge pull request #5812 from zhuomingliang/placeholder

add redeclaration exception of placeholder parameter
jdv i run blin in the container so if there's an issue its likely in the image, not a local box 13:18
but iirc Red was never a real issue
JimmyZhuo RAKUDO_RAKUAST=1 ./rakudo-m -e 'sub foo(int $x = "omg") { }' 13:40
===SORRY!=== Error while compiling
Default value 'omg' will never bind to a parameter of type int
at line
it's better with rakuast
nine I hope that there's no spectest requiring us to be worse :) 13:59
JimmyZhuo just passed t/spec/S06-signature/optional.t 14:00
JimmyZhuo can't open github again because of GFW 14:03
now it's 1275 14:04
nine JimmyZhuo++ # yeah!
JimmyZhuo nine: it is github.com/zhuomingliang/rakudo TypeCheck branch, I can't create the pr, the GFW always blocks github web, which always ERR_CONNECTION_TIMED_OUT 14:11
Geth rakudo: zhuomingliang++ created pull request #5814:
add X::Parameter::Default::TypeCheck exception to parameters		 14:12
JimmyZhuo ok now, just open the web
It's hard :)
nine my $type := $!type.PRODUCE-META-OBJECT; # That's wrong. Should be $!type.meta-object
We really only want to produce that meta-object once. It's then cached. 14:13
JimmyZhuo nine: thanks , force pushed 14:17
and it's 1276?
Geth rakudo/main: 9713c41f85 | (Jimmy Zhuo)++ | src/Raku/ast/signature.rakumod
add X::Parameter::Default::TypeCheck exception to parameters
 14:18
rakudo/main: 2a6f1822e4 | niner++ (committed using GitHub Web editor) | src/Raku/ast/signature.rakumod
Merge pull request #5814 from zhuomingliang/TypeCheck

add X::Parameter::Default::TypeCheck exception to parameters
nine That was a quick one :)
Geth rakudo/main: 9bb1fc7d4e | (Elizabeth Mattijsen)++ | 4 files
RakuAST: allow literal expression such as 2³⁺²ⁱ

In response to #4465. Felt that the most sense it would make to allow val() based expression in so far the superscript characters allow that (since there is no superscript period or e, this disallows Rats and Nums).
... (7 more lines)		 16:30
nine Does this ^^^ work in a bootstrapped RakuAST compiler? 16:34
lizmat is that merged ? 16:41
or do I just do: RAKUDO_RAKUAST=1 make install ? 16:42
[Coke] red: gist.githubusercontent.com/coke/9d.../data.json 16:43
Could not find JSON::Class:ver<0.0.20+> in:\n[Red] 16:44
if I do a zef look on Red, I don't see JSON::Class anywhere in that distro. wtf. 16:46
nine Not merged yet. Just run RAKUDO_RAKUAST=1 make in the branch 16:47
[Coke] guessing one of the deps uses it but doesn't declare? 16:50
lizmat nine: that dies with:
===SORRY!=== Error while compiling /Users/liz/Github/rakudo/tools/build/clean-target-files.raku
A unit-scoped sub definition is not allowed in a subscope;
Please use the block form.
at /Users/liz/Github/rakudo/tools/build/clean-target-files.raku:3
ah, with make install 16:51
didn't try with just "make" just yet
[Coke] hurm. I see in the dep chain JSON::Class:ver<0.0.20+> - so Red should be able to compile... 16:52
nine I have never tried make install with RakuAST 16:53
[Coke] JSON::Class – AlwaysFail 16:55
So not Red's fault, SmokeMachine. :) 16:56
SmokeMachine Oh! Thanks! That’s good to know! Can it be related to existing 2 different JSON::Class modules? 16:57
[Coke] Might be nice to do dep analysis on all the AlwaysFails to see which ones are the most productive to fix.
we're going to get whichever one 'zef info' on the dep reports. 16:58
Geth rakudo/main: cbc29eee7d | (Elizabeth Mattijsen)++ | src/core.c/Exception.rakumod
Add a tip to MethodNotFound logic for !cursor_start

In response to #3025.
   $ raku -e 'my regex foo {.}; foo "a"'
   No such method '!cursor_start' for string 'a'. Did you try to call a
   token / rule / regex directly?
   in regex foo at -e line 1
I think this case of basically DIHWIDT is covered sufficiently with this.		 16:59
[Coke] ah. JSON::Class deps on Test::Async which is a hard skip in blin. 17:00
afk
ugexe go.dev/blog/osroot would be nice to have 17:08
"The new os.Root type represents a directory somewhere in the local filesystem ... Root provides methods to operate on files within the root. These methods all accept filenames relative to the root, and disallow any operations that would escape from the root either using relative path components ("..") or symlinks." 17:10
lizmat IO::Root ? 17:11
and force all abspaths to be starting with the abspath of IO::Root ?
resolved abspaths I mean? 17:12
ugexe not sure, cause it does seem specific to directory but we don't have IO::Dir for instance. really it seems like os.OpenRoot opens a handle to a folder, but that handle has methods for doing things that ensure they do not escape the root 17:14
lizmat doesn't look like "openat" is used by libuv 17:16
linux.die.net/man/2/openat 17:18
ugexe not yet at least github.com/libuv/libuv/pull/4434 17:26
lizmat so looks like we would need to look at using that once that'e merged > 17:29
?
nine: branch builds with "make" for me
[Coke] Might need a new blin status for skipped-due-to-dependencies 17:31
nine lizmat: does the thing you implemented also work? 17:33
[Coke] (because I won't remember this in six months when it comes up again) also, removing the hard skip and trying a run for JSON::Class again.
lizmat doublechecks
nine: meanwhile, looks like the unit sub MAIN form is NYI 17:37
m: say Q|unit sub MAIN(|);|.AST
camelia ===SORRY!=== Error while compiling <tmp>
Unexpected closing bracket
at <tmp>:1
------> say Q|unit sub MAIN(|<HERE>);|.AST
lizmat m: say Q/unit sub MAIN(|);/.AST
camelia ===SORRY!=== Error while compiling /home/camelia/EVAL_0
A unit-scoped sub definition is not allowed in a subscope;
Please use the block form.
at /home/camelia/EVAL_0:1
------> unit sub MAIN(|);<HERE><EOL>
nine It is. Skipped that spectest because I was sure this wouldn't get me closer to compiling the setting 17:37
Also that's probably easy for someone else to implement 17:38
lizmat ok, so I'll work around it for now in that script that "make install" uses ?
nine Why not just implement that support? 17:39
lizmat fair enough :-)
I'll give it a stab, even though RakuAST is not in my current mindset :-)
lizmat nine: so I got a StatementList for the unit sub MAIN case, but that somehow needs to be turned into a Block to get it to work 19:09
do we have an official way to do that? I guess we could thunk the StatementLIst ? 19:10
ok. just wrap it in a RakuAST::Blockoid :-) 19:15
nine Probably just the same as with unit scoped packages? 19:17
lizmat I think I only need to find out why the unless $*R.outer-scope =:= $*UNIT condition fires 19:18
I just commented out that bit while getting the rest to work 19:19
looks like $*UNIT isn't set ? 19:23
which isn't strange, as that doesn't appear to get set anywhere ? 19:25
$*OUTER-RESOLVER =:= $*R doesn't cut it 19:31
nine That's a totally different thing 19:33
lizmat so what is the RakuAST equivalent of 19:34
nine Why don't you check whether outer-scope is a CompUnit?
lizmat unless $*R.outer-scope =:= $*UNIT { ?
ok, will try that
nine: like this? 19:38
unless $*R.outer-scope.HOW.name($*R.outer-scope) eq 'RakuAST::C
ompUnit' {
nine Didn't we agree that class names never have a use besides printing? 19:39
lizmat well, yeah, but how can I get at the RakuAST::CompUnit class in the Grammar ?
nine self.actions.r('CompUnit') 19:40
lizmat aaah... yes, ok, it's coming back to me now :-)
that's what I meant it's not in my current mindset :-) 19:41
running spectest now 19:45
Geth rakudo/main: 490a23b0cd | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add support for "unit sub MAIN"
 19:51
lizmat that appears to give us t/spec/S06-other/main-semicolon.t
but indeed, S32num/power.t is failing now, fixing that now 19:52
m: dd ⁰⁺¹² # huh? 19:56
camelia 0
lizmat what crazy value is that ?
why do we even allow that ? 19:57
Geth roast: 12b4bb8fa3 | (Elizabeth Mattijsen)++ | S32-num/power.t
Skip failing test on RakuAST

I believe this whole set of tests is bogus, and *all* of the tested sequences should be compilation errors		 20:26
lizmat 1276 for me, which should mean 1278 for nine 20:35
afk&
[Coke] so removing "Test::Async" from the havok set of modules didn't work, presumably because we're missing test-depends when doing the tests. 20:55
SmokeMachine: I wonder if red used to get tested because JSON::Class didn't always depend on Test::Async 20:57
(nope that doesn't seem to be it) 21:00
jdv does red work outside of blin?
[Coke] yup 21:02
in my blin, it can't find JSON::Class, which in turn can't find Test::Async 21:03
I'm trying to at least get JSON::Class working. (and found bin/blin's code that is pulling in test-depends)
ugexe: use Zef::Distribution; my $a = Zef::Distribution.new(name => "JSON::Class"); seems to have an empty test-depends-spec. 21:08
ugexe sure, it doesnt contain any data 21:11
Zef::Dsitribution.new(name => "JSON::Class") doesnt do anything like query for the module and fill out the meta data
[Coke] ah
missed a step in bin/blin then, checking... 21:12
... weird. on this azure box, I vi output/data.json (blin output), type /JSON::Class and at the C... it hangs. I connected again, it hung in the same place. 21:35
SmokeMachine Red does not directly depends on JSON::Class… 22:33
Red test-depends on Test::META and Test::META depends on META6 that depends on JSON::Class… I would expect more modules to depend on that… 22:42
[Coke]: ^^ 22:44

Powered by Cro and the Raku® Programming Language.

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

Thank you!