Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-01-11

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

All times shown according to UTC.

Time Nick Message
02:37 Zoffix joined #perl6-toolchain
02:47 Zoffix joined #perl6-toolchain
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
07:44 FROGGS joined #perl6-toolchain
08:23 masak lizmat: I might be at the QA hackathon this year.
10:36 * sjn has made a PR to the bikeshed repo
12:40 leont joined #perl6-toolchain
12:54 ilbot3 joined #perl6-toolchain
12:54 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
13:44 PerlJam joined #perl6-toolchain
17:53 patrickz joined #perl6-toolchain
18:23 patrickz joined #perl6-toolchain
18:55 TimToady joined #perl6-toolchain
19:11 alpha123 joined #perl6-toolchain
19:17 tony-o joined #perl6-toolchain
19:35 patrickz Someone said that Zef is broken for loads of modules because Build.pm. Is that still true?
19:37 tony-o i believe ugexe patched zef for a workaround with Build.pm
19:40 ugexe not really. if they declare their build dependencies properly it always worked. otherwise it will make a copy of the source and modify it to try and do the right thing
19:43 patrickz ugexe: So is it working? (Working as in it would be fine to hand Zef out to the masses.)
19:43 patrickz I ask because: https://github.com/perl6/perl6.org/pull/45
19:44 * leont is working on a replacement system for Build.pm
19:49 tony-o leont: hooks?
19:49 ugexe patrickz: probably, or at least close. the output (fetching xxx, installing xxx, errors) need to be improved instead of the place holder stuff in there now, but as far as installing stuff its fairly well off
19:49 leont A make like system, but without using shell
19:50 tony-o do you have anything floating around the internet i can read or is it just local currently?
19:51 leont I'm planning to put it online as soon as it is actually working (it's mostly a port of a p5 project of mine), which I'm actually close to
19:51 patrickz ugexe: As far as I tested stuff works, too. So I guess that PR is ok for you...?
19:52 ugexe patrickz: yeah
19:52 patrickz :-)
19:54 leont Woot, it just passed its tests :-)
19:55 autarch leont: have you looked at my p5 module Stepford? it has a dependency resolver that might be of interest
19:55 leont So now I need more tests :-)
19:55 tony-o leont sweet, is the p5 project something i can go take a look at?
19:56 leont https://github.com/leont/build-graph/
19:57 leont autarch: BG's main interesting trait is that it can serialize and deserialize its entire internal state without data-loss, to a hash of strings that's begging to be turned into JSON.
20:06 leont This also makes dry-runs trivial to implement (which makes mst happy)
20:07 Kassandry joined #perl6-toolchain
20:08 leont It's also supporting transparently supporting wildcards and pattern substitutions based on files that either exist on the filesystem or that are in the build graph but not yet build (I rather dislike make making a mess of that). E.g. "For all *.pm files in lib, create a *.frobnicated in frob/", works not only when the .pm files are static, but also if they're dynamically generated.
20:49 patrickz joined #perl6-toolchain
20:49 nine ugexe: zef fails to install Inline::Perl5. Doesn't seem to install any files other than the dist itself.
20:58 hankache joined #perl6-toolchain
21:28 ugexe ah, seems to be this bit: `?? ~"resources/libraries".IO.child($*VM.platform-library-name($0.Str.IO))`. would that not be better in CU::R::I itself though? or its own hash key under resources?
21:33 ugexe i only say this because i also like the idea that i can write a -e 1 liner to install a module if i really want to, and that would seem to make that quite a bit more complicated
21:35 hoelzro I noticed last night that Panda has some extra magic for a 'libraries' resource subdirectory; is that (or something else to address distributions that bundle helper libs) going to be added to the language spec?
21:37 hoelzro I wrote Native::Resources last week to deal with the native lib situation before I found out, so I'll just keep using that until the spec changes, even if it's for 6.d
21:37 ugexe thats essentially what im hoping for above
21:37 hoelzro heh, I should backlog next time =P
21:38 hoelzro I also noticed that panda refers to "resources" as a JSON array, whereas the spec refers to "resource" as a JSON dictionary
21:38 ugexe yeah, it shows hooks being defined there too
21:38 ugexe build-time or whatever
21:39 hoelzro true
21:39 hoelzro it would be nice if panda followed the spec, and fell back to old behavior with a warning for a little while
22:05 nine I tried installing the spec but it just didn't work out
22:05 nine s/installing/implementing/
22:07 nine The difficulty lies in that I really didn't want the module's code to have to differentiate between FileSystem and Installation repositories as that's exactly what %?RESOURCES should hide.
22:09 hoelzro nine: the libraries spec?
22:09 nine yes
22:10 hoelzro nine: I'll be publishing a blog post about %?RESOURCES + libraries tonight; I'll link it to you after I post it.  I would really like your feedback!
22:10 nine One just cannot assume that the additional meta data from META.info is available, so the only way was to encode the information into the resource's path. Hence the special cased "libraries" directory.
22:11 hoelzro it's just the sum of my experiences dealing with how %?RESOURCES and native libs interact atm, and I'm hoping to start a dialogue about how best to proceed
22:13 mst nine: why not? a filesystem repo can have a meta6 at its root, no?
22:15 nine mst: unusable as it is. It's looking for a META6.json in the repo's root, while e.g. Inline::Perl5 has a META.info in the root's parent directory.
22:15 hoelzro META6.json is what's spec'd, right?
22:16 nine I think so.
22:16 nine The larger issue is the difference in directories.
22:17 nine OTOH FileSystem is now looking in ../resources for those resources, so it could look in .. for the META6.json
22:19 * leont has no idea what the difference between META6.json and META.info is supposed to be
22:19 nine That's what you get, when you try to make cross platform resources work on Dec 23 in the evening...
22:19 nine leont: nothing
22:20 PerlJam META.info is old, use META6.json  :)
22:22 mst nine: *laughs*
22:25 leont https://github.com/Leont/build-graph6
22:26 leont Still a bit a hacky port, but it's passing its tests
23:30 ugexe the hash-key-per-directory thing also abstracts away the path separator, which while normally abstracted by IO as it is, could run into problems if a windows user uses a backslash sequence
23:32 tony-o hash key per dir in what?
23:32 ugexe resources
23:33 ugexe i.e. "resources" : [ "libraries" : "some-library1.so", "some-library2.so" ] is resources/libraries/<files>
23:35 ugexe and then access them with their original names even after the CU::R theoretically does the $*VM.platform-library-name

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