|
🦋 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. |
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 | ||
|
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 |
13:01 | |
| 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 |
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 | ||
|
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. |
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 | ||
|
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
|
|||