Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
00:22 llfourn joined #perl6-toolchain
01:23 llfourn joined #perl6-toolchain
02:22 llfourn joined #perl6-toolchain
02:48 ilbot3 joined #perl6-toolchain
02:48 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:23 llfourn joined #perl6-toolchain
04:24 llfourn joined #perl6-toolchain
05:09 llfourn joined #perl6-toolchain
07:37 nine sjn: pong
08:08 FROGGS joined #perl6-toolchain
09:27 leont joined #perl6-toolchain
11:44 FROGGS joined #perl6-toolchain
14:14 domidumont joined #perl6-toolchain
14:57 domidumont joined #perl6-toolchain
15:48 nine What do toolchain people think about moving Test.pm from the CORE distribution out into the ecosystem? Rakudo could still come with a Test.pm for its make test and make spectest, but no longer install it by default.
15:48 moritz -1
15:48 tony-o nine++
15:49 moritz I use Test.pm in every single one of my projects, and I'd hate to install a dependency
15:49 moritz users can still distribute their Test::More, Test::Less, Test::Fancy, Test::Whatever, just like in p5
15:49 nine With it being an ecosystem module, it would be much easier to upgrade or to require a specific version. There's nothing that actually requires us to bind Test's version to the Perl 6 version.
15:49 tony-o i think it's more common now than when p5 came about
15:50 nine lizmat has to revert an otherwise harmless fix to Test.pm because it breaks a spec test for unknown reason.
15:50 tony-o actually, i guess, i'm with moritz - most languages don't have a supercedes mechanism
15:50 moritz can we make it dual-lived at least?
15:50 [Coke] we could try to fix the breakage, btw.
15:50 moritz installed with core, but overridable from panda
15:50 [Coke] (dual lived) aaaaaigh
15:51 [Coke] that won't address nine's concern, and will add complexity. -1
15:51 nine Of course we will try to fix this, but the principle remains. Having Test in the ecosystem would allow for quicker turnarounds with for example added features. Waiting for a year for a language release to be able to use a new test function sucks.
15:52 tony-o i like the idea of removing it from core.
15:52 nine Especially since people who know Perl 5's test frameworks think Test.pm is severly outdated architecture wise
15:53 tony-o i can see mortiz's point and right now it makes sense to leave it in core or every module will fail testing, currently and all METAs will need updated
15:53 [Coke] also it changes what 6.c means. we'd need a 6.c.1 or so
15:53 tony-o `green` behaves more like node's mocha
15:55 tony-o which is friendlier for async things
15:55 nine [Coke]: we may still get away with removing it even from 6.c by having panda and zef add it automatically to a module's test-depends until all META files have been updated
15:55 moritz nine: I do test modules without panda
15:55 nine But we may as well remove it in 6.d
15:56 nine moritz: but installing one ecosystem module once per Perl 6 installation doesn't sound that bad, does it?
15:56 [Coke] there are Test tests in 6.c; I think we're on the hook to include it for now
15:56 nine moritz: keep in mind that we no longer loose installed modules on rakudo upgrades
15:56 sjn nine: are you going to the easter hack thing in Salzburg?
15:56 nine sjn: have never heard about that?
15:56 PerlJam nine: we wouldn't remove it in 6.d would we?  We'd deprecate it and remove in 6.e.  right?
15:56 tony-o PerlJam++
15:57 sjn nine: Easterhegg 2016 - http://www.easterhegg.eu/category/easterhegg-2016/
15:57 [Coke] or dep in 6.c.1 and remove in 6.c.2
15:58 moritz nine: does panda still work after a rakudo upgrade?
15:58 nine moritz: yes it does
15:59 moritz nine: then maybe it's no as dire as I imagined it :-)
15:59 nine moritz: only the first startup after a rakudo upgrade is a little slow
16:00 PerlJam [Coke]: or that  (though, I'm not clear on the timing of these point releases.  If they happen too quickly, then I'm against using them for a deprecation cycle)
16:00 nine PerlJam: I'm not sure if it would warrant a deprecation cycle (we're talking about a year or more there!), as it's really just a "panda install Test". And our installers may even do that automatically.
16:03 PerlJam nine: I dunno.  I worry a bit about setting precedent here.  Would we do the same thing if it were IO::Socket::Async or one of the other core modules?
16:04 [Coke] PerlJam: you mean like the one that we're already trying to remove in nom?
16:05 PerlJam [Coke]: Are you referring to IO::Argfiles?
16:05 [Coke] I don't remember which one it was.
16:07 nine IO::Socket::Async is no module but part of the setting and a part of the language that's tested by the spec test suite. We've been shipping a Test.pm as convenience. It's not integrated at all with the rest and is really the odd man standing out.
16:07 lizmat Pod::To::HTML ?
16:07 lizmat sorry, Pod::To::Text ?
16:09 PerlJam nine: I guess if there are no tests in roast/6.c that test Test.pm6, then removing it should be harmless.
16:10 PerlJam (and I probably should have put scare quotes around harmless too)
16:11 flussence um, don't 100% of the tests in roast also test Test.pm6 by definition, since they use its API?
16:11 ugexe i prefer having a basic tap emitter in core. i dont like the idea that it makes it harder to just test/install something without having a module installer
16:11 PerlJam flussence: I'd call that more of a side-effect.
16:12 nine > 80 ecosystem modules have already a test-depends: [ "Test" ]
16:12 ugexe that doesnt mean anything if its built in though
16:13 ugexe if i just want to clone someones project and install it now it means i have to also install Test.pm somehow or have a module installer installed
16:14 PerlJam ugexe: How would you install someone's project without a module installer?
16:14 nine I don't see how after going through all of rakudo's installation, getting one extra file from somewhere would be such a large barrier.
16:14 ugexe PerlJam: you can do it with a 1 liner using CompUnit::Repository
16:15 nine Rakudo is the compiler. Rakudo* is the usefull distribution with compiler + modules
16:15 PerlJam ugexe: and it'll auto-run any tests?
16:15 PerlJam ugexe: and you can't tell it not to?
16:16 ugexe no, someone doing that would certainly run their own prove command manually as well
16:16 nine PerlJam: the one liner will install. It won't run tests or check dependencies.
16:17 ugexe right, but to write any testable module you would then *have* to have a dependency
16:19 ugexe maybe im in the minority but im not a fan of huge fragile dependency chains
16:19 nine Why should they be fragile?
16:19 ugexe they shouldnt but generally are
16:20 nine In Perl 6? We support and encourage people to depend on exact versions.
16:21 nine Aaand if that support is NYI it will probably come soon ;)
16:21 ugexe yes in perl6, and i also mean at the moment (in the future im sure this gets better as well)
16:28 PerlJam nine: I'm conflicted.   I'm sympathetic to your argument, but I also think Test.pm6 should just Be There.  We're going to use some test module anyway (and encourage others to do so); one should be included as part of any Rakudo installation.  It's one of the things I really like about how we do things now.
16:33 PerlJam Same goes for NativeCall btw.  That one opens up huge possibility and should be part of any Rakudo install.  Would you rather add that as a dependency to Inline::Perl5 or just rely on it being there?
16:35 autarch nine: big ++ on getting Test.pm6 out of core
16:35 PerlJam autarch: why?
16:35 autarch I'm really hoping that I can get this test stream stuff done soonish and have that be the basis for all future test modules
16:36 autarch PerlJam: because if people use a module not based on this test stream code I'm working on then it'll make everyone's life harder down the road
16:36 PerlJam Hmm.
16:38 ugexe but it makes everyones lifes harder no matter what
16:40 ugexe you either make it harder for end users or you make it harder for people who write tests but plan on porting it to your stream format
16:40 nine PerlJam: I wouldn't mind a dependency in Inline::Perl5 at all and indeed, NativeCall has been an ecosystem module initially. It only got moved to core because most of its implementation is actually in the VM, so it's really tighly coupled to the compiler. The opposite of Test.
16:41 nine PerlJam: and Inline::Perl5 already has dependencies. No reason to avoid others.
16:42 nine ugexe: autarch's plan is to provide a Test module that has the same interface but uses the stream module for it's underlying implementation. So no pain for test writers.
16:42 tony-o that changes module installers method of installs
16:42 ugexe he just said it would be harder
16:42 tony-o test-depends: ["Test"] <- if test isn't available or installable, do you install the module or fail ?
16:42 tony-o i'm curious more about down stream
16:43 ugexe and this all seems like the type of thing supercedes/augments/emulates of s22
16:43 ugexe is meant to address
16:43 tony-o i brought that up earlier
16:45 PerlJam autarch: If we replace the exising Test.pm6 with one based on your test stream stuff, then it'll only make things harder for those people using a compiler that uses the existing Test.pm6 (which will be an ever-shrinking set)
16:46 nine tony-o: the test-depends question is independent of this dicussion. Inline::Perl5 for example has a test-depends: ["Test", "File::Temp"] as one of the tests uses File::Temp.
16:46 * autarch is in a $work meeting, will catch up and respond when done
16:46 tony-o nine: i know it's separate, i'm curious what the thoughts are on that.
16:47 PerlJam autarch: but ... you've got me thinking about Test::* and interoperability and I think you've tipped the balance for me in favor of removing Test.pm6.
16:47 tony-o thank you for pointing out that it's separate
16:47 nine tony-o: I guess it should either ask the user or treat it as --notests
16:47 nine "it" being a missing test dependency
16:48 nine The "supersedes" angle is interesting. I wonder how using that feature would play out in real life.
17:11 [Coke] Note that we have S24-testing/ tests, but those seem to just be explicit versions of the implicit testing. I don't think they're actually testing TAP output or anything like that.
17:12 [Coke] ... crap, except 3-output.t, which is an explicit test for things like "does the output match "not ok"
17:12 [Coke] so yes, we rely on TAP in 6.c
17:15 autarch PerlJam: I don't think it should be removed so much as removed from the docs and marked as "only use this internally for testing other core stuff"
17:15 nine Maybe this really would be a good test case for all the speculation about auths and supersedes and what not? A first step could be to just publish an updated Test module under different auth in the ecosystem and have some dists require that.
17:16 autarch nine: I could rename my stuff from Test::Stream to just Test if we think that's a good idea
17:16 nine autarch: my suggestion was not removing it entirely from Rakudo but no longer installing it by default.
17:16 autarch nine: right, that makes sense
17:16 nine .oO(Test:auth<autarch>)
17:17 autarch I mean once my test stream is _done, reviewed, and documented_ I could rename it and we could put it into the ecosystem
17:17 autarch with a "use Test" layer that works more or less exactly how the current one does, which I've already started writing as Test::Predicates in the repo
17:17 autarch my repo, that is
17:40 leont joined #perl6-toolchain
17:48 nine ugexe: Failed to copy '/home/nine/.zef/store/Inline-Perl5.git/resources/libraries/p5helper' to '/home/nine/rakudo/install/share/perl6/site/resources/42895AB4F020BCF13D71DFC98C445CD8CD3B4206.': Failed to copy file: no such file or directory
17:51 nine ugexe: with zef commit 499d47bda621c0bdd0e7b15f218d9e8f19fda247
18:02 Kassandry joined #perl6-toolchain
19:56 ugexe strange, it works for me. i've been using install Inline::Perl5 after each commit to test too
20:00 nine I thought you'd have done that. Especially since you mentioned Inline::Perl5 in the commit message.
20:05 ugexe i wonder if it could have something to do with `$*VM.platform-library-name($0.Str.IO)` turning a basename only into an IO (which involves some $*CWD stuff)
20:06 nine same on my desktop
20:40 ugexe m: say $*VM.platform-library-name($*CWD.relative.IO)
20:40 camelia rakudo-moar 007f02: OUTPUT«"/home/camelia/lib..so".IO␤»
20:40 ugexe m: say $*VM.platform-library-name($*CWD)
20:40 camelia rakudo-moar 007f02: OUTPUT«/home/libcamelia.so␤»
20:41 ugexe other than the path differenence one returns a string and one returns an IO
20:42 lizmat ugexe: this won't be fixed before 6.d, I'm afraid
20:45 nine What's the difference to what panda's doing? The code looks quite similar ;)
20:47 ugexe passes in the absolute path instead of giving `.IO` a chance to get the $*CWD incorrect
20:48 ugexe well, what i want the path absolutified with (which might not be $*CWD)
21:07 hankache joined #perl6-toolchain
22:01 ugexe travis-ci is able to install Inline::Perl5 with zef as well
22:02 ugexe https://travis-ci.org/ugexe/zef/jobs/102204480#L1771-L1774
22:26 leont joined #perl6-toolchain

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