Not sure if this info is relevant now, but the hang was introduced in
(2016-02-18)
https://github.com/rakudo/rakudo/commit/9983c2c8434ed81c532a5706996f284283b48d0a
On 2017-08-05 06:33:14, c...@zoffix.com wrote:
> Since Seq is not a Positional type, *binding* it to a `@` variable is
> typecheck err
There's a little problem with it. You see, right now this works:
exit "1"
So we simply cannot force it to do something else with Strs because that can
break existing (perfectly valid) code. We can go through a long deprecation
cycle but it's not worth it (IMO).
But it may be possible to catch X:
IRC discussion: https://irclog.perlgeek.de/perl6/2017-08-09#i_14989886
Turns out that .hyper/.race never worked reliably anyway, so this ticket is
less important than it looks.
Maybe we should have a meta ticket that tracks all .hyper/.race issues. Another
option would be to just close them all,
It was bisected to
https://github.com/rakudo/rakudo/commit/f590863e1736c75207c9ce0335ea646e3529060e
Example (before and after):
https://gist.github.com/Whateverable/2a9088ddcff37fd6f748b77ba3339af2
On 2017-08-10 14:54:24, jdv79 wrote:
> I updated to:
>
>
> [jdv@localhost ~]$ perl6 -v
> This is Ra
Great analysis!
The first issue seems to be already mentioned in RT #126112 (and I vaguely
recall one more ticket, but I'm failing to find it now).
This ticket seems to be getting a bit unmanageable, please file smaller tickets
for every issue you discover.
On 2017-08-10 21:36:34, b...@abrij.or
There was some progress on this. jnthn++
I guess the most promising commit regarding this issue is
https://github.com/MoarVM/MoarVM/commit/0d2e5f8cc0264eb495ea4f20f3a0c90d05d55710
, but there's at least one other commit that could've improved the situation (
https://github.com/rakudo/rakudo/commit
I think things would go faster with this one if it was golfed down.
Given the previous warnings saying “Use of uninitialized value $key of type Any
in string context.”, the issue is quite possibly in Uzu itself (or maybe even
Mustache). The ticket is of course valid because the error should not co
No bug with MVM_SPESH_DISABLE=1.
On 2017-08-07 19:48:36, ddgr...@gmail.com wrote:
> [22:44] m: sub foo(:color(:$colour)) { $colour + 1 }; my
> $s;
> for ^100 { $s += foo(:color($_)) }; say $s; say now - INIT now
> [22:44] <+camelia> rakudo-moar a91ad2: OUTPUT: «Unexpected named
> argument
> '
OK, this is still not resolved, but it got noticeably better.
The issue is reproducible with the snippet provided in the original report.
On 2017-08-11 10:01:42, alex.jakime...@gmail.com wrote:
> There was some progress on this. jnthn++
>
> I guess the most promising commit regarding this issue is
Bisected:
bisect: old=HEAD~300
https://gist.githubusercontent.com/AlexDaniel/1e2c456f006687ea7100a35b2931af41/raw/9aad30ec83728b43b5d1d134a4c0701354e2c8c5/nativehelpers-test.p6
AlexDaniel, Successfully fetched the code from the provided URL.
AlexDaniel, Bisecting by exit code (old=HEAD~300 new=
Note that the tests on 92bd7e4^ and 92bd7e4 are not very related to this
particular issue.
To put simply: it went from 58628 to 138220 because of changes related to this
commit (or maybe one or two commits before it):
https://github.com/rakudo/rakudo/commit/9658dd98c9dd8ecbefc606a08357e59718e328c2
TL;DR it went from 59820 to 215976 after this commit:
https://github.com/rakudo/rakudo/commit/92bd7e4f54a92fa660f99b4d056d33a08fb98bd2
Bisect log:
https://gist.github.com/678ce88a13272eab454a22568f3bddc7
On 2017-08-16 14:24:48, scoli...@gmail.com wrote:
> Similar to https://rt.perl.org/m/ticket/s
Also, it's not any different on HEAD:
committable6test: 9658dd98c9dd8ec^^,9658dd98c9dd8ec,HEAD say
"/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024
AlexDaniel, ¦9658dd98c9dd8ec^^: «58628» ¦9658dd9: «138220»
¦HEAD(3e70d44): «136436»
On 2017-08-16 14:27:37, alex.jakime...@gmail.com wr
https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032963
On 2017-08-16 14:30:42, alex.jakime...@gmail.com wrote:
> TL;DR it went from 59820 to 215976 after this commit:
>
https://github.com/rakudo/rakudo/commit/92bd7e4f54a92fa660f99b4d056d33a08fb98bd2
>
> Bisect log:
> https://gist.github.com/67
This could've been a LHF, except for these tests:
https://github.com/perl6/roast/blob/4bfd6d2374cb4ea1b8fa057a5f294b988e4dec44/S32-exceptions/misc.t#L180-L185
¯\_(ツ)_/¯
But yes, I think it should say “slurpy” everywhere.
On 2017-08-18 07:10:52, comdog wrote:
> Consider this program which I don't
Another way to do it is to support custom nl (similarly to how we do
｢$*IN.nl-in = 0.chr｣ now). Split may be an overkill.
On 2017-08-18 08:40:32, c...@zoffix.com wrote:
> On Fri, 18 Aug 2017 08:35:18 -0700, alex.jakime...@gmail.com wrote:
> > Most command line tools support zero-separated input an
It was fixed in this commit:
https://github.com/MoarVM/MoarVM/commit/5363a0742d9ea7183200a747c2d7531e82bc5c71
samcv++
Tests needed.
On 2017-08-18 12:48:20, alex.jakime...@gmail.com wrote:
> The issue happens in Email::Simple (one of its tests is now failing,
> but it was ok in 2017.07).
>
> Here'
The change was moved to v6.d in this commit:
https://github.com/rakudo/rakudo/commit/d2278b471cb0bd691dc7a1235fbcb9318ff5d61f
On 2017-08-17 08:50:48, alex.jakime...@gmail.com wrote:
> See this commit:
>
https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
>
> These roas
I had to revert one of the nqp commits related to .parse:
https://github.com/perl6/nqp/commit/d4d77b66c46c57de800b147df61fe486b4486acd
Here's a ticket for the module that was affected by the change:
https://github.com/p6-css/CSS-Module-p6/issues/10
Most certainly we want this change back ASAP, bu
Nevermind, the test was wrong.
https://github.com/perl6/roast/commit/66792f989db6eb0832b134b2b327135f785e7974
On 2017-08-20 05:12:56, alex.jakime...@gmail.com wrote:
> This test is failing:
>
https://github.com/perl6/roast/blob/b0044b0751fc13f97abca1ac4f76ccc5bb109112/S17-
> promise/allof.t#L32-L4
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
It was removed completely for 2017.08 release.
Rakudo commit:
https://github.com/rakudo/rakudo/commit/465d91abdfda038cb7feda35f7966be4ec39acf3
Discussion: https://irclog.perlgeek.de/perl6-dev/2017-08-21#i_15048995
On 2017-08-19 15:31:01, alex.jakime...@gmail.com wrote:
> I had to revert one of the
Is this ticket relevant today?
Note that we also have this: https://rt.perl.org/Ticket/Display.html?id=131919
On 2016-12-19 08:41:33, ronaldxs wrote:
> On Tue, 03 Nov 2015 14:26:06 -0800, ronaldxs wrote:
> > 18:07 mr_ron m: grammar G { token TOP { a+ } }; my Nil $x =
> > G.parse("zz")
> > 18:07 ca
This is the same issue, but it is interesting nonetheless:
m: dd (0x0F75.chr x 2).uninames
rakudo-moar 636a3c: OUTPUT: «("TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL
SIGN U", "TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL SIGN U").Seq»
m: dd (0x0F75.chr ~ 0x0F75.chr).uninames
rakudo-moar 636a3c: OUTPUT:
Indeed, I'm not sure what I was smoking.
On 2017-01-20 21:27:50, sml...@gmail.com wrote:
> > It numifies ranges so that the number of elements is used. In other
> > words, 1..2
> > works like 2 and 1..1 works like 1.
>
> No, if it worked like that then the first two examples would throw the
> same
It is more or less reliable actually. I think writing a stresstest will do.
On 2017-08-26 05:33:17, sml...@gmail.com wrote:
> Both the demo script (from the top post) and the one-line test case
> (2nd post) now pass without error!
>
> Bisectable identifies a commit from last week as the fix:
>
> ht
Indeed. The limit was introduced as a response to this ticket:
https://rt.perl.org/Ticket/Display.html?id=126800
The check is probably too aggressive, and indeed, maybe there's nothing wrong
with 0 sized arrays. I wonder what was the justification for making the check
inclusive.
On 2017-08-26 16:15
index such an array?
>
> On Sat, Aug 26, 2017 at 8:11 PM, Aleks-Daniel Jakimenko-Aleksejev via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > Indeed. The limit was introduced as a response to this ticket:
> > https://rt.perl.org/Ticket/Display.html?id=126800
> >
See https://github.com/perl6/doc/issues/1472
Turns out that $proc.lines does the wrong thing, which is probably a bug. We do
need nl-in for Proc::Async, and this nl-in should also be the same as in
IO::Handle.
On 2017-08-18 08:54:36, alex.jakime...@gmail.com wrote:
> Another way to do it is to sup
I meant $proc.stdout.lines of course.
On 2017-08-27 07:32:35, alex.jakime...@gmail.com wrote:
> See https://github.com/perl6/doc/issues/1472
>
> Turns out that $proc.lines does the wrong thing, which is probably a
> bug. We do
> need nl-in for Proc::Async, and this nl-in should also be the same as
Still not 77.
On 2012-12-07 02:55:44, masak wrote:
> rn: sub postfix:<+>($a) is looser(&infix:<+>) { $a; 77 }; say
> +6+ +8+
> rakudo 53daef: OUTPUT«83»
> ..niecza v24-5-g599cbcb: OUTPUT«77»
> hah!
> :D
> masak wins
> * masak submits rakudobug
> should be 77
> then Niecza is right.
> in
Currently it says this:
Use of uninitialized value of type Any in numeric context
in block at line 1
As well as complains about sink context in non-repl:
Useless use of "**" in expression "$_**2" in sink context (line 1)
I see no problem with it. Except that it no longer says which variable cau
Yea, it is a feature request. And I'd say a very reasonable one.
On 2012-08-07 14:43:12, moritz wrote:
> I'm a bit confused about what to do with an RFC bug. Close it, because
> no patch was forthcoming? Regard it as a feature request?
We no longer seem to care about “is cached”, so… I don't think we should reject
this (because it may be a nice test case once we start supporting cached
trait), but at the same time this ticket is kinda useless.
On 2014-06-01 03:12:32, elizabeth wrote:
> On 01 Jun 2014, at 12:07, Elizabeth Mattijs
This was untodo-ed in
https://github.com/perl6/roast/commit/e180d46b926aaa0b781b1fe5d1ee66d32a666d23
This was untodo-ed in
https://github.com/perl6/roast/commit/e180d46b926aaa0b781b1fe5d1ee66d32a666d23
Untodoed in
https://github.com/perl6/roast/commit/e9f0893dc39450be68a0550c451ad1eca7e6f3ab
Untodoed in
https://github.com/perl6/roast/commit/100f141a2103f8c3194520bea7312ac3dad123c2
Untodoed in
https://github.com/perl6/roast/commit/e9f0893dc39450be68a0550c451ad1eca7e6f3ab
Unskipped in
https://github.com/perl6/roast/commit/5425477851ee07c5489d4647920797fe7ae01e19
Unskipped in
https://github.com/perl6/roast/commit/e7252a2a1281f666f362b621c030f7b75db513ae
Untodoed in
https://github.com/perl6/roast/commit/b60cef93e356908eadc7855f816ec8f77bd03e01#diff-4a0037e48f821303bb0939ba43d6e6cfL264
Untodoed in
https://github.com/perl6/roast/commit/b60cef93e356908eadc7855f816ec8f77bd03e01#diff-4a0037e48f821303bb0939ba43d6e6cfL291
Untodoed in
https://github.com/perl6/roast/commit/03e5a5120465622d9e13451b43cdeb03fd2354a7
Well, it was clearly wrong to say that we don't care about it, sorry about
that. Maybe it's not the top priority thing (for example, there is a module to
do this: https://github.com/azawawi/perl6-memoize), but there are still plans
to get it done eventually.
I'll change the title a little bit so t
Bisected to
https://github.com/rakudo/rakudo/commit/51b63bf9f0d0594687908f0756774f29cde39c1f
On 2017-08-25 18:56:37, alex.jakime...@gmail.com wrote:
> The input file for this problem is ≈15 MB so please bear with external
> link:
> https://files.progarm.org/golfed.gz (1.6 MB compressed)
>
> Comman
I bisected moarvm manually to
https://github.com/MoarVM/MoarVM/commit/a6abd3c6654413d2230470dbaa82b7b3a2b05762
On 2017-08-30 19:09:18, alex.jakime...@gmail.com wrote:
> Bisected to
>
https://github.com/rakudo/rakudo/commit/51b63bf9f0d0594687908f0756774f29cde39c1f
>
> On 2017-08-25 18:56:37, alex.j
https://irclog.perlgeek.de/perl6-dev/2017-09-01#i_15102810
On 2017-07-31 08:27:09, alex.jakime...@gmail.com wrote:
> FWIW, still happens after all changes during this month.
>
> On 2017-07-22 16:21:30, alex.jakime...@gmail.com wrote:
> > I bisected it to
> >
>
https://github.com/rakudo/rakudo/comm
We now have a note in the docs about this. When fixed, change the docs
accordingly (*maybe* saying that versions before X are known to have a bug).
https://github.com/perl6/doc/commit/39e3efc08d
See IRC discussion: https://irclog.perlgeek.de/perl6/2017-09-01#i_15103501
On 2017-09-01 03:33:34, ale
A lot of discussion drifted to this ticket for some reason:
https://github.com/perl6/doc/issues/1428
Let's get ourselves back here.
On 2017-07-31 14:40:50, c...@zoffix.com wrote:
> > But do you really think I'm wrong
>
> Nope. I agree it should be tossed.
>
> There's one test in 6.c-errata that m
Revert this commit when the ticket is resolved:
https://github.com/perl6/doc/commit/70084290cf881af88546d507fc2ba4448bfa7aaf
(possibly with a note that it only works since rakudo 20XX.XX)
On 2017-09-01 20:15:07, alex.jakime...@gmail.com wrote:
> Command:
> # run it and then send SIGINT (e.g. with
Thanks. Done.
Unfortunately, RT does not save titles of merged tickets, so I think we lost a
little bit of information after the merge. But fear not, these ticket IDs are
referenced in S04-statements/do.t, so once this ticket is resolved please also
unskip the tests.
On 2017-09-03 19:01:48, b...@
Oh. A crude way to reproduce it is:
while :; do clear; PERL6LIB=lib ./perl6-m t/spec/S17-lowlevel/atomic-ops.t ||
break; done
And just leave it running, it'll fail at some point. Get your system busy with
something and it'll fail faster.
On 2017-09-05 00:14:11, alex.jakime...@gmail.com wrote:
>
The issue is likely in Text::CSV so it's not fully a rakudo bug.
However, we probably have a bunch of broken modules in the ecosystem because of
this. I guess we need a Toaster report and a bunch of PRs for missing .close
calls to fix everything…
On 2017-09-05 00:54:27, alex.jakime...@gmail.com wr
“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
“almost always” indeed. It does work sometimes. Interesting.
On 2017-09-07 13:33:30, nlo...@gmail.com wrote:
> The code below almost always results in "MoarVM panic: Internal error:
> Unwound entire stack and missed handler"
> ```
> sub ran-ok() {
> react {
> my $proc = Proc::Async.new("echo", "1”
Heh.
FWIW we had this since forever:
https://gist.github.com/Whateverable/78168042a011e01fc768c042b0d91898
On 2017-09-09 19:53:53, tomentiru...@gmail.com wrote:
> > my @h is default([])
> []
> > @h[0].push: 3
> [3]
> > @h
> []
> > @h[0]
> [3]
>
> > my %h is default({})
> {}
> > %h = 3
> 3
> > %h
Sorry, it was marked as “resolved”, but I don't see any mention of tests.
On 2014-09-16 07:51:34, elizabeth wrote:
> 16:48:20] jnthn: sanity check: we should allow more than
> one signal to be tapped at a time, right ?
> [16:49:10] lizmat: aye
> [16:49:32] putting this in a file:
> [16:49:34]
FWIW there is still some ecosystem fallout (possibly very minor). I'll be
linking issues here so that we have all things in one place.
IO::MiddleMan and Lumberjack:
https://github.com/zoffixznet/perl6-IO-MiddleMan/issues/5
On 2017-09-11 04:18:39, elizabeth wrote:
> Fixed with 3c9cfdba88287e23e0ced
NCurses, Term::Choose, Term::Choose::Util, and Term::TablePrint:
https://github.com/azawawi/perl6-ncurses/issues/16
This one is weird because it seems to be working unless you run it under prove.
Perhaps the module is alright but it's the test that is broken.
On 2017-09-13 18:16:56, alex.jakime..
Thanks!
On 2017-09-13 21:02:09, lloyd.fo...@gmail.com wrote:
> I think we can close this. It's most likely an internals change
> because I
> call nqp::setparameterizer() directly. I'll figure out what the
> problem is
> eventually and if I can't fix it myself I'll open a more concise RT.
>
> Cheer
CSS::Specification and CSS::Module:
https://github.com/p6-css/CSS-Specification-p6/issues/2
That's basically it. We won't see any other affected modules from toaster data.
On 2017-09-13 18:54:42, alex.jakime...@gmail.com wrote:
> NCurses, Term::Choose, Term::Choose::Util, and Term::TablePrint:
> h
Actually, another direct implication of using .first is this:
Code:
enum Animal (Cat => 0, Dog => 0, Human => 42);
say Dog.succ
Result:
Dog
So it's not just the algorithmic complexity, and we need a test for that.
On 2017-09-14 17:47:59, alex.jakime...@gmail.com wrote:
> Source code:
> https:/
Bisected to
https://github.com/rakudo/rakudo/commit/cd7dc4ce934003b9da1e540e638ee6dbe1f44b1b
Committable output
https://gist.github.com/Whateverable/ee36fb271f2700f1684e1290a966e709
On 2017-09-14 08:16:43, ash.gabr...@gmail.com wrote:
> Hello,
>
> I've written a module with release 2017-07.
>
> s
Well, the title says “Enum.succ and Enum.pred are O(n)” and the issue is still
there, so this ticket is definitely not resolved. If anything, it was rejected.
However, the reasoning for keeping O(n) kinda contradicts itself. If we're
trading RAM for performance, and the amount of elements in enums
Now resolved in
https://github.com/rakudo/rakudo/commit/f925c64826f78803969bb43398877309f6b4a1ac
Closing.
On 2017-09-15 09:01:04, alex.jakime...@gmail.com wrote:
> Well, the title says “Enum.succ and Enum.pred are O(n)” and the issue
> is still
> there, so this ticket is definitely not resolved.
What about this commit?
https://github.com/rakudo/rakudo/commit/0704cd97226e6300194342c88cef1c5fe711
On 2017-09-12 13:55:51, david.warring wrote:
> current behavior of isa method on a subset:
>
> % perl6 -v
> This is Rakudo version 2017.08-110-g5f3350656 built on MoarVM version
> 2017.08.1-156
This is definitely an issue in MoarVM, and it existed since 2014.02 but for
some reason it was unnoticeable before recent changes.
Code:
my $value = -0x7FFF - 1;
say $value;
say -2147483648;
say $value == -2147483648;
Result (MoarVM):
-2147483648
-2147483648
False
Result (JVM):
-2147483648
-
The issue seems to be resolved in
https://github.com/MoarVM/MoarVM/commit/9c5fed708f35edb28f1adf91e9c141372882815f
Tests needed.
When adding tests for this, please cover this case also:
say (-0x7FFF - 1).base(16) # should probably be -8000 but it
erroneously gives -8000
On 20
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 fi
Once this is implemented, replace nqp::setbuffersizefh with it in Test.pm6.
On 2017-09-17 08:38:34, alex.jakime...@gmail.com wrote:
> Using nqp, one can do something like:
>
> nqp::setbuffersizefh(nqp::getstdout(), 0);
>
> But it would be nice if it was available from Perl 6 level.
>
>
> See also:
Plain-wrongs and WHATs print different results today. Bisectable points at
https://github.com/rakudo/rakudo/commit/242baf256a210f1cb643cb6324916dbc76184c9f
I think we now only need tests for this ticket.
On 2015-06-23 09:05:43, hmbrand wrote:
> $ perl6 -e'my int $i = int.Range.min; say $i; say $i
The change was made in https://github.com/rakudo/rakudo/pull/1160
See also: https://rt.perl.org/Ticket/Display.html?id=132111
On 2017-09-16 21:06:03, coke wrote:
> See https://rt.cpan.org/Public/Bug/Display.html?id=108390 which was
> mentioned here:
>
> https://irclog.perlgeek.de/perl6/2017-09-13#
Closing this myself in favor of this ticket:
https://github.com/perl6/doc/issues/1567
On 2017-07-17 23:51:21, alex.jakime...@gmail.com wrote:
> Alright, it seems that rakudo is not entirely incorrect here. See this
> discussion: https://irclog.perlgeek.de/perl6-dev/2017-07-18#i_14885863
>
> TL;DR,
There was a little bit of progress with this here:
https://github.com/MoarVM/MoarVM/pull/687
On 2017-09-01 12:53:36, alex.jakime...@gmail.com wrote:
> https://irclog.perlgeek.de/perl6-dev/2017-09-01#i_15102810
>
> On 2017-07-31 08:27:09, alex.jakime...@gmail.com wrote:
> > FWIW, still happens afte
ed arg for the alphabet, so that the user can provide any character
set he wants
On 2017-09-25 02:01:55, elizabeth wrote:
>
> > On 25 Sep 2017, at 08:21, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> > wrote:
> >
> > # New Ticket Created by Aleks-Daniel Jakimenko-Alekse
I'm shocked to see \r\n→\n translation being defended without any reasoning.
Why are we doing it at all?
“\r\n => \n transformation is done consistently” consistently what? And why?
Even .IO.lines splitting on \r\n is wrong because it cuts \r that may be part
of the data (which is fine in the midd
This reminds me of https://rt.perl.org/Ticket/Display.html?id=132004
On 2015-03-27 15:01:38, drf...@pobox.com wrote:
> OS: Ubuntu 14.04 LTS on VirtualBox
> Host: Windows 8, dual Core i5
>
> Rakudo version: current as of 3/25/2015
>
> This edge case invokes the OOM killer on my test machine. It req
Oh wow, that's really interesting… and old.
I don't think that substr should work like this. Normal arrays are stringified
by ｢substr｣, why would it do something completely different for a native array?
So for both UInt and uint8 arrays I'd expect “65 66 67” as an output.
I think this ticket is r
I think that this stuff is resolved. Not sure when exactly because bisectable
is refusing to work today, but this is TESTNEEDED.
On 2015-06-05 09:18:44, alex.jakime...@gmail.com wrote:
> Code:
> .say for Inf..0
>
> Result:
> -9223372036854775808
> -9223372036854775808
> -9223372036854775808
> -922
I think this is already fixed in
https://github.com/rakudo/rakudo/commit/f6e25b54ea18ba7bd7d7861537d2439933000cb3
¦f6e25b54ea18ba7bd7d78^:
1.83886070
Rat|999/1611392
True
¦f6e25b54ea18ba7bd7d78:
1
Rat|999/1000
This now simply complains about unboxing a large integer. Not sure when this
changed, but testneeded.
On 2015-08-14 22:21:17, alex.jakime...@gmail.com wrote:
> Code:
> say e> .roll(-9).perl;
>
> Result:
> it hangs
>
> Code:
> say e> .roll(-
> e> 99
Now it complains about unboxing a large int.
On 2015-08-14 21:07:37, alex.jakime...@gmail.com wrote:
> First part is OK, but once we start increasing the number it falls
> apart.
>
> say "x".indent(9);
> repeat count > 1073741824 arbitrarily unsupported...
> in bloc
It is better now, but still LTA:
This type cannot unbox to a native integer: P6opaque, Failure
in block at -e line 1
On 2015-08-14 22:27:20, alex.jakime...@gmail.com wrote:
> Code:
> say .rotate(Inf);
>
> Result:
> Earlier failures:
> No zero-arg meaning for infix:<%>
> in block at ./test.pl:2
I guess this is not better, but it's progress:
===SORRY!=== Error while compiling -e
Could not instantiate role 'A':
Cannot invoke this object (REPR: Null; VMNull)
at -e:1
On 2015-07-29 04:08:02, elizabeth wrote:
> Please merge with #125716 or vice-versa :-)
>
> > On 29 Jul 2015, at 12:58, Tobi
1. I think it is properly guarded now. (error message: Cannot coerce a lazy
list onto a Bag)
2. That's OK. A lot of things require whitespace in 6lang (another example
here:
https://docs.6lang.org/language/traps#Less_than_vs._Word_quoting/Associative_indexing
). If you insist on no whitespace you'r
Oh, actually, I noticed it too a few months ago. And removed it.
https://github.com/rakudo/rakudo/commit/5b8d4c2f4232dc0e5e9c62dc602fdcb74f7bdd24#diff-7e0467c62428b3696cb555c69c52a4a0
I guess this is NYI so we can keep it open. I don't know if we have any
alternative to the non-existing ｢.pid｣.
O
Thank you for your report.
Realistically, that's the end of that ticket. Obviously, ｢make｣ no longer
fails, and who knows what was the problem back then.
Given that the issue no longer happens I think it's fair to say that it is
resolved.
Feel free to reopen if you are still having issues with m
Oh. Maybe it's https://rt.perl.org/Ticket/Display.html?id=127279 ?
On 2017-08-26 08:01:06, alex.jakime...@gmail.com wrote:
> Indeed, I'm not sure what I was smoking.
> On 2017-01-20 21:27:50, sml...@gmail.com wrote:
> > > It numifies ranges so that the number of elements is used. In other
> > > wo
The problem went away during the glr. Bisectable points to 96 candidates, so
nothing useful there.
On 2017-10-01 23:15:28, alex.jakime...@gmail.com wrote:
> I think that this stuff is resolved. Not sure when exactly because
> bisectable
> is refusing to work today, but this is TESTNEEDED.
>
> On 2
FWIW, fix bisected (not precisely, but maybe this helps anyway):
* bisect log: https://gist.github.com/5049c109fce53fa78ff969a44ba66366
* (2015-08-27)
https://github.com/rakudo/rakudo/commit/23b3d29da6ffd8e016ea6da6c34858b95339af34
https://github.com/perl6/nqp/compare/2015.07.2-29-ga9a4c0b...2015.
FWIW bisectable gives the same result as in
https://rt.perl.org/Ticket/Display.html?id=125820
On 2017-10-01 23:32:03, alex.jakime...@gmail.com wrote:
> Now it complains about unboxing a large int.
>
> On 2015-08-14 21:07:37, alex.jakime...@gmail.com wrote:
> > First part is OK, but once we start i
See also https://rt.perl.org/Ticket/Display.html?id=125816 (same bisectable
result)
On 2017-10-02 17:12:02, alex.jakime...@gmail.com wrote:
> FWIW, fix bisected (not precisely, but maybe this helps anyway):
> * bisect log: https://gist.github.com/5049c109fce53fa78ff969a44ba66366
> * (2015-08-27)
>
Bisected. First issue was resolved in
https://github.com/rakudo/rakudo/commit/11f27a30bdf380c53697330ec62e982dde68e0b0
On 2017-10-01 23:59:39, alex.jakime...@gmail.com wrote:
> 1. I think it is properly guarded now. (error message: Cannot coerce a
> lazy
> list onto a Bag)
> 2. That's OK. A lot of
Any ideas on what could be a better error message?
On 2014-09-10 10:53:18, equinox wrote:
> Hi all,
>
>
> use NativeCall;
> class TopWindow is repr('CPointer') {
> multi sub TopWindow_TopWindow_c() returns OpaquePointer is
> native("ultimatewindll") { * } #symbol('TopWindow_TopWindow_c')
>
> multi
Yes, this was fixed in
https://github.com/rakudo/rakudo/commit/563abdd46845d70483a21180c817de516003309c
Testneeded.
On 2015-11-12 12:19:37, barto...@gmx.de wrote:
> As a status update: 10 ** -1 is now a Rat:
>
> $ perl6-m -e 'say (10 ** -1).WHAT'
> (Rat)
>
> 9.0 ** -1 is also a Rat, and there is
Yes, I'm happy with it too. No need for perl 5 error message here (also,
please, let's have less perl 5 error messages).
testneeded.
Also, here's how the error message was changing over time:
https://gist.github.com/Whateverable/2373e732b2c3c10f643fa8eb5c5470a7
On 2016-07-07 06:52:35, coke wrote
Right, because it's a Rat.
sub foo(num64 $scale = 1.0) {}; say foo # This type cannot unbox to a native
number: P6opaque, Rat
sub foo(num64 $scale = 1.0.Num) {}; say foo # Nil
I don't know what is the consensus on this one, but having to .Num your values
is rather reasonable.
The error message i
I'd say it's TESTNEEDED for now. Maybe the the stuff from S03 should be spec-ed
in tests and then we can have a separate ticket asking for these changes.
On 2015-09-06 20:11:24, labster wrote:
> Comparison ops added in dac0167a, but I still feel like this behavior
> runs counter to S03#1332.
>
> O
It now prints a completely different error message. The major change was in
https://github.com/rakudo/rakudo/commit/1628e485df1356ae51513009863998daacceffea
but see also how it was changing throughout the years:
https://gist.github.com/555d070b47c007258bd51d95004c2e40
Code:
say [SR-]
Result:
No s
1 - 100 of 434 matches
Mail list logo
