|
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 23 March 2016. |
|||
|
02: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 | ||
|
07:16
domidumont joined
07:21
domidumont joined
08:14
FROGGS joined
08:15
domidumont joined
|
|||
| stmuk_ | bugs.debian.org/cgi-bin/bugreport....bug=818926 | 10:13 | |
| domidumont | stmuk_: I've discussed this issue with nine yesterday. | 10:40 | |
| nine | domidumont: I don't know if I've mentioned this already. The tool-to-be-written is basically gist.github.com/niner/8ad4cbefde16d9494e16 | 10:46 | |
| domidumont | nine: you did mention it, but I forgot the URL :-) | ||
| nine | What's missing is only a build step for modules that need to compile some native library. That depends on us finding a replacement for Build.pm6 files that extend Panda::Builder | ||
| domidumont | I'm going to test it for simple modules like JSON::Fast | 10:47 | |
|
15:20
stmuk joined
|
|||
| ugexe | there are problems with the absoultifying of object. the relative path part is used as 1 of 2 parts, but it only counts the part after `resources/` into the hash | 16:02 | |
| this means you can have 2 different files with the same id | |||
| MyModule/script/xxx, MyModule/resources/scripts/xxx (both hashed with the same root, and if in the same distribution the same Dist.id) | 16:03 | ||
| i worked some of that out but im not sure how well it will merge now | 16:04 | ||
| todays commits for instance seem like that would fit into what i discussed yesterday, the need for an `absolutifier` | 16:08 | ||
| there is lots of redundant stuff going on that should be rolled up into Distribution. for instance CompUnit.new(...ver => $dist<ver>, auth => $dist<auth>, distribution($dist)) | 16:09 | ||
| stmuk | does "zef search" work? | 16:11 | |
| ugexe | stmuk: yes, but only exact searches right now | 16:15 | |
| stmuk | ah | ||
| ugexe | if you --cpan you can use whatever elastic search understands though | ||
| stmuk | BTW I would have assumed "zef fetch" to have populated the cwd rather than ~/.zef/tmp (or at least printed dest dir) | 16:16 | |
| ugexe | i cant say for sure, but i dont think it will if you disable the LocalCache content storage | 16:17 | |
| --/cached would disable it | |||
| but otherwise it stashes it so if you do `zef fetch "XXX:ver<1>"` and already have it cached, you dont fetch it | 16:18 | ||
| the caching thing is a bit wonky though i agree | |||
| stmuk | was impressed by uninstall! :) | 16:19 | |
| ugexe | luckily that feature is mostly built in to CURI now | 16:22 | |
| nine: can i break method.install down into smaller parts? mostly to be `install --> installs source dist --> !install-precomp --> installs precomp (a method like this: gist.github.com/ugexe/c5a74134164bcaabd756) | 16:26 | ||
| let me rephrase: create a `method !precompile-distribution` thats called at the end of `method install`. the pros is it makes method install smaller as well as the possiblity of using a different precompile strategy based on the known topology of a Distribution | 16:29 | ||
| the cons are that piece of code is otherwise inside a lock. ie. calling self!precompile-distribution($myDist) could accidently be done outside the method install lock | 16:30 | ||
| i'd go as far as breaking each step into its own private method `!install-source, !install-bins, etc` leaving `.install` to mostly comments describing the process and using the higher level private methods | 16:32 | ||
| i can do these things, but im assuming im overlooking something | 16:33 | ||
| could probably do things like add-short-name in bulk instead of once per provides too | 16:39 | ||
| since the Distribution would provide all the neccesary info | 16:40 | ||
|
16:46
Kassandry joined
17:18
domidumont joined
|
|||
| nine | Sounds good! But I've made a lot of changes to install in the relocateable-precomp branch, so maybe it's better to hold off for now to avoid a massive refactoring headache | 17:45 | |
| ugexe | have you had a chance to read github.com/ipfs/specs/blob/master/...s/ipfs.pdf ? it seems to align with what we are doing (sections 3.5 onward) | 17:50 | |
| nine | I think I've read it once...looks awfully familiar | 17:59 | |
| jdv79 | relocatable precomp is a thing now? | 18:02 | |
| nine | jdv79: I merged the first commit today giving us more usefull backtraces and easing some of the packaging pain. | 18:03 | |
| More to come once I've shaved this massive yak... | 18:04 | ||
| jdv79 | i thought jnthn said it was really hard or something like that last i heard about it | ||
| wow | |||
| nine | AFAIK he said that I probably knew better than him how hard it would be and indeed it was not that hard at all :) | 18:05 | |
| The only absolute paths in precomp files were the source annotations | 18:06 | ||
| jdv79 | oh, ok. maybe i'm remembering very outdated or imaginary utterances then . | 18:13 | |
| [Coke] | nine++ | ||
| MadcapJake | ugexe: wrt IPFS, did you see this github.com/whyrusleeping/gx ? | 18:44 | |
| ugexe | MadcapJake: yeah, ipfs seems to be a thing to talk about since the npm shit show the other day | 18:55 | |
| MadcapJake | right, that was my thought too | 18:56 | |
| i'm honestly surprised that they just caved like that, I'd gander that the perl community wouldn't be so quick to fold but it'd be better to breed the option out completely! | 18:59 | ||
| once relocatable-precomp lands, setting up a gx-perl6 CLI should be really simple (was planning on tackling that sooner but I think I'll wait for that branch to land :P ) | 19:00 | ||
| ugexe | whats being worked on will essentially be ipfs | 19:03 | |
| MadcapJake | really? Why reinvent an internet protocol? or is it just over the internet? | 19:05 | |
| ugexe | the protocol/network/filesystem layers are transparent | 19:09 | |
| IPFS also stands for inter planetary file system, not internet protocol file system | 19:11 | ||
|
19:29
FROGGS joined
|
|||
| MadcapJake | ugexe: right, but it is described as a p2p hypermedia protocol | 19:31 | |
| so essentially what you're saying is that Perl6 modules will be a Merkel DAG, right? | |||
| ugexe | For the most part, yes. Distribution will consist of `method meta`, the data Distribution needs to create a merkel dag(possibly encoded in a file path and not listed in json somewhere), and a `method content($orig-relpath)` capable of translating $orig-relpath based on the dag into an IO::Handle (a common interface to read data from). So perl6 modules themselves are a merkel dag, but they still need | 20:01 | |
| a Distribution object to imply how to generate the dag (Distribution::Hash -> explitily in the meta already, Distribution::Directory -> grep all files in <lib bin resources>>>.IO (maybe using $meta for hints), Distribution::Tar -> grep all files from run(<<tar --list $module.tar>>, :out).out.lines) | |||
| makes it trivial to slap a role onto any Distribution with `method content($xxx) { use HTTP::UserAgent; <do internet stuff>; return $io-handle-to-data; }` | 20:07 | ||
|
21:33
MadcapJake joined
21:35
stmuk joined
21:37
pnu joined
22:13
stmuk_ joined
|
|||