Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
02:49 ilbot3 joined #perl6-toolchain
02:49 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
02:55 FROGGS_ joined #perl6-toolchain
04:32 TimToady joined #perl6-toolchain
07:33 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:37 FROGGS joined #perl6-toolchain
13:06 sufrostico joined #perl6-toolchain
13:32 perlpilot joined #perl6-toolchain
13:42 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.
14:23 nine flussence: but the dependencies are recorded in the META6.json
14:26 flussence dependencies between ./lib/A.pm and ./lib/B.pm?
14:27 nine flussence: what do you need those for?
14:29 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:36 nine Why would you want to do that manually?
14:37 ugexe nine: the provides hash stored is not the same as the provides meta hash
14:37 ugexe so when you give a Distribution created from the stored meta file it has provides => 'name' => { 'pm' => { 'file' => xxx, time => xxx } }
14:38 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)
14:39 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
14:39 ugexe but, ive said before that i wished the provides structure was not changed
14:40 ugexe 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
14:40 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.
14:40 ugexe nine: yeah, but modifying the existing structure (or adding values) would be ok
14:41 ugexe just not adding new levels of stuff
14:41 ugexe if you need new structure, i would hope a different key could be used all together
14:42 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?
14:42 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.
14:43 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
14:43 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.
14:44 nine flussence: that will make packaging precompiled files at least possible.
14:44 nine flussence: then we'll have to make rakudo smarter so it will also use those files.
14:44 flussence right, so there *is* a way forward. that's good. less worried now.
14:46 nine Just none of this requires Makefiles or manual precompilation. That's why I didn't understand you asking about those.
14:47 flussence never mind, was overthinking
15:11 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:13 ugexe 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:40 ribasushi joined #perl6-toolchain
17:05 FROGGS joined #perl6-toolchain
17:18 sufrostico joined #perl6-toolchain
17:22 nine ugexe: absolutely correct!
17:23 nine amazing how many things I could screw up in such a short method
17:39 Kassandry joined #perl6-toolchain
17:53 jdv79 yeah, 100% declarative dep resolve would be pretty sweet.  maybe arbitary code execution can be kept out of that path.
18:15 nine ugexe: actually, we have to remove the dist-id from all short/ files.
18:16 nine Which thanks to Perl 6' awesomeness is just: for $short-dir.dir -> $file { $file.spurt: map("$_\n", ($file.lines ⊖ $id).keys.sort); }
18:29 ugexe yeah. although i wonder if `nqp::sha1($dist.name).{$dist.id}` as the file name would be faster to lookup
18:30 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)
18:32 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:36 sufrostico joined #perl6-toolchain
19:01 sufrostico joined #perl6-toolchain
19:14 jdv79 what is the change that you all are talking about?
19:15 nine ugexe: https://github.com/rakudo/rakudo/commit/6c44df46f1
19:16 patrickz joined #perl6-toolchain
19:53 hankache joined #perl6-toolchain
20:07 raiph joined #perl6-toolchain
20:36 El_Che joined #perl6-toolchain
20:38 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: http://www.learningperl6.com/2016/02/06/dont-install-over-your-existing-perl-6/
21:49 nine rakudobrew...again
21:49 nine And the broken idea of needing to install different rakudo builds in parallel
21:55 El_Che nine: most he writes about perl6 is negative, but this one feel less so
22:09 jdv79 perlbrew is useful for testing and some other cases.
22:09 jdv79 why is the idea broken for 6?
22:10 jdv79 i agree its annoying to deal with sometimes.
22:11 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
23:32 [Coke]_ joined #perl6-toolchain
23:41 TimToady joined #perl6-toolchain
23:45 autarch joined #perl6-toolchain
23:58 sufrostico joined #perl6-toolchain

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