Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
00:18 ugexe ah i see the backslash case is taken care of already :)
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
03:34 ugexe nine: have you considered putting more functionality into Distribution? For instance, if .content from s22 is implemented it allows CU::R to not have to worry about turning the relative paths of the meta into an absolute path, as they just feed the meta keys to .content and it returns the data for the file
03:34 ugexe Then CU::R::FS and CU::R::I can save that to a repo (and some other CU::R might do something like upload/ftp it somewhere), and do whatever else it needs to do (precompile, etc)
03:35 ugexe https://gist.github.com/ugexe/8684abcc89aa2d03d009 this demonstrates that somewhat with a Distribution::Local and a Distribution::Tar
05:08 llfourn joined #perl6-toolchain
05:32 hoelzro I wrote up my thoughts and experiences on distributing helper libraries with dists: http://hoelz.ro/blog/distributing-helper-libraries-with-perl6-modules
05:51 llfourn joined #perl6-toolchain
07:15 nine hoelzro: your usage of $*VM.config<dll> is broken on Linux and BSD
07:16 nine m: say say $*VM.config<dll>
07:16 camelia rakudo-moar 0c4db8: OUTPUT«lib%s.so␤True␤»
07:17 nine If you make sure that the library is generated into resources/libraries/ it's enough to do "is native(%?RESOURCES{'libraries/linenoise'})". NativeCall will find the library according to the platform's convenions.
07:18 nine That is: it will look for resources/libraries/linenoise.dll on Windows, resources/libraries/linenoise.dylib on OS X and resources/libraries/liblinenoise.so on others.
07:19 nine Your META.info should just read "resources": ["libraries/linenoise"] as well
07:24 FROGGS joined #perl6-toolchain
07:24 nine So I dare say your Native::Resources is obsolete already as you'd hoped. What's missing is better support for this in LibraryMake
10:10 leont joined #perl6-toolchain
10:18 peter4 joined #perl6-toolchain
11:20 TimToady joined #perl6-toolchain
13:25 nine About uninstall: it takes a Distribution object, leaving the question where this object is coming from. That could be $*REPO.resolve(CompUnit::DependencySpecification(:short-name<Inline::Perl5>, :ver(v0.1)).dist but that feels like a bit of a roundabout way.
13:51 hoelzro nine: I found out about panda's special treatment of resources/libraries yesterday when hunting for panda-specific behaviors
13:52 hoelzro I'll probably stick with using N::R until zef supports that, and maybe that behavior is spec'd
13:52 hoelzro agreed about LibraryMake, though
15:12 FROGGS joined #perl6-toolchain
16:21 hankache joined #perl6-toolchain
16:47 ugexe zef could install Native::Resources yesterday, but i changed the resources code to the /libraries/(*.*?)/ $*VM.platform-name thing to work with Inline::Perl5
16:49 hoelzro well, N::R's needs didn't last very long =/
16:50 hoelzro it makes me uncomfortable that all this isn't spec'd, but I don't know if this kind of behavior is going to be a 6.c vs 6.d thing
16:51 ugexe i still like the idea of Distribution providing an API to the meta file via .meta and access to the content via .content(<provides Module lib/ModuleName.pm6>) (or .content(<resources libraries libname>)), then FileSystem or Installable don't have to care where the content is coming from
16:51 ugexe instead they are only concerned with where it is going
16:55 hoelzro that makes sense
17:16 nine ugexe++ # resource fixes
17:17 nine ugexe: with your Distribution proposal, what would a repository that stores everything into an SQL database look like?
17:44 ugexe using pseudo code (perl6 with dbix::class representing the sql parts) something like https://gist.github.com/ugexe/abdd3f0b9e03d696ba0b
17:44 ugexe nine: ^
18:20 leont joined #perl6-toolchain
18:32 nine ugexe: ah, so you _do_ intend repositories to define their own Distribution subclasses
18:41 ugexe nine: s22 made it seem that way (saying Distribution is for CU::R::Installable), but the .content implementation should be usable by most CompUnit::Repository (im failing to think of an example ::Repository that wouldnt work)
19:00 FROGGS joined #perl6-toolchain
19:23 leont joined #perl6-toolchain
19:29 tony-o i think it would work that way ideally
19:29 Kassandry joined #perl6-toolchain
19:29 tony-o since hte repo is really describing the storage mechanism,
19:34 nine ugexe: I think I'm misunderstanding something there. Do you mean that the Distribution classes can share the .content method? That doesn't seem likely as your own gist show two very different implementations. So I guess you mean something else?
19:36 ugexe Distribution is just an interface requiring a .meta and .content(*@keys) method. How each type of Distribution retrieves the data with .content is not important to the CompUnit::Repository, it just needs to know how to use that interface to get at the actual data
19:38 tony-o s/repo/distro/
19:42 nine Ah, now I got it :)
20:51 FROGGS joined #perl6-toolchain
21:30 sjn \o
22:16 sjn nine: ping
22:19 ugexe zef can `--dry install Module::With::DepenenciesToGet` once again
22:46 tony-o ++

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