🦋 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.
ab5tract patrickb: have you seen microsoft.github.io/debug-adapter-protocol/? 00:08
Saw this because zed editor just added a debugger that supports that 00:09
nine: unfortunately it has been a time issue for me, otherwise I would have poked at those other two tickets 00:10
01:29 nine left 01:30 nine joined
patrickb ab5tract: IIRC that's closely related to the language server protocol. 04:21
nine: We'll get there eventually. It just needs to move to the top of a few people's to-do lists. 08:06
08:51 nine left, nine joined
lizmat just spotted on Mastodon: 09:02
m: class A { has $.b = 42; method bb() { $.b++; } }; my $A = A.new; $A.bb; dd $A.b
camelia 42
lizmat feels that should fail, just like:
m: class A { has $.b = 42; method bb() { self.b++; } }; my $A = A.new; $A.bb; dd $A.b 09:03
camelia Cannot resolve caller postfix:<++>(Int:D); the following candidates
match the type but require mutable arguments:
(Mu:D $a is rw)
(Int:D $a is rw --> Int:D)
(int $a is rw --> int)
(uint $a is rw --> uint)
(num $a is rw …
lizmat fwiw, same issue exists with = 42, and += 42
bisectable6: class A { has $.b = 42; method bb() { $.b++; } }; my $A = A.new; $A.bb; dd $A.b 09:06
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, More than 3 changes to bisect, please try a narrower range like old=2025.01 new=HEAD 09:07
lizmat, Output on all releases: gist.github.com/50206818ba8c11170b...3c0280cb84
lizmat bisectable6: old=2023.02 class A { has $.b = 42; method bb() { $.b++; } }; my $A = A.new; $A.bb; dd $A.b
bisectable6 lizmat, Bisecting by exit code (old=2023.02 new=92068d9). Old exit code: 1
lizmat, bisect log: gist.github.com/d4e1990a77de9b2548...2f36d90e2d 09:08
lizmat, (2025-02-15) github.com/rakudo/rakudo/commit/a6...c5ffe83e68
lizmat aahhh.. the $.foo is self.foo.item case :-( 09:09
09:25 [Tux] left
lizmat m: sub a($a) { use nqp; say nqp::iscont($a) }; a 666 # untyped, $a is a container 09:26
camelia 1
lizmat m: sub a($a) { use nqp; say nqp::iscont($a); $a = 1 }; a 666 # but not one can assign to
camelia 1
Cannot assign to a readonly variable or a value
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: sub a(Int $a) { use nqp; say nqp::iscont($a) }; a 666 # typed, $a is NOT a container 09:27
camelia 0
09:29 [Tux] joined
lizmat nine: looking in the binder to find where (and how) read-only containers are created 09:38
but so far, appear to be glancing over it :-(
ab5tract: maybe I'm looking at the wrong place?
Geth rakudo/main: f95f85ac3e | (Elizabeth Mattijsen)++ | src/core.c/Mu.rakumod
Make sure .item returns a read-only container

Issue #5908 showed that the container that .item should return, should either be the invocant (if it is a container already), or a read-only container if it is not.
This commit achieves that by introducing a helper sub called ... (7 more lines)		 10:32
roast: 5dc49a8fe5 | (Elizabeth Mattijsen)++ | S12-methods/accessors.t
Add test for #5908
 10:38
[Tux] Rakudo v2025.05-87-gf95f85ac3 (v6.d) on MoarVM 2025.05-70-g66f31681f
csv-ip5xs0.262 - 0.263
csv-ip5xs-201.050 - 1.398
csv-parser1.120 - 1.124
csv-test-xs-200.114 - 0.115
test1.772 - 1.779
test-t0.409 - 0.427
test-t --race0.273 - 0.279
test-t-204.993 - 5.042
test-t-20 --race1.248 - 1.260
 12:05
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
Geth rakudo/main: 67c1b5182d | (Timo Paulssen)++ | src/vm/moar/ops/perl6_ops.c
Better error when p6invokeunder gets passed wrong arg types

instead of segfaulting.		 12:09
timo someone can take over from this; this addresses the `use nqp; nqp::p6isbindable(Signature.new,Capture.new)` segfault 12:10
lizmat timo++
[Coke] getting tux to be able to run rakuast would also be nice. 12:19
tux++ 12:20
[Tux] [Coke] : tux.nl/Files/rebuild is the script to build/install raku. What should be changed? 12:22
lizmat raku.land/zef:slavenskoj/Inline::Python3 I wonder how much of this is AI hallucinated
lizmat hopes none of it is
timo turning off GC to optimize GC performance is certainly A Choice 12:39
Geth rakudo/main: 8263885caf | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp
RakuAST: don't allow upping language versions in EVAL

This code silently does the wrong thing.
   use v6.c;
   "use v6.*; say nano".EVAL; # expect "nano" to work
   ===SORRY!=== Error while compiling EVAL_0
... (13 more lines)		 12:52
lizmat m: use v6.*; "use v6.d; say nano".EVAL # still needs work :-( 12:56
camelia 1750337785053634567
lizmat afk for a bit& 12:59
timo do we already know how it's supposed to work? 13:42
do we just put the 6.whichever setting in between the eval's scope and the scope of the thing that calls eval?
[Coke] tux - While we might be able to fake it, ideally you'd want one raku installed defaulting to RAKUAST and one with it off (the current default). We have a blocker on make install with the AST version just now, We'll ping you when we can do it both ways. 13:50
You could probably do a run right now with `RAKUDO_RAKUAST=1 (your script)`
be curious to see the results of that, I guess. 13:51
[Tux] +++ Compiling blib/CORE.c.setting.moarvm 14:05
The following step can take a long time, please be patient.
Stage start : 0.000
Class X::Redeclaration+{X::Comp} cannot inherit from X::Redeclaration because the parent is not composed yet
at src/Perl6/Metamodel/Configuration.nqp:53 (/pro/3gl/CPAN/rakudo/blib/Perl6/Metamodel.moarvm:throw_or_die)
from src/Perl6/Metamodel/MultipleInheritance.nqp:60 (/pro/3gl/CPAN/rakudo/blib/Perl6/Metamodel.moarvm:add_parent) 14:06
(fail on `🐧 env RAKUDO_RAKUAST=1 rebuild`
ugexe "We have a blocker on make install with the AST version just now, We'll ping you when we can do it both ways." 14:07
[Tux] I saw that, but it does not even build like that. I'll awit instructions :}
ab5tract lizmat: I don’t know if $.a++ should fail. We have allowed people to use the accessor form as an equivalent to $!a for so long that it feels off to diverge the behavior. Though I never use the accessor form so maybe I don’t know the expectations of those who do 14:36
The commit says prevent upping the version in an eval. But going from more less specific does make some sense, doesn’t it? 14:38
[Tux] you don’t really need to be able to compile with RakuAST to get the csv timings tho, right? 14:39
ugexe lizmat: i would be surprised if that Python3 library works. at a minimum github.com/slavenskoj/raku-inline-...on#L25-L27 isn't right
ab5tract But the broken zef situation may still be a major blocker
As [Coke]++ pointed out 14:40
ugexe yeah it definitely is not at a point it should be in the ecosystem 14:41
github.com/slavenskoj/raku-inline-...akumod#L15
16:53 nine left, nine joined
ab5tract *going from less specific to more specific 16:59
El_Che [Coke]: is there a chance the back-out will be backed out? 18:05
18:40 coleman left 18:41 coleman joined
patrickb re Inline python3, the readme states: 18:49
"This is an initial implementation focusing on core functionality and is in development and testing."
So seems some stuff works already. 18:50
I think this is pretty cool.
ab5tract yeah definitely. I don't think we have ever set up a minimum criteria for publishing something to the ecosystem, have we? 18:56
I could see some simple filters in fez that check whether the resource handling is sane or not, amongst other details 18:57
but I don't think it would be fair to single this module out in particular as "ecosystem unworthy"
[Coke] El_Che: it should be, yes. Would love it if you could submit a PR. 19:12
Issue is github.com/rakudo/rakudo/issues/5864 19:13
lizmat ab5tract: $.a++ *should* fail, if $.a does not have "is rw", for the same reason that 42++ fails 19:21
m: 42++
camelia Cannot resolve caller postfix:<++>(Int:D); the following candidates
match the type but require mutable arguments:
(Mu:D $a is rw)
(Int:D $a is rw --> Int:D)
(int $a is rw --> int)
(uint $a is rw --> uint)
(num $a is rw …
lizmat m: use v6.*; sub a() { say $CALLER::a }; my $a = 42; a 20:03
camelia 42
lizmat m: use v6.d; sub a() { say $CALLER::a }; my $a = 42; a
camelia Cannot access '$a' through CALLER, because it is not declared as dynamic
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat So I wonder: is that change in 6.e made consciously, or is it a NYI in the new PseudoStash handling ? vrurg ?
20:04 guifa_ left
lizmat m: say ::("Exception").gist 20:06
camelia (Exception)
lizmat m: use v6.*; say ::("Exception").gist 20:07
camelia Died with Exception
in block <unit> at <tmp> line 1
ab5tract I don’t follow how a clearly containerized value can’t handle ++ versus a non containerized value 20:14
My point is more about the cultural usage pf $.foo than the technical correctness of it 20:15
Ah, never mind, forgot about .item
lizmat m: sub a($a) { use nqp; say nqp::iscont($a) }; a 42
camelia 1
lizmat so $a is a container here
yet:
ab5tract But hen how is it working now? 🙃
lizmat m: sub a($a) { $a = 666 }; a 42 20:16
camelia Cannot assign to a readonly variable or a value
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
ab5tract Yes that part I grok and accept
lizmat it's a special sort of container that is read-only
so what's the issue with $.foo++ not working ?
ab5tract I have never used $.foo outside of a gas declaration
lizmat well, you can't
ab5tract ?
lizmat I read "gas" as "class" ? 20:17
ab5tract I meant has
(Switching to a real keyboard now :))
lizmat aah... ok 20:18
ab5tract IMO it was a mistake to have $.whatever outside of a has. I find it unreadable, but more than that, I don't think the people using it understand the distinction
lizmat well, the nice thing about $.foo is that you can interpolate it in a string, and self.foo you can't 20:19
also, it is subclass proof
vs $!foo not being subclass proof
ab5tract hmm, I hadn't considered that... why isn't $!foo sub-class proof? 20:20
because someone might have declared custom methods for handling the value?
lizmat because it directly accesses the attribute, even if a subclass created their own accessor
yup
ab5tract okay, I could buy that. *iff* it wasn't tacking on a .item call 20:21
lizmat yeah, I'm still not sure why *that* was done 20:22
ab5tract but I guess I should summarize my concern as: this will almost certainly break user-space in a way that surprises people who had (reasonably or not) assumed that $!foo and $.foo were equivalent syntax 20:23
I wonder what would collapse if we un-itemized it... because then the distinction is only along a single, easy to describe axis (via accessor or not) 20:24
Anyway, despite that concern, I do support your fix for this :) 20:25
japhb The .item call is the difference between $.foo and @.foo, IIRC. 20:33
lizmat eh, I think it's the other way around?
japhb Because really they're both wrapped around self.foo()
lizmat: Possibly confusing wording. I think we agree. 20:34
lizmat $ sigilled attributes get an .item attached, @ attributes a .list, and % attributes a .hash ?
m: use v6.d; subset A of Int; my A $a = 42; $a = Nil; say $a 20:37
camelia (A)
lizmat m: use v6.*; subset A of Int; my A $a = 42; $a = Nil; say $a
camelia (Int)
lizmat actually: 20:38
m: use v6.d; subset A of Int; my A $a; say $a.VAR.default
camelia (A)
lizmat m: use v6.*; subset A of Int; my A $a; say $a.VAR.default
camelia (Int)
lizmat ok, will look at that tomorrow 20:39
&
ab5tract o/

Powered by Cro and the Raku® Programming Language.

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

Thank you!