|
08:54
finanalyst joined
09:04
librasteve_ left
09:13
librasteve_ joined
09:47
finanalyst left
13:28
finanalyst joined
16:54
librasteve_ left
18:34
finanalyst left
20:53
kjp_ left,
rakkable left,
lucs left,
JRaspass left
20:54
disbot11 is now known as disbot
20:58
disbot is now known as 068AAN878,
kjp_ joined,
rakkable joined,
lucs joined,
JRaspass joined
21:09
zjmarlow joined
|
|||
| lizmat | m: my $answer = 42; say answer # wonder whether this should mention "$answer" as an alternative | 21:12 | |
| camelia | ===SORRY!=== Error while compiling <tmp> Undeclared routine: answer used at line 1 |
||
| zjmarlow | Should the implied separator rule come into play if a hash composer ends a line? | 21:15 | |
| lizmat | you mean, to have it turned into a block ? | 21:20 | |
| zjmarlow | No, it is interpreting it as the end of the statement. So if you put a statement-modifying condition after it, it looks for a block on that line. | 21:21 | |
| It still says it's a Hash, though. According to .^name | |||
| lizmat | well, that's the general rule: a closing } at the end of a line *is* by definition the end of a statement | 21:22 | |
| zjmarlow | my %args; %args<key> = { } | ||
| unless %args<key>.isa: Hash | |||
| lizmat | whether that's from a hash access or a block | ||
| zjmarlow | Ah, docs mention it applies to blocks.\ | ||
| okay | |||
| lizmat | then that's a doc issue | 21:23 | |
| hmmmm | 21:24 | ||
| perhaps you're right | |||
| or maybe that's changed sometime in the last 10 years or so, and I missed it | 21:25 | ||
| m: q/my %h = :42a; say %h{"a"}\nsay %h<b>/.EVAL | 21:26 | ||
| camelia | ===SORRY!=== Error while compiling /home/camelia/EVAL_0 Confused at /home/camelia/EVAL_0:1 ------> my %h = :42a; say %h{"a"}\<HERE>nsay %h<b> expecting any of: postfix |
||
| zjmarlow | m: my %args; %args<key> = { } | 21:28 | |
| camelia | ( no output ) | ||
| zjmarlow | unless %args<key>.isa: Hash | ||
| that errors on 2025.12 | |||
| [Coke] | can use bisectable to find if a behavior changed. | 21:29 | |
| zjmarlow: seems fine, what is the code that's dying? | 21:31 | ||
| ah, those two lines one after the other in a script? end the first line with a \ | 21:33 | ||
| zjmarlow | okay. I wasn't sure if there was an issue. | 21:34 | |
| (that worked) | 21:35 | ||
| [Coke] | m: my %args; %args<key> = { }  unless %args<key>.isa: Hash | 21:37 | |
| camelia | ===SORRY!=== Error while compiling <tmp> Missing block at <tmp>:2 ------> unless %args<key>.isa: Hash<HERE><EOL> expecting any of: block or pointy block |
||
| [Coke] | bisectable: my %args; %args<key> = { }  unless %args<key>.isa: Hash | ||
| bisectable6 | [Coke], Will bisect the whole range automagically because no endpoints were provided, hang tight | ||
| [Coke], Output on all releases: gist.github.com/1d7540eb1ed1cf7937...7f169c3a46 | 21:38 | ||
| [Coke], Bisecting by output (old=2024.10 new=2024.12) because on both starting points the exit code is 1 | |||
| [Coke], bisect log: gist.github.com/3da6739543a154727f...f655111484 | |||
| [Coke], (2024-11-22) github.com/rakudo/rakudo/commit/a9...b4dced35bc | |||
| [Coke], Output on all releases and bisected commits: gist.github.com/e2f59181fe3df7bd8c...50bcda2ffa | |||
| [Coke] | Did we discontinue EJECT? huh | 21:40 | |
| zjmarlow | I have to head out | 21:41 | |
| lizmat | [Coke]: EJECT as a phaser ? | ||
| does not occur in the Rakudo source tree | |||
| or do you mean: 23CF EJECT SYMBOL ⏏ | 21:42 | ||
| [Coke] | Yes, the symbol (the only diff in the bisect) | 22:17 | |
|
23:29
zjmarlow left
|
|||
| japhb | U+23CF is Unicode 4.0 ... maybe someone wanted to avoid possible ASCII incompatibility in error messages? | 23:44 | |
| From Rakudo/Internals.rakumod: | 23:45 | ||
| method error-rcgye() { # red clear green yellow eject | |||
| !$*COMPILING_CORE_SETTING && $*ERR.t && (self.NUMERIC-ENV-KEY("RAKUDO_ERROR_COLOR") // !self.IS-WIN) | |||
| ?? ("\e", "\e", "\e", "\e", "\x[23CF]") | |||
| !! ("", "", "", "", "<HERE>"); | |||
| That avoidance of Windows might be out of date these days. | 23:46 | ||
| (The modern Windows Terminal doesn't suck.) | |||
| ... well, assuming it's in UTF-8 mode at least. But if not in that mode, Rakudo use is going to be less than joyful. | 23:49 | ||