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
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
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
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
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
>
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
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.
>
>
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:
>
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.
>
>
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,
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]
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
“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",
“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).
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
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:
>
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,
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.
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
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,
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
> >
>
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,
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)
>
>
Untodoed in
https://github.com/perl6/roast/commit/03e5a5120465622d9e13451b43cdeb03fd2354a7
Untodoed in
https://github.com/perl6/roast/commit/b60cef93e356908eadc7855f816ec8f77bd03e01#diff-4a0037e48f821303bb0939ba43d6e6cfL291
Untodoed in
https://github.com/perl6/roast/commit/b60cef93e356908eadc7855f816ec8f77bd03e01#diff-4a0037e48f821303bb0939ba43d6e6cfL264
Unskipped in
https://github.com/perl6/roast/commit/e7252a2a1281f666f362b621c030f7b75db513ae
Unskipped in
https://github.com/perl6/roast/commit/5425477851ee07c5489d4647920797fe7ae01e19
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
This was untodo-ed in
https://github.com/perl6/roast/commit/e180d46b926aaa0b781b1fe5d1ee66d32a666d23
This was untodo-ed in
https://github.com/perl6/roast/commit/e180d46b926aaa0b781b1fe5d1ee66d32a666d23
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
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?
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
Still not 77.
On 2012-12-07 02:55:44, masak wrote:
> rn: sub postfix:<+>($a) is looser(:<+>) { $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 case
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
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
dex 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
> > The check
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
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
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:
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
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
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
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-
>
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,
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
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).
>
>
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
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
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:
>
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
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
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):
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
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
>
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
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 (
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,
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,
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
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
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/commit/40a953f5d9f5c661d8cf9b043643002d348a2000
>
> On earlier rakudo versions it seems to be working fine. I haven't seen
> it
ed by:
>
> $_ = 1; /1/
>
> Because $_ contains an Int, this becomes a very slow path. Compare
> this with:
>
> (^1)>>.Str.grep({!/1/}).elems.say
>
> which is 3x faster, even when using a sub-optimal hyper.
>
> Investigating further...
>
> > On 27 Jul
".gist" is probably the wrong answer in this case.
my @got = ‘one’, ‘two three’; say @got # OUTPUT: [one two three]
↑ Not very useful
On 2017-07-25 12:52:25, alex.jakime...@gmail.com wrote:
> Sometimes it is useful to test the input against regexes. Let's try:
>
> Code:
> use Test;
> cmp-ok
Another interesting thing is that if this is implemented, then it will make it
possible to use ? in other places where is used. For example, it
will allow %h:?exists . It seems that it will also affect character classes
(e.g. <:?Ll>). Some of these totally make sense, some not so much. But we
For those who don't agree that there is a connection between ? and !… Actually,
there are some other places where ?↔! connection is implied. In fact, I will
probably never list all of them.
In regexes:
* always succeeds, always fails (and no question implied)
* tests for truthy and falsey
23, 2017 at 12:41 PM Aleks-Daniel Jakimenko-Aleksejev via
> RT <
> perl6-bugs-follo...@perl.org> wrote:
For those reading this on RT, here's the previous comment in a readable way:
I wouldn't be so eager to judge the proposal based on the original post.
Sometimes I submit tickets fast, and sometimes ideas are not conveyed as
clearly as I assumed.
“How are those things related?”
These were the
ething.
> >
> > ‘:foo’ sets foo to True. ‘:!foo’ sets it to False. ‘:?foo’ looks like
> > it's
> > trying to ask something a question, but I'm not sure about what.
> >
> > On Sun, Jul 23, 2017 at 12:41 PM Aleks-Daniel Jakimenko-Aleksejev via
> > RT <
>
t;
> On Sun, Jul 23, 2017 at 6:05 AM Aleks-Daniel Jakimenko-Aleksejev via
> RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > sub foo($bar!) { say $bar }; foo(42)
> >
> > On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> > > Eh. The e
Perhaps also worth noting that this applies to other holes as well, e.g. those
created by extending an array:
my @a = 42; @a[5] = 49; say |@a # 42(Mu)(Mu)(Mu)(Mu)49
In fact, this the actual problem the user had.
On 2017-07-22 18:52:03, c...@zoffix.com wrote:
> On Sat, 22 Jul 2017 18:48:38
I bisected it to
https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000
On earlier rakudo versions it seems to be working fine. I haven't seen it crash
once on anything earlier, but it is *very* slow on rakudos that old, so it's
hard to tell.
nqp changes:
ger
>
> $ 6 'my @a[999]'
> Illegal dimension in shape: 999. All dimensions must
> be integers bigger than 0
>
> etc etc etc.
>
> > On 7 Dec 2016, at 01:37, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> > <perl6-bugs-follo...@perl.org&g
sub foo($bar!) { say $bar }; foo(42)
On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> Eh. The effort required to implement the feature is much less than
> having
> discussions *like this*. I'll try to be quick.
>
> “there's large possibility of introducing some unwanted ambiguity
>
Eh. The effort required to implement the feature is much less than having
discussions *like this*. I'll try to be quick.
“there's large possibility of introducing some unwanted ambiguity somewhere”
A good thing to keep in mind indeed.
I don't really like these discussions before actual PRs, but
A test was added in
https://github.com/perl6/roast/commit/84e5309567a5f3ee0d1d7450e08225119b08f3af
dogbert17++
On 2017-07-21 12:46:12, jan-olof.hen...@bredband.net wrote:
> On Sat, 14 Nov 2015 14:06:52 -0800, grond...@yahoo.fr wrote:
> > $ perl6 --version
> > This is perl6 version
Is there any code snippet to reproduce it?
The backtrace mentions mongo-perl6-driver…
On 2017-07-22 02:38:03, mt1...@gmail.com wrote:
> Test code erred in perl6 version 2017.07-31-g895bdc8 built on MoarVM
> version 2017.07.
>
> Regards,
> Marcel
>
>
> The crash dump;
>
>
> *** Error in
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, one should use something like this:
whenever $proc.print(“one\ntwo\nthree\nfour”) { $proc.close-stdin }
So it seems that it's not a bug, but a
I think the purpose of the ticket was stated clearly in the first message.
Feel free to change the comment in the source code to “This is a hack but
there's no point to improve it” and close the ticket.
To me it felt like the intention was to improve this part later, but no TODO
comment was
I don't think this ticket needs so much discussion… It's basically about
implementing the damn thing properly (and coming up with a way to do it along
the way).
On 2017-07-16 21:17:22, alex.jakime...@gmail.com wrote:
> See this:
>
On 2017-07-13 08:18:20, alex.jakime...@gmail.com wrote:
> On 2017-07-12 22:49:43, ug...@cpan.org wrote:
> > This only applies if you call .stdout or .stderr *and* never close
> > them.
>
> Hm, isn't it fixed now? Similarly to
> https://github.com/perl6/doc/issues/1304 ?
Ah, no, it's not. It's a
On 2017-07-12 22:49:43, ug...@cpan.org wrote:
> This only applies if you call .stdout or .stderr *and* never close them.
Hm, isn't it fixed now? Similarly to https://github.com/perl6/doc/issues/1304 ?
That's pretty good. But issues are not closed without tests, unless there's a
good reason not to add a test. No reason was mentioned, therefore reopening
this with “testneeded” tag.
On 2017-07-09 15:49:46, jan-olof.hen...@bredband.net wrote:
> On Wed, 19 Oct 2016 05:57:04 -0700, jn...@jnthn.net
Since when are we rejecting tickets like that? :)
The title says “Strange error”. Current error message is:
===SORRY!===
redo without loop construct
Two things:
1) No line number
2) Even if the line number was there, we don't want the behavior of this to be
changing like crazy. See output on all
This was resolved together with
https://rt.perl.org/Ticket/Display.html?id=131241
Tests needed, maybe. See other ticket for info on this.
On 2016-12-17 01:42:04, elizabeth wrote:
> $ 6 'my $b = .BagHash; $_-- for $b.values; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>1,"e"=>0,"f"=>0,"d"=>0).BagHash
Hm. Wouldn't that make behavior of Lists and Arrays different?
On 2017-07-04 05:29:20, comdog wrote:
> Accessing a List element beyond the end of the List returns Nil,
> although accessing an element before the beginning returns an out of
> bounds failure. I think there's two things that can be
Case in point: https://stackoverflow.com/questions/44835476
On 2016-08-29 19:28:10, alex.jakime...@gmail.com wrote:
> First of all, take a look at this:
> https://docs.perl6.org/language/traps#String_Ranges/Sequences
>
> The question is: why do we keep this trap?
>
> We all know that the idea of
I don't really want to start another ticket for what I'm about to suggest,
therefore I'll reopen this one.
Not so long ago I filed this ticket:
https://rt.perl.org/Ticket/Display.html?id=131640
The underlying issue is exactly the same. And it has actually happened during
whateverable
I'd agree that it is a bug, yes. Well, the reason why it happens might be
justified, but this is probably one of the fattest traps I've seen so far. I
really think we should come up with a way to eliminate this trap somehow. Not
sure how, but there must be a way and I really recommend anybody
I think this is related: https://github.com/perl6/doc/issues/1400
On 2017-07-01 12:25:39, pe...@mscha.org wrote:
> This is OK:
>
> > say [X] ((1,2,3), (4,5,6));
> ((1 4) (1 5) (1 6) (2 4) (2 5) (2 6) (3 4) (3 5) (3 6))
> > say [X*] ((1,2,3), (4,5,6));
> (4 5 6 8 10 12 12 15 18)
>
> ... but this
This was discussed in
https://github.com/rakudo/rakudo/pull/1032#issuecomment-284217342
In theory, this ticket should apply for other ops as well.
Note that I said that I will change the way unicode ops are implemented, but I
didn't have much time since then. Hoping to get to it at some point.
An important line from bisectable output was omitted :)
samcv, The result looks a bit unrealistic, doesn't it? Most
probably the output is different on every commit (e.g. ｢bisect: say rand｣)
We can try this:
c: releases say ('a' x 1).IO.open
AlexDaniel,
See also this discussion:
https://irclog.perlgeek.de/perl6-dev/2017-06-07#i_14699799
In other words, if you fix this, please also fix the dead code issue in
“default {}”.
On 2017-06-07 09:35:49, alex.jakime...@gmail.com wrote:
> Code:
> say byte.Range
>
> Result:
> -Inf^..^Inf
>
“The only people I see complaining about it are those who just type it up
randomly to see what it'd do”
We had a bunch of segfaults and overflows that could only be caused by people
throwing random stuff into the compiler. And yes, very often we had to go
through this “wait, but normal people
Well,
say IntStr ~~ Str # True
In other words, IntStr *is* a Str.
What I find interesting, however, is this difference:
sub s (Str() :$str) {say $str.WHAT}; s(:str<1>) # IntStr
sub s (Str :$str) {say $str.Str.WHAT}; s(:str<1>) # Str
I would have expected the same output in both cases.
On
But we already have ..., !!! and ???. Isn't it what you want?
m: sub foo() { … }; foo
rakudo-moar 608e88: OUTPUT: «Stub code executed in sub foo at
line 1 in block at line 1Actually thrown at: in block
at line 1»
m: sub foo() { !!! }; foo
rakudo-moar 608e88: OUTPUT: «Stub code
Bisectable failed in the provided log, here is the right result:
AlexDaniel, Bisecting by output (old=2015.12 new=95b4e5d) because
on both starting points the exit code is 0
AlexDaniel, bisect log:
https://gist.github.com/1b6f1bdabefa1cb13338451abceea153
AlexDaniel, (2017-05-25)
301 - 400 of 405 matches
Mail list logo
