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 4 August 2017.
01:53 ilbot3 joined
moderator 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
02:28 lizmat joined
nine ugexe: I guess it very much depends on how the repo versions differ. It's also a given that we should bump the repo version only when absolutely necessary. 07:45
sjn ugexe: how about just having a comprepo index that is tied to the perl6 release, and just keep the rest of the installed files? (just throwing out some ideas without knowing the full context here :) 08:08
oh, you're talking about the precompiled stuff 08:09
that's a simple fix; add a precompilation format version number to the file name 08:10
sjn stops speculating :-P 08:12
nine Precomp files are already stored in a directory named after the compiler's id. They are not a problem. Installed distributions are. 08:15
sjn right, and with "installed distributions" you mean rakudo+etc., and not the bare perl6 module files 08:16
nine We want those to be shared between rakudo versions, do already just fine with upgrading rakudo but not so much if there is a bump in the repo version format and you continue to use a rakudo version that doesn't understand this format (in addition to one that does)
"rakduo+etc"?
We do mean modules and especially their meta data for which we create various indices during installation. 08:17
sjn rakudo + backend (e.g. what one might find in ~/.rakudobrew/...
nine It's ok to add more data to those indices and we have done so a couple of times already. But changing their format requires a version bump.
sjn mm 08:18
so it's prudent to introduce a version number to all the files that one might want to upgrade (either in the filename directly, or as part of a directory name) 08:19
nine What's missing is forwards compatibility. I guess we could only have that if we restricted ourselves to adding to the repo format (possibly having multiple indices for the same purpose)
There's already a "version" file in the repo. 08:20
sjn repo version != format version, is it?
nine No, repo version == format version.
sjn which file contains the repo version? 08:22
nine install/share/perl6/site/version for example 08:24
Or ~/.perl6/version
sjn yeah, that won't do
you could add a .$version suffix to all the files that are version sensitive 08:26
that would allow files from different versions to be installed in parallel at least
so old files would still be available to perl6's that require earlier versions 08:27
09:04 edehont joined
nine Well the exact way of how we handle this will depend on the kind of changes we want to perform. The important bit is that thanks to ugexe++ we are now very much aware of the issue :) 09:24
Btw. sjn will you be in Amsterdam?
sjn nine: yeah, I'll arrive tuesday evening 12:27
ugexe nine: hmmm, you already had zef installed before building that pr eh? 14:44
although I would have expected an error about no such method .script 14:45
oh that part is run in CUR now, so maybe something else along that line though 14:46
nine Haven't dug into it yet. Got rid of #131831 first 14:47
ugexe ah yeah 14:55
run-script would be called with a first argument of "zef"
but when I switched to backing it with .files it seemed to make sense to ask for the full name-path, bin/zef 14:56
but if that wrapper already exists then its already hardcoded as just "zef"
for something called run-script though its ok to not have to have the bin/, so easy enough to tweak since it doesn't have to mirror .files exactly 14:58
nine :)
Being more flexible with internal changes is pretty much the whole point of having run-script in CompUnit::RepositoryRegistry :) 14:59
ugexe is testing a fix 15:27
also actually hooking up !matching-dist which I removed when I was doing benchmarks 15:28
there was no difference, but as will be noted in the commit message there are cases when it would help
I have an idea for getting rid of the bin wrapper using :$name, :$ver, :$auth - since this is the uncommon case make them instead deal with something like :$from-spec (--from-spec="My::Module:ver<whatever>") 15:53
as for parsing that, it can be done pretty easily. I have a grammar in some toy code that does this along with some util functions - some of these ideas may work well in CompUnit::DependencySpecification gist.github.com/ugexe/f786039212b2...ils-pm6-L3 15:57
nine Btw. as a workaround for the ~/.perl6 repo containing an older zef issue, you could have zef load all it's modules with an exact version. That's what you're actually supposed to be doing anyway. 16:08
It just sucks that there's no easy way to just load the modules contained in the same dist. 16:10
ugexe well, i'm still of the opinion you shouldnt have to pin versions of things of the same distribution'
nine Well I think you should :) But there should be a simple way to do so without having to repeat the version time and again.
ugexe it can be done. i already forget how, but I figured it out at one point. i thought it acted that way because it was intended to 16:11
nine Part of the issue is that there's duplicate information between the meta data and the actual source code. Would be lovely if we had to specify version requirements just once. 16:13
ugexe right. if we can get at the CompUnit that is making the query while inside method candidates then we can just add a sort to put those with a matching $calling-comp-unit.distribution in front 16:18
which also goes well with the idea of .candidates acting as a recommendation manager
anyways pushed fixes to #1125 16:24
nine Didn't seem to help much here :/ 16:56
17:00 http_GK1wmSU joined 17:01 http_GK1wmSU left
nine There's something wrong with LazyDistribution: :source(IO::Path.new("/home/nine/.perl6/resources", :SPEC(IO::Spec::Unix), :CWD("/home/nine"))) 17:05
ugexe whats the content of the bin wrapper? does it use run-script, or is it pre run-script? 17:14
hmm looking through the code path I can only guess that in some situations the lookup file does not contain a `source` line. to fix is easy enough - fall back to the slow path. but not sure why I do not encounter this while you do 17:29
oh I think I know... one of the damn files multis returns a hash, and the other a Distribution :x 17:45
nine oops ;) 18:17
it's post run-script
The short-name lookup file does contain the resources id of the script 18:30
Oh but not the one in ~/.perl6. Or maybe there isn't even one (despite zef being installed there, too) 18:33
ugexe ah good, so i'm on the right track thinking I need an extra `.meta<source> || .meta<files>{$file}` somewhere 18:35
nine Though it's odd that something completely unrelated ends up in there 18:37
ugexe ok i think I fixed it. third time is a charm and whatnot 19:27
I'm also starting to wonder if this is causing some strange problems for someone github.com/rakudo/rakudo/blob/nom/...tem.pm#L13 19:28
because that is shared between all the CURFS it means the order of the repos is not respected when searching 19:29
nine Yep, could cause issues 19:32
What the? It still fails :( 20:09
.meta returns: {api => v0, auth => github:ugexe, checksum => (Str), name => bin/zef, source => (Any), ver => v0.1.17} 20:30
So neither %meta<source> nor %meta<files>{$file} can return anything useful
ugexe: this is the short name lookup file in full: gist.github.com/niner/cb46d1598654...73fb9bc680 20:35
ugexe: and the dist meta file: gist.github.com/niner/7d27d8d92949...e06017a2dc 20:37
ugexe hmm, well calling .perl on the %meta doesn't mean much because some of it is set lazily 20:40
where are you printing out .meta at? 21:22
I suspect im treating an empty string incorrectly somewhere... 21:24
I think I traced where it could be too lazy based on the code path I think you get with no $source... 21:37
github.com/rakudo/rakudo/pull/1125...13febe90a5 21:42
if I try to emulate your problem it is solved by this commit
well, emulate the short name stuff 21:43
to see the lazy thing in action though compare: 21:44
say CompUnit::RepositoryRegistry.repository-for-name("site").files("bin/zef")[0]
say CompUnit::RepositoryRegistry.repository-for-name("site").files("bin/zef")[0]<provides>
the first one will not show you the provides key (it doesn't know it yet), but the second one forces it to parse json to see if it exists and grab its value 21:45
say CompUnit::RepositoryRegistry.repository-for-name("site").files("bin/zef", :name<Zef>)[0] - this will show you the entire meta data non-lazily as well, because if you pass :$name it has to parse json no matter what 21:47
well, you have to parse json if you want to filter on both a dist/module name and an individual name-path (file) 21:49
fast lookup only works for one or the other 21:50

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!