|
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 10 January 2016. |
|||
|
02:37
Zoffix joined
02:47
Zoffix joined
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 | ||
|
07:44
FROGGS joined
|
|||
| masak | lizmat: I might be at the QA hackathon this year. | 08:23 | |
| sjn has made a PR to the bikeshed repo | 10:36 | ||
|
12:40
leont joined
12:54
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 | ||
|
13:44
PerlJam joined
17:53
patrickz joined
18:23
patrickz joined
18:55
TimToady joined
19:11
alpha123 joined
19:17
tony-o joined
|
|||
| patrickz | Someone said that Zef is broken for loads of modules because Build.pm. Is that still true? | 19:35 | |
| tony-o | i believe ugexe patched zef for a workaround with Build.pm | 19:37 | |
| 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:40 | |
| patrickz | ugexe: So is it working? (Working as in it would be fine to hand Zef out to the masses.) | 19:43 | |
| I ask because: github.com/perl6/perl6.org/pull/45 | |||
| leont is working on a replacement system for Build.pm | 19:44 | ||
| 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 | ||
| leont | A make like system, but without using shell | ||
| tony-o | do you have anything floating around the internet i can read or is it just local currently? | 19:50 | |
| 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...? | ||
| ugexe | patrickz: yeah | 19:52 | |
| patrickz | :-) | ||
| leont | Woot, it just passed its tests :-) | 19:54 | |
| 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 :-) | ||
| tony-o | leont sweet, is the p5 project something i can go take a look at? | ||
| leont | github.com/leont/build-graph/ | 19:56 | |
| 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. | 19:57 | ||
| This also makes dry-runs trivial to implement (which makes mst happy) | 20:06 | ||
|
20:07
Kassandry joined
|
|||
| 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:08 | |
|
20:49
patrickz joined
|
|||
| nine | ugexe: zef fails to install Inline::Perl5. Doesn't seem to install any files other than the dist itself. | 20:49 | |
|
20:58
hankache joined
|
|||
| 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:28 | |
| 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:33 | ||
| 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:35 | |
| 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 | ||
| hoelzro | heh, I should backlog next time =P | ||
| 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 | ||
| build-time or whatever | |||
| hoelzro | true | 21:39 | |
| it would be nice if panda followed the spec, and fell back to old behavior with a warning for a little while | |||
| nine | I tried installing the spec but it just didn't work out | 22:05 | |
| s/installing/implementing/ | |||
| 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:07 | ||
| hoelzro | nine: the libraries spec? | 22:09 | |
| nine | yes | ||
| 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. | ||
| 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:11 | |
| mst | nine: why not? a filesystem repo can have a meta6 at its root, no? | 22:13 | |
| 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? | ||
| nine | I think so. | 22:16 | |
| The larger issue is the difference in directories. | |||
| OTOH FileSystem is now looking in ../resources for those resources, so it could look in .. for the META6.json | 22:17 | ||
| 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... | ||
| leont: nothing | |||
| PerlJam | META.info is old, use META6.json :) | 22:20 | |
| mst | nine: *laughs* | 22:22 | |
| leont | github.com/Leont/build-graph6 | 22:25 | |
| Still a bit a hacky port, but it's passing its tests | 22:26 | ||
| 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:30 | |
| tony-o | hash key per dir in what? | 23:32 | |
| ugexe | resources | ||
| i.e. "resources" : [ "libraries" : "some-library1.so", "some-library2.so" ] is resources/libraries/<files> | 23:33 | ||
| and then access them with their original names even after the CU::R theoretically does the $*VM.platform-library-name | 23:35 | ||