[Coke]++ bisected it to
https://github.com/rakudo/rakudo/commit/80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
On 2017-10-22 12:25:07, b...@post.pl wrote:
> There is no strace on macOS, I used dtruss (dtrace):
>
> $ dtruss -p 1827
> SYSCALL(args) = return
> fstat64(0x0, 0x7FFF5B18B2F0, 0x1) = 0 0
> lsee
OK, first of all, thank you for the report. The issue is indeed there, and in
my opinion it's a significant problem.
Secondly, ♥👍 for trying to bisect it manually. Nowadays I only do it with a bot
unless I have to trisect rakudo+nqp+moar.
However, the result of bisection is wrong (as far as I can
You're right, sorry, I should've been more clear.
Tickets are not closed without tests, but as you pointed out not everything
should be spec-ed. That's correct. Therefore, some tests go to
https://github.com/rakudo/rakudo/tree/nom/t (these tests can be changed at any
moment and don't serve as a gu
rectly.
>
> > On 2017-10-13 04:50:32, elizabeth wrote:
> > > > On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via
> > > > RT)
> > > > wrote:
> > > >
> > > > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
&
And also:
https://github.com/tadzik/perl6-Acme-Meow/blob/35286b14447d22516fbf68767c4d7e18b7396971/lib/Acme/Meow.pm#L65-L69
https://github.com/skids/perl6-Control-Bail/blob/3e6ab6c3bab9176a44476bd0883ba99205306400/lib/Control/Bail.pm6#L81
https://github.com/tadzik/Grammar-BNF/blob/14f51ca5882f00f0ac
Just for the record, there was another module affected by this:
https://github.com/nkh/P6-Text-Template/blob/5e1752c08ddb064e366be862fd500c4de0c4b833/lib/Text/Template.pm#L142
On 2017-10-21 10:44:51, c...@zoffix.com wrote:
> On Sat, 21 Oct 2017 09:06:24 -0700, alex.jakime...@gmail.com wrote:
> > C
https://irclog.perlgeek.de/perl6-dev/2017-10-21#i_15334639
I' think we should test that both are listed, and we can close the ticket.
On 2017-10-13 04:50:32, elizabeth wrote:
> > On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> > wrote:
> >
> >
Offending commit reverted in
https://github.com/MoarVM/MoarVM/commit/1a9be0ad487bc6e2d21df54c6a12892e3f9c8259
I tested it with moar HEAD and indeed the issue is no longer there. So it
should work fine after moar and nqp bumps.
｢testneeded｣ ?
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 tests started to fail (with segv) after this rakudo commit:
>
https://github.com/rakudo/rakudo/commit/ff063e7b53ab41b79279ffc38e1740d3d
Slight change after https://github.com/rakudo/rakudo/commit/b6982e68
Current output:
https://gist.github.com/Whateverable/6500a98a091e42d8b664e4b870f09a7d
On 2017-10-13 20:09:41, alex.jakime...@gmail.com wrote:
> Code:
> say .name, “ – ”, .gist for .^methods
>
> Result:
> from-iterator – from-ite
Oh. This was fixed in https://github.com/rakudo/rakudo/commit/56eef696
｢testneeded｣
On 2017-10-08 21:38:13, alex.jakime...@gmail.com wrote:
> Code:
> use lib ‘’
>
> Result:
> ===SORRY!===
> Too few positionals passed to 'repository-for-spec'; expected 3
> arguments but got 0
>
>
> Also there's no
Alright, so this was fixed, or at least Committable is sure that it was:
https://gist.github.com/Whateverable/569f4cd48eb7e12e50922035d0d4d94e
According to brrt the fix is in this moarvm commit:
https://github.com/MoarVM/MoarVM/commit/bedc8511387af00ea3b71d07770e9e7eb2c0e279
I guess we need tests
How can I reproduce this issue? What code did you use?
Bisected: (2016-06-29)
https://github.com/rakudo/rakudo/commit/d5c750f74cd4cdbc4746da8bf32d42fc37032b78
On 2017-10-14 06:33:04, c...@zoffix.com wrote:
> m: use nqp; say nqp::getlexdyn('&DEPRECATED')
> rakudo-moar 0d217357a: OUTPUT: «(signal SEGV)»
FWIW the title is very misleading, see this discussion:
https://irclog.perlgeek.de/perl6/2017-10-16#i_15312269
On 2017-10-16 16:23:05, alex.jakime...@gmail.com wrote:
> Code:
> say 1.1
>
> Result (2014.01 .. d6a9eda):
> 1.1604544
>
>
> The number itself is store
Right. Then I guess it's not a regression. Tag removed.
On 2017-10-16 07:42:06, jn...@jnthn.net wrote:
> On Fri, 13 Oct 2017 20:43:42 -0700, alex.jakime...@gmail.com wrote:
> > Code:
> > my $s1 = Supplier.new; $s1.Supply.tap: { say $_; $s1.emit(2) if $++ <
> > 5; say "here" }; $s1.emit(1)
> >
> >
And not only parameters, but unused variables also:
https://github.com/rakudo/rakudo/blob/ebb0521bd259e9f81e4b127527534090969f398e/src/core/native_array.pm#L1399
On 2017-10-14 20:53:03, alex.jakime...@gmail.com wrote:
> FWIW I made a throwaway script that looks for unused params, and there
> are m
FWIW I made a throwaway script that looks for unused params, and there are many
of these in rakudo sources. Of course, most of these cases are not in hot
paths, but the overall performance benefit may be very noticeable.
There are also cases like this:
https://github.com/rakudo/rakudo/blob/nom/src
Oh, I guess it applies to methods as well.
On 2017-10-14 20:10:15, alex.jakime...@gmail.com wrote:
> Code:
> sub f1($a, $, $, $, $, $) { 1 };
> my $s;
> $s += f1($_, $_, $_, $_, $_, $_) for ^1_000_000;
> say now - BEGIN now
>
> Result:
> 0.43209886
>
>
> Code:
> sub f2($a, $b1, $b2, $b3, $b4, $b5)
Maybe it is worth noting that this is pretty much a regression (even though an
old one, and caused by a non-optimizer change).
(2016-08-09)
https://github.com/rakudo/rakudo/commit/328402599c16077e182bb38baf68e435b8bc1082
Output before and after:
https://gist.github.com/75b15f93438bd038cf0bec26c43
Someone asked why this issue is ANNOYING, here's some clafirication.
Basically, most of the stuff said said in linked comment applies here as well:
https://rt.perl.org/Ticket/Display.html?id=131003#txn-1496218
In other words, *some* signals have correct values and you don't notice the
issue right
Actually, it is a regression.
Code:
my int @x[-2**63]; say @x.shape
¦«2015.12»:
(-9223372036854775808)
¦«2016.06»:
Illegal dimension in shape: -9223372036854775808. All dimensions must be
integers bigger than 0
in block at
/home/bisectable/git/whateverable/data/regressionable/15074816/snippet
There's something regression-ish about it.
Code:
say $*KERNEL.signal: SIGUSR1
¦79b8ab9d3f^:
10
¦79b8ab9d3f:
30
See (2017-06-02)
https://github.com/rakudo/rakudo/commit/79b8ab9d3f9a5499e8a7859f34b4499fb352ac13
On 2017-09-01 15:39:42, alex.jakime...@gmail.com wrote:
> We now have a note in the
Oh, but maybe it's worth mentioning that the name was added in this commit:
https://github.com/rakudo/rakudo/commit/7783fcab24813054902414f30f6fd4fd60823c30
On 2017-10-13 20:13:01, alex.jakime...@gmail.com wrote:
> Code:
> for [:a] X [:b] -> ($i, $j) { }
>
> Result:
> Too few positionals passed to
I'll take a look a bit later. It feels like the commit you mentioned is the
right one, which makes me think that we can reject this ticket, but at that
pace the spectest will get to turtle speeds even though all our changes will be
justified.
Anyway, I'll bisect it first and then we'll have a look
FWIW because of workaround commit mentioned above this code behaves a little
bit differently:
Code:
my $x; my $y := $x; $x = Map.new((:a(42),:b($y))); say $x
¦«2015.12»:
«timed out after 10 seconds» «exit signal = SIGHUP (1)»
¦«2016.06»:
«timed out after 10 seconds» «exit signal = SIGHUP (1)»
¦
This is actually a regression.
Code:
$ = ""; sub postfix:<♥> { $^a + 42}; say "{ 5♥ }"
¦«2015.12»:
47
¦«2016.06»:
47
¦«2016.12»:
47
¦«2017.06»:
===SORRY!=== Error while compiling
/home/bisectable/git/whateverable/data/regressionable/15285677/snippet
Bogus postfix
at /home/bisectable/git/whatev
Alright! This was fixed.
Bisectable points at the merge of “better-sched” branch, which happen right
after 2017.09 release. See
https://github.com/rakudo/rakudo/commit/61a77e60a7d936415503d8916fcc7546569e9135
Zoffix++ found some tests:
https://github.com/perl6/roast/commit/ae3eea8a8b43d9c6b1be6b0
Oh, and if rakudo/issues is opened, then for me all issues raised in this
ticket will be resolved.
On 2017-10-11 13:21:41, alex.jakime...@gmail.com wrote:
> There was some fresh discussion on this topic recently. See
> https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15289848 and the
> start of t
There was some fresh discussion on this topic recently. See
https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15289848 and the start of the
discussion on https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15289680
The idea is that instead of doing a full migration we can just start using
another tr
OK, so the test for this goes like this:
Create a file Simple.pm6 with this content:
unit class Simple; sub buggy-str is export { “: {‘’}\n\r” ~ “\n\r” }
Then run something like this:
use lib ‘sandbox’; # or whatever the path is for your Simple.pm6
use Simple;
say buggy-str() eq “: \n\r\n\r”
O
I'm fairly sure that the ship for this has sailed, we've had this “issue” for a
year now.
I guess during that year everyone has adapted their code to the new behavior.
So if you're reading this comment and you think that the ticket should be
closed, please just mark it as ｢testneeded｣ so that we
I don't know if this should be implemented. But at the same time, isn't it just
a matter of using an arg alias?
On 2016-01-05 05:29:15, elizabeth wrote:
> > On 05 Jan 2016, at 02:49, Alex Jakimenko (via RT) > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Alex Jakimenko
> > # Please in
Well, the crash is no longer there, but it shouldn't be a VMNull.
This problem was observed again today in this discussion:
http://colabti.org/irclogger/irclogger_log/perl6?date=2017-10-11#l104
On 2016-05-11 05:05:20, sml...@gmail.com wrote:
> Similarly to ticket #127254, this does not segfault
FWIW it went from 4.1724 to 3.3393 (2015.12→HEAD(a72214c)) for 5k of says.
On 2016-01-24 06:28:38, n...@detonation.org wrote:
> I don't think it's related to subs. It's compilation in general that's
> rather slow, most of all parsing.
>
> nine@sphinx:~> for x in {1..1}; do echo 'say ‘a’;' >> pr
I'll close this in favor of the doc issue mentioned above.
I'm pretty sure this needs a corresponding [DETRAP] ticket, but that tag is not
a thing *yet*. For now we only document these things. Eventually I'll get to
it, but this a long-term thingie (like v6.d or v6.e or whatever).
On 2017-10-09 0
FWIW if anybody is wondering, not a regression. This exact behavior appeared in
2015.12, see
https://gist.github.com/Whateverable/60a3fc6444bd8ccefc88ce982fa00e8f
On 2017-10-05 21:38:49, j.david.l...@gmail.com wrote:
> This program dies after a short but inconsistent run:
>
> ```
> #!/usr/bin/env
FWIW it always did that, not a regression.
On 2017-10-05 21:10:39, j.david.l...@gmail.com wrote:
> This short program crashes reliably (with a segmentation fault) on my
> system:
>
> ```
> #!/usr/bin/env perl6
>
> use v6.c;
>
> my $lock = Lock.new;
> my $set = SetHash.new;
> await (^12).map: {
> s
SORRY disappeared after
https://github.com/rakudo/rakudo/commit/25e9fd76e85fabda20e263b6f87e27b0673f26e2
On 2017-10-08 01:21:27, alex.jakime...@gmail.com wrote:
> Code:
> say ‘Hello’; say *...‘WAT’
>
> Result:
> Hello
> No such method 'succ' for invocant of type 'Whatever'. Did you mean 'sum'?
> i
Code:
say ‘Hello’; say *...‘WAT’
Result:
Hello
No such method 'succ' for invocant of type 'Whatever'. Did you mean 'sum'?
in block at -e line 1
Code:
say 0, * ... "what"
Result:
No such method 'pred' for invocant of type 'Whatever'. Did you mean any of
these?
grep
tree
in block at -e line 1
On a slightly more positive note, that PR indeed resolves this ticket. I think
the new error message is clear enough.
On 2017-10-08 00:52:36, alex.jakime...@gmail.com wrote:
> There is a PR but it's really bad:
> https://github.com/rakudo/rakudo/pull/1188
>
> On 2016-04-07 17:05:15, alex.jakime...
There is a PR but it's really bad: https://github.com/rakudo/rakudo/pull/1188
On 2016-04-07 17:05:15, alex.jakime...@gmail.com wrote:
> Code:
> loop (my $x = 0, $x < 10, $x++) {}
>
> Result:
> ===SORRY!=== Error while compiling -e
> Malformed loop spec
> at -e:1
> --> loop (my $x = 0, $x < 10,
So-o. Zoffix insists that everything is correct here, and perhaps it is so.
That being said, I don't quite understand why it can't be done. Maybe somebody
else can take a look also. Here's my logic:
So if you have
@array[0...@array.end]
and
@array[0..*]
Would we get identical results from both
I created this doc issue: https://github.com/perl6/doc/issues/1591
On 2017-10-07 19:33:40, allber...@gmail.com wrote:
> On Sat, Oct 7, 2017 at 10:21 PM, Itsuki Toyota > wrote:
>
> > See the following result:
> >
> > $ perl6 -e 'my $proc = Proc::Async.new("yes");
> > $proc.stdout.head(1).tap(&say)
Basically, this would need to throw X::Syntax::KeywordAsFunction, but it blows
up when trying to look up $test so that's rather unfortunate. Pretty sure we
can do something about it but maybe it's not a one-line fix.
On 2016-04-07 16:29:37, alex.jakime...@gmail.com wrote:
> Code:
> my($test) = 42
Oops. Last link:
https://github.com/rakudo/rakudo/blob/de0533c4d4c9f425ce22432a8e4555ded27cba91/src/Perl6/Grammar.nqp#L3853
On 2017-10-07 17:35:58, alex.jakime...@gmail.com wrote:
> FWIW to add it one will need to hack this part:
>
https://github.com/rakudo/rakudo/blob/de0533c4d4c9f425ce22432a8e45
FWIW to add it one will need to hack this part:
https://github.com/rakudo/rakudo/blob/de0533c4d4c9f425ce22432a8e4555ded27cba91/src/Perl6/Actions.nqp#L7999-L8055
See the implementation for S/// for more inspiration:
https://github.com/rakudo/rakudo/blob/de0533c4d4c9f425ce22432a8e4555ded27cba91/src/
FWIW to add it one will need to hack this part:
https://github.com/rakudo/rakudo/blob/de0533c4d4c9f425ce22432a8e4555ded27cba91/src/Perl6/Actions.nqp#L7999-L8055
See the implementation for S/// for more inspiration:
https://github.com/rakudo/rakudo/blob/de0533c4d4c9f425ce22432a8e4555ded27cba91/src/
Zoffix++ pointed out that there is a problem with IntStr also:
Code:
enum Foo (:Bar(1), :Baz(<42>))
Result:
===SORRY!===
Incompatible MROs in P6opaque rebless for types IntStr and Foo
On 2017-10-07 17:16:30, alex.jakime...@gmail.com wrote:
> Actually, it's not about the error message. The whole
Actually, it's not about the error message. The whole thing can be golfed to
this:
enum Foo (:Bar(1), :Baz(True))
And the error happens because:
Code:
use nqp;
say so nqp::istype(True, Int);
nqp::rebless(True, Int)
Result:
True
Incompatible MROs in P6opaque rebless for types Bool and Int
in blo
FWIW I agree about the “debug” mode.
That said, it isn't just a nice-to-have. This is something that can make people
mention Perl 6 when discussing the most amazing features of modern programming
languages… much like people mention grammars today :)
On 2016-01-17 04:07:19, jn...@jnthn.net wrote:
>
This was resolved in these commits:
*
https://github.com/rakudo/rakudo/commit/ac97a4016196c1fb5c39365dfbe8980574fb929b
*
https://github.com/rakudo/rakudo/commit/64b001a1464bf618fa4c0eed984e240fcf8b772b
｢testneeded｣
Please try to cover various variants in tests, like:
(--> Bool Int $x, Int $y)
(--
Yeah.
On 2017-10-02 22:10:56, alex.jakime...@gmail.com wrote:
> Actually, this is a dup of
> https://rt.perl.org/Ticket/Display.html?id=128804 ,
> and I think it's now resolved.
>
> On 2015-12-30 12:39:37, alex.jakime...@gmail.com wrote:
> > Code:
> > say :5<1.I>
> >
> > Result:
> > ===SORRY!=== E
“Couldn't the confusing wording be fixed without additional information?”
Yes. But how? We can't *remove* this hint because sometimes it is super useful.
On 2017-10-06 11:13:34, sml...@gmail.com wrote:
> On Wed, 04 Oct 2017 22:10:22 -0700, alex.jakime...@gmail.com wrote:
> > To produce an error m
I merged the PR. Thank you for you patience.
｢testneeded｣
See
https://github.com/rakudo/rakudo/commit/c7a82d451d6506bda9422813fe72974575e473df
You can see some code examples here:
https://github.com/rakudo/rakudo/pull/565#issuecomment-334965048
Maybe these can be turned into tests easily.
On 20
Should be fixed in https://github.com/rakudo/rakudo/commit/5747bc7121
Testneeded. Slightly relevant tests here:
https://github.com/perl6/roast/commit/34577134e0
Should be fixed in https://github.com/rakudo/rakudo/commit/5747bc7121
Testneeded. Slightly relevant tests here:
https://github.com/perl6/roast/commit/34577134e0
On 2017-10-06 21:01:48, alex.jakime...@gmail.com wrote:
> This one is a bit harder than it seems.
>
> So here is what throws:
>
https://
FWIW, here was my attempt to resolve this issue:
diff --git a/src/Perl6/Grammar.nqp b/src/Perl6/Grammar.nqp
index 13c09feb9..09b05bac7 100644
--- a/src/Perl6/Grammar.nqp
+++ b/src/Perl6/Grammar.nqp
@@ -3553,6 +3553,9 @@ grammar Perl6::Grammar is HLL::Grammar does STD {
|
]
| $ >
<.typed_sorry: '
OK. There are 5 new tickets for all other issues. In this particular ticket
let's talk about (), [], "", etc. Basically, anything that currently says
“corresponding starter” (word “starter” instead of the actual starter). It
should really print the actual starter, but for now it's a good way to fig
Some discussion: https://irclog.perlgeek.de/perl6/2017-10-07#i_15271146
Thanks, indeed.
Bisectable points to
https://github.com/rakudo/rakudo/commit/2574f8835f7e1342e848c0135fbed6319d55eb0e
On 2017-10-07 06:52:35, j...@gellyfish.co.uk wrote:
> Hi,
> Given a module (Suptest.pm):
>
> my package EXPORTHOW {
> class SUPERSEDE::class is Metamodel::ClassHOW {
> has $.foo;
Ah, sorry. Even though some tests are needed, this ticket is still not fully
resolved. I'll try to split it right now.
On 2017-10-07 09:40:03, alex.jakime...@gmail.com wrote:
> PR was merged, tests needed.
>
> On 2017-10-06 19:40:44, alex.jakime...@gmail.com wrote:
> > See this pull request: https
PR was merged, tests needed.
On 2017-10-06 19:40:44, alex.jakime...@gmail.com wrote:
> See this pull request: https://github.com/rakudo/rakudo/pull/1183
>
> Unfortunately not all of the things are covered. For example:
>
> perl6 -e 'my $x = q:to/foo/;
> blah
> '
> ===SORRY!=== Error while compilin
» is supposed to be an explicit promise that you don't care about
order, and there are lots of places that are not marked pure that are
nevertheless effectively pure
On 2017-10-07 09:34:59, alex.jakime...@gmail.com wrote:
> Zoffix: so ».say should not be discouraged?
> Interesting
> AlexDaniel_
Zoffix: so ».say should not be discouraged? Interesting
AlexDaniel_: well, that's based on an off-hand comment in IRC chat.
Not a final design descision :)
On 2017-10-07 09:32:43, alex.jakime...@gmail.com wrote:
> AlexDaniel: FWIW jnthn++ said we'll likely make ». autothread
> only is
> pure ro
AlexDaniel: FWIW jnthn++ said we'll likely make ». autothread only is
pure routines, so no shuffling is really needed
On 2017-01-02 11:31:47, alex.jakime...@gmail.com wrote:
> Code:
> ».say
>
> Result (2015.07):
> d
> b
> c
> a
>
> Result (HEAD):
> a
> b
> c
> d
>
>
> The idea was that the order
This one is a bit harder than it seems.
So here is what throws:
https://github.com/rakudo/rakudo/blob/f62ae60c48d1372df18b49aca44e10af44ead2d6/src/Perl6/Grammar.nqp#L315
However, the cursor has wrong position for some reason. Looking at the lines
above, it may seem that doing this:
self.'!cursor
FWIW for those wondering how exactly it was resolved, here's the commit:
https://github.com/rakudo/rakudo/commit/382c78a97ae6132d0054e0112cf19ceb2d50fef6
On 2016-12-10 10:10:48, c...@zoffix.com wrote:
> Tests now exist:
>
https://github.com/perl6/roast/commit/da6fde44ab97cdcbb50bf181528f5567191461
See this pull request: https://github.com/rakudo/rakudo/pull/1183
Unfortunately not all of the things are covered. For example:
perl6 -e 'my $x = q:to/foo/;
blah
'
===SORRY!=== Error while compiling -e
Ending delimiter foo not found
at -e:3
--> ⏏
expecting any of:
whitespace
Then there's als
1
debug
at SETTING::src/core/Exception.pm:57 (./CORE.setting.moarvm:throw)
from src/Perl6/World.nqp:4660 (blib/Perl6/World.moarvm:throw)
from src/Perl6/Grammar.nqp:272 (blib/Perl6/Grammar.moarvm:typed_panic)
from src/Perl6/Grammar.nqp:262 (blib/Perl6/Grammar.moarvm:panic)
from src/Perl
3
debug
at SETTING::src/core/Exception.pm:57 (./CORE.setting.moarvm:throw)
from src/Perl6/World.nqp:4660 (blib/Perl6/World.moarvm:throw)
from src/Perl6/Grammar.nqp:272 (blib/Perl6/Grammar.moarvm:typed_panic)
from src/Perl6/Grammar.nqp:262 (blib/Perl6/Grammar.moarvm:panic)
from src/Perl
OK, RT refuses to display it, so let's try again.
Previous message:
Oof. I'm wondering why is it a .sorry and not .panic. Panic will blow up
immediately with a good error message, but I think there's some reason for it
to be a sorry. I can't figure out what it is exactly. Maybe something about
su
Oof. I'm wondering why is it a .sorry and not .panic. Panic will blow up
immediately with a good error message, but I think there's some reason for it
to be a sorry. I can't figure out what it is exactly. Maybe something about
subs called “if”? I tried various ways to trigger it erroneously but cou
I'll close this ticket. I'm failing to reproduce the issue on 2015-ish versions
of rakudo, let alone HEAD. I think the actual problem was resolved and
hopefully there are tests for it, but trying to find what exactly fixed it is a
total waste of time unfortunately. Even with all powers of whatevera
This was fixed in
https://github.com/rakudo/rakudo/commit/502b886e8d14dbd51b5dc201309f9f8bb0a4c3e0
Not sure why it's still not closed. Closing.
On 2015-12-12 20:45:06, lloyd.fo...@gmail.com wrote:
> test:
>
https://github.com/perl6/roast/commit/c205f71781a29a456349a791fdf912d6955fe50f
>
> On Sat,
So there are three issues:
1) ✓ no line number. RESOLVED in
https://github.com/rakudo/rakudo/commit/25e9fd76e85fabda20e263b6f87e27b0673f26e2
2) ✗ it could mention '* > 5'.
3) ✓ it could mention the 2. RESOLVED in
https://github.com/rakudo/rakudo/commit/f1cd8e313abff2f66b9989fe60870a6e11cf7588
On
This was changed in
https://github.com/rakudo/rakudo/commit/fb5db59220d38e2f9af4c747138742f157d0fabb
… and now you can use anything, even NaN.
Assuming that this behavior is right, testneeded.
See also: https://github.com/perl6/doc/issues/1589
On 2016-01-21 12:04:33, alex.jakime...@gmail.com wr
This was resolved in this commit trio:
https://github.com/rakudo/rakudo/commit/22f00cd72defbaeb1ad83187309854e33739
https://github.com/perl6/nqp/commit/b083e3471a25bf376fa89b5ec53969b870eb6ac2
https://github.com/MoarVM/MoarVM/commit/1288e7edde60b8c88afb85029dc089092db80168
｢testneeded｣
On 201
As far as I know, this ticket is impossible to resolve. At least not with what
we have now in rakudo.
To produce an error message that is more precise we'll need more information
than just a line number, but we don't have that during the run time.
See https://rt.perl.org/Ticket/Display.html?id=12
The first part of the ticket was resolved in
https://github.com/rakudo/rakudo/commit/46dca95547949bc3d791efb2620d362a68176fdc
So you can no longer create an array using 0.5.
But you can still create an array with any fractional value that's larger than
1, and it will blow up later.
♥
I wonder if this needs a separate sub or variable instead of adding secret
functionality to $*PROGRAM-NAME.
On 2017-10-01 09:52:19, allber...@gmail.com wrote:
> On Sun, Oct 1, 2017 at 12:35 PM, Zoffix Znet
> wrote:
>
> > $*PROGRAM-NAME is supposed to be a replacement for Perl 5's $0, but it
> > d
I'll close it. Suggested use of ｢or｣ is rather clear, and learning about it
takes exactly the same amount of effort the second optional argument will take.
If anybody has to say something about it please feel free to. We can reopen the
ticket if there's new information on why that particular featu
I bisected it to
https://github.com/rakudo/rakudo/commit/87288285f6f398ec7cba0900312ced4b580d79ed
The error is still there but different. See
https://gist.github.com/Whateverable/536231b535ec98403f2cc96a452dd5b1
Not sure if it helps though.
On 2017-09-29 17:01:40, c...@zoffix.com wrote:
> $ echo
In this particular case it means you cannot write web scrapers using rakudo.
And not only that, but it makes you feel like rakudo is completely broken if it
can't even go through a few tens of pages without SEGV-ing. If Skarsnik's
suspicion that the issue is in XML right, then it's not just with gu
IIRC the idea was that in some cases you should be able to do this without
commas. I don't think we need an RFC for this, somebody just has to implement
it properly.
Also, I think there are several tickets related to this problem. Maybe worth
looking for other ones.
On 2016-01-03 10:09:47, c...@z
This is just a test.
Writing a comment by email.
See
https://github.com/rakudo/rakudo/blob/f946bd35dca39af97983ec95d4da7fdd0416b73d/src/core/Exception.pm#L1025-L1031
It seems that you can add “need” and “use” there (with a good message) and it
will do exactly what was requested.
On 2015-11-17 18:57:53, fecund wrote:
> When Rakudo (MoarVM) 6.b e
Actually, this is a dup of https://rt.perl.org/Ticket/Display.html?id=128804 ,
and I think it's now resolved.
On 2015-12-30 12:39:37, alex.jakime...@gmail.com wrote:
> Code:
> say :5<1.I>
>
> Result:
> ===SORRY!=== Error while compiling -e
> Couldn't process entire number: 1/1 int chars, -1/1 frac
This was fixed during the uncurse merge. Bisect log (20 candidates):
https://gist.github.com/7cedc2e2e35913544f75bc5fc89bd088
｢testneeded｣
On 2016-11-26 18:36:35, alex.jakime...@gmail.com wrote:
> *Code:*
> dd ‘789’.comb(/ . {say $/} /)'
>
> *Result:*
> ｢7｣
> ｢7｣
> ｢7｣
> slip()
>
> It may seem l
Oh. That's actually related to this ticket:
https://rt.perl.org/Ticket/Display.html?id=132168
I'll merge it because both tickets are asking for the same problem to be
resolved.
On 2015-11-09 05:03:59, jns...@gellyfish.co.uk wrote:
> perl6 -e 'my $a = "jsjsjs {"; for -> $b { say $b }'
> ===SORRY!
Interesting.
On 2015-11-05 16:13:33, besc...@gmail.com wrote:
> m: grammar G {rule TOP {}; token G1 {A}}; my $g =
> G.parse("A"); say $g».Str
>
> rakudo-moar c880f1: OUTPUT«()»
>
> See: http://irclog.perlgeek.de/perl6/2015-11-05#i_11492065
>
> and subsequent discussion.
Also worth taking a look at https://rt.perl.org/Ticket/Display.html?id=126569
On 2017-09-29 14:06:58, b...@abrij.org wrote:
> On Sun, 28 May 2017 00:08:18 -0700, sml...@gmail.com wrote:
> > This bug is still present in
> >
> > This is Rakudo version 2017.05-134-g0c5fe56cc built on MoarVM version
>
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
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
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
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
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
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
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
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)
>
201 - 300 of 434 matches
Mail list logo
