|
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 24 February 2016. |
|||
|
00:58
autarch joined
01:14
hankache joined
02:48
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 | ||
|
04:40
sevvie joined
07:41
FROGGS joined
10:45
domidumont joined
12:41
sufrostico joined
12:42
sufrosti1o joined
13:43
autarch joined
|
|||
| ugexe | thinking more about version in reference to META6: perhaps the version field should treated as a single concrete version. as in curli would read `"version" : "*"` as matching *.Str, which makes sense as I dont think anyone is asking to allow a distribution to declare itself in a range of version (only lookup) | 16:24 | |
| nine | Yeah! I just had the first run where a make install && perl6 -e 'use Test;' did not have to precompile Test again on the first load :0 | 16:25 | |
| ugexe | by lookup i also mean from the recommendation manager/service, not curli | 16:28 | |
| example: `$curli.uninstall(Distribution.new(:name<xxx>, :ver<*>))`; # uninstall version where eq "*"? where ~~ Version.new(*), and if so just 1 or all matching? | 16:32 | ||
| note Distribution.new should be assumed to come from a call to .resolve (to locate the dist), which uses ::DependencySpecification to match | 16:45 | ||
| i dont know if that should be a different method, an option to method resolve, or making !matching-dist into a multi | 16:50 | ||
|
16:55
sufrostico joined,
sufrosti1o joined
|
|||
| nine | The good thing is that we can still change .resolve to whatever we really need | 16:57 | |
| ugexe | method candidates, like `resolve` but returns *every* matching CompUnit. anything using .candidates could then do a string match to get the exact one they want, while candidates can continue matching with ::DependencySpecification | 17:02 | |
|
17:29
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 | ||
|
17:39
sevvie joined
|
|||
| ugexe | something else i just thought of is that if a single rakudo installation may have both jvm and moar backends installed, then differentiation between jvm and moar precomp files needs to be thought out (i.e. both would have the same sources/<sha1s>) | 18:06 | |
|
18:08
domidumont joined
|
|||
| perlpilot | What are the SHA1s used for exactly? (or should I just read the code?) | 18:09 | |
| The reason I ask, is that if it's just for unique storage location, then we could do something like what git does. SHA1 == filename + timestamp + backend | |||
| ugexe | it could also add the extension (.moarvm, .jar) to the sha1 (the extension is stored in the dist meta file) | 18:11 | |
| ugexe duh thats the same thing | 18:12 | ||
|
18:48
FROGGS joined
19:38
Kassandry joined
21:02
sufrostico joined,
sufrosti1o joined
22:16
sufrostico joined,
sufrosti1o joined
|
|||