Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-02-26

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

All times shown according to UTC.

Time Nick Message
00:58 autarch joined #perl6-toolchain
01:14 hankache joined #perl6-toolchain
02:48 ilbot3 joined #perl6-toolchain
02:48 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
04:40 sevvie joined #perl6-toolchain
07:41 FROGGS joined #perl6-toolchain
10:45 domidumont joined #perl6-toolchain
12:41 sufrostico joined #perl6-toolchain
12:42 sufrosti1o joined #perl6-toolchain
13:43 autarch joined #perl6-toolchain
16:24 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:25 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:28 ugexe by lookup i also mean from the recommendation manager/service, not curli
16:32 ugexe example: `$curli.uninstall(Distribution.new(:name<xxx>, :ver<*>))`; # uninstall version where eq "*"? where ~~ Version.new(*), and if so just 1 or all matching?
16:45 ugexe note Distribution.new should be assumed to come from a call to .resolve (to locate the dist), which uses ::DependencySpecification to match
16:50 ugexe i dont know if that should be a different method, an option to method resolve, or making !matching-dist into a multi
16:55 sufrostico joined #perl6-toolchain
16:55 sufrosti1o joined #perl6-toolchain
16:57 nine The good thing is that we can still change .resolve to whatever we really need
17:02 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:29 ilbot3 joined #perl6-toolchain
17:29 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
17:39 sevvie joined #perl6-toolchain
18:06 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:08 domidumont joined #perl6-toolchain
18:09 perlpilot What are the SHA1s used for exactly?  (or should I just read the code?)
18:09 perlpilot 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
18:11 ugexe it could also add the extension (.moarvm, .jar) to the sha1 (the extension is stored in the dist meta file)
18:12 * ugexe duh thats the same thing
18:48 FROGGS joined #perl6-toolchain
19:38 Kassandry joined #perl6-toolchain
21:02 sufrostico joined #perl6-toolchain
21:02 sufrosti1o joined #perl6-toolchain
22:16 sufrostico joined #perl6-toolchain
22:16 sufrosti1o joined #perl6-toolchain

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