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 14 February 2016.
02:49 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
02:55 FROGGS_ joined 04:32 TimToady joined
nine ugexe: commented on your "Fix uninstall" commit. Btw. it would be nice if the commit message mentioned in what way uninstall was broken. 07:33
07:37 FROGGS joined 13:06 sufrostico joined 13:32 perlpilot joined
flussence autarch: yes, literally "make". Because that'd require three fundamental things: a way of querying the dependencies of a given .pm without running it, a deterministic .pm->.mbc filename mapping, and parallel compilation. 13:42
nine flussence: but the dependencies are recorded in the META6.json 14:23
flussence dependencies between ./lib/A.pm and ./lib/B.pm? 14:26
nine flussence: what do you need those for? 14:27
flussence if I compile those to moarvm bytecode manually (which *used* to work fine, I haven't been able to keep up recently), it has to be done in the right order or they error out 14:29
nine Why would you want to do that manually? 14:36
ugexe nine: the provides hash stored is not the same as the provides meta hash 14:37
so when you give a Distribution created from the stored meta file it has provides => 'name' => { 'pm' => { 'file' => xxx, time => xxx } }
nine ugexe: oh my, of course, you're right. Then why do I have this <pm pm6>.first(*.so) everywhere? We can get rid of that :) 14:38
ugexe the problem was you seemed to think the last hash with `file => xxx` did not have any other keys, but it does (time)
nine Having this pm key in the first place makes no sense 14:39
ugexe there used to be pm key, and a moarvm/jar key
but, ive said before that i wished the provides structure was not changed
i.e. going from META6 provides -> CompUnit provides 14:40
nine We at least need to store the name of the stored file in there
flussence nine: I'm trying to preserve a workflow that won't have distro maintainers screaming bloody murder like some of our users have. If perl6 is so far gone into automagical land that it doesn't even make sense to *ask*, then I don't know where to go from here. I may as well give up.
ugexe nine: yeah, but modifying the existing structure (or adding values) would be ok
just not adding new levels of stuff 14:41
if you need new structure, i would hope a different key could be used all together
nine flussence: I absolutely want to make distro maintainer's lives easier. Because right now, they're completely screwed. However I'm not sure if that necessitates having the user do those tasks manually. 14:42
flussence is the distro maintainer not a user?
nine flussence: what I do know is that before everything else, we have to get rid of those absolute paths in the precomp files and the .deps and .rev-deps files.
flussence they're the ones that have to build this stuff, and end users are going to be pissed if their perl6 "binaries" spend half an hour byte-compiling at first run 14:43
ugexe zef used to have parallel precompilation. it just used a grammar + meta provides to find which files appeared to use one another, then created the precomp order
nine flussence: yes, but to fix that we have to allow for building in a different directory than the files are going to end up in and with an unpriviledged user.
flussence: that will make packaging precompiled files at least possible. 14:44
flussence: then we'll have to make rakudo smarter so it will also use those files.
flussence right, so there *is* a way forward. that's good. less worried now.
nine Just none of this requires Makefiles or manual precompilation. That's why I didn't understand you asking about those. 14:46
flussence never mind, was overthinking 14:47
ugexe nine: should $short-dir.child(nqp::sha1($dist.name)) not really be unlinked? if i understand correctly that file can contain more than 1 value, where each line represents a different ver/auth of $dist.name 15:11
it looks like if you have Foo:ver<1> and Foo:ver<2> installed that uninstalling one would delete the short-id file that both would be using (including the still installed version of Foo) 15:13
15:40 ribasushi joined 17:05 FROGGS joined 17:18 sufrostico joined
nine ugexe: absolutely correct! 17:22
amazing how many things I could screw up in such a short method 17:23
17:39 Kassandry joined
jdv79 yeah, 100% declarative dep resolve would be pretty sweet. maybe arbitary code execution can be kept out of that path. 17:53
nine ugexe: actually, we have to remove the dist-id from all short/ files. 18:15
Which thanks to Perl 6' awesomeness is just: for $short-dir.dir -> $file { $file.spurt: map("$_\\n", ($file.lines ⊖ $id).keys.sort); } 18:16
ugexe yeah. although i wonder if `nqp::sha1($dist.name).{$dist.id}` as the file name would be faster to lookup 18:29
nine Hard to say if reading a file with a well known name or listing a directory is faster 18:30
ugexe otherwise you also have to handle unique lines (somehow I ended up with 2 identical $dist.id in a short-id file)
nine Moving away from files will also have benefits for packaging modules. Package installation is ideally just dropping some files into some directories. Modifying existing files makes everything complicated. 18:32
18:36 sufrostico joined 19:01 sufrostico joined
jdv79 what is the change that you all are talking about? 19:14
nine ugexe: github.com/rakudo/rakudo/commit/6c44df46f1 19:15
19:16 patrickz joined 19:53 hankache joined 20:07 raiph joined 20:36 El_Che joined
El_Che If someone hasn't seen this post; brian d foy may be trolling a little (the blogpost is categorized in "horror"), but he has a point: www.learningperl6.com/2016/02/06/do...ng-perl-6/ 20:38
nine rakudobrew...again 21:49
And the broken idea of needing to install different rakudo builds in parallel
El_Che nine: most he writes about perl6 is negative, but this one feel less so 21:55
jdv79 perlbrew is useful for testing and some other cases. 22:09
why is the idea broken for 6?
i agree its annoying to deal with sometimes. 22:10
El_Che In my use case I am experimenting via a docker image that builds rakudo star and installs my application with "panda install .". The start overhead is extremely low 22:11
23:32 [Coke]_ joined 23:41 TimToady joined 23:45 autarch joined 23:58 sufrostico joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!