Open vrurg opened 3 years ago
As to my view there are only two possible solutions:
Inline::Perl5
into RakudoRe 1. the Inline::Perl5 spec tests are run when Inline::Perl5 is installed. They should be able to run correctly regardless of the version of Inline::Perl5 installed. Whether that is done by adapting tests to the Inline::Perl5 installed, or not do any Inline::Perl5 version specific tests at all, is I guess in the end, the question.
I'm equally ok with both ways. The 1 could be done in a way of reducing tests to the basic ability of using :lang<Perl5>
.
On the other hand, it feels pretty weird to me that something being part of the spec is basically a 3rd party project.
Why not move Inline::Perl5 from roast into say, alternative test system? In r3 I could test Inline::Perl5
against any version of Rakudo and any version of Inline::Perl5
... Just a thought ... Overall I personally would consider such a tests as are integration tests for a certain version of Rakudo and certain version of Inline::Perl5, where incompatible changes may happen in any piece of a system and along the road. So it's not classic unit tests like we have in roast ...
Anything related to details of embedding other languages should not be included in the core Raku test suite or roast.
The tests / roast for Perl 5 embedding should be a wholly separate thing, same as tests for any CPAN module are separate.
I understand the points.
I guess I'm one of the people in the world who runs the spectest manually a lot of times. I would very much welcome it to take shorter. However, I have also found the Inline::Perl5
tests to be a canary: I know I broke something significantly if the Inline::Perl5
tests are not run because it thinks it's not installed (aka I broke the installation test).
And the Inline::Perl5 tests pretty thoroughly test NativeCall
capabilities.
So maybe the integration tests could be moved to a section of Inline::Perl5
, still to be run in roast if Inline::Perl5
is installed, but with Inline::Perl5
being responsible for its contents, rather than roast?
Come to think of it: such a mechanism generalized could make spectest a more general tool? Maybe a "make integrationtest" that would run all the test-suites of any installed modules? A sort of Blin, but for your locally installed modules?
@lizmat if we talk about integration tests, I would also recommend tool like r3, because it's fully supported by Sparrow which is designed to solve integration like tasks
Come to think of it: such a mechanism generalized could make spectest a more general tool? Maybe a "make integrationtest" that would run all the test-suites of any installed modules? A sort of Blin, but for your locally installed modules?
I'd be against adding more complications to roast.
An idea just've crossed my mind and I'd like to record it here to think over it more thorough. Basically, Rakudo already does this kind of thing: it depends on kind of 3rd party NQP. And we ensure compatibility via the NQP_VERSION mechanism. Can't utilize something similar for Inline::Perl5
? It could be done in one of two ways:
:lang<Perl5>
which wouldn't rely on Inline::Perl5
.Thanks for the productive discussion so far! I just wanted to point out that this is the very first time in almost 6 years that there is an incompatible change. That's simply because usually it's abundantly clear what the correct behaviour is. E.g. if you call a method on a Perl object using the period as a method call operator, the corresponding method should be called. If you pass a string to it, it should arrive as a Unicode string in Perl. If you pass a blob, it should arrive as a binary string, and so forth.
With regards to the current change, the only reason we even had the previous aggressively flattening behaviour was that pre-GLR that was how Perl 6 behaved and post-GLR I didn't spend enough time to figure out which of the slurpy arg prefixes really matched the needed semantics. Just recently I was motivated enough to take another look, after I had been bitten by this a couple times, I had seen people at work getting bitten and I got a bug report that led back to this.
The new semantics clearly match better what people expect to happen.
Now the curious thing is that this one spec test actually expected us to flatten. It's not really surprising though, considering that it got added to roast back in 2009 and was written even before that. I.e. that was long before we nailed down flattening semantics for Perl 6 with the GLR. So arguably this test has been wrong since before the 6.c release. It's just that it has taken me embarrassingly long to fully adapt Inline::Perl5 to the post-GLR world, so this omission has stayed hidden for as long.
@niner thanks for the detailed explanation! But it actually underlines the whole point of this issue. With special measures taken we would rather discuss the test which doesn't conform to the to day standards, than the problem of a module breaking spectests. The fact that such a breakage happens only once in many years only adds to the confusion of those who's not familiar with the details of Perl5 support.
That's why I would be in favor of bundling Inline::Perl5
in a way similar to NQP: by means of adding _INLINEP5VERSION file. In this case bumping module version would more likely be preceded with a spectest round.
I don't think we should incorporate Inline::Perl5 further into Rakudo.
For one thing it would have likely prevented this bug fix from happening as soon.
I would be more in favor of deleting all of the tests in Roast for Inline::Perl5.
I don't think we really need to go that far. So just delete this one test.
Honestly I think that you should have to add a useĀ Inline::Perl5
to get something like the following to run
use v6.d;
use Scalar::Util:from<Perl5> <reftype>;
say reftype [];
# ARRAY
It doesn't work if we try to use a Python module without writing useĀ Inline::Python
, so why does it work with Perl5?
Raku tries to have every feature on a relatively level playing field, why is Perl5 put upon a pedestal?
I think that incorporating it specifically more into the language, runtime, or codebase is the wrong direction. Unless we are thinking about doing the same with the other Inline::*
modules.
(Doing so with NativeCall was necessary as it needed specific support at every level to work correctly.)
rakudo/rakudo#4418 reveals a situation which I would consider as highly problematic: roast specs Perl5 embedding, but the actual support of the feature is provided by a 3rd party module. A change in the module can breaks specs, what actually happened in the above mentioned issue.