| Voldenet | ugexe: obviously R should start from the tail as it used to previously, so `[R_] …` should be equivalent to `[_] reverse …` | 00:45 | |
| docs also say "Associativity of operands is reversed as well." | 00:49 | ||
| I'm pretty sure that the result of `R,` should be flattened too, it could maybe make sense to have `multi infix:<,>(*@a) { … }` | 00:54 | ||
| otoh, reduce is defined as "processing list from left to right" | 01:07 | ||
| no strings attached, `R-` op is applied later, so `((1 R- 2) R- 3)` seems correct | |||
| reduce doesn't say anything about operator's associativity | 01:08 | ||
| …haha, okay, I read further into docs and | |||
| `If &with is the code object of an operator, its inherent identity value and associativity is respected` | |||
| so in short `say [R-] 1, 2, 3` should be equivalent to `say 1 R- 2 R- 3` | 01:10 | ||
| it gets really confusing fast and apparently both current implementation and rakuast impl is wrong | 01:13 | ||
| nah, old implementation is right, rakuast is wrong | 01:19 | ||
| m: say qqx/RAKUDO_RAKUAST=1 raku -e 'say 2 R- 3 R- 4; say [R-] 2, 3, 4'/ | 01:20 | ||
| evalable6 | -1 3 |
01:21 | |
| Voldenet | m: say qqx/RAKUDO_RAKUAST= raku -e 'say 2 R- 3 R- 4; say [R-] 2, 3, 4'/ | 01:23 | |
| evalable6 | -1 -1 |
||
| Voldenet | apparently rakuast has reduce impl that assumes left-assoc of the operator, which R reverses | 01:24 | |
| m: say qqx/RAKUDO_RAKUAST=1 raku -e 'say 2 R** 3 R** 4; say [R**] 2, 3, 4'/ # this correctly uses right associativity, which in this case is left :> | 01:26 | ||
| evalable6 | 262144 262144 |
||
| Voldenet | m: say qqx/RAKUDO_RAKUAST=1 raku -e 'say 4 ** (3 ** 2); say [**] 4, 3, 2'/ # apparently reduce metaop is able to understand right-assoc just fine, so the bug is just in the R metaop | 01:31 | |
| evalable6 | 262144 262144 |
||
|
01:33
MasterDuke joined
|
|||
| Voldenet | I'm naively thinking that simply replacing `[R_]` with `[_] reverse` could work in any case, but I have no way to prove it | 01:42 | |
|
02:10
MasterDuke left
|
|||
| Geth | rakudo: ugexe++ created pull request #6201: RakuAST: emit proper SORRY exceptions for invalid feed-operator stages |
04:16 | |
|
10:06
Pixi` joined
10:08
Pixi left
10:24
donaldh joined
10:36
librasteve_ left
10:42
kurahaupo left
|
|||
| releasable6 | Next release in ≈3 days and ≈7 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 11:00 | |
|
11:12
kurahaupo joined
11:31
kurahaupo left,
donaldh left,
donaldh joined
11:39
kurahaupo joined
13:10
hurufu joined
14:38
kjp left,
kjp joined
14:39
hurufu left
|
|||
| [Coke] | gist.github.com/coke/97d0aafddd5ad...9ce86eb7d5 | 15:31 | |
| ^^ 3 commits mentioned over 6 packages - the first one is the merge commit, so maybe just a flapper. | |||
| er, a release merge commit | |||
| lizmat | ok, both by me :-( | 15:44 | |
| [Coke] | I understand we have one more localized bug fix that wants in, and then maybe fixing these issues before Saturday? | 15:54 | |
| lizmat | yes, the Gzz and Clifford ones I already left issues for | 15:56 | |
| so are not fixable in core | |||
| [Coke] | please nothing too big going in before then. | ||
| lizmat | fixing %g format in 6.e sprintf is the only thing I'm still working on | 15:57 | |
| [Coke] | I see no issues on Gzz-Text-Utils | ||
| lizmat | it's borked at the moment, and blin didn't see that, so I don't worry too much about that (or its fix) | ||
| the problem with Gzz... is one of the dependencies: Gzz::Prompt I left the issue there | 15:58 | ||
| [Coke] | ah | ||
| ... interesting that the dependency didn't show up in this list? | |||
| lizmat | not sure why blin didn't catch that, indeed | ||
| looking at Curry atm | 15:59 | ||
| [Coke] | ah, I probably should have opened an actual ticket, just threw it in a gist to get it out there asap | 16:00 | |
| one sec | |||
| added to github.com/rakudo/rakudo/issues/6168 | 16:01 | ||
| lizmat | aah... indeed. now I remember... seems codeberg is up now, so I will make an issue for Curry there now | 16:04 | |
| hmm...wonder why we didn't see the JSON::RPC one before | 16:15 | ||
| seems like the synthetic code has trouble finding the URI symbol | |||
|
16:19
Pixi` is now known as Pixi
|
|||
| lizmat | hmm... ok, looks like the JSON::RPC is actually pointing to a real issue... | 16:41 | |
| but still not understanding why we didn't see this before | |||
| ugexe | probably some follow up rakuast work | 16:42 | |
| since assuming is exposing rakuast changes | 16:43 | ||
| anywho don't worry about it, i'll fix it after work | |||
| lizmat | golfed to: use URI; my sub a(URI :$uri) { dd }; my &b = &a.assuming(:uri(URI.new)) | ||
| the problem is the URI constraint on the argument in sub A | 16:44 | ||
| it generates: | |||
| RakuAST::Parameter.new( | |||
| type => RakuAST::Type::Simple.new( | |||
| RakuAST::Name.from-identifier("URI") | |||
| ), | |||
| should that be something other than Type::Simple ? | |||
| ugexe | my hunch will be the context being passed to eval | 16:45 | |
| s/hunch/wild guess/ | 16:46 | ||
| lizmat | s/.URI/Int/ and everything's ok, so it really looks like a context issue | ||
| context is CALLER::LEXICAL:: (the default) | 16:48 | ||
| maybe assuming needs its CALLER::LEXICAL:: context | |||
| $ast.EVAL(:context(CALLER::LEXICAL::)) | 16:50 | ||
| now fails with: | |||
| ===SORRY!=== Error while compiling: | 16:51 | ||
| 'self' used where no object is available | |||
| ugexe | yeah, that isnt sufficient | 16:52 | |
| github.com/ugexe/rakudo/commit/cdb...4c8892b049 | 16:53 | ||
| i tossed the problem to the clanker and thats what it came up with. i haven't vetted it at all though and won't have time for another 5ish hours | |||
| lizmat | ack, thanks, looks like that will work | 16:54 | |
| ugexe | lol... `END { run(<rm -rf>, $tmp.Str) if $tmp.defined && $tmp.e }` | 16:55 | |
| lizmat | the proposed fix fixes JSON::RPC, but breaks some spectest | 17:04 | |
| Geth | rakudo/lizmat-5: 447caa85c7 | (Elizabeth Mattijsen)++ | src/core.c/core_epilogue.rakumod Fix for .assuming not seeing imported symbols Adaptation from ugexe++ github.com/ugexe/rakudo/commit/cdb...4c8892b049 Differences: also add support for a RAKUDO_ASSUMING_DEBUG environment variable, and make the actual EVAL calling code a bit DRYer. And no test yet. |
17:14 | |
| ugexe | why did you remove the .EVAL | 17:18 | |
| vs RakuAST::PointyBlock.new(|%args).EVAL(:$context) | |||
| lizmat | the EVAL is at the end | 17:19 | |
| so we can get some debug info inbetween | |||
| m: class A { our method f(:$x) { } }; my &g = &A::f.assuming(my $a = A.new) | 17:25 | ||
| evalable6 | |||
| lizmat | this is broken wth github.com/rakudo/rakudo/commit/447caa85c7 | 17:26 | |
| m: class A { our method f(:$x) { } }; my &g = &A::f.assuming(A.new) | |||
| evalable6 | |||
| lizmat | is *not* broken, so the `my $a =` is needed | ||
| the error: This element has not been resolved. Type: RakuAST::Var::Lexical | |||
| ah, I see the issue now: because the context has shifted to the caller, it doesn't see its own arguments anymore | 17:36 | ||
| and that's needed in case the original sub had an "is raw" on it | 17:44 | ||
| so what we need is a lookup chain that first does the lexical, and then the caller | 17:50 | ||
| or somehow be able to specify more than one context | 17:52 | ||
| ugexe | Fix: in src/core.c/core_epilogue.rakumod:415-420: drop the @positionals[$i] indirection. Always embed the positional value via RakuAST::Literal.from-value(@positionals[$i]). The synthesised closure no longer needs @positionals to resolve in any scope. | 17:53 | |
| lizmat tries | 17:54 | ||
| but that won't work | 17:55 | ||
| ugexe | i would be surprised if it didn't work | 17:56 | |
| lizmat | m: sub a($a is raw) { dd $a }; my $b = 42; my &c = &a.assuming($b); c; $b = 666; c | 17:57 | |
| evalable6 | $b = 42 $b = 666 |
||
| lizmat | it breaks that ^^ | ||
| I guess you didn't know you could do that with .assuming | |||
| ugexe | 🤔 | 18:00 | |
| lizmat | I remember being very surprised by that :-) | ||
| I guess we need a way to enshrine the container into the AST | 18:31 | ||
| something with RakuAST::ContainerCreator ? | 18:47 | ||
|
19:28
ShimmerFairy left
19:30
ShimmerFairy joined
19:53
ShimmerFairy left,
kurahaupo left,
Pixi left
20:02
kurahaupo joined
|
|||
| lizmat | bisectable6: old=2026.04 sub a($a is raw) { dd $a }; my $b = 42; my &c = &a.assuming($b); c; $b = 666; c | 21:00 | |
| bisectable6 | lizmat, On both starting points (old=2026.04 new=6f0f1f5) the exit code is 0 and the output is identical as well | ||
| lizmat, Output on both points: «$b = 42$b = 666» | |||
| lizmat | bisectable6: old=2026.03 sub a($a is raw) { dd $a }; my $b = 42; my &c = &a.assuming($b); c; $b = 666; c | ||
| bisectable6 | lizmat, On both starting points (old=2026.03 new=6f0f1f5) the exit code is 0 and the output is identical as well | ||
| lizmat, Output on both points: «$b = 42$b = 666» | |||
| lizmat | ugexe: turns out this behaviour is actually *not* enshrined in spec tests | 21:01 | |
| but it *is* a behaviour of the old implementation | 21:02 | ||
| ugexe | its not a big deal, i can probably fix it in like 15 minutes once im out of work | ||
| lizmat | ok, then I'll stop my research into this for now | 21:06 | |
| [Coke] | releasable6: next | 21:31 | |
| releasable6 | [Coke], Next release in ≈2 days and ≈21 hours. 1 blocker. 87 out of 133 commits logged | ||
| [Coke], Details: gist.github.com/949043d762f363e092...b3fd743fbb | |||
| lizmat | [Coke]: looks like we also want to get github.com/MoarVM/MoarVM/pull/2006 in the release | 21:32 | |
| [Coke] | lizmat: that sprintf fix still pending? if so please also create a blocker ticket for it. | ||
| lizmat | it's still pending... got distracted by the blin run :-) | 21:33 | |
| [Coke] | I am very hesitant to merge a moar chang post blin | ||
| lizmat | it's preventing segfaults / buffer overflow | ||
| it's been there for years, so in that sense we can wait... it's just that it's public now :-( | 21:34 | ||
| [Coke] | ok. | 21:36 | |
| ugexe | i'll fix pod::contents as well, i assume it is a similar issue | 21:39 | |
| [Coke] | ugexe++ lizmat++ | 21:43 | |
|
22:07
ShimmerFairy joined
22:16
vrurg_ joined
22:20
vrurg left
|
|||
| Geth | nqp/main: f85683c67b | (Daniel Green)++ | tools/templates/MOAR_REVISION Bump MoarVM for nqp::strtocodes() fix |
22:29 | |
| rakudo/main: 07e674626c | (Daniel Green)++ | tools/templates/NQP_REVISION Bump NQP for nqp::strtocodes() fix |
22:32 | ||
| rakudo: ugexe++ created pull request #6202: RakuAST: two Code.assuming bugs in synthesised closures |
22:50 | ||
| ugexe | that should fix JSON::RPC and Pod::Contents | 22:51 | |