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 11 August 2016.
01: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
ugexe why do we determine various identifiers based on the sha1 of names/paths instead of the sha1 of the contents of what those point at? Is it because nqp::sha1 would be too slow, or because of the added complexity of having a reference counter for each file (i.e two different versions have a file with the same sha1, so uninstalling one version shouldn't delete said file)? 16:03
jdv79 what's the benefits of uniquing on contents? 18:11
TimToady see git? 18:12
specifically, it enforces immutability 18:13
jdv79 i thought at the moment we were just using name hashing as a cheap fix for fs encoding issues 18:15
TimToady whereas while name/version/auth is mandated to be unique for officially installed modules, it doesn't specify how to enforce it
jdv79: almost nothing has a single reason in Perl 6 :)
jdv79 it would be nice if the paths were hash free. its near impossible to figure out what files one is looking at when the editor tab just has a bunch of partial hash values 18:16
it slows down debugging significantly for me 18:17
TimToady maybe we could symlink human-readable names as guesses, and make collisions fail-soft 18:18
jdv79 the immutibility concern could be addressed outside of the filenames. maybe just in precomp and a side channel - maybe meta? 18:19
not all fses support sylinks:( 18:20
*symlinks 18:21
anyway, ugexe that's my guess. no idea really.
mst I suggested, ages ago, that we used IDN syntax for dealing with the weird naming stuff 18:30
and I thought people had agreed that was a good idea
perhaps they agreed it was a good idea that I wrote the patch for that and I didn't realise 18:31
TimToady :) 18:40
20:47 smls joined
smls The zef install failure on `rakudobrew build moar-blead`, has returned for me... 20:48
"Install [FAIL] for zef:auth('github:ugexe'): zef:ver<*>:auth<github:ugexe>:api<> already installed"
Is it an known issue?
ugexe smls: `rakudobrew build moar-blead` does not attempt to reinstall zef for me 22:32
smls ugexe: Did you have it installed under moar-blead previously? 22:33
ugexe yes
smls hm
ugexe jdv79: another reason is deduplication, like how Dovecot dbox deduplicates attachments instead of saving every copy. this seems like a good fit for resources/, not so much for source code. 23:00
the other current problem with duplication is `"provides" : { "Module::Foo::Bar" : "lib/Module/Foo/Bar.pm6", "Module::Foo::Bar::Helper" : "lib/Module/Foo/Bar.pm6" }` 23:15
which is ironically caused by the hashing (the above creates 2 files but uses the module name to hash and not the duplicated file name) 23:17
gist.github.com/ugexe/ddc78c5b39a1...68ead88c11 this is a fairly complete meta-level solution using sha1 filenames. unfortunately it doesn't really help its case 23:23