Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
Set by moderator on 8 April 2016.
MadcapJake nine: I'm not sure I can actually add another CUR without resorting to a hack (writing my own script runner or concat'ing some code on the beginning of scripts). So I think I'll actually need to keep the IPFS repos separate from P6 repos (If there was some way to add/replace CURs from the command line I could avoid needing to keep them separate) 00:18
ugexe: Is it possible to add plugins to zef via an external module? i.e., can I modify the config.json file and add a ContentStorage plugin? If so, I could possibly implement gx as a plugin for zef. 00:20
It looks like I could also implement a Zef::Fetch::GX that runs gx 00:27
02:18 ZoffixWin joined, ZoffixWin left
ugexe MadcapJake: thats the idea. im not sure how well it'll actually work yet, but I can help make it happen 03:29
MadcapJake It looks like I could also implement a Zef::Fetch::GX that runs gx 03:34
oops! 03:35
meant to say, I think this fits that idea well! I will try and whip something up this weekend. Will have a few moving parts (gx-perl6 cli for gx, GX:ContentStorage, and GX::Fetcher) 03:36
ugexe Sweet. I lost my damn phone, so I might not be able to access github till monday (2FA) 03:37
05:24 hankache joined 07:32 hankache_ joined 08:09 domidumont joined
nine MadcapJake: why do you think you can't add a CUR? 08:10
09:43 hankache joined 12:18 hankache joined 12:38 cognominal joined
MadcapJake nine: How would I execute someone's script after changing the repo-chain? 13:07
14:46 camelia joined
nine What do you mean by execute someone's script? 14:56
17:12 jdv79 joined 17:16 domidumont joined
MadcapJake nine: gx downloads and organizes a directory as a filesystem database just like Perl 6 does, so I want to avoid needing a separate store and just write a CUR that searches for sources inside the gx/ipfs directory. I would need to preempt the current repo-chain with a repo that knows how to search through gx's database instead. 17:31
There's no way to do that from the command-line, so I would need to create a wrapper but I can't just do `run('perl6' 'script.pl6') because it will just use the regular $*REPO.repo-chain 17:32
and as far as I can tell, the perl6 script is highly engineered, it would be a mess to try and just duplicate all that only so that I could prepend a CUR on the repo-chain 17:33
I could concatenate my CUR code on the beginning of any script that a user would like to run but then that's going to screw with line numbers in error messages 17:34
maybe I could create a GX module that users would have to do `use GX;` before their modules, and that would integrate my custom CUR into the repo-chain, is that possible? 17:35
ugexe -I"<short id>#path" 17:39
-Iinst#/a/b/c
-Igx#/a/b/c
MadcapJake ugexe: but all the short-codes are hard-coded in rakudo 17:40
ugexe you register them
MadcapJake github.com/rakudo/rakudo/blob/nom/...#L247-L251 17:41
ugexe i believe you're "supposed" to be able to register just like that (but in a BEGIN) 17:42
not that it works right now
MadcapJake ultimately, I want to avoid having users do much more than `use GX` or (LTA) a wrapper script `gx-perl6` 17:45
ugexe altnernatively CUR may just be put into a separate location that is always searched first
right, ive been after similar things
but there is some precompilation stuffs i guess that have to be worked out first
MadcapJake ok, so it's not quite ready for custom CURs then? 17:46
ugexe not in the sense we have in mind. you can do a kinda custom cur like github.com/niner/CompUnit-Reposito.../Panda.pm6 17:47
but stuff like "precompiled with a module from CUR::<default> against CUR::<custom> + when to invalidate" type stuff that i wont pretend to understand
MadcapJake how does that get loaded? 17:48
ugexe its a "kinda" custom cur because i believe its only used for "saving" a module somewhere
MadcapJake ugexe: oh that's neat so you could just place the use line before modules and it will be added then eh?
ugexe github.com/perl6/toolchain-bikeshed/issues/1 17:49
MadcapJake ugexe: right it runs a shell script and then just loops back to the repo-chain
ugexe originally i think it would have been `use cur "SomeCur";`, but yeah
we have the same concept in mind, and i believe ive explained it to nine before such that he understands. its just there is precomp stuff in the way 17:50
MadcapJake nine says in that thread that you lose precomp if you change the $*REPO *after* a module, what if you change it before all modules? then are you still getting precomp? 17:51
ugexe im not sure you can load an external CUR before the other CUR are early loaded
MadcapJake ok so no matter what, some module is being loaded before any use statements in your script
ugexe thats why in that example i use -CCustom::Repo instead of -ICustom::Repo 17:52
MadcapJake I gotcha
ugexe it depends. BEGIN { } can push it earlier
but even if you BEGIN { } to get your use statement loaded earlier, something else might also have a BEGIN that you cant control 17:53
MadcapJake Well hopefully this gets some attention! I'll see what I can muster up following the CU:R:Panda example 17:56
ugexe what you're after might also be doable with `github.com/rakudo/rakudo/pull/729`. It would allow you to create a Distribution that uses network resources to pull whatever "content address" (so My::Module:ver<*>#lib/My/Module.pm6, where sha1(My::Module:ver<*>) is the root instead of the sha1 of the actual content)
that would simply translate it into a CUR::Installation style install though 17:57
so its only half of it 17:58
MadcapJake yeah that would be great! gx-perl6 would store each installed module under a hash of the entire directory (as that's how ipfs does it) but there is a package.json that has short-names mapping to hashes iirc, so it would just involve some translation into the proper path. 18:30
ugexe my Distribution PR has a similar mapping 18:50
it saved it under the meta6.json in dist/ under the `files` key. that key is used currently for the same thing, except it for things in `lib` which are stored in `provides` still 18:51
but the idea with the PR is you can then make a CompUnit::Installation::Distribution (we will call $dist) which you then $dist.content("lib/My/Module.pm6") which translates it to whatever hash, and returns a handle to the content 18:52
for a normal/typical Distribution the mapping of lib/My/Module.pm6 wouldnt have to generate the sha1 hash, but it would still return a handle 18:53
the CUR can create the root/prefix itself (typically $dist.id, so {$dist.id}/lib/My/Module.pm6) 18:54
$dist.id = nqp::sha1($dist.Str), where $dist.Str is the long name (My::Module:ver<*>:auth<*>) 18:55
with the general idea being to have Distribution be a super general interface, so you can move modules from 1 CUR type to another by simply targeting a genralized distribution interface 18:57
and CUR handle storage, loading, and absolutifying (adding whatever prefix / generating content address) 18:58
MadcapJake Sounds good to me! I'm curious how far I can get just on the current CUR stuff. I'm trying out the `use GX;` idea right now. 19:23
19:37 FROGGS joined
ugexe i tried to subclass CURI before, hard coding the short-id2class bit into rakudo and recompiling. it worked for installing, but the modules failed to work due to precompilation issues. i didnt try to work around those issues, so it might be something that can be worked around yet 19:43
(i.e. install#/xxx/yyy worked [not to be confused with inst#])
so what you might want to do first is come up with a PR to allow `BEGIN { short-id2class("gx") = "CompUnit::Repository::GX" }` so you dont have to hard code that part 19:45
alterntively we talked about putting all CUR into a special directory. in that case i imagine each CUR would just have a `method short-id { "gx" }` or some such that would get called after rakudo starts and combs that directory to load the CURs 19:47
20:15 TimToady joined
nine MadcapJake: just have a look at CompUnit::Repository::Panda 20:46
MadcapJake: you probably shouldn't worry about precompilation too much right now as there's already a branch that will obsolete the "only one PrecompilationStore" rule. And sometime this year I'm sure I will fix that damn EVAL issue blocking a merge. 20:48