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 25 January 2016.
03:09 llfourn_ joined 03:31 Kassandry joined
tony-o_ nine autarch: I have a testing multiplexer I've been working on during flights. The TAP parsing needs work but the multiplexing/reporting on tests is pretty solid. Check it out: github.com/tony-o/perl6-kangaroo/b...ce.pm6#L14 03:37
autarch: i attempted the cross process hub thing with an event emitter type deal a while ago and was told that the $*IN/$*OUT stuff wouldn't be corrected to work cross thread, I'm not sure if that is still the case, that was around 4 or 5 months ago. If that is the case then getting something to communicate cross process without threading can becomeone somewhat of a mess unless you are willing to make [imo] big us 03:42
autarch tony-o_: the whole point of what I'm working on is to make parsing TAP unnecessary 03:43
that was a mistake made in p5 space that we should not repeat
so there's no handling of $*IN or $*OUT needed
tony-o_ autarch: agreed, i suggested we do away with it when i first did green. there wasn't much of a response 05:00
doing away with TAP, anyway 05:01
autarch tony-o_: see github.com/autarch/perl6-Test-Stream - it's all working so far, though I think there are a few parts that I need to rethink
tony-o_ i'm taking a look at it now
autarch: the Kangaroo thing could work with this as well 05:02
[Coke] hugs mst. 05:03
tony-o_ kangaroo was more of a way to perl6ify 'prove', it's built in a way that integrating Test::Stream would be very little effort, 1 or 2 lines 05:04
autarch: where is this commincating events cross process? 05:06
autarch tony-o_: I haven't written that part yet
tony-o_ is the plan to use fpipes ? 05:07
06:59 domidumont joined 07:05 domidumont joined
autarch tony-o_: actually, i was going to try network sockets first - that'll work for threads or forks 07:27
08:27 FROGGS joined 08:42 leont joined 09:12 leont joined 10:29 domidumont joined 13:00 domidumont joined 13:24 domidumont joined 15:13 MadcapJake joined 15:39 lizmat joined
[Coke] trac.macports.org/ticket/50158 16:29
mojca could use some help getting a panda macport working.
16:53 mojca joined 17:06 autarch1 joined 17:21 lizmat joined 17:23 autarch joined
nine I wonder, if there is a sane way at all to package module dists right now. 17:27
mojca nine: if that was a reply to my ticket, all I want is to have a minimal installation of perl6 and panda; I would suggest installing modules "by hand" with panda 17:31
it's just that panda still has some minor issues
nine If you can package panda, you can package any Perl 6 module as panda is mostly just that 17:33
To be precise: building in a different directory that the installation target is what is hard about this.
For packaging you will want to build in a temporary directory with an unprivileged user, package the resulting files and make installation mostly just extracting of the resulting archive. 17:36
Right now installing a dist creates files with hard coded path names (precomp files pointing to their sources) and changes already installed files (additions to the .rev-deps files).
For precompilation we're gonna need a way to provide the source file and the path for $?FILE separately to the precomp process. 17:37
The .rev-deps files should be replaced by directories where you can simply drop in the additions.
Those are from my experience so far the two most important changes to rakudo to allow for sane packaging of modules. 17:38
Oh and the files in short/ have the same issue as the .rev-deps files. They should probably also be replaced by directories which unfortunatly will incure some runtime cost :/ 17:40
mojca ok, so this means that rakudo needs some changes first; would you be willing to summarize that in a ticket somehow?
I could provide hardcoded path names to the proper / final location 17:41
sadly I don't know enough about how all the components of perl6 work 17:42
nine I added my thoughts to github.com/perl6/toolchain-bikeshed 17:45
mojca: if you give me your github user name, I can add you to that repo 17:46
mojca it's the same 17:48
17:52 patrickz joined
mojca is there any description about how panda works (not what it does, but how and where the files get renamed and installed) 17:53
nine added
rakudo's docs/module_management.md
mojca I don't understand almost anything in "packaging issues" from github.com/perl6/toolchain-bikeshed 17:54
I'll take a look at rakudo
shortly, does all that mean that packaging panda in a package manager is still [highly/somewhat] problematic? 17:56
nine yes 17:59
18:28 ugexe joined 18:35 Kassandry joined 18:46 domidumont joined 18:55 hankache joined 19:00 lizmat joined 19:06 FROGGS joined 19:14 nine joined 19:16 autarch joined 19:35 hankache joined
tony-o_ nine: github.com/tony-o/perl6-http-serve...-178819081 21:15
nine: any ideas on what would cause this?
nine Is it possible that those two distributions both contain an HTTP::Response? 21:16
tony-o_ most likely
nine Yes, both HTTP::UserAgent and HTTP::Server contain a HTTP::Response 21:18
ugexe i wonder if we can make a module in a distribution prefer its own `provides` if there are multiple candidates for an identity 21:19
nine That would solve only a single symptom. 21:23
Anyway, we already have all we need for that: :auth
But really, I don't think this is a good example case where :auth is a good solution. We should be able to coordinate better. 21:24
ugexe but why should you have to auth your own modules in a distribution?
nine Because what you suggest is a policy that may not be the right one for all use cases. What if a distribution just contains a pure Perl fallback for one of its optional dependencies? 21:25
ugexe in those cases yes, you would put an auth. because its not the common usage 21:26
i just dont see how defaulting to the distribution it came as a part of is not better than defaulting to whatever it encounters first in a json file 21:27
nine Really what we need is better tooling on the repository side to avoid accidents like this. If one makes a conscient decision to publish a module under the same name as another one hopefully has a good reason.
ugexe i think the entire point of the auth/ver is to solve exactly that. but there still has to be default behavior for `use Vague::Identity;` 21:28
nine Because it hides a problem. It doesn't solve it in any way for other users of those modules. You install HTTP::Server and suddenly your HTTP::UserAgent using code doesn't work correctly anymore.
ugexe HTTP::UserAgent would load its own http request...
nine Yes, but non-HTTP::UserAgent code would be broken. 21:29
ugexe non-http useragent code is the code that should be using auth/ver
nine So basically all Perl 6 use statements need to contain auth and ver except for the couple where a module from the same dist is loaded. 21:31
ugexe the alternative seems to be make people give a good reason for using the same name as someone else. i think expecting users to be explicit about their use statements is a good thing 21:32
nine Coordination of authors to not overload the same names with different meanings is also a good thing to have in a module ecosystem. 21:33
ugexe if you aren't explicit, you don't know what happens. but because consistent behavior is needed for when those practices are not used I think its more consistent to use the current distribution candidates first than to use whatever random dist was installed first
no one says it is not. but i will say its not a solution to this problem 21:35
nine Also a module is only part of a dist when it's installed. That makes for different behavior between development and production 21:37
tony-o_ doesn't it search 'lib' first? wouldn't that be similar to using your own version over another's during development? 21:39
nine interesting point
22:01 leont joined 22:37 stmuk_ joined 23:44 lizmat joined 23:46 leont joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!