g if a module is installed and loading
> it if it is:
>
> https://rakudo.org/post/lexical-require-upgrade-info
>
> Hope that helps!
> - Timo
> On 11/10/2018 19:08, Fernando Santagata wrote:
>
> Hello,
>
> I wish to run some tests on one module of mine only if there
that helps!
- Timo
On 11/10/2018 19:08, Fernando Santagata wrote:
> Hello,
>
> I wish to run some tests on one module of mine only if there's a
> certain third-party module available during installation.
> Before I concocted something horrid using try/catch in the INIT
&
> написав(ла):
>
> Hello,
>
> I wish to run some tests on one module of mine only if there's a certain
> third-party module available during installation.
> Before I concocted something horrid using try/catch in the INIT phaser, is
> there any gentle way to do this?
>
Hello,
I wish to run some tests on one module of mine only if there's a certain
third-party module available during installation.
Before I concocted something horrid using try/catch in the INIT phaser, is
there any gentle way to do this?
Thanks!
--
Fernando Santagata
Tests added in
https://github.com/perl6/roast/commit/40edf6d2c939fe095a848056db3489d7b1482a8a
I think we can close this.
On 2017-09-16 19:58:20, alex.jakime...@gmail.com wrote:
> Two of the mentioned modules have pending pull requests that add
> missing .close
> calls in tests. NCurses
On Mon, 29 Jan 2018 03:54:38 -0800, pesc...@gmail.com wrote:
> On Sat, 14 Jan 2017 13:46:47 -0800, barto...@gmx.de wrote:
> > On Tue, 10 Jan 2017 12:46:48 -0800, barto...@gmx.de wrote:
> > > I managed to golf this a bit:
> > >
> > > $ ./perl6-j -e 'use nqp; class A { has Mu $!foo; method bar () {
>
eded｣ ?
>
> On 2017-10-20 07:53:23, alex.jakime...@gmail.com wrote:
> > Moar bisected to
> >
>
https://github.com/MoarVM/MoarVM/commit/4eadf94599cc021ec7a9e0e49e198f5861468dc1
> >
> > On 2017-10-20 07:23:04, alex.jakime...@gmail.com wrote:
> > > DBIish t
On Sat, 14 Jan 2017 13:46:47 -0800, barto...@gmx.de wrote:
> On Tue, 10 Jan 2017 12:46:48 -0800, barto...@gmx.de wrote:
> > I managed to golf this a bit:
> >
> > $ ./perl6-j -e 'use nqp; class A { has Mu $!foo; method bar () {
> > $!foo
> > := nqp::null; say nqp::isnull($!foo) ?? "null" !! $!foo }
On Sat, 14 Jan 2017 13:46:47 -0800, barto...@gmx.de wrote:
> On Tue, 10 Jan 2017 12:46:48 -0800, barto...@gmx.de wrote:
> > I managed to golf this a bit:
> >
> > $ ./perl6-j -e 'use nqp; class A { has Mu $!foo; method bar () {
> > $!foo
> > := nqp::null; say nqp::isnull($!foo) ?? "null" !! $!foo }
There was indeed something wrong with the multi cache on the JVM backend. Fixed
with https://github.com/perl6/nqp/commit/7eaebf5abd
I'm closing this ticket as 'resolved'.
On Tue, 28 Nov 2017 12:35:42 -0800, barto...@gmx.de wrote:
> [...]
> I tried to golf the failures from set_addition.t and found the
> following:
>
> $ ./perl6-j --ll-exception -e '&infix:<(+)>(SetHash.new, SetHash.new,
> SetHash.new); &infix:<(+)>(|(Set.new, Set.new, Set.new));
> &infix:<(+)>(|(Se
# New Ticket Created by Christian Bartolomaeus
# Please include the string: [perl #132514]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132514 >
Currently the following test files under S03-operators do not run
to completion
The tests in question are passing again.
I'm closing this ticket as resolved.
wrote:
> Moar bisected to
>
https://github.com/MoarVM/MoarVM/commit/4eadf94599cc021ec7a9e0e49e198f5861468dc1
>
> On 2017-10-20 07:23:04, alex.jakime...@gmail.com wrote:
> > DBIish tests started to fail (with segv) after this rakudo commit:
> >
>
https://gith
Moar bisected to
https://github.com/MoarVM/MoarVM/commit/4eadf94599cc021ec7a9e0e49e198f5861468dc1
On 2017-10-20 07:23:04, alex.jakime...@gmail.com wrote:
> DBIish tests started to fail (with segv) after this rakudo commit:
>
https://github.com/rakudo/rakudo/
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #132328]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132328 >
DBIish tests started to fail (with segv) after this rakudo com
> > > My vote on this feature is a most definite -1. I see no reason to
> > > over-engineer a core module to support some fringe usecase.
> > > The tests routines return the test status, so you can write that
> > > particular usecase as:
> > >
> >
dule to support some fringe usecase.
> > The tests routines return the test status, so you can write that
> > particular usecase as:
> >
> > ok check-name($meta, :$relaxed-name), "name has a hyphen rather than
> > '::'"
> > or diag "\n
On Sun, Oct 1, 2017 at 17:23 Zoffix Znet via RT
wrote:
> On Sun, 01 Oct 2017 10:10:55 -0700, tbrowder wrote:
...
> My vote on this feature is a most definite -1. I see no reason to
> over-engineer a core module to support some fringe usecase.
> The tests routines return the test st
On Sun, Oct 1, 2017 at 17:23 Zoffix Znet via RT
wrote:
> On Sun, 01 Oct 2017 10:10:55 -0700, tbrowder wrote:
...
> My vote on this feature is a most definite -1. I see no reason to
> over-engineer a core module to support some fringe usecase.
> The tests routines return the test st
> ok check-name($meta, :$relaxed-name), \
> "name does not contain a hyphen", \
> :desc-fail("name has a hyphen rather than '::' (if this is
> intentional please pass :relaxed-name to meta-ok))";
Thank you for the report.
My vote on this f
> ok check-name($meta, :$relaxed-name), \
> "name does not contain a hyphen", \
> :desc-fail("name has a hyphen rather than '::' (if this is
> intentional please pass :relaxed-name to meta-ok))";
Thank you for the report.
My vote on this f
# New Ticket Created by Tom Browder
# Please include the string: [perl #132195]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132195 >
The purpose of the second description would be for use if a test
fails. For example we lo
s also have type-specific attributes which can hold further details to
differentiate similar but different error conditions.
If file tests should be made to expose more fine-grained error states (probably
a good idea), they can use those two mechanisms without the need to change
anything about Failu
On Sat, Sep 30, 2017 at 4:35 PM, Sam S. via RT wrote:
> To the extent that you're basing your expectations on the fact that a Perl
> 5 `undef` can be used in ways that a Perl 6 `Failure` cannot (without
> blowing up), well, that's just a matter of having to unlearn Perl 5 (or
> other programming
On Sat, Sep 30, 2017 at 4:35 PM, Sam S. via RT wrote:
> To the extent that you're basing your expectations on the fact that a Perl
> 5 `undef` can be used in ways that a Perl 6 `Failure` cannot (without
> blowing up), well, that's just a matter of having to unlearn Perl 5 (or
> other programming
I agree with Zoffix that this seems to be fine as is.
Generally speaking, IO operations that logically require an existing path will
return a Failure if the path does not in fact exist:
Slurp its content? Failure.
Rename/move/copy it? Failure.
Check its size? Failure.
Check if it is of t
On Fri, 29 Sep 2017 14:43:22 -0700, allber...@gmail.com wrote:
> So, the first problem is that you have to be aware of the special behavior
> of Failure and how it interacts with a method which is documented as
> producing Bool.
That documentation also lists the conditions when the method `fail`s.
On Fri, 29 Sep 2017 14:43:22 -0700, allber...@gmail.com wrote:
> So, the first problem is that you have to be aware of the special behavior
> of Failure and how it interacts with a method which is documented as
> producing Bool.
That documentation also lists the conditions when the method `fail`s.
ond file tests. (Again! It only caused a syntax rethink and the redesign
of smartmatching when I poked file test issues in Pugs in 2007)
The original problem is that a fairly obvious (from shells or perl 5 or
etc.) test for whether a file (as such) exists or not, can yield surprises:
pyanfar Z
On Mon, 18 Sep 2017 14:00:02 -0700, barto...@gmx.de wrote:
> On Sat, 16 Sep 2017 08:46:00 -0700, barto...@gmx.de wrote:
> > Here is a simple example:
> >
> > $ ./perl6-j -e 'try { die "foo" }; say $!.perl; say $!.gist'
> > X::AdHoc.new(payload => "foo")
> > Died
> > in block at -e line 1
>
>
>
On Sat, 16 Sep 2017 08:46:00 -0700, barto...@gmx.de wrote:
> Here is a simple example:
>
> $ ./perl6-j -e 'try { die "foo" }; say $!.perl; say $!.gist'
> X::AdHoc.new(payload => "foo")
> Died
> in block at -e line 1
It looks like the 'Died' stems from this line:
https://github.com/perl6/nqp/
Two of the mentioned modules have pending pull requests that add missing .close
calls in tests. NCurses module is trickier, but arguably the failing test is a
little bit wrong. See this discussion for more info:
https://github.com/azawawi/perl6-ncurses/issues/16
In other words, the ecosystem is
Here is a simple example:
$ ./perl6-j -e 'try { die "foo" }; say $!.perl; say $!.gist'
X::AdHoc.new(payload => "foo")
Died
in block at -e line 1
$ $ ./perl6-m -e 'try { die "foo" }; say $!.perl; say $!.gist'
X::AdHoc.new(payload => "foo")
foo
in block at -e line 1
017-09-16#i_15171820
3) a lot of tests for $! seem to fail. i think that happens since commit
1a4d94930c (there was a call to nqp::setmessage removed from method throw)
https://github.com/rakudo/rakudo/commit/1a4d94930c581e915a2351049e8ee12246c4c26c
017-09-16#i_15171820
2) 'make test' fails a lot of nativecall tests. afaik that happens because the
op 'nativecallinvoke' was introduced with commit cd7dc4ce93 in
lib/NativeCall.pm6 (but isn't known on the JVM backend)
https://github.com/rakudo/rakudo/commit/cd7dc4ce934003b9da1e540e638ee6dbe1f44b1b
On 2017-09-11 04:18:39, elizabeth wrote:
> > > Fixed with 3c9cfdba88287e23e0ced8 (and further refined by later
> > > commits), tests needed.
> > >
> > > > On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT > > > follo...@perl.org> wrote:
>
11 04:18:39, elizabeth wrote:
> > Fixed with 3c9cfdba88287e23e0ced8 (and further refined by later
> > commits), tests needed.
> >
> > > On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT > > follo...@perl.org> wrote:
> > >
> > > On Tue, 05 Sep 2017 09
xed with 3c9cfdba88287e23e0ced8 (and further refined by later
> commits), tests needed.
>
> > On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT > follo...@perl.org> wrote:
> >
> > On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
> >> On Tue, Sep 5, 2017 at 5:40 AM,
Fixed with 3c9cfdba88287e23e0ced8 (and further refined by later commits),
tests needed.
> On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT
> wrote:
>
> On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
>> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via
Fixed with 3c9cfdba88287e23e0ced8 (and further refined by later commits),
tests needed.
> On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT
> wrote:
>
> On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
>> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via
> On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT
> wrote:
> To recap the IRC discussion yesterday: no, we haven't had this so far (except
> for stdout/stderr), and have gotten away with it due to the lack of output
> buffering. At present, we can either choose between:
>
> 1) Start keeping a
> On 6 Sep 2017, at 15:38, jn...@jnthn.net via RT
> wrote:
> To recap the IRC discussion yesterday: no, we haven't had this so far (except
> for stdout/stderr), and have gotten away with it due to the lack of output
> buffering. At present, we can either choose between:
>
> 1) Start keeping a
On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > Failing to close output handles has been clearly documented (and yes,
> > documented well before the recent buffering change) as so
On Tue, 05 Sep 2017 09:11:19 -0700, allber...@gmail.com wrote:
> On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > Failing to close output handles has been clearly documented (and yes,
> > documented well before the recent buffering change) as so
“Will leave this ticket open a little longer for further comments/discussion,
but my intention is to reject it.”
Nope, that's not exactly a good sounding plan.
We'll run toaster and fix all modules that require fixing (or create
appropriate issues if fixing something turns out to be too hard). Th
On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:
> Failing to close output handles has been clearly documented (and yes,
> documented well before the recent buffering change) as something that can
> cause data loss. Default output buffering just makes i
On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:
> Failing to close output handles has been clearly documented (and yes,
> documented well before the recent buffering change) as something that can
> cause data loss. Default output buffering just makes i
h from an int container
>> ok 8 - Can do an atomic assign to an int container; returns new value
>> ok 9 - Atomic int fetch after atomic int assign shows latest value
>> ok 10 - Updated value seen by non-atomic too
>> A IntLexRef container does not know how to do an atomic load
&g
h from an int container
>> ok 8 - Can do an atomic assign to an int container; returns new value
>> ok 9 - Atomic int fetch after atomic int assign shows latest value
>> ok 10 - Updated value seen by non-atomic too
>> A IntLexRef container does not know how to do an atomic load
&g
On Tue, 05 Sep 2017 05:29:00 -0700, 1parr...@gmail.com wrote:
> Perl 5 programmers are used to being casual about closing file
> handles. Obviously, 6 requires a change of habits. A cultural shift,
> if that's not too pretentious a term. Perhaps it needs to be mentioned
> in large, friendly letters
On Tue, 05 Sep 2017 05:29:00 -0700, 1parr...@gmail.com wrote:
> Perl 5 programmers are used to being casual about closing file
> handles. Obviously, 6 requires a change of habits. A cultural shift,
> if that's not too pretentious a term. Perhaps it needs to be mentioned
> in large, friendly letters
ia RT wrote:
> On Tue, 05 Sep 2017 00:54:27 -0700, alex.jakime...@gmail.com wrote:
>> <[Tux]> CSV tests started to fail
>> <[Tux]> # at t/90_csv.t line 260
>> <[Tux]> # expected: $[["1", "2", "3"], ["2", "a b&
ia RT wrote:
> On Tue, 05 Sep 2017 00:54:27 -0700, alex.jakime...@gmail.com wrote:
>> <[Tux]> CSV tests started to fail
>> <[Tux]> # at t/90_csv.t line 260
>> <[Tux]> # expected: $[["1", "2", "3"], ["2", "a b&
On Tue, 05 Sep 2017 00:36:34 -0700, n...@detonation.org wrote:
> A golfed version that reliably fails:
>
> {
> my Int $test-cont = 42;
> ⚛$test-cont;
> }
> {
> my atomicint $set = 0;
> start { sleep 1; $set ⚛= 1 };
> until ⚛$set { }
> }
>
> The important bit is the Int being r
On Tue, 05 Sep 2017 00:36:34 -0700, n...@detonation.org wrote:
> A golfed version that reliably fails:
>
> {
> my Int $test-cont = 42;
> ⚛$test-cont;
> }
> {
> my atomicint $set = 0;
> start { sleep 1; $set ⚛= 1 };
> until ⚛$set { }
> }
>
> The important bit is the Int being r
On Tue, 05 Sep 2017 00:54:27 -0700, alex.jakime...@gmail.com wrote:
> <[Tux]> CSV tests started to fail
> <[Tux]> # at t/90_csv.t line 260
> <[Tux]> # expected: $[["1", "2", "3"], ["2", "a b", ""]]
> <[Tux
On Tue, 05 Sep 2017 00:54:27 -0700, alex.jakime...@gmail.com wrote:
> <[Tux]> CSV tests started to fail
> <[Tux]> # at t/90_csv.t line 260
> <[Tux]> # expected: $[["1", "2", "3"], ["2", "a b", ""]]
> <[Tux
l.com wrote:
> <[Tux]> CSV tests started to fail
> <[Tux]> # at t/90_csv.t line 260
> <[Tux]> # expected: $[["1", "2", "3"], ["2", "a b", ""]]
> <[Tux]> # got: $[["1", "2&q
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #132030]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132030 >
<[Tux]> CSV tests started to fail
<[Tux]> # at t/90
8 - Can do an atomic assign to an int container; returns new value
> ok 9 - Atomic int fetch after atomic int assign shows latest value
> ok 10 - Updated value seen by non-atomic too
> A IntLexRef container does not know how to do an atomic load
> in block at t/spec/S17-lowlevel/atomic-op
ue
ok 10 - Updated value seen by non-atomic too
A IntLexRef container does not know how to do an atomic load
in block at t/spec/S17-lowlevel/atomic-ops.t line 41
# Looks like you planned 28 tests, but ran 10
I noticed that it fails more often when the system is under load (e.g. when
run
A workaround for it was added in
https://github.com/rakudo/rakudo/commit/1d69ebb9c2514fe5ae156998f71e4a112801b603
Without MVM_SPESH_DISABLE=1 it can give this kind of warning:
Block (from unknown) seen at:
/tmp/21S1e2RPQr, lines 107,115,122,69
Please use is-approx instead.
This is LTA but at l
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #131935]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131935 >
See IRC log: https://irclog.perlgeek.de/perl6-dev/2017-08-20#i_150458
I have fixed this as of this MoarVM commit:
https://github.com/MoarVM/MoarVM/commit/712cff3341270362b808ba0f4c519f4557a4671d
Full explaination in the commit description.
Thanks a lot for reporting this bug :)
-v
> This is Rakudo version 2017.07-144-gec7bc25 built on MoarVM version
> 2017.07-365-gc0f7a3b
> implementing Perl 6.c.
> [jdv@localhost ~]$
>
>
> from a build from last weekend or so and the json tiny tests failed
> and
> spit out some bad bytes:
>
>
> # Faile
144-gec7bc25 built on MoarVM version
2017.07-365-gc0f7a3b
implementing Perl 6.c.
[jdv@localhost ~]$
from a build from last weekend or so and the json tiny tests failed and
spit out some bad bytes:
# Failed test 'JSON string «["̥̞ͫͩ̉̎͊ỏ̟͙̞̻
ata that should be run are being run. For example:
'make spectest TEST_JOBS=3', i.e. harness5 tests 1168 files
on the other hand
'make spectest HARNESS_TYPE=6 TEST_JOBS=3' only tests 1160 files
The two harnesses should test the same number of files. There's reason to
b
On Sat, 30 Apr 2016 11:16:44 -0700, barto...@gmx.de wrote:
> Starting with rakudo commit fe2be65806 two tests in S16-io/supply.t
> start to fail with rakudo-j. The following rakudo commit 463e7589a1
> seems to change the code path for the tests in question, but also
> makes them fail.
Update...
I've used --merge on prove! This merges the outputs into one. Removing
this option and using note for the output will give correct results
ok 1 - test 1
1..1
ok 1 - pestering 1
not ok 5 - pestering 2
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.0
test should be
is 1, 1, 'test 1';
say "ok 1 - pestering 1";
say "not ok 5 - pestering 2";
resulting in
ok 1 - test 1
ok 1 - pestering 1
not ok 5 - pestering 2
1..1
Failed -1/1 subtests
Test Summary Report
---
confuse-TAP.t (Wstat: 0 Tests:
..1
Failed -1/1 subtests
Test Summary Report
---
confuse-TAP.t (Wstat: 0 Tests: 2 Failed: 0)
Parse errors: Tests out of sequence. Found (1) but expected (2)
Bad plan. You planned 1 tests but ran 2.
Files=1, Tests=2, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.1
On Fri, 20 Jan 2017 09:16:18 -0800, mt1...@gmail.com wrote:
> Hi Will,
>
> How can it happen that a test gets hurt in this way? If I know this I
> could better search for the problem.
>
> Regards,
> Marcel
Hi,
Here's how that error happens:
The TAP protocol[^1] ex
problems while testing. All
tests run ok but at the end the Test returns failure
...
ok 6 - Testing explain and performance using hint
2017-01-20 13:04:40.783616 [I] 1: Test
/home/travis/build/MARTIMM/mongo-perl6-driver/t/450-find.t stop
1..6
Failed 3/6 subtests
... other test programs ... Test
On Fri, 20 Jan 2017 06:09:00 -0800, mt1...@gmail.com wrote:
> Hi,
>
> Since using Log::Async in MongoDB I get problems while testing. All
> tests run ok but at the end the Test returns failure
>
>
> ...
>
> ok 6 - Testing explain and performance using hint
>
&
# New Ticket Created by mt1957
# Please include the string: [perl #130603]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130603 >
Hi,
Since using Log::Async in MongoDB I get problems while testing. All
tests run ok but
On Sun, 08 Jan 2017 23:31:11 -0800, barto...@gmx.de wrote:
> Since the new Rakudo::Internals.OneValueIterator is used in infix:
> (Rakudo commit c405f06724) there are four failing tests in
> S03-metaops/zip.t on rakudo-j.
>
> One example of failing code:
>
> $ ./perl
udo commit c405f06724) there are four failing tests in
S03-metaops/zip.t on rakudo-j.
One example of failing code:
$ ./perl6-j -e 'say $(1, 2) Z '
(((1 2) a) ((Mu) b) ((Mu) c))
$ ./perl6-m -e 'say $(1, 2) Z '
(((1 2) a))
I investigated a bit and it looks like $!value is Mu here
Fixed with https://github.com/perl6/nqp/commit/b258244952
The tests are passing (again). I'm closing this ticket as 'resolved'.
This issue is fixed if you configure MoarVM with --has-libffi as of today.
(You need of course the libffi-dev package installed.)
On Sat Jul 02 05:50:21 2016, tom.brow...@gmail.com wrote:
> When working in a rakudo dev environment on a PR it would be very
> helpful to work on the associated tests at the same time. One way is
> to have a suitable build option to Configure.pl, e.g.,
>
> + Use a suitably defin
the associated tests at the same time. One way is to have a suitable
build option to Configure.pl, e.g.,
+ Use a suitably defined env var (say. ROAST_LOCAL_REPO_DIR):
$ perl Configure.pl --gen-moar --gen-nqp --backends=moar \
--local-roast-repo
or an explicit path:
$ perl Configure
# New Ticket Created by Will Coleda
# Please include the string: [perl #128069]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128069 >
The 6.c-errata branch of roast is now failing tests in t/spec/S32-num/rat.t
not ok
# New Ticket Created by Christian Bartolomaeus
# Please include the string: [perl #128041]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128041 >
Starting with rakudo commit fe2be65806 two tests in S16-io/supply.t start
# New Ticket Created by Christian Bartolomaeus
# Please include the string: [perl #128031]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128031 >
Since rakudo commit fe2be65806 there are 5 failing test on rakudo-j in
S04-dec
Closing as resolved.
Hi, can you please check if it is still broken?
The patch in https://github.com/rakudo/rakudo/commit/505dc4fa should fix it.
# New Ticket Created by Andy Weidenbaum
# Please include the string: [perl #127046]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127046 >
The following test fails:
[not ok]
https://bitbucket.org/atweiden/config-toml-dev/sr
# New Ticket Created by Christian Bartolomaeus
# Please include the string: [perl #126899]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126899 >
There are quite a few tests in S03-metaops/reduce.t which fail on rakudo.
quot;
nearly all the 01-sanity test pass and almost all of the 04-nativecall tests
fail. I have found a simple change in one file that allows almost all of the
the nativecall tests to pass.
The $cfg in CompileTestLib.pm on my system prints to:
-shared -Wl,--out-implib,lib$(notdir $@).a
If you ch
line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=126678 >
>
>
> There are skipped tests in S15-unicode-information/uniname.t which die with
> the following error mode:
>
> $ perl6-j -e 'say uninames("AB")&#x
I changed the tests to not expect a specific order with commit:
https://github.com/perl6/roast/commit/f1df147714
I'm closing this ticket as 'resolved'.
Great. I unfudged the tests with commit
https://github.com/perl6/roast/commit/e2174a8adf.
I'm closing this ticket as 'resolved'.
Thanks! I'm closing this ticket as 'resolved'.
# New Ticket Created by Christian Bartolomaeus
# Please include the string: [perl #126679]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126679 >
There are skipped tests in S32-str/split-simple.t which die with the follow
# New Ticket Created by Christian Bartolomaeus
# Please include the string: [perl #126678]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126678 >
There are skipped tests in S15-unicode-information/uniname.t which die w
deByZero'
-- as expected by the three tests in S03-operators/arith.t:
$ perl6-j -e 'say 3 % 0'
X::TypeCheck::Return exception produced no message
in block at -e:1
The same thing happens in S32-array/adverbs.t.
# New Ticket Created by Christian Bartolomaeus
# Please include the string: [perl #126671]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126671 >
On rakudo.jvm there are failing tests in S32-hash/adverbs.t because
The problem was, that .sort was broken on rakudo.jvm.
That was fixed with commit https://github.com/rakudo/rakudo/commit/5da0b3faed
Tests are unfudged again and I'm closing this ticket as 'resolved'.
1 - 100 of 2274 matches
Mail list logo
