🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
Geth rakudo: 9681a0932d | (Stefan Seifert)++ | t/06-telemetry/01-basic.t
Support ROAST_TIMING_SCALE in telemetry tests

The telemetry tests sometimes fail due to timing issues on loaded machines.		 07:39
rakudo: c0a6823b0c | (Stefan Seifert)++ | t/06-telemetry/01-basic.t
Fix false positive in basic telemetry test

It's possible (especially with ROAST_TIMING_SCALE) that Telemetry takes multiple snapshots while we give it time to do at least one. So adjust the test to expect at least one snapshot to be taken, but be fine with moar than one. This fits the test description of "did the snapper start taking snaps"		 08:08
Geth rakudo/new-disp: af7df6118c | (Jonathan Worthington)++ | 3 files
Always give VM code handle to setparameterizer
 13:01
rakudo/new-disp: 3f2218b28d | (Jonathan Worthington)++ | src/core.c/Thread.pm6
Always give VM code handle to newthread
Geth rakudo/new-disp: 751a076d9a | (Jonathan Worthington)++ | 4 files
Always give continuation ops VM code handles
 13:39
rakudo/new-disp: c539dd33e8 | (Jonathan Worthington)++ | lib/NativeCall.rakumod
Unwrap code handles for native callbacks

This will be reworked in a more efficient way at some future point when we rework native calling in terms of the new dispatch mechanism.		 15:50
Geth rakudo/new-disp: d975805e70 | (Jonathan Worthington)++ | 2 files
Cease setting up invocation_handler on MoarVM

Soon the entire invocation protocol mechanism will go away on MoarVM; this piece already can.		 17:05
rakudo/new-disp: efb091f907 | (Jonathan Worthington)++ | 2 files
Remove legacy multi dispatch caching leftovers

These were only used on MoarVM anyway, so just remove them rather than making them backend-specific.		 17:12
nqp/new-disp: eeb554f44f | (Jonathan Worthington)++ | 2 files
Eliminate setmultispec

Was part of the legacy multiple dispatch caching mechanism, and is no longer in use.		 17:13
gfldex m: my ($a:D) = 1; 19:38
camelia 5===SORRY!5=== Error while compiling <tmp>
Invalid typename 'D' in parameter declaration.
at <tmp>:1
------> 3my ($a:D7⏏5) = 1;
gfldex is that intentional?
m: use variables :D; my ($a) = 1; 19:39
camelia ( no output )
gfldex m: use variables :D; my ($a) = Any;
camelia Type check failed in assignment to $a; expected Any:D but got Any (Any) (perhaps Nil was assigned to a :D which had no default?)
in block <unit> at <tmp> line 1
gfldex Well, that's a useful workaround. 19:40
lizmat tonyo_ ugexe so what would be the best way to introduce my updated version of IRC::Client (with an appropriate auth and version) in such a way that people would have to opt-in to using it, and not break anybody trying to just install "IRC::Client" get an ambiguous specification error ? 20:10
introduce with a lower version ? 20:11
lower than what is now in the ecosystem ?
ugexe a lower api version would work, although youd have to change the existing module to api:1 and use api:0 for the new one 20:12
would also work^
lizmat no, the API is the same
so switching API would not make much sense? 20:13
I mean, i *think* it is a drop-in replacement, but since there aren't really any tests, I'd like people to opt-in for the new version
ugexe if the api is the same switching the version doesnt make much sense either. in the end these are just tools 20:16
lizmat thing is, IRC::Client is without auth in the ecosystem atm 20:18
I think we need to add an auth 20:19
ugexe: so you're saying: just bite the bullet and upload a higher versioned version to the ecosystem (e.g. fez) ?
ugexe well you cant really opt-in to something just on the zef side, it has to be on the raku side as well i.e. "use Foo:auth<...>:` 20:23
so yes that is probably what i would do
to be clear you could install Foo:auth<...> via zef, but that doesnt help with any potentially already installed Foo:auth<> or if it was installed before or after 20:24
opting in would look something like telling users to use `use IRC::Client:auth<myauth>` in their code in addition to `zef install "IRC::Client:auth<myauth>"` 20:27
such an opt-in workflow could probably be improved with like superceded-by or emulates 20:30
which are NYI for anyone following along
lizmat but if there's an IRC::Client (no auth) and IRC::Client:auth<fez:lizmat> in the ecosystem 20:32
what would happen if you do a "zef install IRC::Client" 20:33
tonyo_ depends on api and versions 20:36
it wouldn't be bad to start migrating that stuff away from p6c
lizmat well, this is a trial case for sure :-) 20:37
I mean, a module relatively upstream
lizmat ok, I think I'll upload the new IRC::Client with an auth and a higher version number to fez tomorrow, when I'm less tired 20:50
lizmat afk& 20:53
tonyo_ i'm testing org creation on fez atm lizmat so if you want to move that into community modules then you may want to wait a few 21:11
lizmat tonyo_: no, I just moved IRC::Client out of community modules :-) 22:45

Powered by Cro and the Raku® Programming Language.

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

Thank you!