🦋 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. |
|||
releasable6 | Next release in ≈6 days and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 03:00 | |
Geth | rakudo/remove-types-specification-by-name-in-parameter-constructor: 3216812a2f | (Stefan Seifert)++ | src/core.c/Parameter.rakumod Remove type specification by name in Parameter constructor The Parameter constructor has a "type" argument that besides type objects also accepts concrete values. In moste cases it used that value's type but if the value was a string, it instead checked whether that string might be a type name and looked up that type instead. ... (8 more lines) |
08:19 | |
rakudo: niner++ created pull request #5877: Remove type specification by name in Parameter constructor |
|||
08:53
lizmat joined
09:10
lizmat left
|
|||
Geth | rakudo/remove-types-specification-by-name-in-parameter-constructor: 11be008b9d | (Stefan Seifert)++ | src/core.c/Parameter.rakumod Remove type specification by name in Parameter constructor The Parameter constructor has a "type" argument that besides type objects also accepts concrete values. In most cases it uses that value's type but if the value is a string, it instead checks whether that string might be a type name and looks up that type instead. ... (8 more lines) |
09:46 | |
rakudo/main: 11be008b9d | (Stefan Seifert)++ | src/core.c/Parameter.rakumod Remove type specification by name in Parameter constructor The Parameter constructor has a "type" argument that besides type objects also accepts concrete values. In most cases it uses that value's type but if the value is a string, it instead checks whether that string might be a type name and looks up that type instead. ... (8 more lines) |
|||
rakudo/main: a82696a1af | niner++ (committed using GitHub Web editor) | src/core.c/Parameter.rakumod Merge pull request #5877 from rakudo/remove-types-specification-by-name-in-parameter-constructor Remove type specification by name in Parameter constructor |
|||
nine | lizmat: thanks for the quick review :) | ||
tellable6 | nine, I'll pass your message to lizmat | ||
ab5tract | so …does MAIN somehow override that GLOBAL points to? | 11:26 | |
nine | ab5tract: PseudoStash is the word for those pseudo packages | 11:41 | |
ab5tract | Ah! Right, now I remember | 11:42 | |
It’s just really confusing because the runtime details appear exactly the same between the “in scope” and the imported versions | 11:43 | ||
Except that when the thevalue sub is called for the import version, GLOBAL::(a) resolves to Nil | 11:44 | ||
nine | Because module loading tries to be as lexical as possible | 11:45 | |
ab5tract | But importing should bring it into GLOBAL | ||
I sent a few things to camellia last night showing that was the cas | 11:46 | ||
nine | That wouldn't be very lexical :) | ||
m: module Test {}; say GLOBAL::.keys | |||
camelia | (Test) | ||
nine | m: use Test; say GLOBAL::.keys | 11:47 | |
camelia | () | ||
ab5tract | m: package P { enum E is export <f g> }; import P; dd GLOBAL::(f), ::(f) | ||
camelia | Failure.new(exception => X::NoSuchSymbol.new(symbol => "GLOBAL::f")) E::f |
||
ab5tract | Hmm, now I’m even more confused | 11:48 | |
nine | m: package P { enum E is export <f g> }; import P; dd GLOBAL::(f), ::(f) | ||
camelia | Failure.new(exception => X::NoSuchSymbol.new(symbol => "GLOBAL::f")) E::f |
||
nine | m: package P { enum E is export <f g> }; dd GLOBAL::(f), ::(f) | ||
camelia | ===SORRY!=== Error while compiling <tmp> Undeclared routine: f used at lines 1, 1 |
||
ab5tract | Anyway, it doesn’t pick it up in global and it doesn’t pick it up with the lexy ::() | ||
(In thevalue, I mean) | |||
I am just tapping on my phone at the moment but will try to provide a usable paste for it | 11:49 | ||
nine | m: use Test; say MY::.keys | 11:53 | |
camelia | (&lives-ok &diag $=finish &fails-like &MONKEY-SEE-NO-EVAL !UNIT_MARKER Test &skip-rest &plan &use-ok &throws-like &unlike &nok $/ $?LANGUAGE-REVISION &is-deeply &isa-ok &bail-out &eval-dies-ok &is $¢ &subtest &trait_mod:<is> GLOBALish &does-ok &dies-… | ||
ab5tract | nine: things are working as expected in the non-import case, but if you put in some print debugging into ‘thevalue’ you will find that ::(a) resolves to Nil, so it’s only picking it up from GLOBAL | 12:06 | |
I would expect the lexical lookup to also succeed | |||
s/lookup/psuedostash/ | |||
R#5875 | 12:07 | ||
linkable6 | R#5875 [open]: github.com/rakudo/rakudo/issues/5875 [good first issue][enumerations][objects] Success in enum resolution during &MAIN invocation depends on declaration scope of the enum. | ||
nine | m: package P { enum E is export <f g> }; import P; dd ::(f) | 12:25 | |
camelia | E::f | ||
nine | A lexical lookup apparently does succeed? | ||
ab5tract | nine: not in ‘thevalue’ it doesn’t | 12:29 | |
Neither for enums imported nor directly declared within the current scope | 12:30 | ||
nine | And why would it? How would those enum values appear in the lexical scope of a sub defined in src/core.c/operators.rakumod? | ||
The whole point of lexical scoping is to avoid the mess such magical name appearing would create :) | |||
ab5tract | Because the lookup is lexical and runtime | 12:31 | |
nine | lexical *where* | ||
ab5tract | The snippet you just shared should be exactly the same | ||
Ie, an imported enum should be usable in a signature for MAIn | |||
nine | Look at github.com/rakudo/rakudo/blob/main...rs.rakumod | 12:32 | |
How would those enum values appear in that file if they are not imported into that file? | 12:33 | ||
ab5tract | Why am I looking at operators? | ||
The subject is MAIN | |||
nine | Ah, sorry, github.com/rakudo/rakudo/blob/main...in.rakumod | ||
ab5tract | What’s the point of psuedostashea at all if they don’t allow for this kind of thing? | 12:35 | |
And before we discuss further, is your position that MAiN signatures shouldn’t be able to use imported enums? | |||
Why then can I used imported classes? | 12:36 | ||
nine | The ::(a) can find e.g. core-a, the-value, default-args-to-capture, RUN-MAIN and thanks to the setting being all those core files concatenated, also every top level name in the setting. | ||
Because those are in the lookup's lexical scope. | |||
A enum or any other name imported into a completely different scope is not in that lexical scope, so those cannot be found that way. | 12:37 | ||
ab5tract | Except this only affects enums | ||
You can totally do “use Foo; sub MAIN(Foo $f) | 12:38 | ||
(I say confidently without directly testing 😅) | 12:39 | ||
I recall it working, anyway | 12:40 | ||
nine | > rakudo -Ilib -e 'use Foo; sub MAIN(Foo $a) { }' 1 | 12:41 | |
Usage: -e '...' <a> | |||
With a class Foo is Int { } | |||
ab5tract | Well shucks | 12:42 | |
This feels unfortunately brittle | |||
But also apparently not so much of an issue that we had tickets about it prior to this ticket | 12:43 | ||
nine | Probably because the things you can reasonably expect to get on the command line are numbers, strings and if you stretch it enums. | 12:44 | |
ab5tract | Right | ||
But one could also reasonably stash some subset deflations in a separate package | 12:45 | ||
*definitions | |||
nine | true | ||
Anyway, the core of the issues really seems to be that that lookup written like that cannot work as intended. | 12:46 | ||
ab5tract | So… is this remotely fixable? Or do we somehow try to fix the LTA of the current situation with some targeted error? (Producing the error would probably require more or less the same solution as fixing the problem..) | ||
Well the current code did fix some edge case or another, though I can’t recall which atm | 12:47 | ||
nine | Sure. The lookup needs to be done on the actually interesting scope | ||
ab5tract | You make it sound so easy :P | 12:49 | |
Can we pass psuedostashes as parameters? So I could send the right LEXICAL all the way down to thevalue? | 12:50 | ||
nine | docs.raku.org/language/packages#Pseudo-packages | ||
PseudoStash is just an object | 12:51 | ||
ab5tract | Oooo | ||
CLIENT | |||
sounds reasonable | |||
nine | m: sub MAIN() { } | 12:52 | |
camelia | ( no output ) | ||
ab5tract | Though MAIN is pretty funky and need not be in a package of its own (maybe that would still meet the right criteria) | ||
nine | In what package is this ^^^ MAIN? | ||
exactly | |||
But I think, you should now quite well what the call stack will look like | 12:53 | ||
ab5tract | So if I do an import outside of a package, these symbols get imported into a pseudostash, right? | ||
nine | Names are imported into a lexical scope | ||
That lexical scope might get accessed via a PseudoStash as that class' implementation contains the necessary low level magic | 12:54 | ||
ab5tract | I think CLIENT might still qualify | ||
Because CALLER refers to lexical scope, not a package | 12:55 | ||
According to the docs anyway | |||
nine | Why are you so interested in some package? | ||
ab5tract | I’m not | 12:59 | |
I’m looking at the list of pauedosatashes for something that would work for MAIN | 13:00 | ||
CLIENT goes up the call chain until you are no longer in Main.Ramiro’s | |||
lol | |||
Main.rakumod | |||
Maybe it would be simpler if you explained what you have in mind for accessing the correct scope | 13:02 | ||
nine | from SETTING::src/core.c/Main.rakumod:78 (/home/nine/rakudo.main/blib/CORE.c.setting.moarvm:thevalue) | 13:05 | |
from SETTING::src/core.c/Main.rakumod:148 (/home/nine/rakudo.main/blib/CORE.c.setting.moarvm:) | |||
from SETTING::src/core.c/Main.rakumod:92 (/home/nine/rakudo.main/blib/CORE.c.setting.moarvm:default-args-to-capture) | |||
from SETTING::src/core.c/Main.rakumod:427 (/home/nine/rakudo.main/blib/CORE.c.setting.moarvm:RUN-MAIN) | |||
from -e:1 (<ephemeral file>:<unit>) | |||
Looks to me like it's about 4 CALLER::s out. So maybe something like CALLER::CALLER::CALLER::CALLER:: | 13:08 | ||
Or rather CALLER::CALLER::CALLER::CALLER::MY:: | 13:09 | ||
ab5tract | trying that now | 13:10 | |
tried CLIENT and it doesn't work | |||
nine | Which can be made less fragile by taking the CALLER::MY:: in RUN-MAIN's top-level and storing it in a lexical that's accessed in thevalue | ||
ab5tract | the fragile variant doesn't work either :( | 13:12 | |
I'll try the RUN-MAIN now | 13:13 | ||
nine | How do you know? | ||
ab5tract | I got my laptop out :) | ||
is callframe(1).my different than CALLER::MY:: ? | |||
grrr. the one time I don't do a full recompile of Rakudo... | 13:16 | ||
so maybe it did work. | |||
checking now | |||
so checking %caller-my{a} works fine! CALLER::CALLER::CALLER::CALLER::MY:: is not | 13:20 | ||
Geth | rakudo/r5875: 7757312e7d | ab5tract++ | src/core.c/Main.rakumod Better commit message coming soon |
13:22 | |
ab5tract | nine: do you reckon that ::(a) was always wrong? or should I do something like try ::(a) // %caller-my{a} ? | 14:01 | |
nine | The former | 14:03 | |
ab5tract | 4 TODOs passing :O | 14:07 | |
I think that must just be noise | |||
nine | That's likely the TODOs added for RakuAST | 14:11 | |
I.e. spec tests that only pass accidentally on the old frontend | 14:12 | ||
ab5tract | ok so interestingly enough, we *do* need to attempt to get ::(a) | 14:15 | |
or else enums don't convert properly | |||
it's above my paygrade to know why :D | 14:16 | ||
... how can a subtest be marked as failing when all of it's component tests are marked passing? 🙃 | 14:18 | ||
.... because I misread the output, naturally | 14:19 | ||
Geth | rakudo/r5875: 020eccdf5b | ab5tract++ | src/core.c/Main.rakumod Allow MAIN args to reference imported names Previously the following was not possible: module M { enum E is export <F G> } import M; sub MAIN (E $f, E :$g) { ... } ... (5 more lines) |
14:26 | |
rakudo: ab5tract++ created pull request #5878: Allow MAIN args to reference imported names |
14:27 | ||
15:35
guifa left
15:39
guifa joined
19:48
MasterDuke joined
|
|||
MasterDuke | m: my $s; my $a; my $b; for ^1_000_000 { $a = rand < 0.5 ?? Int !! 5; $b = rand < 0.5 ?? Int !! 2; $s += $a // $b // -1 }; say now - INIT now; say $s | 20:42 | |
camelia | 1.110254003 2751773 |
||
MasterDuke | m: my $s; my $a; my $b; for ^1_000_000 { $a = rand < 0.5 ?? Int !! 5; $b = rand < 0.5 ?? Int !! 2; $s += $a // ($b // -1) }; say now - INIT now; say $s | ||
camelia | 0.853582615 2748287 |
||
MasterDuke | noticed that from 6guts.wordpress.com/2017/07/02/opt...om-a-file/ | 20:43 | |
looks like there are a couple cases of chained // in rakudo. might be worth investigating if they should be parenthized | 20:45 | ||
ab5tract crosses his fingers in hopes that we have the right knobs now that we can eliminate the performance hit of not parenthesizing | 20:51 | ||
21:21
MasterDuke left
|
|||
ugexe | I wonder if we still need %*ENV<PERL6_PROGRAM_NAME>. it looks like it was originally added by nine almost a decade ago to be used by CURI (although it no longer seems to be used by anything) in github.com/rakudo/rakudo/commit/b5...9811d72ba8 | 21:27 | |
21:29
lizmat joined
|
|||
ugexe | hmmm its used by App::InstallerMaker::WiX - github.com/raku-community-modules/...kumod#L246 | 21:30 | |
Geth | rakudo/main: 28a1cdcafe | ab5tract++ | src/core.c/Main.rakumod Allow MAIN args to reference imported names Previously the following was not possible: module M { enum E is export <F G> } import M; sub MAIN (E $f, E :$g) { ... } ... (5 more lines) |
22:19 | |
releasable6 | Next release in ≈5 days and ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 23:00 |