🦋 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.
01:57 dogbert17 left, dogbert17 joined 02:42 hythm joined 04:26 hythm left 04:47 japhb left 04:51 japhb joined 06:26 dogbert11 joined 06:29 dogbert17 left 08:23 finanalyst joined
nemokosch bisectable: say(Duration(10) / 2) 08:45
bisectable6 nemokosch, Will bisect the whole range automagically because no endpoints were provided, hang tight
nemokosch, Output on all releases: gist.github.com/dca647db4a3e95b146...02fd9ca169
nemokosch, Bisecting by exit code (old=2020.11 new=2020.12). Old exit code: 1
nemokosch, bisect log: gist.github.com/d190c09d1aa1e954be...5e744cebb5 08:46
nemokosch, (2020-12-08) github.com/rakudo/rakudo/commit/79...0f7bdc46f6
nemokosch, Bisecting by output (old=2016.04 new=2016.05) because on both starting points the exit code is 1
nemokosch, bisect log: gist.github.com/2aa7821138d5861d0d...7ede01f83a
nemokosch, (2016-05-12) github.com/rakudo/rakudo/commit/33...d4efe221de
nemokosch, Output on all releases and bisected commits: gist.github.com/97f8cd7862fbbace00...f44161c154 08:47
nemokosch Okay but this was more or less sensible behavior...
bisectable: 10.Duration / 2 andthen .WHAT.say
bisectable6 nemokosch, Will bisect the whole range automagically because no endpoints were provided, hang tight
nemokosch, Output on all releases: gist.github.com/3496cd012a6bfc905a...a1089d37c1 08:48
nemokosch, Bisecting by output (old=2016.09 new=2016.10) because on both starting points the exit code is 1
nemokosch, bisect log: gist.github.com/e3661309982351737b...704ccb72f5
nemokosch, Output on all releases and bisected commits: gist.github.com/c8d089382f0958c430...076e3de5cb
Geth WebService-GitHub/main: 12ef2f2afa | (Patrick Böker)++ | dev-scripts/static/lib/WebService/GitHub/OAuth.rakumod
Fix OAuth token retrieval
 09:03
09:20 finanalyst left
Geth WebService-GitHub/main: 0b692be23b | (Patrick Böker)++ | dev-scripts/static/Changes
Add a Changes file
 09:24
WebService-GitHub/main: 223dbd9d7f | (Patrick Böker)++ | dev-scripts/generate-module
Version 1.0.0
09:56 sena_kun joined
Geth WebService-GitHub/main: bd0362f707 | (Patrick Böker)++ | 21 files
Fix up tests and move tests depending on internet access to xt/
 10:06
WebService-GitHub/main: 091b32995e | (Patrick Böker)++ | 2 files
Version 1.0.1
10:24 sena_kun left
lizmat vrurg nine is there a way to easily check in the core setting whether we're running under RAKUDO_RAKUAST=1 without needing to do a %*ENV lookup ? 11:12
Geth rakudo/main: a9da976e88 | (Elizabeth Mattijsen)++ | src/core.c/Raku.rakumod
Add Raku.legacy implementation-detail class method

To allow easy checks in the core whether it is running under the new Raku grammar or not.		 12:07
ugexe Are we confident there will never be anything close sidered “legacy” in the future? 12:33
I guess it’s an implementation detail so it doesn’t really matter 12:34
lizmat wrt to core, it can probably be removed when RakuAST is default
however, some current module developers might want to use it 12:35
to basically say: sorry, this module needs RakuAST, so it won't work
so I'm in two minds whether it should be an implementation detail or not 12:36
ugexe If module authors want to use it then it needs a new name
lizmat Raku.legacy not clear enough ? 12:37
ugexe It is general. What you are applying to is not. It’s super specific
lizmat Raku.running-with-legacy-grammar ? 12:38
ugexe It hard couples legacy to mean a specific thing that shouldn’t change
even that isn’t great
lizmat Raku.running-with-perl6-grammar ? 12:39
ugexe The method should probably reference the feature in some way 12:40
and even then it seems like what is really wanted is a thought out feature detection mechanism or api
lizmat ok, then I'll leave it as an implementation-detail method for now 12:45
Geth rakudo/lizmat-rat-raku: c7fa23409d | (Elizabeth Mattijsen)++ | src/core.c/Rat.rakumod
RakuAST: change rakufication of Rats

If the Rat cannot be displayed using a decimal notation (such as
  <22/3>), then rakufy as a vulgar: 7¹/₃ instead of <22/3> if the
RakuAST grammar is being used. The RakuAST grammar allows vulgars such as 7¹/₃ to represent <22/3>, so roundtripping is ensured.		 13:22
rakudo: lizmat++ created pull request #5466:
RakuAST: change rakufication of Rats
ugexe github.com/ugexe/zef/blob/2da47937...#L231-L253 13:28
Use of uninitialized value @short-names-to-index of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
in block at /home/patrickb/.rakubrew/versions/moar-2023.10/share/perl6/site/sources/7B8C4765AC0B50F3E076BE3378DD767C55081947 (Zef::Repository::Ecosystems) line 250
how could the code linked above generate that warning?
lizmat *.contains ?
ugexe It is in a bug report I can't reproduce, and looking at that code I'm not sure where @short-names-to-index is used in string context
append @short-names-to-index, $dist.meta<provides>.keys.first(*.contains('<')) 13:29
it isn't called on short-names-to-index
lizmat .unique is probably stringifying ?
or maybe the .WHICH on the values is stringifying ? 13:30
ugexe m: my @a; say @a.unique
camelia ()
ugexe even if that was the case, it seems fine there
lizmat %!short-name-lookup{$_} ? 13:31
I assume its not an object hash ?
ugexe no, it contains strings (and that is all I'm putting into it afaict) 13:32
i.e. %!short-name-lookup<Text::Foo>
lizmat I would double check @short-names-to-index for any Anys 13:33
ugexe well I cant reproduce it for one
lizmat m: my %h; %h{$_} = 1 for (Any,)
camelia Use of uninitialized value of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
in block at <tmp> line 1
ugexe that does seem to be the only possible way though 13:34
lizmat line 236: push @short-names-to-index, $dist.name // 'unknown'; ??
ugexe yeah ultimately i'll grep out invalid values now. still strange i cant reproduce it though... it almost suggest some module in the ecosystem temporarily had some type of invalid value 13:35
13:36 tbrowder__ left, tbrowder__ joined
lizmat push @short-names-to-index, $_ with dist.name; 13:38
I guess
ugexe m: my @a = (Any,); my %h; %h{$_} = 1 for @a
camelia Use of uninitialized value @a of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
in block at <tmp> line 1
ugexe i'm not sure if im a fan of that error message or not though 13:39
m: my @a = (Any,1); my %h; %h{$_} = 1 for @a
camelia Use of uninitialized value @a of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
in block at <tmp> line 1
lizmat well, it tells you it's a container of the @a array that has Any in it
ugexe the "Use of uninitialized value @a"
instead of like "Use of uninitialized value in @a"
lizmat s/in/from/ ?
ugexe in the second example @a contains Any and 1, so it isn't uninitialized
yeah 13:40
14:01 kjp left 14:34 AlexDaniel joined 14:35 kjp joined
codesections I'm having trouble detecting a Mu value in NQP. nqp::isnull and nqp::isnull_s both return 0, but dump throws an error saying it's a VMNull. What am I missing here? 15:11
I'm trying to fix github.com/Raku/nqp/blob/main/src/...#L603-L610 15:12
which is currently calls tryfindmethod on Mu (i.e., unset) action objects
15:43 kjp left
ugexe m: my byte $a; say $a.^name 15:45
camelia Int
ugexe Is byte an actual type we provide or is it leaking?
i guess we have bit and byte native types 15:46
ah none of the native types are shown on docs.raku.org 15:47
Geth rakudo/fix-CoC-link: 2846ea599f | (Daniel Sockwell)++ (committed using GitHub Web editor) | README.md
Replace incorrect CoC report link

This commit replaces that link with instructions to email [email@hidden.address] The README currently claims to link to a CoC "Report Guide", but we don't have a Report Guide; the link actually points to our _Response_ Guide, which isn't very relevant to someone who just wants to report.
This commit replaces that link with instructions to email CAT@raku.org
rakudo: codesections++ created pull request #5467:
Replace incorrect CoC report link
ugexe I wonder if anything actually uses the byte or bit types 15:53
like even Buf.rakumod doesn't use it 15:54
16:07 kjp joined
ab5tract_ Maybe that’s an oversight? 16:16
ugexe it seems like it has to be getting used *somewhere* 16:19
or else why would it even be added
i guess it could have just been in the design docs
i'm mostly something if its something i should be using 16:20
i'm mostly wondering^
ab5tract_ I’ve used it in NativeCall bindings before. Seems to do what it says on the tin :) 16:21
I think it’s just there as an optional alias for `uint8` that might be more evocative under certain cirumstances 16:23
(That’s for `byte`. I didn’t know we had a `bit`!) 16:26
16:37 dogbert17 joined 16:39 dogbert11 left
Geth rakudo/main: 349ee9c225 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: make handling of ⁶⁶⁷/₃ sane

In the legacy grammar, this was interpreted as 6 ** 67 / 3, which is clearly a bit of a WAT, if not outright a bug.
This is now properly treated as 667 / 3, and codegenned as a proper RatLiteral.		 17:50
nqp: codesections++ created pull request #813:
Prevent method calls on nonexistent actions object		 18:29
nemokosch could you be at least a tiny little bit receptive of problems that have factual examples of biting the user, and their controversial nature is so acknowledged at times (like with this "token names are method names" stuff) that they are identified as "traps" even in the documentation? 18:40
I know it's not convenient but at this point I feel it's actually taking a toll on my sanity, like we live in parallel worlds 18:41
why does it always have to be neglected or denied?
lizmat wonders what this is even about ? 18:42
18:43 sena_kun joined
nemokosch github.com/rakudo/rakudo/issues/5443 18:48
turned out that built-in methods not only name conflict with token/rule/regex stuff (do they have one common name?) but even the resolution order was wrong 18:49
now, the resolution order is right at least...
Geth rakudo/lizmat-rat-raku: 1720fbeb43 | (Elizabeth Mattijsen)++ | src/core.c/Rat.rakumod
RakuAST: compose vulgars that have a composed version

So produce <1/3> as ⅓ instead of as ¹/₃ . Note that many of the composed vulgars will never show as a vulgar because they can be truthfully produced as a decimal, e.g. <1/2> is produced as 0.5		 18:57
codesections the resolution order wasn't wrong. In fact, rakudo/rakudo#5443 turned out not to be exactly the same issue we were discussing with .from, etc 19:06
linkable6 RAKUDO#5443 [open]: github.com/rakudo/rakudo/issues/5443 Rakudo incorrectly calls methods on Match subclasses (eg Grammars) instead of on Match itself
codesections instead, it was caused by Grammar not correctly checking to see if it had an action object before trying to call the corresponding action method 19:07
lizmat I have a better fix 19:08
codesections spectesting now
nemokosch then I don't get the whole thing about how it is solved now 19:13
how will methods of the same name not name conflict all of a sudden? 19:14
Geth rakudo/main: bd2c719ed4 | (Elizabeth Mattijsen)++ | src/core.c/Grammar.rakumod
Make sure that "no actions" really means it

Putting a Raku Mu object in the actions of a grammar by default, is telling NQP that it should look in the Raku Mu class, of which we have many, and one of them is called "print". Which causes issue #5443.
... (6 more lines)		 19:16
lizmat I think docs.raku.org/language/traps#Using...en/regexes can now have a mention that it is fixed in 2023.11 19:17
nemokosch well, I still don't get how the name conflicts are avoided now, if it's apparently not the resolution order that changed, and they still share the same name 19:19
lizmat the problem was that users thought they indicated not to call any action methods, while in fact they indicated to use action methods of the Mu classs 19:20
now, if you indicate you don't want any action methods, they will not even try to execute action methods
nemokosch I don't know how this relates. 19:21
lizmat you can parse a grammar either *with* an action method class, or without 19:22
m: say grammar { token TOP { <print>+ } }.parse: "foo"
camelia Cannot resolve caller print(Mu:U: <anon|1>:D); none of these signatures matches:
(Mu: *%_)
in regex TOP at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat what happens here, is that you *think* you've indicated you don't want any action methods executed 19:23
but in fact, you indicated that you want it to search for methods in the Mu class when a token matches
nemokosch okay okay, hold on 19:24
lizmat and since the signature doesn't match, you get an error
nemokosch so the grammar itself doesn't inherit any methods?
lizmat it actually does, that's why the <print> matched
nemokosch okay... does it inherit methods that have nothing to do with grammar-ish stuff? 19:25
lizmat it does NQP's NQPMatchRole 19:27
actually, Match does: my class Match is Capture is Cool does NQPMatchRole 19:28
and Grammar isa Match
nemokosch well that's what I'm asking, pretty much
lizmat yeah, so inheriting tokens is fine, and what you want 19:29
nemokosch why is it okay that even though Match is a bloated class with loads of inherited methods for traditional method purposes, they all just flow through implicitly to the grammar
lizmat when the <print> token matched, it tried to execute: 19:30
m: Mu.print("foo")
camelia Cannot resolve caller print(Mu:U: Str:D); none of these signatures matches:
(Mu: *%_)
in block <unit> at <tmp> line 1
nemokosch that's okay, I'm asking about the principle
why is it okay that <raku> for the .raku method and <print> for something that is supposedly really a token, look the same and are available under the very same terms? 19:31
why are these two unrelated things implicitly intermixed?
lizmat the grammar machinery is really oblivious to the meaning of the tokens / methods 19:32
nemokosch what justifies that?
lizmat it sees that a token named "foo" matched, checks if there is an actions class, if there is, then checks if there is a method "foo" on it, if there is, tries to execute it
19:34 MasterDuke joined
Geth roast: 20b07d6704 | (Elizabeth Mattijsen)++ | S05-grammar/inheritance.t
Untodo a now passing test
 19:34
nemokosch really, this is what I don't get about the whole thing. In reality, to the user, tokens and methods are not the same thing. They don't have the same purpose to begin with. The raku, elems, rotor, Int, etc. methods have nothing to do with tokens like ws or print or alpha, regardless of the implementation 19:36
lizmat agree.. and they shall not intefere with each other from now on
nemokosch then I probably still don't understand how it all works 19:37
lizmat had I known what I know now about how grammars work in NQP, I would have been able to fix this a long time ago :-(
nemokosch because in my mind, if you have <raku> or <hash> in your grammar, it can still fall back to these methods
which may not be a prevalent issue than outright shadowing your own tokens named "raku" or "hash" but it still seems completely unjustified 19:38
lizmat well, you can create a method in a grammar, as long as you abide by the interface for tokens
MasterDuke m: grammar A { token froom { "froom" }; token TOP { <froom>+ }; }; dd A.parse("froom")
camelia Match.new(:orig("froom"), :from(0), :pos(5), :hash(Map.new((:froom([Match.new(:orig("froom"), :from(0), :pos(5))])))))
MasterDuke m: grammar A { token from { "froom" }; token TOP { <from>+ }; }; dd A.parse("froom")
camelia (timeout) 19:39
nemokosch my point is that this shouldn't be a big deal from the technical side of things
the intermixing could be stopped by appending a prefix to the grammar stuff
much like how trait_mod or sym or infix exists
if somebody wanted to write a regexish thing as a method, they could still do just that 19:40
but without the confusing part
and the resolution wouldn't fall back to something that has no business with grammars at all
MasterDuke yeah, a prefix has been suggested as a possible solution before. it's one of the things i was going to experiment with a while ago, but never got around to
lizmat ok, this is a different issue 19:41
codesections Yeah, I think I'm responsible for the confusion between the two issues – I got confused and thought that #5443 was caused by the regex-vs-method name issue -- but it's not; it's the action bug (now fixed, lizmat++) 19:44
I've now opened rakudo/rakudo#5468 to track the regex-vs-method name issue 19:45
linkable6 RAKUDO#5468 [open]: github.com/rakudo/rakudo/issues/5468 Rakudo incorrectly calls methods on Match subclasses (eg Grammars) instead of on Match itself
nemokosch well that might have been my fault to begin with, to be fair
after all, I implied that it was probably a related thing
codesections Yeah, we were all on the wrong track together for a bit :D
Yeah, we were all on the wrong track together for a bit :D 19:46
Geth rakudo/main: 2846ea599f | (Daniel Sockwell)++ (committed using GitHub Web editor) | README.md
Replace incorrect CoC report link

This commit replaces that link with instructions to email [email@hidden.address] The README currently claims to link to a CoC "Report Guide", but we don't have a Report Guide; the link actually points to our _Response_ Guide, which isn't very relevant to someone who just wants to report.
This commit replaces that link with instructions to email CAT@raku.org		 19:49
rakudo/main: 6d90c9230a | (Daniel Sockwell)++ (committed using GitHub Web editor) | README.md
Merge pull request #5467 from rakudo/fix-CoC-link

Replace incorrect CoC report link
nqp/main: 548b0263bb | (Daniel Green)++ | tools/templates/MOAR_REVISION
Bump MoarVM for libuv update
 20:08
rakudo/main: c5622ff927 | (Daniel Green)++ | tools/templates/NQP_REVISION
Bump NQP for libuv update
 20:10
lizmat I wonder how much would break if we would let Grammar just inherit from NQPMatchRole
fwiw, libuv bump is ok on MacOS 20:38
afk&
23:39 sena_kun 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!