Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2017-07-05

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

All times shown according to UTC.

Time Nick Message
00:09 lizmat joined #perl6-toolchain
01:49 ilbot3 joined #perl6-toolchain
01: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:23 domidumont joined #perl6-toolchain
16:49 ugexe nine: how would I write a dependency for a version range of rakudo (by-vm.version ?)
16:51 nine ugexe: that's a dreaded topic, isn't it?
16:52 ugexe m: say $*VM.version.Str.substr(0, 7); # it would be easy enough if there was access to a substring
16:52 camelia rakudo-moar d7e104: OUTPUT: «2017.06␤»
16:54 nine But that's MoarVM's version?
16:55 ugexe there is one for rakudo too though, but its the same deal i think
16:56 domidumont joined #perl6-toolchain
16:57 ugexe depends => runtime => [ { :name<rakudo>, :from<native>, hints => { "by-perl.compiler" => { ...? } } ]
16:58 nine Is this a workaround for us failing to release a 6.d some time this decade?
17:00 ugexe well for me to remove all the hacky proc workarounds for pre-2017.06 I have to make changes that wont work on older rakudo. something like this could allow zef on older rakudos to not upgrade past what they are capable of using
17:01 mst surely you could write a slang that gives you compiler-version-based ifdefs
17:24 nine Maybe what we actually need is this: https://metacpan.org/pod/CPAN::Meta::Spec#conflicts1
17:24 nine Since while you don't know on which versions of which Perl 6 compilers the code will work, you do know that on some very specific versions of rakudo it will not.
17:26 ugexe you still need a range
17:27 ugexe which is what i'm wondering how we declare in the hints
17:31 ugexe sure, but i'd like to avoid that route for as long as possible - panda would just version itself after rakudo versions for instance - to avoid all the cruft that leaves behind
17:31 ugexe re: ifdefs / wrappers
17:32 nine That would be https://metacpan.org/pod/CPAN::Meta::Spec#Version-Ranges
17:33 ugexe but how to write it as a *dependency hint*
17:34 ugexe we would have to define a "version" key means turning it into a version object
17:35 ugexe er, you're saying to use that in conflicts, but it would still need to be written in that dependency hint format I assume
17:35 nine In your case it's not just a hint, is it? You know the code will not run on those rakudo versions.
17:36 ugexe thats the case no matter where i put it
17:37 ugexe but this is mostly for someone upgrading zef
17:38 ugexe their old version of zef would check the hints, see it can't run on that native depends (missing), and look for a version it can
17:38 nine I wonder if this would warrant a whole new section in the META file. Thing is, if we add a way to positively depend on some compiler version, there will in some future be a compiler that has to pretend to be rakudo to be able to run software. Because people are lazy.
17:39 nine If there's only a way to exclude certain versions of specific compilers, newcomers won't have any issues.
17:40 nine Btw. I guess nothing we come up with now will help users of old zef versions trying to upgrade beyond their rakudo's capabilities, because those old zef versions won't understand what we do anyway.
17:41 ugexe true. in my case i depend on rakudo::internals so its not as much an issue
17:41 nine Unless we specifically break their META parser...
17:41 nine Then they won't be able to install the new zef, but also won't tell the user why :)
17:41 ugexe not true. Build.pm can be used. what we cant do is have zef automatically upgrade to the latest they can use
17:42 ugexe oh that
17:44 nine On a slightly different topic: I think we could drop the old Distribution compatibility crap in rakudo. AFAIK only panda used it as a class and panda doesn't seem to work anymore anyway.
17:45 ugexe i suppose if zef sent user agent strings the ecosystem could choose what dists to display. essentially if no user agent is sent it would remove the *new stuff* from the meta data and apply whatever logic it can
17:45 nine Perfect backwards compatibility was a pipe dream anyway and we've broken it many times already.
17:46 nine ugexe: sounds like a lovely workaround where we stay in control :)
17:54 ugexe another more interesting problem i'm facing is how to treat a distribution that is both Distribution::Tar but also Distribution::Remote. the naive approach is just to get the Distribution::Remote to then build a Distribution::Tar from locally, but i'd like to handle it such that it can be done A) without creating a local file B) where the ::Remote logic can be reused with say ::Unzip and ::Tar can be
17:54 ugexe reused locally
17:56 ugexe so something like `Distribution::Tar but Distribution::Remote(&logic-for-fetching)`?
17:58 ugexe or maybe the other way around? I suppose it could possible be both tar'd and zip'd for some insane reason
18:09 ugexe another design problem i'm having is with `Distribution.meta<name|ver|auth>` and remote distributions. ideally i'd be able to do `Distribution::Remote::GitHub.new(:url<...>, :meta(:name<Foo::Bar>, :ver<0.1>)).meta<name>` without it having to connect to the url to get the meta data (because we already assume to know the name), but doing so on `.meta<name>` itself (instead of some `method name { $.name
18:09 ugexe // self.meta<name>> }`)
18:10 ugexe while still having say .meta<provides> or .meta<depends> fetch the meta data since we do not have any such hash keys defined in %.meta
18:10 ugexe so probably a Proxy object?
18:15 ugexe something like `has %.meta but role :: { multi method AT-KEY($key where {not defined %.meta<< $key >>)}) { self = self!fetch-meta_($url); nextsame() } }`
18:22 ugexe even better if it could warn if any values change from a undefined value to a defined value - e.g. this Distribution was created with :version<0.1.0> as declared by the ecosystem, but the meta data was actually fetched the :version was changed to :version<0.1.9>
18:23 ugexe s/from a undefined/from an already defined/
18:26 nine I'd probably write someting doing the Associative role and delegating all but the special keys to the contained meta data hash.
18:28 nine On that note, Distribution.meta should actually not return a Hash but an Associative, too.
18:29 ugexe m: class Foo { has %.hash handles <AT-KEY>; multi method AT-KEY($key where {$_ eq 'foo'}) { say "Got foo"; nextsame(); }; } # this is what I was trying
18:29 camelia rakudo-moar b3c14c: OUTPUT: «Resource temporarily unavailable»
18:29 nine And all implementors should return a Map rather than a Hash
18:29 ugexe ===SORRY!5=== Error while compiling <tmp>␤Package 'Foo' already has a method 'AT-KEY' (did you mean to declare a multi-method?)
18:32 ugexe if those all serialize to json the same then i don't see a reason not to return something else
18:32 ugexe i guess the spec only returns .meta to return a hash though, so the json bit is irrelevant
18:32 ugexe only expects^
18:36 ugexe another breaking change we might consider is %?RESOURCES returning a IO::Handle (or a fake one like .content) instead of an IO::Path - right now you can have a Distribution that installs all source files using data from a socket but you *have* to have resources stored locally because they only give you a path
18:38 ugexe https://github.com/ugexe/Perl6-CompUnit--Repository--Tar/blob/master/lib/CompUnit/Repository/Tar.pm6#L113 - here is an example where CUR::Tar has to extract the resource files from the archive to some tmp location whereas the source files bytes are piped directly from tar
18:39 nine ugexe: the lovely thing about %?RESOURCES is that we can actually change it in a lexical scope :) So we can stay backwards compatible with 6.c in that case :)
18:40 ugexe how so?
18:43 nine It's implemented in Perl6::Actions which creates the Distribution::Resources object backing it. At that point it can do things differently depending on the lexical scope's current language version, so instead it could create a Distribution::Resources::LikeItShouldHaveBeen object.
18:45 ugexe i think it would mostly work if it returned the Fake::Handle that stringified using its :path attribute
18:45 ugexe depends on the differences between IO::Handle and IO::Path methods I guess
18:47 nine Why stringify to a path at all?
18:48 ugexe so `require %?RESOURCES<foo>` still works
18:49 ugexe (i think that works anyway)
18:50 nine That sounds terrible?!
18:50 nine Why would we want to support that?
18:51 ugexe not saying we do, this is just from a backwards compatible perspective
18:51 nine Which we don't have to use, as 6.c code will still get the old path based %?RESOURCES
19:04 ugexe right, i mean a backwards compatible change that can also implement the new functionality *in 6.c*
19:04 ugexe not that I care if it waits till 6.d
19:50 ugexe https://gist.github.com/ugexe/8817d4244fe13b6a6be33e2026fb8a0d
20:24 FROGGS joined #perl6-toolchain
23:02 b2gills joined #perl6-toolchain

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