Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2017-08-05

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:53 ilbot3 joined #perl6-toolchain
01:53 Topic for #perl6-toolchain is now Fire is step THREE! | https://github.com/perl6/toolchain-bikeshed | Channel logs: http://irclog.perlgeek.de/perl6-toolchain/today | useful prior art: https://metacpan.org/pod/CPAN::Meta::Spec
02:28 lizmat joined #perl6-toolchain
07:45 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.
08:08 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:09 sjn oh, you're talking about the precompiled stuff
08:10 sjn that's a simple fix; add a precompilation format version number to the file name
08:12 * sjn stops speculating :-P
08:15 nine Precomp files are already stored in a directory named after the compiler's id. They are not a problem. Installed distributions are.
08:16 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)
08:16 nine "rakduo+etc"?
08:17 nine 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/...
08:17 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.
08:18 sjn mm
08:19 sjn 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)
08:20 nine There's already a "version" file in the repo.
08:20 sjn repo version != format version, is it?
08:20 nine No, repo version == format version.
08:22 sjn which file contains the repo version?
08:24 nine install/share/perl6/site/version for example
08:24 nine Or ~/.perl6/version
08:24 sjn yeah, that won't do
08:26 sjn you could add a .$version suffix to all the files that are version sensitive
08:26 sjn that would allow files from different versions to be installed in parallel at least
08:27 sjn so old files would still be available to perl6's that require earlier versions
09:04 edehont joined #perl6-toolchain
09:24 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 nine Btw. sjn will you be in Amsterdam?
12:27 sjn nine: yeah, I'll arrive tuesday evening
14:44 ugexe nine: hmmm, you already had zef installed before building that pr eh?
14:45 ugexe although I would have expected an error about no such method .script
14:46 ugexe oh that part is run in CUR now, so maybe something else along that line though
14:47 nine Haven't dug into it yet. Got rid of #131831 first
14:55 ugexe ah yeah
14:55 ugexe run-script would be called with a first argument of "zef"
14:56 ugexe 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 ugexe but if that wrapper already exists then its already hardcoded as just "zef"
14:58 ugexe 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 :)
14:59 nine Being more flexible with internal changes is pretty much the whole point of having run-script in CompUnit::RepositoryRegistry :)
15:27 * ugexe is testing a fix
15:28 ugexe also actually hooking up !matching-dist which I removed when I was doing benchmarks
15:28 ugexe there was no difference, but as will be noted in the commit message there are cases when it would help
15:53 ugexe 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:57 ugexe 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 https://gist.github.com/ugexe/f786039212b2064898b0aee8b4e5cddb#file-dist-utils-pm6-L3
16:08 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:10 nine 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'
16:10 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.
16:11 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:13 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:18 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 ugexe which also goes well with the idea of .candidates acting as a recommendation manager
16:24 ugexe anyways pushed fixes to #1125
16:56 nine Didn't seem to help much here :/
17:00 http_GK1wmSU joined #perl6-toolchain
17:01 http_GK1wmSU left #perl6-toolchain
17:05 nine There's something wrong with LazyDistribution: :source(IO::Path.new("/home/nine/.perl6/resources", :SPEC(IO::Spec::Unix), :CWD("/home/nine")))
17:14 ugexe whats the content of the bin wrapper? does it use run-script, or is it pre run-script?
17:29 ugexe 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:45 ugexe oh I think I know... one of the damn files multis returns a hash, and the other a Distribution :x
18:17 nine oops ;)
18:17 nine it's post run-script
18:30 nine The short-name lookup file does contain the resources id of the script
18:33 nine Oh but not the one in ~/.perl6. Or maybe there isn't even one (despite zef being installed there, too)
18:35 ugexe ah good, so i'm on the right track thinking I need an extra `.meta<source> || .meta<files>{$file}` somewhere
18:37 nine Though it's odd that something completely unrelated ends up in there
19:27 ugexe ok i think I fixed it. third time is a charm and whatnot
19:28 ugexe I'm also starting to wonder if this is causing some strange problems for someone https://github.com/rakudo/rakudo/blob/nom/src/core/CompUnit/Repository/FileSystem.pm#L13
19:29 ugexe because that is shared between all the CURFS it means the order of the repos is not respected when searching
19:32 nine Yep, could cause issues
20:09 nine What the? It still fails :(
20:30 nine .meta returns: {api => v0, auth => github:ugexe, checksum => (Str), name => bin/zef, source => (Any), ver => v0.1.17}
20:30 nine So neither %meta<source> nor %meta<files>{$file} can return anything useful
20:35 nine ugexe: this is the short name lookup file in full: https://gist.github.com/niner/cb46d15986544befc6e3b473fb9bc680
20:37 nine ugexe: and the dist meta file: https://gist.github.com/niner/7d27d8d929492583a2be21e06017a2dc
20:40 ugexe hmm, well calling .perl on the %meta doesn't mean much because some of it is set lazily
21:22 ugexe where are you printing out .meta at?
21:24 ugexe I suspect im treating an empty string incorrectly somewhere...
21:37 ugexe I think I traced where it could be too lazy based on the code path I think you get with no $source...
21:42 ugexe https://github.com/rakudo/rakudo/pull/1125/commits/29d74709f4fe72ac7138b66d309a6413febe90a5
21:42 ugexe if I try to emulate your problem it is solved by this commit
21:43 ugexe well, emulate the short name stuff
21:44 ugexe to see the lazy thing in action though compare:
21:44 ugexe say CompUnit::RepositoryRegistry.repository-for-name("site").files("bin/zef")[0]
21:44 ugexe say CompUnit::RepositoryRegistry.repository-for-name("site").files("bin/zef")[0]<provides>
21:45 ugexe 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:47 ugexe 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:49 ugexe well, you have to parse json if you want to filter on both a dist/module name and an individual name-path (file)
21:50 ugexe fast lookup only works for one or the other

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary