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 27 July 2017.
ugexe ah moving the role outside of the method allows it to work 00:18
but for some reason declaring the role inside the method or applying the role anonymously would fail 00:19
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
ugexe nine: github.com/rakudo/rakudo/pull/1120/files I pushed it here 02:05
github.com/rakudo/rakudo/pull/1120...cf08a4ce1a er the summary is here though 02:06
05:38 Cheery joined 05:40 Cheery joined 07:05 domidumont joined 07:12 domidumont joined 12:52 perlpilot joined 13:35 perlpilot joined 13:41 lizmat joined 15:03 domidumont joined 15:32 jdv79 joined
ugexe i feel like we could also remove setting the version/auth/api in CompUnit.new in CURI by giving CU a way to use its $.distribution to obtain those 16:19
i would also propose implementing .candidates on ::FileSystem (or any CUR that can represent more than one file/module) 16:38
actually maybe we need to chain .candidates when calling .resolve.... because right now I'm thinking a if repo-1 has XXX:ver<2> and repo-2 has XXX:ver<3> that ver<2> would get loaded because that repo is seen first 16:42
...which would explain some of the weird "why is this using the old version of my module?" that goes away when deleting ~/.perl6 16:43
i'm surprised we overlooked this 16:44
nine We didn't. 16:53
That was a concious choice. If you say :ver<2> suffices, you shouldn't complain when it gets loaded. 16:54
ugexe i mean when you say just 'XXX' 17:06
i thought this was understood as 'load the latest version', not 'load the latest version found in the first repo' 17:09
first repo with a match^
nine The only thing we guarantee is that you will get a module that matches your stated requirements. Given multiple matching ones, CompUnit::Repository::Installation happens to pick the highest one it has available. 17:14
ugexe so the problem with ~/.perl6 seems to be somewhat related. if you install zef v0.1.25 to site, and use that to install zef v0.1.24 to home, then `zef ...` will launch/use v0.1.24 18:10
nine But why would you install the older version? 18:22
ugexe 1: a dependency may have required that specific version 2: emulate the problem of updating an old rakudo, getting problems with zef (from IO refactor), finally figure out how to install a newer zef only to have it continue using the old version and continue giving the same errors 18:25
nine Considering all repos will not exactly do wonders for performance :/ 18:30
ugexe i wouldnt think it would hurt performance much. the first lookup is already optimized to avoid as much io as possible, and after that its just looking up %!loaded{...} a few extra times 18:35
at the very least CompUnit::RepositoryRegistry.run-script should consider every repository 18:54
or rather, that the script it launches is using those libs 18:56
ah this is a problem with .script as what it returns gives no indication of the version, so you cant compare the results from multiple CURs in run-script 19:01
so whats happening is people have some old version of zef installed in ~/.perl6 and were likely using a newer version of zef installed to site ok. then they upgrade rakudo and .run-script starts grabbing the old version of zef because the wrapper no longer does a version sort over all candidates 19:19
on the bright side that means those weird problems, despite the hail mary delete ~/.perl6 always solving it, aren't precomp issues 19:24
i could add more info to the zef "Already installed" message as well to indicate where, which might be enough to nudge the majority into figuring out to uninstall from home 19:28
19:37 mspo joined
mspo hi I'm trying to get reproducable builds into precomp/ and the timestamps in the middle of the path are not exactly working 19:38
is there a way to tell install-dist.pl (or another method) to use a fixed path?
for example compiling zen I have 19:39
precomp/9AD391BB028FBF86169E02934A6181BA21049736.1497985253.01802/FE/FE48D13883ACBA2CF35E1746EEFE956A173BE8AE.repo-id vs precomp/6C3B1056A15F23B58ED8A7017D2C24B8F7524EB2.1501209729.51376/FE/FE48D13883ACBA2CF35E1746EEFE956A173BE8AE.repo-id
s/zen/zef
ugexe im not sure, but just for some insight into a naive solution: change the timestamp to all 0 on initial install. this is naive because it only would work if you knew the dependency graph beforehand (which you can probably emulate by ordering META6.json provides perfectly) - but for it to actually figure this graph out it has to run the code, which (to oversimplify) will try to precompile each file and 19:51
if it fails it puts it at the end of the queue to try after trying everything else
so that timestamp would change each time it needs to retry to precompile 19:52
or something along those lines
which, btw, ordering your META6.json provides to the perfect precomp order should speed up a distribution's install time 19:54
mspo ugexe: this is only for bootstrapping stuff and packaging individual things into pkgsrc which has a requirement for reproducable-ish builds (file names, at least) 19:55
ugexe: the timestamp is obvious but I don't know what the other stuff is: 6C3B1056A15F23B58ED8A7017D2C24B8F7524EB2
ugexe well, couldnt you just use rename to 0 out that time stamp before finalizing the package?
mspo just rename the entire middle part? does that work? 19:56
like moar could find it, I mean
ugexe im not sure but i suspect it would
mspo interesting
ugexe i'm failing to find where the code that generates that path is at heh
mspo ugexe: wouldn't it make more sense to add an option to the compiler? :) 19:57
yeah I was looking too but this is my first time down the road
so I'm miles away
compunit something?
PRECOMP_PREFIX would be nice
ugexe CompUnit::Precomp* 19:58
mspo here somewhere? github.com/rakudo/rakudo 19:59
ah I need to go pick up my kid. bbl
ugexe a utility to capture RAKUDO_MODULE_DEBUG output from an install of a module could provide an author with an optimal provides order. that could be a neat little tool or mi-6 plugin 20:05
nine The timestamped thing is the compiler's id which is the serialization context's id + the timestamp
Oh that's not correct. 20:12
It's actually the sha1 hash of CORE.setting's source code + the timestamp at time of compilation. 20:14
What it doesn't include is the NQP code, i.e. src/Perl6/. With that it could be enough to enable reproducible builds. 20:15
ugexe: looks like our ::Installation repos will have to communicate a little. So the first matching one asks the following repo for a matching one with a higher version. 20:24
ugexe i think the version sort can be done inside of run-script the same way it used to - no intercommunication required - using .files and/or .candidates from PR#1120 by just changing 20:35
`my $matches-file := $_.grep: { .meta<files>{$file} }` to `my $matches-file := $_.grep: { .meta<source> eq $file || .meta<files>{$file} }`
since the distributions all use the fast path and include <source> 20:36
e.g. .meta<source> would not call self!dist, but .meta<files>{$file} would 20:37
mspo nine: so my CORE.setting must be different since the first part of my file path was also different 21:06
{CORE.setting}.unix.milliseconds/module_hash{2}/module_hash?
something like that?
anyway is there a way for me to influence this or do I need to wait until something is changed? 21:07

Powered by Cro and the Raku® Programming Language.

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

Thank you!