|
🦋 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. |
|||
|
09:06
finanalyst joined
13:05
finanalyst left
|
|||
| tbrowder | lizmat: i have some more changes for Pod::TreeWalker. i have pushed them to MY github account and they are ready to submit as a PR to raku-community modules. is *does* have the correct "source-url" in the dist.ini file. how shall i proceed? (last chg was a bit confusing because i tried an update during the process) | 13:09 | |
| *it does | 13:11 | ||
| ugexe | .tell finanalyst a new method is fine too if that is was i originally recommended. a provides-docs (not doc-provides since the meta/distribution data is providing doc data). then CURI.install(...) needs to understand that provides-docs field and data and then place all the files where they need to go, rename them, precompile them, etc. in other words the heavy lifting is done in rakudo, not zef. | 13:51 | |
| tellable6 | ugexe, I'll pass your message to finanalyst | ||
| ugexe | i'm not sure if much of anything would need to change in zef | ||
| lizmat | create a PR I'd say | ||
| tbrowder | i'll do that again in a few minutes | 14:00 | |
| ugexe | .tell Xliff no there are no hooks (anymore... there were hooks like literally 10 years ago for a short time). reason being is no one has thought up a generalized spec that doesn't work for some very specific workflows only. the one i originally wrote was just having files like hooks/ but such a naive approach is ripe for misuse (such as where we are with Build.rakumod), and won't actually work | ||
| tellable6 | ugexe, I'll pass your message to Xliff | ||
| ugexe | the way people expect in many situations (similar to how people become confused when they spawn processes from their tests, and wonder why those processes don't see some of the dependencies that are staged but not installed) | ||
| even if there was a post install hook, I'm not sure that zef would be the place for it instead of CURI.install(...) | 14:02 | ||
| tbrowder | ok, pr is there awaiting review and merge. if no objection, i'll merge it myself in a day or two | 14:07 | |
| lizmat | tbrowder: link, for convenience ? | 14:21 | |
| nine | Post install hook is a bad idea in general. Usually there are just better solutions for the use cases that people want them for. | 14:31 | |
| We should (and so far tried to) really learn from the lessons that distro package managers learned the hard way. All of them introduced such hook and later switched to discouraging their use. | 14:32 | ||
|
14:34
sjm_ joined
|
|||
| tbrowder | pr link is github.com/raku-community-modules/...er/pull/11 | 14:47 | |
| afk& | 14:48 | ||
| timo | what xliff is looking for i think is a spot to call an optimized pre-compilation routine that goes through stuff in parallel instead of serially - glib and related libraries are very parallelizable for their precomp | 15:09 | |
| but just having a script that first runs zef --/install-precomp and then precomps the things won't help someone who just uses "zef install GLib" which will still be slow as molasses | |||
| [Coke] | "doing things in parallel" seems a nice default if we can manage it | 15:12 | |
| timo | gotta be careful about memory usage though | 15:16 | |
| memory usage needed for compilation is extremely unpredictable, i'd reckon. especially if your module does anything nontrivial at BEGIN time | 15:22 | ||
|
15:52
sjm_ left
16:27
vrurg left
16:28
vrurg joined
17:12
vrurg left
17:13
vrurg joined
|
|||
| timo | though we could throw an env var at it :) | 17:51 | |
| nine | So, yep, use case with a better solution waiting | 17:53 | |
|
22:52
librasteve_ left
23:53
sivoais_ left,
sivoais joined
23:57
jdv left
|
|||