|
🦋 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. |
|||
|
00:00
reportable6 left
00:01
reportable6 joined
01:01
lizmat left
06:00
reportable6 left,
reportable6 joined
08:25
sena_kun joined
08:39
lizmat joined
|
|||
| ab5tract | The USAGE fix seems trivial, which makes me feel suspicious that I’m overlooking something.. | 09:39 | |
| lizmat | FWIW, looks like a nice and correct hack to me | 11:00 | |
| ab5tract | i wonder about the missing deprecation message.. it almost feels like USAGE and GENERATE-USAGE could live side by side without issue | 11:26 | |
| lizmat | perhaps that's why the deprecation message was never added | ||
| ab5tract | could be :) | 11:44 | |
| then I won't worry about it now | |||
|
12:00
reportable6 left
12:01
reportable6 joined
|
|||
| ab5tract | huh. the merge wasn't announced .. | 12:02 | |
|
12:05
sena_kun left
|
|||
| ab5tract | nine: so it sounds like jnthn thinks the the cuuid as uint32 story could bear fruit. lizmat mentioned that Inline::Perl5 would need to be revised. I'd be willing to pick that work up, assuming that it doesn't require something like a full rewrite. | 13:10 | |
|
13:11
Geth joined
|
|||
| Geth | rakudo/supply-exit-status-for-usage: a2af93feae | ab5tract++ | src/core.c/Main.rakumod Provide conditional exit status for USAGE Even though it's an older approach, it is trivial to provide `USAGE` the same exit code logic as for `GENERATE-USAGE`: If a `--help` is part of the invocation, exit 0. Otherwise, exit 2. Addresses R#5514 (#5514). |
13:12 | |
| linkable6 | R#5514 [closed]: github.com/rakudo/rakudo/issues/5514 [CLI] Bug: Command-line interface generator exits with success code 0 even when you pass random jibberish in the arguments | ||
|
13:13
linkable6_ left,
linkable6_ joined
|
|||
| Geth | rakudo/main: a4c7d5d193 | ab5tract++ | src/core.c/Main.rakumod Provide conditional exit status for USAGE Even though it's an older approach, it is trivial to provide `USAGE` the same exit code logic as for `GENERATE-USAGE`: If a `--help` is part of the invocation, exit 0. Otherwise, exit 2. Addresses R#5514 (#5514). |
13:14 | |
| linkable6 | R#5514 [closed]: github.com/rakudo/rakudo/issues/5514 [CLI] Bug: Command-line interface generator exits with success code 0 even when you pass random jibberish in the arguments | ||
| lizmat | manual re-deliveries | 13:15 | |
|
13:15
linkable6_ left
13:18
linkable6_ joined
18:00
reportable6 left
18:02
reportable6 joined
|
|||
| nine | ab5tract: Inline::Perl5 exports an INIT phaser to the importing module. For that we need a cuid that has not been taken yet. I used a random 128 bit number as that gives you practically 0 chance of collision. | 18:06 | |
| ab5tract | Hmmm | 18:07 | |
| I see it also uses $*W | 18:13 | ||
| In the slang at least | 18:14 | ||
| Ah, in fact the code in question uses $*W | 18:21 | ||
| Would a rakuast based solution have this issue? | 18:23 | ||
| nine | Depends on what the way to inject an INIT phaser would look like with RakuAST | 18:48 | |
| ab5tract | fair enough | 18:57 | |
| feels like there should be some possibility of reserving a cuid | 19:05 | ||
| which layer hands out the cuid anyway? I would expect the VM to be in charge of that but the majority of the references are related to heapsnapshot and nativecall/ffi | 19:10 | ||
| the remaining hits seem to be about the `getcodecuid` op, which is a post-hoc thing | 19:11 | ||
| does every frame get one of these? my impression was that they are QAST-level | 19:12 | ||
| nine | They are generated by QAST::Block itslf | 19:32 | |
| ab5tract | Ah, that’s clear now, thanks! | 19:47 | |
| So, if they are sourced incrementally, wouldn’t just assigning max_uint128 be even safer than rolling the dice? | 19:49 | ||
| Oh, duh | 19:52 | ||
| :) | |||
| Still, something could maybe be rigged similar to the QAST::Block generator, but assigning decrementally from max instead of incrementally from 0 | 19:54 | ||
| nine | No, that would be way worse. | 20:17 | |
| ab5tract | I believe you, but I'd like to know why :) | 20:18 | |
| nine | First of all there is no "safer than random 128 bit number" at least assuming your PRNG is somewhat decent. a 1/2**128 chance is for all intents and purposes 0. 2**128 is such a mind boggingly enormous number that we have no intuition at all. 1/2**128 is safe. No one will ever get a collission from that. | 20:20 | |
| When you replace that with a seemingly safer option like counting from the top, then you are actually running the risk of someone else having the very same "clever" idea. And indeed, it's a quite obvious one, so that will happen. Now if 2 modules try to install INIT phasers on the same target using the same method for determining cuids, you'll get the exact outcome you tried to avoid. | 20:22 | ||
| With non-cooperating generators, random numbers are just the safe option. Of course if you have a central source that everyone can use that avoids the whole problem. | 20:24 | ||
| But actually modules shouldn't need to worry about these cuids in the first place. So the mechanism how modules may export these phasers should take care of this detail. | 20:25 | ||
| ab5tract | that all makes a lot of sense | 20:27 | |
| IIUC, the reason why we can't just use `QAST::Block.next-cuid` in place of generating the random number is that this cuid would be generated relative to the declaring scope, rather than being generated in the intended scope of the module the INIT is being installed into | 20:32 | ||
| to throw out another wild/"clever" idea, could we fix this by wrapping `QAST::Block.next-cuid` in a `gather/take`? | 20:34 | ||
| Let me rephrase -- as I expect its more about "when" than "where" -- so rather than scope, the issue as I understand it is that it would be generated at installation time, rather than at INIT time as intended | 20:37 | ||
|
21:47
sena_kun joined
|
|||
| Geth | nqp/getnextcuid: 2de4717787 | ab5tract++ | 2 files Add nqp::getnextcuid This is a mechanism for HLLs to rationally supply CUIDs at runtime without fear of collision. |
23:06 | |
|
23:08
Altai-man joined
23:12
sena_kun left
|
|||
| ab5tract | Both github.com/ab5tract/Inline-Perl5/c...0a348059d6 (regular) and github.com/ab5tract/Inline-Perl5/c...7a8c1d5bd1 (probably overly protective lazy gather/take approach) | 23:13 | |
| *Both pass Inline::Perl5 tests | 23:14 | ||
| on another note, my weekend long project of completing a local blin run accomplished is finally over. | 23:17 | ||
|
23:44
Altai-man left
|
|||
| [Coke] | ab5tract: what OS? | 23:57 | |
| ab5tract | For blin? macOS using podman to run a Dockerfile to run arm64 Debian | 23:59 | |