Geth nqp/tests-for-iterator-misuse: fa10274ccd | ab5tract++ (committed using GitHub Web editor) | t/nqp/108-vmhash.t
Clarify test message
 01:05
01:29 nine left 01:30 nine joined 03:01 MasterDuke joined
MasterDuke ab5tract: fyi, there's a #whateverable channel if you want to spam the bots 03:19
06:24 vrurg joined 06:27 vrurg_ left
ab5tract Ah, nice. 06:33
06:53 MasterDuke left
Geth rakudo/main: 99bfab8c88 | ab5tract++ (committed using GitHub Web editor) | src/core.c/Rakudo/SEQUENCE.rakumod
Fix memory leaking in infinity-bound ...

There's no reason to involve the `righti` iterator at all. Remove that, et voila, no memory leak for inifinite sequences.
There are only two possible `righti` for infinities: ... (11 more lines)		 09:13
09:27 sena_kun joined 09:59 finanalyst joined
lizmat just realizes that .grep doesn't take :end 11:33
[Coke] ... but .first does? weird. 13:18
lizmat yeah, things you find out when trying to make a better .hyper 13:21
ab5tract lizmat: this is an interesting one ... R#5130 15:55
linkable6 R#5130 [open]: github.com/rakudo/rakudo/issues/5130 dd misreports array items
ab5tract m: my %e = :joy("full"); dd %e<joy> 15:56
camelia Mu %e = "full"
ab5tract not sure how resolvable it actually is
without doing some ad-hoc parsing or something similarly icky 15:57
lizmat a. this is not an array item, and b. what's wrong ? 15:59
ab5tract I was showing that the same thing is happening for hashes 16:00
lizmat dd inspects the value it gets: in this case it gets the container of which the descriptor lives in the hash
what's before the = is basically a representation of the descriptor 16:01
ab5tract the core conceit of the issue is "can dd tell me that I'm looking at a piece of the variable, rather than looking at the whole variable"
lizmat dd can only see that it gets a container for %e<joy>
ab5tract that's what I figured 16:02
lizmat I guess we could remove the "%e" in this case, so it'd be: Mu = "full"
ab5tract if that's possible, another suggestion from the ticket would be to say " Mu element of %e = 'full'" 16:04
or something like that
some queue to indicate that you aren't dd'ing the whole container 16:05
s/queue/thing/
lizmat you *are* dding the whole container :-)
ab5tract m: my @a = $[3,4], 4, 5; dd @[0]; dd @[1] 16:06
camelia [0]
[1]
ab5tract m: my @a = $[3,4], 4, 5; dd @a[0]; dd @a[1]
camelia Mu @a = $[3, 4]
Mu @a = 4
ab5tract m: my @a = $[3,4], 4, 5; dd @a[0]; dd @a[1]l; dd @a
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> my @a = $[3,4], 4, 5; dd @a[0]; dd @a[1]⏏l; dd @a
expecting any of:
infix
infix stopper
postfix
statement…
ab5tract gah, typo. but you get the point
anyway, if its complicated then forget I mentioned it. but I thought it was an interesting feature request 16:08
lizmat compiling a fix now :-) 16:09
ab5tract sweet :D 16:14
Geth rakudo/main: e1bd3ffd3e | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod
Make dd be more verbose about hash/array elements

  ab5tract++ for nudging!		 16:16
rakudo/main: 2b2e896b0b | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod
Be a little more restrictive in adding "element of"

Especially handy when dealing with N-dimensional arrays		 16:40
rakudo/main: 184c2ec218 | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod
Fix dd behaviour on Nil values
 16:57
ab5tract did something get broken wrt FIRST in RakuAST? 16:59
lizmat you mean recently after work you've done on it ? 17:00
ab5tract m: Q| dd my $f = FIRST ($ = 9)++ |.AST.EVAL
camelia Mu $f = (VMNull without .raku or .perl method)
lizmat bisectable6: old=2022.12 Q| dd my $f = FIRST ($ = 9)++ |.AST.EVAL
bisectable6 lizmat, Bisecting by exit code (old=2022.12 new=2b2e896). Old exit code: 1
lizmat, (2023-03-01) github.com/rakudo/rakudo/commit/97...15b050cecd 17:02
lizmat, bisect log: gist.github.com/b53f2ffe724ac954db...159385f1fd
lizmat bisectable6: old=2023.12 Q| dd my $f = FIRST ($ = 9)++ |.AST.EVAL 17:03
bisectable6 lizmat, Bisecting by output (old=2023.12 new=2b2e896) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/7bfaa292e5d73c1c9e...392de99eb7
lizmat, (2023-12-27) github.com/rakudo/rakudo/commit/57...839cc1981a
ab5tract well, that's really weird 17:04
m: Q| dd my $f = FIRST ($ = 9) |.AST.EVAL
camelia Mu $f = (VMNull without .raku or .perl method)
ab5tract i don't think I would have claimed this was working if I hadn't, you know, gotten it working :/
lizmat m: Q| { dd my $f = FIRST ($ = 9) }() |.AST.EVAL 17:05
camelia Mu $f = 9
lizmat doesn't work in the outer scope, apparenntly
ab5tract phew
lizmat I wonder if an easy fix would be to replace a FIRST phaser in the compunit with an ENTER phaser 17:21
ab5tract: ^^
ab5tract hmm 17:22
lizmat m: say ENTER 42 17:24
camelia 42
ab5tract for reference, I'm poking at R#1684 17:36
linkable6 R#1684 [open]: github.com/rakudo/rakudo/issues/1684 once doesn't work in C-style loop conditional
ab5tract and getting quite strange results
lizmat I'm not surprised: "once" has gone through quite a few changes and name changes
[Coke] we've had a change recently that did something to once vs. FIRST, no? 17:37
lizmat now that we have FIRST for all scopes in RakuAST, I have half a mind to deprecate "once"
I mean. it's really a phaser, so should be all UPPERCASE (and at some point, it actually was) 17:38
ab5tract yeah, it would make sense 17:39
unfortunately, the weird results I'm getting are for FIRST and ENTER
ohhh
both of those phasers fire prior to variable setup 17:40
so `$i < (FIRST ++$end)` was evaluating to 1, because `my $end = 9;` hadn't actually happened yet 17:42
[Coke] ... you mean it went. *lowers shades* FIRST? 17:43
ab5tract it did indeed :) 17:44
but you might expect to get an undeclared variable error in this instance 17:45
s/you/a user/ 17:46
m: enum BatchCategory(:Label(11), :Issue(222)); sub MAIN(BatchCategory $c) { dd :$c, +$c }; @*ARGS = "Label" 18:29
camelia Usage:
<tmp> <c>
ab5tract m: enum BatchCategory(:Label(11), :Issue(222)); sub MAIN(BatchCategory $c) { dd :$c, +$c }; @*ARGS = "Label" 18:30
camelia Usage:
<tmp> <c>
ab5tract m: enum BatchCategory(:Label(11), :Issue(222)); sub MAIN(BatchCategory $c) { dd :$c, +$c }; @*ARGS = "Issue"
camelia 222
ab5tract what the heck?
lizmat dd ignores nameds 18:31
m: my $c = 42; dd :$c
camelia :c(42)
lizmat huh?
hmmm
m: my $c = 42; dd :$c, 666
camelia 666
lizmat unless it's the only one, right
ab5tract not an issue with dd at all, thankfully 18:32
the what the heck is why we get a Usage for "Label" but the body runs for "Issue"
I thought it could somehow be related to enum values starting from 0 by default, but changing that doesn't fix it 18:33
lizmat I recall there being quite a bit of convoluted code to handle enums in MAIN
ab5tract interesting,..
let's see if I can fix two MAIN bugs in 30 days :) 18:34
lizmat ++ab5tract
ab5tract m: dd :class-how(::("Label").HOW); { my enum BatchCategory(:Label(11), :Issue(222)); dd Metamodel::EnumHOW.ACCEPTS(::("Label").HOW); dd :how(::("Label").HOW) } 19:06
camelia :class-how(Perl6::Metamodel::ClassHOW.new)
Bool::True
:how(Perl6::Metamodel::EnumHOW.new)
ab5tract but when main is checking things out, `::("Label").HOW` is always the ClassHOW version 19:08
19:13 lizmat left, lizmat joined 19:15 Altai-man joined 19:16 greenfork left, patrickb left, greenfork joined 19:21 gfldex left, Geth left
lizmat . 19:22
19:22 Geth joined
ab5tract so... is that even remotely fixable? 19:28
m: { our enum BatchCategory(:Label(11), :Issue(222)); }; dd :label-how(::("Label").HOW); dd :enum-how(::("Issue").HOW) 19:30
camelia :label-how(Perl6::Metamodel::ClassHOW.new)
:enum-how(Perl6::Metamodel::EnumHOW.new)
ab5tract is there a way to ask `::()` to keep searching? 19:31
lizmat vrurg might know
19:31 gfldex joined
vrurg ab5tract: what do you mean by "keep searching"? 19:39
ab5tract the enum values are in scope 19:40
but `::()` pulls up the class
vrurg It picks up the first symbol found. 19:41
ab5tract so that's what I mean by keep searching ;)
vrurg But should it skip the symbol to which, most likely, the key would resolve if used literally? 19:42
m: { our enum BatchCategory(:Label(11), :Issue(222)); }; dd :label-how(LEXICAL::("Label").HOW); dd :enum-how(::("Issue").HOW) 19:43
camelia :label-how(Perl6::Metamodel::ClassHOW.new)
:enum-how(Perl6::Metamodel::EnumHOW.new)
vrurg m: { our enum BatchCategory(:Label(11), :Issue(222)); }; dd :label-how(LEXICAL::("Label").HOW); dd :enum-how(::("Issue").HOW); say Label.HOW.^name; 19:44
camelia :label-how(Perl6::Metamodel::ClassHOW.new)
Perl6::Metamodel::ClassHOW
:enum-how(Perl6::Metamodel::EnumHOW.new)
vrurg m: { our enum BatchCategory(:Label(11), :Issue(222)); }; dd :label-how(LEXICAL::("Label").HOW); dd :enum-how(::("Issue").HOW); note Label.HOW.^name;
camelia :label-how(Perl6::Metamodel::ClassHOW.new)
:enum-how(Perl6::Metamodel::EnumHOW.new)
Perl6::Metamodel::ClassHOW
vrurg So, it's consistent behavior.
ab5tract How is that consistent? It should resolve to the user-provided type, like we always do 19:49
vrurg Do you see the note at the end? Label variant is not available lexically. 19:50
ab5tract No, what I see is tht it is not *resolved* lexicallu 19:51
the other enum value is clearly available lexically
vrurg m: { our enum BatchCategory(:Label(11), :Issue(222)); }; dd :label-how(LEXICAL::("Label").HOW); dd :enum-how(::("Issue").HOW); note LEXICAL::<Issue>.HOW.^name;
camelia :label-how(Perl6::Metamodel::ClassHOW.new)
:enum-how(Perl6::Metamodel::EnumHOW.new)
Perl6::Metamodel::ClassHOW
vrurg m: { our enum BatchCategory(:Label(11), :Issue(222)); }; dd :label-how(LEXICAL::("Label").HOW); dd :enum-how(::("Issue").HOW); note LEXICAL::<Issue>;
camelia :label-how(Perl6::Metamodel::ClassHOW.new)
:enum-how(Perl6::Metamodel::EnumHOW.new)
Nil
vrurg m: { our enum BatchCategory(:Label(11), :Issue(222)); }; dd :label-how(LEXICAL::("Label").HOW); dd :enum-how(::("Issue").HOW); dd LEXICAL::<Issue>;
camelia :label-how(Perl6::Metamodel::ClassHOW.new)
:enum-how(Perl6::Metamodel::EnumHOW.new)
Nil
ab5tract are you missing the `dd :enum-how(::("Issue").HOW)` in the middle? 19:52
vrurg As you can see, variants are not lexically available.
m: { our enum BatchCategory(:Label(11), :Issue(222)); }; dd :label-how(LEXICAL::("Label").HOW); dd :enum-how(::("Issue").HOW); dd LEXICAL::<BatchCategory>;
camelia :label-how(Perl6::Metamodel::ClassHOW.new)
:enum-how(Perl6::Metamodel::EnumHOW.new)
Nil
vrurg m: { our enum BatchCategory(:Label(11), :Issue(222)); }; dd :label-how(LEXICAL::("Label").HOW); dd :enum-how(::("Issue").HOW); dd MY::<BatchCategory>; 19:53
camelia :label-how(Perl6::Metamodel::ClassHOW.new)
:enum-how(Perl6::Metamodel::EnumHOW.new)
Nil
ab5tract I guess I'm not clear on why LEXICAL or MY are relevant to the underlying question of having `::()` go past the first resolution 19:56
`::()` can clearly find `Issue`, so it ought to be able to access `Label` 19:57
vrurg It finds 'Issue' because there is no other symbol with this name. I forgot, what `::` resolves into, but it determines what search chain is used. 19:58
ab5tract Yes, the fact that there is a class named `Label` is quite clearly the reason why `::("Label")` doesn't resolve to the enum... that's why I'm asking whether it is possible to not have it behave so single-mindedly 20:00
it's not that it can't find the enum version, it's that it stops at the first one it finds. 20:02
vrurg The answer somewhere in core.c/operators.rakumod, INDIRECT_NAME_LOOKUP. My point is that if there is a bug in it then it's to be fixed. But the principle "first found is the answer" must not change or it's a way to multiple WATs of even worse kind. 20:03
Let's put it this what: if it's not the first one found then which one should we stop at? 20:04
Second? Third? Last?
I think the problem is that the default lookup order is lexical and then, if nothing found, we fall back to the GLOBAL. This is where the enums are installed. But lexical resolves all the way to the outsermost CORE setting – and, thus, anything found in there wins. 20:06
ab5tract I never mentioned changing anything about what it should "stop" at, but since you asked, in an ideal world of my own design it would probably never return a core type over a user-defined type 20:07
that's *not* a suggestion that we should change it to behave that way at this point :) 20:08
vrurg I would just add to it: "if user-defined is in lexical scope". The current problem is that `GLOBAL` isn't considered as lexical. Basically, if you look at INDIRECT_SYMBOL_LOOKUP, you'd find that first resolved are lexically imported syms (`require`), then PseudoStash (lexical), then GLOBAL. 20:09
ab5tract m: { our enum BatchCategory(:Label(11), :Issue(222)); }; dd :label-how(GLOBAL::("Label").HOW); dd :enum-how(GLOBAL::("Issue").HOW) 20:10
camelia :label-how(Perl6::Metamodel::EnumHOW.new)
:enum-how(Perl6::Metamodel::EnumHOW.new)
ab5tract well there's the trick 20:11
vrurg I'm afraid, that changing this order may break a lot of code around for 6.c/d. But we can do it differently in 6.e. But it would require in-depth investigation as to what exactly ends up in GLOBAL and how it might interact with the core.
ab5tract thanks vrurg
vrurg In my view, it looks reasonable if GLOBAL would sit somewhere in the middle of the actual lexical space of the current compunit and the CORE. 20:12
ab5tract makes sense to me
vrurg Welcome! :) But I'm off to the work again. 20:13
ab5tract cheers!
for now, this appears to do the trick `::(a) === CORE::(a) && GLOBAL::(a) !=== CORE::(a) ?? GLOBAL::(a) !! ::(a)` 20:22
Geth rakudo/main: e3ad75a691 | ab5tract++ | src/core.c/Main.rakumod
Allow the use of enum values in MAIN that shadow core types

The issue previously is that we would allow users to create enums with values that overlap with types defined in CORE, but then when they would try to pass these values as arguments to MAIN, it would fail and print the usage string. ... (8 more lines)		 20:37
20:39 Altai-man left, sena_kun joined
ab5tract lizmat: `not ok 1 - Failures don't get marked as handled in &dd` from `/02-rakudo/dd.t` 20:51
20:53 finanalyst left
ab5tract now I'm stuck wondering how to determing if an enum is "the" enum or "an" enum value 🙃 20:54
resolved 21:06
Geth rakudo/main: f521883488 | ab5tract++ | src/core.c/Main.rakumod
Address a few details regarding enums in MAIN

Ensure that there are no un-resolved Failures due to looking up non-existent enums/types.
And reinstate the constraint that passing in the enum
  "itself" (as opposed to a value) will not pass the
MAIN call.		 21:12
roast: 6aaf1591ee | ab5tract++ | S06-other/main.t
Add test for the shadowing of CORE types by an enum used by MAIN
 21:13
21:57 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!