🦋 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.
00:02 reportable6 left 01:02 releasable6 left, bloatable6 left, greppable6 left, sourceable6 left, committable6 left, benchable6 left, squashable6 left, tellable6 left, bisectable6 left, coverable6 left, nativecallable6 left, unicodable6 left, shareable6 left, notable6 left, evalable6 left, linkable6 left, statisfiable6 left, quotable6 left 01:03 greppable6 joined, bisectable6 joined, notable6 joined, statisfiable6 joined 01:04 releasable6 joined 01:05 nativecallable6 joined, quotable6 joined, bloatable6 joined, squashable6 joined, shareable6 joined 02:03 reportable6 joined 02:04 coverable6 joined, benchable6 joined, evalable6 joined 02:05 unicodable6 joined 02:50 Util_ left 04:04 committable6 joined 05:03 tellable6 joined 05:36 frost joined 06:02 reportable6 left 06:03 sourceable6 joined 06:04 linkable6 joined 07:01 dogbert17 joined 07:02 dogbert11 left 07:27 dogbert11 joined 07:30 dogbert17 left
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.
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"
09:20 dogbert17 joined 09:23 dogbert11 left, dogbert11 joined 09:26 dogbert17 left 09:28 dogbert17 joined 09:30 dogbert11 left 09:38 dogbert11 joined 09:41 dogbert17 left 09:57 dogbert17 joined, dogbert11 left 11:03 reportable6 joined 11:06 Xliff joined 11:14 cognominal joined 11:16 cognominal_ left 11:22 Kaiepi joined 12:02 reportable6 left 12:56 MasterDuke left 12:59 cognominal left
Geth rakudo/new-disp: af7df6118c | (Jonathan Worthington)++ | 3 files
Always give VM code handle to setparameterizer
rakudo/new-disp: 3f2218b28d | (Jonathan Worthington)++ | src/core.c/Thread.pm6
Always give VM code handle to newthread
13:25 frost left 13:27 cognominal joined
Geth rakudo/new-disp: 751a076d9a | (Jonathan Worthington)++ | 4 files
Always give continuation ops VM code handles
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.
16:05 reportable6 joined 16:26 melezhik joined 16:58 melezhik left, dogbert11 joined 17:00 dogbert17 left
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.
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.
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:15 b2gills1 left 17:16 b2gills joined 18:02 reportable6 left 18:03 reportable6 joined 18:12 dogbert11 left, dogbert11 joined 18:22 dogbert17 joined, dogbert11 left 18:34 dogbert11 joined 18:36 dogbert17 left 18:51 dogbert11 left 18:58 dogbert11 joined 19:16 melezhik joined 19:23 TempIRCLogger left, TempIRCLogger joined 19:25 melezhik left 19:34 TempIRCLogger left 19:35 TempIRCLogger joined
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
20:44 melezhik joined
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
20:52 TempIRCLogger left, TempIRCLogger joined
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
21:52 evalable6 left, linkable6 left 21:55 linkable6 joined 21:56 melezhik left 22:42 jgaz joined
lizmat tonyo_: no, I just moved IRC::Client out of community modules :-) 22:45
22:52 evalable6 joined 22:58 jgaz left 23:02 squashable6 left 23:04 squashable6 joined