Geth rakudo/main: 7 commits pushed by (Stefan Seifert)++ 10:46
rakudo/main: 91904bc306 | (Stefan Seifert)++ | 2 files
RakuAST: fix overeager reporting of variable in sink context
 11:35
rakudo/main: bf5e15688e | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: report trying to call unknown routines in BEGIN blocks

If we encounter a call to an unknown routine in BEGIN time code, there's two cases:
  * the call is in some nested code block
  * the call is at the top level of the BEGIN block
... (11 more lines)
lizmat nine: should having a valud :outer-cu in a ::CompUnit.new be enough to fix the .assuming issue? 12:08
*valid
nine That would be nice. It might be :) Usually there's always yet another corner with problems though until there isn't 12:11
lizmat ok, then I'll focus on that. Because under RakuAST doing a BEGIN $ast.EVAL *does* have a valid $*CU to work with as outer 12:12
so it should just work, really :-) 12:13
and it doesn't atm
bisectable6: old=2024.01 my @a; @a[my $ = -1]="meow" 12:53
bisectable6 lizmat, On both starting points (old=2024.01 new=bf5e156) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «»
lizmat bisectable6: old=2020.01 my @a; @a[my $ = -1]="meow"
bisectable6 lizmat, On both starting points (old=2020.01 new=bf5e156) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «»
lizmat wow
bisectable6: old=2020.01 my @a; @a[my $ = -1]="meow"; dd @a 12:54
bisectable6 lizmat, Bisecting by output (old=2020.01 new=bf5e156) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/0c0fc2b47a8065aa63...5f92e8ca76 12:58
lizmat, There are 10 candidates for the first “new” revision. See the log for more details
lizmat ok, so basically this has been like forever 12:59
m: my @a; @a.AT-POS(-1)="meow" 13:00
camelia Index out of range. Is: -1, should be in 0..^Inf
in block <unit> at <tmp> line 1
lizmat m: my @a; @a.ASSIGN-POS(-1,"meow")
camelia Index out of range. Is: -1, should be in 0..^Inf
in block <unit> at <tmp> line 1
lizmat weird
m: my @a; @a[my $ = -1] = "meow" 13:24
camelia ( no output )
lizmat m: my @a; (@a[my $ = -1] = "meow").sink
camelia Index out of range. Is: -1, should be in 0..^Inf
in block <unit> at <tmp> line 1
lizmat looks like the return value of postcircumfixes is not getting sunk ?
nine Assignment targets in general don't get sunk 13:26
lizmat ok, but we agree that: my @a; @a[my $ = -1] = "meow" silently not doing anything, is bad, right ? 13:27
nine Sure. I wonder why it even needs to be sunk to actually try that assignment?
lizmat well, it returns a Failure, and if that gets sunk, it throws 13:28
since we don't sink it, it just goes on silently, which I feel is pretty wrong ?
so I think we need to fix postcircumfix to throw if the ASSIGN-POS returns a Failure 13:29
nine I get that Failure is a clever way to let the user decide whether they want to deal with exceptions or wrap calls in if statements. But who would write if @a[my $ = -1] = "meow" { ... } to catch a problem with the assignment itself? 13:33
When I see that code, I'd expect it to check the assigned value 13:34
lizmat the my $ = -1 is only there to make it not trigger the compile time check 13:35
m: my @a; @a[-1] = "meow"
camelia ===SORRY!=== Error while compiling <tmp>
Unsupported use of a negative -1 subscript to index from the end. In
Raku please use: a function such as *-1.
at <tmp>:1
------> my @a; @a[-1]<HERE> = "meow"
nine I know
if @a[$foo] = $bar { ... }
Still I'd expect this to check $bar, not whether @a[$foo] is a valid position 13:36
Just like with if $foo = $bar
lizmat yeah, but if you just do:
@a[$foo] = $bar 13:37
with $foo being OOR, nothing happens
it quietly contines, not doing the assignment and not throwing an error
nine Yeah, because we return a Failure in a case where absolutely no one would check for one
lizmat so my proposal is to *not* return a Failure in that case, but to throw it 13:38
nine Looks to me like a case of "whoo, there's Failures in this language, let's put them everywhere without thinking about whether it's even appropriate"
lizmat ok, so you mean it should always throw in the AT-POS / ASSIGN-POS ? 13:39
nine yes 13:40
With `if @a[$foo] = $bar { ... }` you don't even know whether $foo contains an invalid index or $bar is just falsey if it doesn't execute 13:42
lizmat afk for a few hours& 13:54
nine Sigh.... seems like t/spec/S32-exceptions/misc.t alone is as much work as the rest combined 14:24
[Coke] Only two failures in blin run: github.com/rakudo/rakudo/issues/5836 14:32
both bisected to github.com/rakudo/rakudo/commit/83...22caf86f39 14:33
(which is weird because that says RakuAST)
Doesn't look like Test::Async had any problems... but also doesn't look like it gained us many modules 14:37
liztormato [Coke]: looks to me CSS::Stylesheet is a flapper 15:02
nine liztormato is sending invisible messages 15:03
[Coke] when I see the invisible ones, I know to highlight it. :) 15:20
I think they also look fine in the logs. it's weird.
liztormato Weird. 15:25
I can see my messages ok. Also on the irclogs site 15:26
[Coke] lizmat: the flap protectin is running it up to 4 times. 16:21
Geth rakudo/main: 6 commits pushed by (Stefan Seifert)++ 16:25
timo does the irclog site strip out irc colors? 4test for red text 17:21
that shows up as "4test for red text" so i might not have done it exactly correctly? but it shows up correctly in my own irc client 17:23
before 0cyan text (code 10) between 9light green (code 09) between bold text end 17:25
yeah looks like only the first letter of the color code is stripped for presentation in the irclog viewer
lizmat hmmm... interesting... 17:27
timo learns about cursor mode in weechat 17:29
whoops, that was a command for my ssh, not my irc 17:30
liztormato Can you see me now?
timo yes 17:31
lizmat ok, changed a setting in Colloquy
should be able to not speak in cloudy tongues the next time :-)
timo is it related to away mode or something? 17:32
the weird messages are outside of my irc raw buffer so i can't see what they actually were 17:33
lizmat [Coke]: could it be that CSS::Stylesheet has a repeatable segfault at that commit ? 17:34
lizmat m: my Int @a; @a[my $ = -1] = 42 17:56
camelia ( no output )
lizmat m: my int @a; @a[my $ = -1] = 42
camelia Index out of range. Is: -1, should be in 0..^Inf
in block <unit> at <tmp> line 1
timo m: my Int @a; @a[my $ = -1] = 42; dd @a 18:00
camelia Int = Array[Int].new()
timo m: my Int @a; dd @a[my $ = -1];
camelia Failure.new(exception => X::OutOfRange.new(what => "Index", got => -1, range => "0..^Inf", comment => Any))
timo assigning to a Failure doesn't throw it, huh
m: my int @a; dd @a[my $ = -1];
camelia Index out of range. Is: -1, should be in 0..^Inf
in block <unit> at <tmp> line 1
 18:01
timo and on a native array we don't return a failure, we throw immediately
lizmat running a spectest to make it throw immediately for non-natives as well 18:03
making it throw immediately, breaks quite a few spectests :-( 18:10
timo at least attempting to assign to a Failure should throw it
lizmat How would you assign to a Failure? You mean if it's in a container ? 18:12
timo m: my Int @a; @a[my $ = -1] = 42 18:14
camelia ( no output )
timo this is assigning to the Failure object
m: Failure.new(exception => X::AdHoc.new(message => "oh no")) = 5 18:15
camelia Failed

Actually thrown at:
in block <unit> at <tmp> line 1
timo ah, so this is not about the failure that's returned from postcircumfix:<[ ]> being assigned into
instead, it's ASSIGN-POS not doing anything
which spec tests rely on that not throwing? 18:16
lizmat t/spec/S09-multidim/XX-POS-on-undimensioned.t 18:23
t/spec/S32-basics/xxPOS.rakudo.moar
timo so you made AT-POS throw immediately? 18:25
lizmat yeah
timo why? that already successfully returned a Failure
i thought the issue was that ASSIGN-POS wasn't explodey in any way for negative indices 18:26
lizmat the problem is that the return value of: @a[foo] = 42 is not being sunk 18:27
ASSIGN-POS returns a Failure fine
timo ah
lizmat but because the postcircumfix isn't sunk because of the assignment, it just silently does nothing
m: my @a; @a[my $ = -1] = "foo" 18:28
camelia ( no output )
timo makes sense for the return value of postfix assign not to be sunk as a general thing, it's just bitey here
lizmat yup
timo then does making ASSIGN-POS throw, but not AT-POS, also break lots of spec tests?
lizmat it would 18:29
but I was working on multi sub postcircumfix:<[ ]>(\SELF, Int:D \pos, Mu \assignee) is raw {
and have *that* check for Failure and throw if it is
timo ah
does ASSIGN-POS return the thing you assign? 18:30
we will not want to make Failures that you want to stash into an array be thrown for this reason
lizmat m: my @a = ^10; say @a.ASSIGN-POS(3,42) = 666; dd @a
camelia 666
[0, 1, 2, 666, 4, 5, 6, 7, 8, 9]
lizmat so yes 18:31
[Coke]: fwiw, I cannot repro the CSS::Stylesheet issue 18:37
[Coke] OK. I'll see if running it by hand on the blin box is instructive.
lizmat also realizes she's too tired to be programming after cycling almost 2 hours, so goes afk& 18:38
timo hm?
ah
[Coke] lizmat: installs fine from the main shell 18:47
sorry for the noise! 18:49
oh wait, main shell isn't at head. recalibrating. :) 18:52
Geth rakudo/main: 915c14c05b | (Stefan Seifert)++ | 2 files
RakuAST: report conflicting type on signature declarations

Fixes: my Int (Str $x) # to fail		 21:37
nine It's somewhat comical that on the day we discuss about Failure being used too often I come across the fact that array.^parameterize returns plain strings on errors. No exceptions, not even Failures, just a return "Can only parameterize array with a native type, not {t.^name}" 21:40
timo you take the MOP, you get to mop up the dirt :D 22:00
Geth rakudo/main: cfc74a80ef | (Elizabeth Mattijsen)++ | src/core.c/Hash.rakumod
Add a "die" that was missed in 69dd7d66ea
 23:22

Powered by Cro and the Raku® Programming Language.

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

Thank you!