🦋 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.
Geth JSON-Unmarshal/main: e3bcdb6e39 | (Vadim Belman)++ | lib/JSON/Unmarshal.rakumod
Remove extra 'l' from $*JSON-UNMARSHALL-PARAMS and UnmarshallParams

It was there by mistake.		 01:50
Geth rakudo/main: 5fe1bd8266 | ab5tract++ (committed using GitHub Web editor) | 3 files
RakuAST: Add currently supported feed operators (#5374)
 09:08
lizmat 951! +3 ab5tract++ 09:18
ab5tract lizmat: so, what's next? ;) 09:35
lizmat my proto token foo {*} 09:36
that doesn't parse atm, it loses the name
ab5tract oh, weird
I'll take a look 09:37
lizmat also: @5341 #5342 #5343
#5341 rather :-)
ab5tract duh, I forgot about the issues.. thanks! 09:47
hmm, for the issue on once blocks, I see different behavior. the first time through it does give 42. 09:55
m: my $content = 'sub a() { once my $i = 42; ++$i }; dd a() xx 5'; shell Q:scalar<RAKUDO_RAKUAST=1 $*EXECUTABLE -e '$content'> 09:56
camelia (1, 1, 1, 1, 1).Seq
ab5tract m: my $content = 'sub a() { once my $i = 42; dd $i++ }; a() xx 5'; shell Q:scalar<RAKUDO_RAKUAST=1 $*EXECUTABLE -e '$content'>
camelia 0
0
0
0
0
lizmat fwiw: Q|foo|.AST.EVAL does the same 09:57
m: Q|sub a() { once my $i = 42; dd $i++ }; a() xx 5|.AST.EVAL 09:58
camelia 0
0
0
0
0
ab5tract I thought there was an easier way!
m: sub a() { once my $i = 42; dd $i++ }; a() xx 5 09:59
camelia 42
0
0
0
0
ab5tract so that's different from what the ticket says we should expect
lizmat m: sub a() { once my $i = 42; dd $i++ }; a() for ^5 10:02
camelia 42
0
0
0
0
lizmat hmmm
ab5tract your point still holds
m: my $i = 0; sub a() { once $i = 42; dd $i++ }; a() xx 2
camelia 42
43
ab5tract m: Q| my $i = 0; sub a() { once $i = 42; dd $i++ }; a() xx 2 |.AST.EVAL 10:03
camelia 0
1
lizmat right
ab5tract now this is a real mystery.. all the QAST seems to be in place :) 10:07
how important is the :cuid flag ? 10:08
lizmat I haz no idea 10:11
ab5tract well, the QAST does differentiate in that the old frontend produces a call to p6assign, whereas RakuAST refers to calling infix:<=> 10:20
lizmat well, that's probably the case for any assignment atm ? 10:21
ab5tract yeah, it shouldn't be an issue
seems to be working well 10:22
hmmm.... could it be that 'p6stateinit' is never true in RakuAST? naively removing the QAST if check for 'p6stateinit' at leasts runs the once block (even if it fails spectacularly immediately thereafter 10:45
lizmat could be, but that should also affect state variables
I mean, a once block is basically a block that gets called when a hidden state variable isn't set yet 10:46
right?
ab5tract yeah, that seems to be the case 10:49
lizmat at least, that's what I remembered from implementing "once" about 10 years ago 10:50
ab5tract m: Q| sub a() { state $a = 42; $a++ }; dd a() xx 3 | . AST.EVAL
camelia (42, 43, 44).Seq
ab5tract it calls the block at state init and then stores that in a lowered param (your hidden state var) 10:51
Geth rakudo/main: 70944f73ca | (Elizabeth Mattijsen)++ | 2 files
Fix setting properties of operators with ":" in their name

E.g. =:=		 11:20
ab5tract ah, it seems that there should be a container for the state var declared .. 11:25
lizmat ++ab5tract
ab5tract if I'm a subclass of Foo, do I need to include children of Foo in a visit-children method? 11:32
seems likely 11:33
lizmat yeah, that's why almost each class has a visit-children metho 11:34
d
Geth rakudo/main: ee170b9f4a | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod
RakuAST: add "not-reducable" convenience method

Returns whether these properties indicate that the associated operator is *not* reducable.
rakudo/main: 5841afb2a3 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add operator applicability tests to classes

Whether an operator can be reduced, or used in a specific meta operator, is logic that needs to live in the RakuAST classes, since we want the same checks there that the Raku grammar is currently doing.
rakudo/main: 1626cbfb59 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove grammar tests for reducability / meta

These tests are now handled in the RakuAST:: classes. Also remove now no longer needed helper methods.
ab5tract ++++ 11:48
Geth rakudo/main: 76ad99d45c | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %additive hash
 11:49
rakudo/main: 6da14defad | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %additive_iffy hash
 11:55
Geth rakudo/main: e337c82350 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %exponentiation hash
 12:00
Geth rakudo/main: e026c1b05e | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %symbolic_unary hash
 12:05
rakudo/main: 65789659d1 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %dotty_infix hash
 12:10
rakudo/main: 6fa642c676 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %multiplicative hash
 12:17
rakudo/main: c19e7a1c9a | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %multiplicative_iffy hash
 12:22
rakudo/main: 4b09c649e2 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %replication(_xx) hashes
 12:28
ab5tract so it seemed to me like the reasonable approach to getting that state container declared was to do a PERFORM-BEGIN that adds a VarDeclaration::Simple via $resolver.current-scope.add-generated-lexical-declaration 12:32
but it barfs unintelligibly (to me)
Geth rakudo/main: c821ffebdc | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %concatenation hash
 12:33
rakudo/main: 5e10f29564 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %junctive_and(_iffy) hashes
 12:39
rakudo/main: b60812ea0f | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %junctive_or(_iffy) hashes
 12:44
rakudo/main: 6807083550 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %named_unary hash
rakudo/main: 84419efb92 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %structural hash
 12:49
rakudo/main: c978bf2130 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove %chaining hash
 12:54
ab5tract "bindpos_o requires a concrete object (got a VMNull type object instead)" <-- this implies that an argument to a subroutine is undefined, right? 12:58
lizmat it implies the bindpos_o was tried on a VMNull object 12:59
which could be a class not resolved 13:00
generally, but probably not in this case
Geth rakudo/main: 8ec9ae8bfb | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %tight_xxx hash family
 13:03
rakudo/main: e0864b19bb | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %ternary hash
 13:06
lizmat afk for a few hours&
ab5tract lizmat: enjoy your afternoon! 13:11
I'm about to step into the sunshine myself
Just cracked the once issue :D
jdv [Coke]: do you believe the jvm build will work before 9/21? 13:37
ab5tract: wut tz r u? 13:38
ab5tract I'm still in Amsterdam 13:49
Geth rakudo: ab5tract++ created pull request #5375:
RakuAST: Get 'once' statement prefix fully working		 13:57
ab5tract jdv: what about you? 14:00
jdv et 14:17
Geth roast: usev6++ created pull request #838:
Teach test_summary about #rakuast fudging		 15:08
Geth roast: c17f954da4 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | test_summary
Teach test_summary about #rakuast fudging (#838)

This is similar to what was done in
  github.com/rakudo/rakudo/commit/fa9cd8ef55.		 16:36
Geth rakudo/main: 5667eaa784 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove %conditional_ff hash
 16:38
Geth rakudo/main: 700e52485e | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove %item_assignment hash
 16:45
rakudo/main: 8ed9f68110 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove %adverb hash
 16:51
rakudo/main: ec4d75ca6d | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove %list_assignmenrt hash
 16:56
rakudo/main: 628c71bdac | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %loose_xxx hashes
 17:01
rakudo/main: 44ba063696 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove %comma hash
 17:09
rakudo/main: 5881f0b960 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove %list_infix hash
 17:15
rakudo/main: 577498bcb5 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove %sequencer hash

and the %list_assignment hash which apparently wasn't being used anymore. This was the final %prec hash! Whee!		 17:27
rakudo/main: 8631e3ab0b | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: don't use hashes in prefix/postfix checking

Another step towards not using hashes for EXPR parsing		 17:52
Geth rakudo/main: 3a70184aa1 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: conform to the use of "chain"

Instead of "chaining". Originally I thought to de-huffmanize
  "chain", but then I realized it was not being used as a verb,
but more as an adjective. Anyways, this is closer to the legacy wording, so less chance of weird problems occurring in the future.		 18:33
ab5tract lizmat: should I re-work the PR to fix @compstuff bindpos_o failure to ensure that the local @compstuff gets saved back into the Code object? 18:44
lizmat yes, I think the problem is there: Code.@!compstuff perhaps *should* have been initialized already ? 18:47
it feels like covering up a bug, rather than fixing one
ab5tract I see: so IMPL-STUB-CODE is not already called in this codepath, which is where @!compstuff gets set. 19:31
lizmat aha! 20:05
:-)
lizmat is starting to wonder whether it would make sense to do the unicode property database in Raku 20:06
nemokosch how can I inspect a whateverstar in vanilla Raku without whatever-currying constantly getting in the way? 20:36
okay, this is really funny 20:37
if I store it into a scalar variable, that's gonna protect from this behavior
but apparently, at least in the REPL because I'm getting paranoid now, a sigilless "variable" won't protect you
m: my \wut = *; dd wut ~~ Whatever 20:38
Raku eval Bool::True
nemokosch okay, then it's another REPL weirdness
quite unexpected
japhb lizmat: My only concern with Unicode property DB being lifted into Raku is performance, because my terminal code needs to do a LOT of unicode property examination (multiple per codepoint) in order to lay out strings properly. So I tend to be hitting that code pretty hard. 20:51
NemokoschKiwi bisectable: say -Inf .. 'Z' 21:03
bisectable6 NemokoschKiwi, Will bisect the whole range automagically because no endpoints were provided, hang tight
NemokoschKiwi, Output on all releases: gist.github.com/60f50328714ae4de1e...70ea4beabe 21:04
NemokoschKiwi, Bisecting by output (old=2017.05 new=2017.06) because on both starting points the exit code is 1
NemokoschKiwi, bisect log: gist.github.com/144e805ea5dad36e95...8ec2f6c472
NemokoschKiwi, (2017-06-07) github.com/rakudo/rakudo/commit/e5...30bd74d765
NemokoschKiwi, Output on all releases and bisected commits: gist.github.com/0b114c05ad22f31348...297cbc811b
NemokoschKiwi Hm, interesting, I expected a change somewhere on the way 21:05
lizmat japhb: "multiple per codepoint" that feels like currently multiple hash lookups, that maybe could be done smarter 21:45
japhb lizmat: I'd love something smarter! 21:55
See github.com/japhb/Text-MiscUtils/bl...od#L22-L40 for one example routine that itself is used as a primitive by a lot of other routines. 21:56
I guess these days %ignore should be a constant
lizmat yes, and actually I would make it a Map 21:58
Sets, by design, are keyed on the .WHICH, so that's relatively a lot of work
japhb Ooh, that could be a quick win right off. I wrote this code quite a while ago, so hadn't even been thinking about that bit. 21:59
Still, my original point was that even nerfing the handling of %ignore, that code is really painfully expensive.
lizmat my %ignore is Map = < Mn Mc Me Cc Cf Cs Co Cn > Z=> 1 xx *
japhb Where I can get away with the cache not ballooning out of control, I wrap duospace-width in a cache that I can ensure isn't being used concurrently in the calling code. 22:00
Because otherwise this one routine becomes pretty much a bottleneck for the entire layout stack.
lizmat also: you can combine the grep and the map into a single map
.map({ .uniprop('East_Asian_Width') unless %ignore{.uniprop} 22:01
})
japhb I always forget about that ability to fold away in map. Any relative expected performance difference between grep+map and map...unless? 22:02
lizmat really depends on how expensive .uniprop is 22:03
since it is not very (I think), it could be quite significant
and now I'm going to be to think about it some more :-) 22:04
japhb :-D
\o/ Successful nerd snipe!
japhb Annoyingly, can't declare a constant and use `is Map` at the same time. :-P 22:24
nemokosch constants default to Maps 22:25
just read that a couple of minutes ago haha
huh, really? Does Inf..'Z' produce a decent error only because the body of the Range constructor tries to retrieve the coerced value? ... 22:29
japhb m: my constant %foo = < a b c > Z=> 1 xx *; dd %foo; 22:30
camelia Map.new((:a(1),:b(1),:c(1)))
japhb HUH
I'll be darned.
nemokosch github.com/rakudo/rakudo/blob/3a70...akumod#L13 22:52
here, would it be okay to replace the sigilless and nqp::decont to a $variable?
gfldex `constant` declares a `term:<%foo>` and binds to it. 22:58
ab5tract m: my constant %foo = <a b c> X=> 1; dd %foo 23:01
camelia Map.new((:a(1),:b(1),:c(1)))
ab5tract X=> is one of my absolute favorites
gfldex m: my constant %foo = <a b c> »=>» 1; dd %foo 23:03
camelia Map.new((:a(1),:b(1),:c(1)))
gfldex I always have to think when I see X. A hyper fits better into my brain. 23:04
Geth rakudo: ab5tract++ created pull request #5376:
RakuAST: Fix once blorst not running		 23:16
ab5tract gfldex: I've got to figure out how to easily type those quote marks, then I might use them a bit more often :) 23:17
gfldex I had the same issue until I made them easy to type. :) 23:18
nemokosch >>=>>> actually works here xD 23:22
Ouch. The way -Inf..'Z' fails is indeed dependent on the internal logic of the range constructor 23:25
when I added the type check for *..'Z', it constructed a grotesque range that ends with a Failure instance 23:26
however, when passed the maximum value as $max > 0 ?? $max !! $max instead of just $max, suddenly I got the same behavior
gfldex I'm using xcompose and the following script to keep Linux and Windows in sync. The both can't agree on how keys should be called (hence the script). codeberg.org/gfldex/raku-xcompose/...mpose.raku 23:31
Geth File-Find/main: afb86c0405 | (Joseph Brenner)++ | 2 files
Allow junctions with name and exclude (Fixes #36)
 23:54
File-Find/main: 9948fd63c1 | (Márton Polgár)++ (committed using GitHub Web editor) | 2 files
Merge pull request #37 from doomvox/junction_arguments

Allow junctions with name and exclude

Powered by Cro and the Raku® Programming Language.

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

Thank you!