🦋 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.
00:00 reportable6 left 00:02 reportable6 joined 01:04 squashable6 left 01:06 squashable6 joined 01:47 MasterDuke joined
MasterDuke nine: pushed what i have so far to github.com/rakudo/rakudo/pull/5242 01:47
02:33 MasterDuke left 02:34 elcaro_ joined
elcaro_ bisectable6: old=2023.02 gist.githubusercontent.com/0racle/...-test.raku 02:38
bisectable6 elcaro_, Successfully fetched the code from the provided URL
elcaro_, On both starting points (old=2023.02 new=80c35e4) the exit code is 0 and the output is identical as well
elcaro_, Output on both points: «26␤»
elcaro_ bisectable6: old=2022.07 gist.githubusercontent.com/0racle/...-test.raku 02:44
bisectable6 elcaro_, Successfully fetched the code from the provided URL
elcaro_, Bisecting by output (old=2022.07 new=80c35e4) because on both starting points the exit code is 1
elcaro_ oops, I messed up that gist. 02:48
One more time
bisectable6: old=2022.07 gist.githubusercontent.com/0racle/...-test.raku
02:49 bisectable6 left
elcaro_ I think I killed bisectable :( 02:49
In any case... That last gist I posted breaks between 2022.07 and 2023.02
02:51 bisectable6 joined
elcaro_ bisectable6: old=2022.07 new=2023.02 gist.githubusercontent.com/0racle/...-test.raku 02:53
bisectable6 elcaro_, Successfully fetched the code from the provided URL
elcaro_, Bisecting by exit code (old=2022.07 new=2023.02). Old exit code: 0
02:57 bisectable6 left 03:00 bisectable6 joined
elcaro_ Alright, bisectable can't find it... a whole bunch of commits couldn't be tested, but somewhere since 2022.07 it broke 03:02
Oh, it's also fine in 2022.12. One last try... 03:09
bisectable6: old=2022.12 new=2023.02 gist.githubusercontent.com/0racle/...-test.raku 03:10
bisectable6 elcaro_, Successfully fetched the code from the provided URL
elcaro_, Bisecting by exit code (old=2022.12 new=2023.02). Old exit code: 0
03:14 bisectable6 left 03:16 bisectable6 joined 06:00 reportable6 left 06:02 reportable6 joined 07:51 sena_kun joined 08:51 reportable6 left, squashable6 left, evalable6 left, benchable6 left, tellable6 left, benchable6 joined, squashable6 joined 08:52 evalable6 joined, reportable6 joined 08:54 tellable6 joined
elcaro_ FWIW, I manually built commit 9b8a160e42e7ecf0120eb21ae45cc92bf02d110b (RakuAST: implement support for LEAVE phase) which is the first commit after the 2022.12 release, and it's broken there 08:59
08:59 linkable6 left
elcaro_ So... unless I'm mistaken, I think that's where the code in the above gist started failing. 08:59
09:00 linkable6 joined
elcaro_ It's been a while since I was building Raku from scratch, but I built a few commits to track it down, between each build I blew away the `install` folder just to be sure. 09:00
Nemokosch that commit doesn't say a lot... it's probably the RakuAST branch merge overall that broke something 09:01
elcaro_ yeah... I know there was a lot going on in RakuAST branch that got merged... which it's why I said FWIW. I'm not sure how to track it down any further. 09:02
Nemokosch by the way, the pod stuff is not needed 09:07
given '2 * 3 + (4 * 5)' -> $line is enough 09:08
hell, even my $line = '2 * 3 + (4 * 5)'; { say $line.trans('+*' => 'pt').EVAL; } is enough 09:10
BUT that block is needed so you might call this a golf 09:11
okay... even { say '2 * 3 + (4 * 5)'.trans('+*' => 'pt').EVAL; } is enough 09:12
seems like the EVAL inside the block doesn't see the operators defined outside
lizmat you don't need the .trans
Nemokosch and one operator is enough 09:14
lizmat yeah, the only thing you need to make it fail, is to have the EVAL be inside a block 09:16
m: sub infix:<t>($a, $b) { $a * $b }; say '6 t 7'.EVAL; say '6 t 7'.EVAL if 42; if 42 { say '6 t 7'.EVAL } 09:19
camelia 42
===SORRY!=== Error while compiling /home/camelia/EVAL_2
Two terms in a row
at /home/camelia/EVAL_2:1
------> 36⏏ t 7
expecting any of:
infix
infix stopper
statement end
statement …
lizmat I'll make an issue for it 09:21
Nemokosch elcaro: the thing is, 2022.12 was created from a different branch, or better said, anything ever since has been created from a different branch 09:22
lizmat bisectable6: old=2022.07 sub infix:<t>($a, $b) { $a * $b }; if 42 { say '6 t 7'.EVAL } 09:23
bisectable6 lizmat, On both starting points (old=2022.07 new=80c35e4) the exit code is 1 and the output is identical as well
lizmat, gist.github.com/0fbcc6a6d93b92562c...df0d95c297
Nemokosch so it's probably not like "it broke inbetween" but one would need to track the current main branch backwards to times when it hasn't been used for releases
lizmat bisectable6: old=2022.02 sub infix:<t>($a, $b) { $a * $b }; if 42 { say '6 t 7'.EVAL }
bisectable6 lizmat, On both starting points (old=2022.02 new=80c35e4) the exit code is 1 and the output is identical as well
lizmat, gist.github.com/32dbbb0d9a79f25ead...bc6de6f060
Nemokosch the bisecting should be done on that branch
lizmat bisectable6: sub infix:<t>($a, $b) { $a * $b }; if 42 { say '6 t 7'.EVAL }
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/ed1c98b2dea0126ebd...5132b6c8d1 09:25
lizmat, Bisecting by exit code (old=2017.02 new=2017.03). Old exit code: 0
Nemokosch or was the rakuast branch rebased at least before turning it into the main branch?
rebased to the tip of master
lizmat pretty sure it was rebased
bisectable6 lizmat, bisect log: gist.github.com/a9454f1a64c3693708...ce8eacae7a
lizmat, Output on all releases and bisected commits: gist.github.com/3da94d0c769abfc360...98b832cf2f
lizmat bisectable6: old=2017.02 new=2017.03 sub infix:<t>($a, $b) { $a * $b }; if 42 { say '6 t 7'.EVAL } 09:32
bisectable6 lizmat, Bisecting by exit code (old=2017.02 new=2017.03). Old exit code: 0
lizmat, bisect log: gist.github.com/a70ff120388c5e00dc...c9e0c806b9
lizmat, There are 25 candidates for the first “new” revision. See the log for more details
lizmat github.com/rakudo/rakudo/issues/5257 09:42
Geth rakudo/main: ae7a219c94 | (Elizabeth Mattijsen)++ | src/Raku/ast/compunit.rakumod
RakuAST: make sure you can call HLL methods on $=finish

Instead of getting an error such as:
   No such method 'lines' for invocant of type 'BOOTStr'.
   Found 'lines' on type 'Cool'		 09:54
lizmat sadly no additional test files passing
Geth rakudo/main: c55455d73d | (Elizabeth Mattijsen)++ | 2 files
RakuAST: fix rules for determing implied code blocks

Previously, it was assumed that the indentation level of the
  =begin pod would be taken as a base to determine an implied code
block. But it turns out it is indentation level of the last seen doc block.
... (19 more lines)		 11:36
lizmat 801!
m: =begin pod␤E<alpha;beta;gamma>␤=end pod␤say $=pod.head.contents.head.contents.head.contents 11:46
camelia [α β γ]
lizmat TIL you can have multiple ; separated entries in E<> 11:47
docs.raku.org/language/pod#Unicode doesn't document this
m: =begin pod␤E<171;space;raquo>␤=end pod␤say $=pod.head.contents.head.contents.head.contents 11:51
camelia ===SORRY!===
Preceding context expects a term, but found infix = instead.
Did you make a mistake in Pod syntax?
at <tmp>:4
------> ead.contents.head.contents.head.contents⏏<EOL>
Other potential difficulties:
"space" is n…
12:00 reportable6 left 12:01 reportable6 joined
Geth rakudo/main: 5965d7fb00 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6
RakuAST: fix deparsing of E<> markup
 12:35
13:33 lizmat left 14:04 lizmat joined
[Coke] malformed utf throws an adhoc exception - we should probably have a specific exception here. (this is probably true for almost all adhoc exceptions in core) 15:42
I find myself using the pattern of CATCHING everything and basically ignoring it, and then checking to see if my object is in a reasonable state ("did .decode result in a non-empty string?") rather than using real exception handling because peeking in the message is gross. 15:43
Would love to see that also be part of 6.e (exceptions everywhere) 15:44
lizmat m: =begin pod␤E<LATIN CAPITAL LETTER A>␤=end pod␤say $=pod.head.contents.head.contents.head.contents 16:00
camelia [A]
lizmat TIL you can also specify Unicode codepoint names in E<>
which is also not documented
Geth rakudo/main: 8e51307821 | (Elizabeth Mattijsen)++ | t/12-rakuast/doc-markup.rakutest
RakuAST: fixup tests, we use Str, not RakuAST::StrLiteral
 16:23
rakudo/main: 2e3690bdaf | (Elizabeth Mattijsen)++ | 6 files
RakuAST: various pod rendering fixes

  - don't create empty paragraphs from the actions
  - allow for empty =for doc blocks
  - make argument to RakuAST::Doc::Block.set-(atoms|meta) optional to
   allow for resetting
  - added stringification for RakuAST::Doc::Markup, use also in deparse
  - allow for unicode code point names in E<> sequences
  - allow for multiple values in a E<> sequence, separated by ;
  - fix podification of RakuAST::Doc::Markup
lizmat 802
18:00 reportable6 left 18:02 reportable6 joined
vrurg [Coke]: that was something I started but never completed. See throw_or_die calls scattered here and there. 18:15
[Coke] Do core devs agree that most user-facing exceptions should be typed? Seems like something that could be implemented by non-core devs. 18:38
(except for where stuck in NQP or some parsing situations)
lizmat I agree 18:40
OTOH, I'm not sure whether they should be considered part of the language
but rather an implementation-detail
but that's longer term :-) 18:41
[Coke] I think having them be spec is required. 18:45
or else you're stuck with whatever implementation you wrote your code for.
and I think it's ok to turn an adhoc into an typed in the existing compiler version onward, but testing that it's that type should only be in the next (yet unreleased) language version 18:46
japhb Having spec'ed superclasses is a requirement. Subclasses maybe not. (E.g. there could be an OS error on one platform that cannot happen on another, which can fail in a different way -- but they might both be considered process control exceptions or so.)
[Coke] so we could make malformed UTF8 a typed exception now in v6.c and nothing should care, but we can't enforce it until 6.e
japhb: fair. 18:47
japhb For general non-platform specific stuff like malformed UTF-8, I agree with you.
19:25 evalable6 left, linkable6 left 19:27 evalable6 joined 19:28 linkable6 joined 20:41 linkable6 left, benchable6 left, notable6 left, statisfiable6 left, releasable6 left, greppable6 left, committable6 left, shareable6 left, evalable6 left, nativecallable6 left, unicodable6 left, quotable6 left, tellable6 left, squashable6 left, coverable6 left, sourceable6 left, reportable6 left, bloatable6 left, bisectable6 left, coverable6 joined, sourceable6 joined 20:42 benchable6 joined, bisectable6 joined, unicodable6 joined, releasable6 joined, linkable6 joined, evalable6 joined 20:43 squashable6 joined, bloatable6 joined, nativecallable6 joined, statisfiable6 joined, notable6 joined, tellable6 joined, greppable6 joined, shareable6 joined, quotable6 joined, reportable6 joined, committable6 joined 21:45 sena_kun left 23:06 linkable6 left, evalable6 left 23:08 evalable6 joined, linkable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!