Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2017-08-16

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

All times shown according to UTC.

Time Nick Message
01:52 ilbot3 joined #perl6-toolchain
01:52 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
06:18 domidumont joined #perl6-toolchain
06:25 domidumont joined #perl6-toolchain
07:09 nine ugexe: what would we have to do to create the rest of the %!meta?
10:08 llfourn joined #perl6-toolchain
14:06 domidumont joined #perl6-toolchain
14:55 ugexe we want to fill out defaults - name (probably $!prefix or $.path-spec), ver/api (0), perl (6.*) - and generate provides/files. to generate provides/files it has to make assumptions: that if $!prefix/../resources or $!prefix/../bin exist that they belong to the distribution and should have DIR-RECURSE called on them (from which we can generate provides/files)
14:56 ugexe we already make this assumption for resources/
14:56 ugexe for -Ilib to use %?RESOURCES
14:57 ugexe the alternative, as I have also mentioned, is taking %?RESOURCES from -Ilib and quit treating this as a distribution
14:58 ugexe but I think by creating the entire distribution meta its ok to do the ../ thing, because the info to see what was actually used is now available in the CompUnit.distribution
15:04 nine This will cost a bit of performance though
15:05 ugexe for what?
15:05 nine recoursing into additional directories
15:06 ugexe well we already recurse the "lib" to get the CURFS id. technically we should recurse "resources" too since its being used. so its really only additionally recursing bin/
15:07 nine I don't think we have to recurse into "resources" as those will be loaded at runtime, won't they?
15:09 ugexe yeah I suppose I'm not sure about technically afterall. however - this would appear to be the case for -I. already
15:10 nine Oh, also we only consider .pm and .pm6 files anyway
15:11 nine https://github.com/rakudo/rakudo/blob/nom/src/core/CompUnit/Repository/FileSystem.pm#L66
15:11 ugexe right, but only for slurping. the same amount of looking still happens
15:12 ugexe heh also it should check .pm6 first now, since that will be chosen over .pm
15:15 ugexe if the penalty is too high we can always do meta lazily like in the .candidates PR
15:17 ugexe with a .candidates in CURFS and CURI though it makes writing plugin systems much easier
15:19 ugexe i really wouldnt be against changing .installed to .available, and then giving that method to CURFS as well
15:21 nine We could also keep .installed and have it forward to .available.
15:22 ugexe yeah. i wouldnt mind .installed in CURFS either... but something does feel off about it
15:24 ugexe BUT im also not against CURFS having a .install either, that essentially just does a cp into a sha1 directory
15:24 nine What would be the use case?
15:26 ugexe when you -just have to- keep all the original file naming stuff or something.
15:26 nine But why would you? :)
15:26 ugexe some plugin local lib type thing that retains original paths so its still human navigatable
15:27 ugexe the only reason I know of we need to fix in CURI anyway - DLL names
15:27 nine For that Punycode will be the proper solution.
15:29 ugexe yeah. however, I would ask what is the big drawback? the method itself should just be a `copy $dir1 $dir2`
15:30 nine I very much prefer designing APIs where I know the use cases they are meant for. APIs tend to become much more useful that way. Especially in software where we have to support such APIs for a very long time.
15:31 ugexe fwiw these api proposals are all implementations in zef already
15:33 ugexe you could then easily (nearly) round-trip back distributions doing things like $my-curfs.install($curi.need("Zef").distribution)
15:36 nine While in this case the interface is actually already designed, the semantics are not. E.g. what happens with the META data? What happens if a META6.json file is already there? Same for module files.
15:36 lizmat joined #perl6-toolchain
15:37 ugexe I do not understand. These are all problems that already exist
15:38 nine But CURFS doesn't have an .install method yet?
15:38 ugexe install takes a Distribution, so it would have all neccesary data
15:39 ugexe if the directory isn't empty, then yes this would be foolish. dont install (like git wont clone into non-empty dir) or let them be foolish
15:40 ugexe this is why i liked the name .store better
16:19 ugexe that type of decision already has a place though - method can-install() { }
16:20 ugexe method can-install() { (!$!prefix.e && $!prefix.mkdir) || ($!prefix.w && !Rakudo::Internals.DIR-RECURSE($!prefix).elems) } for example
17:05 ugexe hmmm, a bug report just revealed an issue with CUR:RR.run-script - it doesn't work if you have non-perl6 scripts in your bin/
17:30 nine But did that work before?
17:38 ugexe ah right, it still used $*EXECUTABLE so it must have never worked
17:40 nine Also it's kinda sad that people ship non-perl6 scripts considering how lovely Perl 6 is for writing CLI programs...
17:47 ugexe (try require "$bin") || shell($bin); # theres always the 'fuck it' way
17:55 nine Well "it" in that case is "debugging" :)
17:56 ugexe its more "how do you guess if bin/foo is a perl6 script or not"
17:58 mst check the #! line would seem like a good answer
17:59 ugexe right, need heuristics for when people use .pl6 and whatnot as well
18:00 nine If we want to support that
18:31 ugexe if it can be handled by 2 lines of code checking just the extension and shebang, i think its reasonable to support it. but ive no idea if thats good enough or not
18:36 ugexe https://rt.perl.org/Public/Bug/Display.html?id=131911
18:45 ugexe as for why to support it, I would guess its because they havent considered how to do what they want with %?RESOURCES (assuming what they want is to provide bin scripts to be used as tools for their dist and not neccesarily make them invokable by name)
18:49 ugexe e.g. run( %?RESOURCES<scripts/perl5tar.pl> )
18:51 nine I have the nagging feeling that this looks deceptively simple. It is a heuristic, so it will be wrong in some odd cases.
18:51 ugexe what if we make it required to declare bin scripts... is there some info they could also be required to add that solves this?
18:53 ugexe or rather, required if you dont want it to blow up like this
18:54 nine Having a separate directory for arbitrary scripts or requiring some META info sounds much more sustainable.
18:54 nine Of course non-Perl 6 scripts won't support installation of multiple versions
18:56 ugexe why not? the scripts get installed individually due to name hashing, so I would think the wrapper just needs to know if it should launch require $some-path or shell $some-path
18:57 nine Oh, of course, if we still have a Perl 6 wrapper, then we're fine
18:59 ugexe right, the name of the wrapper would be disingenuous for them if they have a file extension, but it should still work
19:00 ugexe now, how does windows fuck this up
19:33 ZofBot joined #perl6-toolchain
20:14 awwaiid joined #perl6-toolchain
23:47 stmuk_ joined #perl6-toolchain

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