timo hey so, why don't we allow the `:to` adverb on regex definitions? :D 02:10
nine m: use v6.*; my $i = 0; say my @a = (LABEL: while True { last LABEL if $i++; 1 }); 08:46
camelia [1 Label<LABEL>(at <tmp>:1, 'i = 0; say my @a = (<HERE>LABEL: while True { last')]
bartolin nine: yes, from what I understand the tests are just wrong. I tried to read up the different issues and discussions related to my old bug report and it looks like I tried to follow some older tests which were with github.com/Raku/roast/commit/9f418777bc. 10:27
Maybe I still don't understand, but doesn't this test have the same problem (assuming that the code in the loop is run, even though it should be lazy)? github.com/Raku/roast/blob/c8c919a...#L748-L750 10:29
btw, my suspicion is that the added label confuses the parser and makes the loop non-lazy. (It's no longer just parens around a loop, as described in github.com/Raku/old-design-docs/bl...ent-level) 10:32
m: say (loop { 42 }).is-lazy; say (loop { 42 })[3] 10:50
camelia False
42
bartolin I don't really get this. 10:51
m: say (while True { 42 }).is-lazy
camelia True
lizmat is-lazy is really a misnomer
bartolin ah, that would explain
lizmat it's really: can't tell you if I can ever tell you how many elems will be produced 10:52
bartolin but there still seems to be a big difference between "loop" and (e.g." "while True" 10:57
m: my $i; @ = (loop { say 42; last if $i++ == 1})
camelia 42
42
bartolin m: my $i; @ = (while True { say 42; last if $i++ == 1})
camelia ( no output )
bartolin the first one is wrong, isn't it? Shouldn't it be lazy, too? 10:58
lizmat well, speculation appears to say so 10:59
not sure whether it makes sense to assign such meaning to something that's otherwise innocuous like adding extra parens for grouping
bartolin however, I'm totally fine with reverting github.com/raku/roast/commit/53d332addf. I'll do that later unless someone beats me to it. 11:04
Geth rakudo/main: a6608c2121 | (Elizabeth Mattijsen)++ | 2 files
Fix issue with .item causing PDF failure

I don't like this solution at all. Historically, the concepts of an item and a container have been conflated, which they probably shouldn't have been.
So now [].time will return an unassignable container, because there ... (13 more lines)
12:46
lizmat argh, [].item
Geth rakudo/main: 248f02baf1 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.rakumod
Add shortcut for (1,2,3).are(Mu)

Since all Raku types are Mu, if we're checking for Mu we actually don't need to do any checks at all.
Part of fixing #5778
14:12
timo i don't even want to think about this, but: json files where keys look the same but have differently normalized characters in them, i.e. ä as one character vs as a character + combining character 14:32
nine Well keys do not have to be unique anyway 14:37
timo it's true, but we map them to Map or Hash, where we do deduplicate
JSON::Fast might actually not need too many changes if we want to support opt-in for this annoyance if we ask the user to feed in a string that was decoded by the utf8-c8 codec 14:38
it will look funky when printing these maps/hashes to a utf8 string, but it should at least behave more like languages where normalization isn't so commonplace in the native String type
is there already a "compare how five million different json parsers interpret this document" tool on line, i wonder? 14:40
like the one the yaml-editor website has on it, or i guess that's not so much a tool and more the results of a comprehensive test suite that were generated ahead of time
different order of combining characters is of course also A Thing 14:43
nine lizmat: I think the rationale was that the parenthesis around a loop would turn it from a statement into an expression: 14:50
m: sub loopy() { for ^2 { $_ } }; sub lazy-loopy() { (for ^2 { $_ }) }; say loopy; say lazy-loopy
camelia Nil
(0 1)
timo m: my $capa = "\c[LATIN CAPITAL LETTER A]".encode("utf8-c8"), my $diar = "\c[COMBINING DIAERESIS]".encode("utf8-c8"), my $diar2 = "\c[COMBINING SNAKE BELOW]".encode("utf8-c8"), my $spc = "\c[SPACE]".encode("utf8-c8"); $*OUT.write($capa ~ $diar ~ $diar2 ~ $spc ~ $capa ~ $diar2 ~ $diar); # does this look like two different graphemes on your device or do they look the same? 14:59
camelia Ä᷂ Ä᷂
timo ... actually, camelia might be sending this through NFG 15:00
ha. i copy these two different Äs with snakes including the « before and » after from one terminal to another and here in my weechat i see the snakes below Äs and on the other i see one Ä with snake below and one A with snake below followed by an » with a diaeresis on top 15:02
this is the same terminal program though :D
pasting it into the firefox developer tools javascript console gives me an A with a snake below followed by a » but there's also a diaeresis *in between and above* the two characters 15:04
m: use JSON::Fast; from-json(Buf[uint8].new(123,34,195,132,34,58,32,34,111,110,101,34,44,32,34,65,204,136,34,58,32,34,116,119,111,34,125,10).decode("utf8-c8")).raku.say 15:13
camelia ===SORRY!=== Error while compiling <tmp>
Could not find JSON::Fast in:
/home/camelia/.raku
/home/camelia/rakudo-m-inst-2/share/perl6/site
/home/camelia/rakudo-m-inst-2/share/perl6/vendor
/home/camelia/rakudo-m-inst-2/share/pe…
timo evalable6: 2024.12 use JSON::Fast; from-json(Buf[uint8].new(123,34,195,132,34,58,32,34,111,110,101,34,44,32,34,65,204,136,34,58,32,34,116,119,111,34,125,10).decode("utf8-c8")).raku.say
evalable6 (exit code 1) ===SORRY!=== Error while compilin…
timo, Full output: gist.github.com/7239836e4b3c210d04...ea65af2899
timo committable: 2024.12 use JSON::Fast; from-json(Buf[uint8].new(123,34,195,132,34,58,32,34,111,110,101,34,44,32,34,65,204,136,34,58,32,34,116,119,111,34,125,10).decode("utf8-c8")).raku.say 15:14
committable6 timo, gist.github.com/b295546d5a297d4391...0234660d89
timo i seem to recall we had at least one bot where you can just "use" libraries, but maybe it requires a "use lib" with the correct path first?
rakkable: irc use JSON::Fast; 15:15
rakkable timo, Don't know how to handle 'irc use JSON::Fast;'
timo quotable6: use JSON::Fast;
quotable6 timo, OK, working on it! This may take up to three minutes (4582161 messages to process)
timo, gist.github.com/5a3bcdc75405649499...a5125d75c8
timo oh it wants that to be a regex
quotable6: "use JSON::Fast;"
quotable6 timo, OK, working on it! This may take up to three minutes (4582161 messages to process)
timo, 70 messages (2015-04-23⌁2018-04-20): gist.github.com/74f5180669eabcba65...a650cecd7b 15:16
timo committable: 2024.12 use lib ‘data/all-modules/cpan/TIMOTIMO/JSON-Fast’; use JSON::Fast; from-json(Buf[uint8].new(123,34,195,132,34,58,32,34,111,110,101,34,44,32,34,65,204,136,34,58,32,34,116,119,111,34,125,10).decode("utf8-c8")).raku.say
committable6 timo, gist.github.com/df58cd8b3cf9eab052...f3d2da3404
timo goes to other channel to fix this 15:17
in any case, that gives an Object™ with two different keys. when you print them to the terminal the one key with the decomposed grapheme gets the utf8-c8 output format, so it looks funny 15:25
to-json would need support for the user telling it that strings involved are utf8-c8, and probably a promise from the user that what's in the utf8-c8-relevant parts is actually valid utf8, since I think json does specify that the document must be valid utf8 15:26
nine ECMA-404 actually does not even mention UTF-8. It just says that a JSON document is a series of Unicode code points. 15:51
timo ah, right, that's even worse 16:01
aren't there a few other standards that seem to standardise json? do they differ? 16:02
nine RFC 8259 does state "JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 16:16
timo ok, that's at least sane :) 16:17
nine "Software implementations are typically required to test names of object members for equality. Implementations that transform the textual representation into sequences of Unicode code units and then perform the comparison numerically, code unit by code unit, are interoperable in the sense that implementations will agree in all cases on equality or inequality of two strings. For example,
implementations that compare strings with escaped characters unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not equal. 16:18
Still no word about normalization
Geth rakudo/main: ad18ca9fd3 | (Elizabeth Mattijsen)++ | src/core.c/Hyper.rakumod
Make sure result of >>foo<< is stored correctly

By default, hyper will create the same data structure as it finds on the left side. However if the result can not be stored, it would die with a typecheck error.
Now it will return a List with the result instead if the storing of the values in the same data structure failed.
Partial fix of #5778
17:08
bartolin m: sub lazy-loopy-parens() { (for ^2 { $_ }) }; dd lazy-loopy-parens; sub lazy-loopy-prefix() { lazy for ^2 { $_ } }; dd lazy-loopy-prefix ## another difference in output 17:11
camelia (0, 1)
(0, 1).lazy.Seq
nine The first one is not lazy at all: 18:10
m: sub lazy-parens() { (for ^2 { say $_ }) }; my $a := lazy-parens; say "done"
camelia 0
1
done
nine My guess is that none of this is very systematic. I think it's an underspecced area where we just observe side effects of the implementation. 18:11
bartolin I wonder if I should try to rewrite the bad tests in a way that they would work for both, lazy and non-lazy loops. (E.g. with putting them in a subroutine, like you showed, and then evaluating the result.) I'd somehow like to keep them as a regression test. (Maybe not as part of roast but of Rakudo's tests.) Or do you think I should just remove them alltogether? 18:23
m: my @res; sub while-loop() { L: while True { while True { @res.push: "while-loop"; last L } } }; say while-loop()[0]; dd @res
camelia Nil
["while-loop"]
bartolin m: my @res; sub while-loop() { (L: while True { while True { @res.push: "while-loop"; last L } }) }; say while-loop()[0]; dd @res
camelia Label<L>(at <tmp>:1, 'sub while-loop() { (<HERE>L: while True { while')
["while-loop"]
bartolin (The test would only be interested in @res.) 18:24
I'll see how that could look like and will maybe create a PR for more detailed discussion/review. 18:44
nine I think this really needs a decision on when a loop is really supposed to be lazy and when not 20:24
bartolin I see. I just finished my attempt to repair the tests, so ... 20:38
Geth roast: usev6++ created pull request #870:
Fix tests for nested loops and labeled last
nine Do they now pass with RAKUDO_RAKUAST=1? 20:43
bartolin I didn't try that before. Interestingly not all of them passed. Two subroutines seem to have problems: while-loop-in-parens() and until-loop-in-parens(). The rest is working. 20:48
m: my $ignored; my @res; sub while-loop-in-parens() { (L: while True { while True { @res.push: 3; last L } }) }; $ignored = while-loop-in-parens()[2]; dd @res 20:50
camelia [3]
bartolin was there a syntax to execute this with RAKUDO_RAKUAST=1 with camelia? 20:51
I got WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you can mark it as handled by calling .Bool, .so, .not, or .defined methods. The Failure was: Index out of range. Is: 2, should be in 0..0 in block <unit> at t/spec/S04-statements/label.t line 117 20:54
nine m: 'say "in a way".AST.EVAL
camelia ===SORRY!=== Error while compiling <tmp>
Unable to parse expression in single quotes; couldn't find final "'" (corresponding starter was at line 1)
at <tmp>:1
------> 'say "in a way".AST.EVAL<HERE><EOL>
expecting any of:
single q…
nine m: 'say "in a way"'.AST.EVAL
camelia in a way
bartolin ah, cool, thanks
even with trying to access the first element instead of the third, @res was empty. 20:55
m: 'my $ignored; my @res; sub while-loop-in-parens() { (L: while True { while True { @res.push: 3; last L } }) }; $ignored = while-loop-in-parens()[2]; dd @res'.AST.EVAL
camelia []
bartolin m: 'my $ignored; my @res; sub until-loop-in-parens() { (L: until False { until False { @res.push: 3; last L } }) }; $ignored = until-loop-in-parens()[2]; dd @res'.AST.EVAL 20:56
camelia []
bartolin m: 'my $ignored; my @res; sub c-style-loop-in-parens() { (L: loop { loop { @res.push: 3; last L } }) }; $ignored = c-style-loop-in-parens()[2]; dd @res'.AST.EVAL 20:57
camelia [3]
bartolin seems to work for all variations except while and until
ah, this seems to be the difference: 21:04
m: dd sub () { (L: while True { last L }) }()
camelia (Label.new(name => "L", file => "<tmp>", line => 1),).Seq
bartolin m: 'dd sub () { (L: while True { last L }) }()
camelia ===SORRY!=== Error while compiling <tmp>
Unable to parse expression in single quotes; couldn't find final "'" (corresponding starter was at line 1)
at <tmp>:1
------> sub () { (L: while True { last L }) }()<HERE><EOL>
expecting any of:
bartolin m: 'dd sub () { (L: while True { last L }) }()'.AST.EVAL 21:05
camelia Label.new(name => "L", file => "EVAL_0", line => 0)
bartolin so there is no Seq
I mean that's *a* visible difference 21:06
m: 'dd sub () { (L: loop { last L }) }()'.AST.EVAL 21:09
camelia (Label.new(name => "L", file => "EVAL_0", line => 0),).Seq
nine m: "abc" ~~ m:g/. { say $/ }/ 21:33
camelia 「a」
「b」
「c」
nine m: '"abc" ~~ m:g/. { say $/ }/'.AST.EVAL
camelia 「a」
「b」
nine m: '"abc" ~~ m:g/. { say $/ }/; say $/'.AST.EVAL
camelia Potential difficulties:
Useless use of constant string abc in sink context
at EVAL_0:1
「a」
「b」
「c」
(「a」 「b」 「c」)
nine Can things become more WTF? 21:34
I would understand 0, 1 or 3 calls, but 2?! 21:38