Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-02-02

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

All times shown according to UTC.

Time Nick Message
03:09 llfourn_ joined #perl6-toolchain
03:31 Kassandry joined #perl6-toolchain
03:37 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: https://github.com/tony-o/perl6-kangaroo/blob/master/lib/Kangaroo/Plugins/Interface.pm6#L14
03:42 tony-o_ 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:43 autarch tony-o_: the whole point of what I'm working on is to make parsing TAP unnecessary
03:43 autarch that was a mistake made in p5 space that we should not repeat
03:43 autarch so there's no handling of $*IN or $*OUT needed
05:00 tony-o_ autarch: agreed, i suggested we do away with it when i first did green. there wasn't much of a response
05:01 tony-o_ doing away with TAP, anyway
05:01 autarch tony-o_: see https://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
05:01 tony-o_ i'm taking a look at it now
05:02 tony-o_ autarch: the Kangaroo thing could work with this as well
05:03 * [Coke] hugs mst.
05:04 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:06 tony-o_ autarch: where is this commincating events cross process?
05:06 autarch tony-o_: I haven't written that part yet
05:07 tony-o_ is the plan to use fpipes ?
06:59 domidumont joined #perl6-toolchain
07:05 domidumont joined #perl6-toolchain
07:27 autarch tony-o_: actually, i was going to try network sockets first - that'll work for threads or forks
08:27 FROGGS joined #perl6-toolchain
08:42 leont joined #perl6-toolchain
09:12 leont joined #perl6-toolchain
10:29 domidumont joined #perl6-toolchain
13:00 domidumont joined #perl6-toolchain
13:24 domidumont joined #perl6-toolchain
15:13 MadcapJake joined #perl6-toolchain
15:39 lizmat joined #perl6-toolchain
16:29 [Coke] https://trac.macports.org/ticket/50158
16:29 [Coke] mojca could use some help getting a panda macport working.
16:53 mojca joined #perl6-toolchain
17:06 autarch1 joined #perl6-toolchain
17:21 lizmat joined #perl6-toolchain
17:23 autarch joined #perl6-toolchain
17:27 nine I wonder, if there is a sane way at all to package module dists right now.
17:31 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 mojca it's just that panda still has some minor issues
17:33 nine If you can package panda, you can package any Perl 6 module as panda is mostly just that
17:33 nine To be precise: building in a different directory that the installation target is what is hard about this.
17:36 nine 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 nine 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).
17:37 nine 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 nine The .rev-deps files should be replaced by directories where you can simply drop in the additions.
17:38 nine Those are from my experience so far the two most important changes to rakudo to allow for sane packaging of modules.
17:40 nine 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?
17:41 mojca I could provide hardcoded path names to the proper / final location
17:42 mojca sadly I don't know enough about how all the components of perl6 work
17:45 nine I added my thoughts to https://github.com/perl6/toolchain-bikeshed
17:46 nine mojca: if you give me your github user name, I can add you to that repo
17:48 mojca it's the same
17:52 patrickz joined #perl6-toolchain
17:53 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
17:53 nine rakudo's docs/module_management.md
17:54 mojca I don't understand almost anything in "packaging issues" from https://github.com/perl6/toolchain-bikeshed
17:54 mojca I'll take a look at rakudo
17:56 mojca shortly, does all that mean that packaging panda in a package manager is still [highly/somewhat] problematic?
17:59 nine yes
18:28 ugexe joined #perl6-toolchain
18:35 Kassandry joined #perl6-toolchain
18:46 domidumont joined #perl6-toolchain
18:55 hankache joined #perl6-toolchain
19:00 lizmat joined #perl6-toolchain
19:06 FROGGS joined #perl6-toolchain
19:14 nine joined #perl6-toolchain
19:16 autarch joined #perl6-toolchain
19:35 hankache joined #perl6-toolchain
21:15 tony-o_ nine: https://github.com/tony-o/perl6-http-server-async/issues/21#issuecomment-178819081
21:15 tony-o_ nine: any ideas on what would cause this?
21:16 nine Is it possible that those two distributions both contain an HTTP::Response?
21:16 tony-o_ most likely
21:18 nine Yes, both HTTP::UserAgent and HTTP::Server contain a HTTP::Response
21:19 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:23 nine That would solve only a single symptom.
21:23 nine Anyway, we already have all we need for that: :auth
21:24 nine 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?
21:25 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:26 ugexe in those cases yes, you would put an auth. because its not the common usage
21:27 ugexe 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.
21:28 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.
21:28 ugexe HTTP::UserAgent would load its own http request...
21:29 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
21:31 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:32 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:33 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
21:35 ugexe no one says it is not. but i will say its not a solution to this problem
21:37 nine Also a module is only part of a dist when it's installed. That makes for different behavior between development and production
21:39 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 #perl6-toolchain
22:37 stmuk_ joined #perl6-toolchain
23:44 lizmat joined #perl6-toolchain
23:46 leont joined #perl6-toolchain

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