OK, so that's not an issue in Rakudo then. Closed.
On 2019-03-05 11:16:41, sortiz wrote:
> The problem is the PEM_write_bio_RSAPrivateKey signature used in the
> NativeCall declaration, it missed five arguments.
>
> From the manual:
>
> int PEM_write_bio_RSAPrivateKey(BIO *bp, RSA *x, const EVP_CI
Moved to https://github.com/rakudo/rakudo/issues/2725
On 2016-12-29 14:43:03, alex.jakime...@gmail.com wrote:
> Of course, same thing with “next” and “last” (is there anything else?)
>
> On 2016-12-29 09:13:24, alex.jakime...@gmail.com wrote:
> > Code:
> > say 42; redo
> >
> >
> > Result (2015.12,
Closing, explanation here: https://github.com/rakudo/rakudo/issues/2708
On 2017-05-12 07:52:34, c...@zoffix.com wrote:
> https://irclog.perlgeek.de/perl6-dev/2017-05-12#i_14572067
>
> 14:49 m: my @a = 1..12; for ('a' x 100 ~ " -- Jan-12-2017")
> xx 100 { when /'-- ' |@a '-' \d**2 '-' \d**4 / { } }
Ticket moved to https://github.com/rakudo/rakudo/issues/2697
On 2015-09-25 14:06:27, duff wrote:
> On Sat Jul 25 12:03:18 2015, moritz wrote:
> > This script here:
> >
> > # BEGIN SCRIPT
> > my grammar PgTokenizer {
> > token double_quote_normal { <-[\\"]>+ }
> > token double_quote_escape { [\\ .
Usually this happens when you have an unclosed string somewhere earlier in your
code.
That is:
say "foo; ← oops! Forgot the closing "
# $a ← we think that this is a comment, but actually it's part of the string
above!
On 2019-01-23 01:27:08, warren.mu...@gmail.com wrote:
> Hello:
>
> I ran into
I'm slightly confused by this ticket… isn't it resolved now? Nowadays you get
an error message like this:
Unable to parse expression in single quotes; couldn't find final "'"
(corresponding starter was at line 2)
So while it blows up at the end of the file, it still mentions where the quote
start
Further discussion on https://github.com/rakudo/rakudo/issues/1946
On 2017-05-28 21:20:08, c...@zoffix.com wrote:
> On Sun, 28 May 2017 18:18:14 -0700, raiph wrote:
> > If there hasn't been significant adoption of these tokens in extant
> > code then I'd personally +1 deprecation of them in v6.d i
Golf:
CONTROL {}; warn 42
On 2018-06-08 15:11:08, comdog wrote:
> While running this program I get a MoarVM panic:
>
> 2 + 2 = 4
> 'two' is not numeric
> MoarVM panic: Trying to unwind over wrong handler
>
> The program:
>
> sub add-two-things ( $first, $second ) {
> CATCH {
> when X::Str::Numeri
The issue with .unique was resolved in these commits
Rakudo:
https://github.com/rakudo/rakudo/commit/8cd70d1ee3e17fad78ae5daf0890d1cfb74c2deb
Roast:
https://github.com/perl6/roast/commit/ad38801161c518a3cf3bca9012db973851c4b0c3
Roast:
https://github.com/perl6/roast/commit/032ce8df8533da3c5ff85c227
https://github.com/rakudo/rakudo/pull/1722#issuecomment-380779444
On 2017-10-12 22:37:24, alex.jakime...@gmail.com wrote:
> Code:
> say "blogger".comb.Bag # if you want for all the letters
>
> ¦«2015.12»:
> bag(r, l, g(2), b, e, o)
>
> ¦«2016.06»:
> bag(r, l, g(2), b, e, o)
>
> ¦«2016.12»:
> bag(r
Tests were added in this PR: https://github.com/rakudo/rakudo/pull/1715
Closing
On 2017-12-02 04:17:46, alex.jakime...@gmail.com wrote:
> Not quite sure what to do with this ticket.
>
> The output varies across releases:
> https://gist.github.com/Whateverable/54e87afdbb2d88d2a959527b255681af
>
>
Test added in
https://github.com/perl6/roast/commit/1f171a9d2f0dd973a5e0d5c0c34a6f50b91da81f
Closing
On 2018-03-08 10:28:12, jan-olof.hen...@bredband.net wrote:
> On Fri, 27 Nov 2015 12:30:15 -0800, zengargo...@gmail.com wrote:
> > autarch noticed an oddness in File::Temp when used with .hyper:
>
jmerelo++, tests added in
https://github.com/perl6/roast/commit/ce173d4c6602333fac3dc8c1c8c2ec1b0b07c0ae
Closing
On 2015-10-19 07:43:11, larry wrote:
> On Mon Oct 19 07:02:44 2015, elizabeth wrote:
> > Fixed with a31cc91a0d604a8a74529 . Tests are still needed
> >
> > > On 19 Oct 2015, at 03:42, C
jmerelo++ brought this ticket to my attention during the squashathon and
suggested that this ticket can be closed.
I've tried reproducing the issue with the provided tarball and couldn't. In
fact, the Makefile in that tarball no longer works as expected because things
are very different now. Moreo
There's now a regression test in
https://github.com/perl6/roast/commit/a7af87465e0dc593f4e008d6dcfe077f1bbff0f1
Closing (but please take a look at that roast commit)
On 2018-03-11 13:11:21, jan-olof.hen...@bredband.net wrote:
> On Tue, 08 Aug 2017 04:19:24 -0700, elizabeth wrote:
> > reverted c63
A test for this issue was already added in
https://github.com/rakudo/rakudo/commit/f3efe5e6b4a9ee5#diff-2aaee6bee3c5525182362ffdcbea1f2cR14
Closing.
On 2018-03-10 16:40:40, jan-olof.hen...@bredband.net wrote:
> On Thu, 22 Jun 2017 05:25:08 -0700, c...@zoffix.com wrote:
> > A WhateverCode detached
Tests in
https://github.com/perl6/roast/commit/b320464868d3b8da98c090ddc4b0d57604683e13
Closing
On 2018-03-10 11:25:06, jan-olof.hen...@bredband.net wrote:
> On Wed, 22 Feb 2017 03:59:05 -0800, elizabeth wrote:
> > > On 22 Feb 2017, at 12:41, jn...@jnthn.net via RT > > follo...@perl.org> wrote:
Tests added in
https://github.com/perl6/roast/commit/d78f33966cf6a6ec6bc060d98dfc521ad59b6f75
Closing
On 2018-02-06 14:12:56, jan-olof.hen...@bredband.net wrote:
> On Sat, 07 May 2016 13:26:09 -0700, sml...@gmail.com wrote:
> > Confirmed on current Rakudo.
> >
> > Interestingly, it works if `for
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 module is
Tests in
https://github.com/perl6/roast/commit/1a42efd4ce0fdc695b16bbf64af92ecf0bca1866
On 2018-03-10 10:43:14, alex.jakime...@gmail.com wrote:
> This ticket now needs tests, further discussion related issues here:
> https://github.com/rakudo/rakudo/issues/1607
>
> On 2017-03-08 05:56:13, c...@zof
Segfault mentioned above is already tested and the test was unfudged in
https://github.com/perl6/roast/commit/ef7b0da83d#diff-72b101ff62a0582672d4de2788ffa1bbL77
Closing
On 2018-03-12 08:29:49, jan-olof.hen...@bredband.net wrote:
> On Mon, 16 Oct 2017 13:04:48 -0700, barto...@gmx.de wrote:
> > On
Tests in
https://github.com/perl6/roast/commit/79dff96fc9f383616dd192ef016725395323887b
and
https://github.com/perl6/roast/commit/82d3a883a52af23c8a67e46b88b313b3cf20b18d
On 2018-03-10 06:26:00, jan-olof.hen...@bredband.net wrote:
> On Wed, 04 Jan 2017 15:02:45 -0800, alex.jakime...@gmail.com wrot
Tests in
https://github.com/perl6/roast/commit/ce1a5a2e6b5b199c0df69a83cf66f1b830ee47e8
and
https://github.com/perl6/roast/commit/38c9dc5fd5339ed434438eb58bae07e7fdd31a1d
Closing.
On 2018-03-12 06:59:31, jan-olof.hen...@bredband.net wrote:
> On Wed, 13 Sep 2017 19:17:16 -0700, b...@abrij.org wrot
Some extra info:
Output on all releases (not a regression because the output was always wrong):
https://gist.github.com/b4b27b8088a230a6051d634dc7b2d13e
The change in behavior happened in (2017-03-21)
https://github.com/rakudo/rakudo/commit/16f950b30572e0fa584ddfab1e84e5ef0ca5dfc9
Which links to
FWIW bisectable points to (2017-06-25)
https://github.com/rakudo/rakudo/commit/a2133dbc6a00d1f87bb0644c829591144381d736
( before that it was giving bag(a, b) or bag(b, a) )
On 2018-03-24 01:43:59, elizabeth wrote:
> That does indeed look wrong to me, investigating
>
> > On 23 Mar 2018, at 15:04,
Closing this in favor of https://github.com/rakudo/rakudo/issues/1638
On 2015-10-17 06:27:53, r...@hoelz.ro wrote:
> As far as I can tell, MoarVM doesn't pass any information about a
> child process' PID to the caller of async proc operations; if it does,
> that information isn't exposed at the Pe
Closing this in favor of https://github.com/rakudo/rakudo/issues/1638
On 2017-10-02 00:09:23, alex.jakime...@gmail.com wrote:
> Oh, actually, I noticed it too a few months ago. And removed it.
>
https://github.com/rakudo/rakudo/commit/5b8d4c2f4232dc0e5e9c62dc602fdcb74f7bdd24#diff-
> 7e0467c62428b3
Further discussion on https://github.com/rakudo/rakudo/issues/1622.
On 2017-01-21 14:13:42, jn...@jnthn.net wrote:
> On Wed, 18 Jan 2017 18:16:20 -0800, c...@zoffix.com wrote:
> > the :sigspace adverb does not affect spaces inside character class.
> > Should it?
> >
> No, I don't think so. `<.ws>`
Pretty sure this is a dup of https://github.com/rakudo/rakudo/issues/1515 , you
can follow the progress on the issue there. Let us know if your problem is
actually different.
Closing
On 2018-02-25 11:11:55, mt1...@gmail.com wrote:
> Hi,
>
> According to the documentation one should use the follow
OK this issue is resolved with the commit mentioned above. Tests needed.
As for *int* native array having NaNs in it, that's not going to happen. It's
an array of native ints, it just can't and won't ever store any other type of a
value. A native int can't be NaN.
On 2016-01-02 06:34:50, lhermida
OK, first of all, a bot-friendly (whateverable-friendly specifically) version
of the first snippet is here:
say run(:out, , ‘await ^100 .map: -> $i { start { "".match(/ { print
$i } /) } }’).out.slurp-rest eq (^100).join
And that points to the better-sched merge as noted by dogbert++
The second
Interestingly, I can't reproduce it as well… But the numbers are still higher
than they were, so I guess the ticket is valid?
Here's the output on all releases:
https://gist.github.com/Whateverable/8687cceb1bfcf39e9818cef819d29391
I'd say we can close it once we go back to 50-ish.
On 2017-08-17
dogbert++ noticed me that this ticket exist. I totally forgot.
OK, that particular leak is gone I think, but there were other (newer) issues.
See https://github.com/rakudo/rakudo/issues/1280
Closing this ticket in favor of GH issue.
On 2017-08-14 14:37:54, alex.jakime...@gmail.com wrote:
> OK, t
I find the behavior surprising. Are there any examples of precedence thinkos
that are caught by this?
Added [RFC][@LARRY] tags, with just a little more information I think we'll be
able to close. Maybe.
On 2017-01-03 09:00:06, jn...@jnthn.net wrote:
> On Tue, 03 Jan 2017 04:54:52 -0800, elizabeth
Still reproducible:
6c: class Foo { method foo { say $!bad; } }
AlexDaniel, ¦6c (28 commits): «===SORRY!=== Error while
compiling /tmp/Qj1o8IL3bGAttribute $!bad not declared in class Fooat
/tmp/Qj1o8IL3bG:6--> ⏏ «exit code = 1»»
On 2017-01-21 16:47:53, agen...@gmail.com wrote:
> Hi
This ticket now needs tests, further discussion related issues here:
https://github.com/rakudo/rakudo/issues/1607
On 2017-03-08 05:56:13, c...@zoffix.com wrote:
> A temporary fix has been committed in
>
https://github.com/rakudo/rakudo/commit/5b7b7fb5c942a3e74097b5eb94a22be262f74c9f
FWIW it's not possible to reproduce the issue on older rakudos because it was
sweeped under the rug in the URI module itself:
https://github.com/perl6-community-modules/uri/issues/21
So yes, #126587 is a “testneeded” ticket for the underlying issue.
On 2018-03-09 12:58:27, jan-olof.hen...@bredban
Well, bisectable just told me that maybe I should mention at least one of the
suspected commits.
(2016-05-12)
https://github.com/rakudo/rakudo/commit/25113987502bba1cb48bd130b21982f6608e4aa3
Output before and after that commit:
https://gist.github.com/8e47787d7d7c7e6cf1ee7161740a999d
Basically,
dogbert++ noticed me that this issue is resolved (according to the provided
snippets). It is indeed so.
Second snippet may need this change:
-return 200, ['Content-Type' => 'text/plain'], 'we win';
+return 200, ['Content-Type' => 'text/plain'], ['we win'];
I can confirm that both issues are not
OK, there's now a follow-up ticket here:
https://github.com/rakudo/rakudo/issues/1598
On 2018-03-08 00:39:56, steve.myn...@gmail.com wrote:
> Maybe the ticket should be closed if/when the RT bug tracker is closed
> to new tickets itself and references to RT removed from all docs?
>
> S
>
> On 5 Ma
Further discussion on https://github.com/rakudo/rakudo/issues/1588
On 2017-10-18 03:46:20, c...@zoffix.com wrote:
> On Sat, 14 Oct 2017 08:29:50 -0700, c...@zoffix.com wrote:
> > Something fishy going on with the Signals enum. If that's fixed then
> > the
> > regression you pointed out will be fix
It seems like it is fixed properly now. See this discussion:
https://irclog.perlgeek.de/perl6-dev/2018-03-01#i_15872426
On 2017-10-22 08:28:20, c...@zoffix.com wrote:
> On Tue, 26 Sep 2017 11:03:11 -0700, c...@zoffix.com wrote:
> > On Thu, 22 Jun 2017 10:29:59 -0700, c...@zoffix.com wrote:
> > > I
On 2018-02-16 09:01:57, c...@zoffix.com wrote:
> On Fri, 16 Feb 2018 05:52:09 -0800, elizabeth wrote:
> > I propose we change all onlies in the core to multis after the release
> > and see how this breaks things / makes things slower.
>
> +1. Let's try.
Yeah, sounds good. +1
So I looked at this, and at very best the proposed error message is wrong. It
says that ? is useless when used with %%, but that's not the case:
m: say ‘af’|‘a’|‘f’|‘’ ~~ /a? %% f/
rakudo-moar 00af9ce27: OUTPUT: «「af」「a」「f」「」»
m: say ‘af’|‘a’|‘f’|‘’ ~~ /a?f?/
rakudo-moar 00af9ce27: OUTPUT:
Just to clarify, the last snippet now produces 0 0 0 0, which is indeed
correct.
There are tests for this change in general, but possibly not for that
particular case. Can we get it covered just in case?
「testneeded」
On 2018-02-06 05:51:23, jan-olof.hen...@bredband.net wrote:
> On Sun, 28 Aug 20
Actually, I've been trying to reproduce it on the said revision with --profile,
--ll-exception and whatnot, and I can't. I think this is an issue on OS X and
therefore should be confirmed (and tested) on OS X also.
On 2018-01-06 12:59:07, jan-olof.hen...@bredband.net wrote:
> On Fri, 28 Jul 2017 1
Honestly, I have no idea how to test this… maybe someone should attempt to golf
it, but given that the commit description is “JIT compile native calls”, I
guess it'd be a bit complicated.
… I'm fine with just delegating it to the DBIish test suite…
On 2017-10-20 08:12:41, alex.jakime...@gmail.com
FWIW, this bug is somewhat similar in feel:
https://github.com/rakudo/rakudo/issues/1202
On 2017-10-15 03:14:02, c...@zoffix.com wrote:
> On Wed, 02 Nov 2016 07:13:26 -0700, jn...@jnthn.net wrote:
> > On Sun Oct 02 12:52:45 2016, gfldex wrote:
> > > sub f(){
> > > my $c = Channel.new;
> > >
> > >
🍕 Test in
https://github.com/rakudo/rakudo/commit/4385e3fc0b5272a14c1c507ccf5846684c16453a
On 2017-08-28 13:58:57, alex.jakime...@gmail.com wrote:
> 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 contex
Tests here:
https://github.com/perl6/roast/commit/2dd5ee1b5935fce03eb815f8336ed26e019d4413
Resolved.
Further discussion on https://github.com/rakudo/rakudo/issues/1475
On 2017-12-02 14:39:07, alex.jakime...@gmail.com wrote:
> https://irclog.perlgeek.de/perl6/2017-12-02#i_15524141
>
> Marking as
Anyway, tests in
https://github.com/perl6/roast/commit/7557eef426fa4ea102d2d89b84c47dd5c1d3ab08
On 2018-02-03 14:40:09, alex.jakime...@gmail.com wrote:
> Ouch. It seems that one of my links is wrong, should've been this one
> I think:
> https://gist.github.com/Whateverable/cedc8ef783acc22e8f07afa9
Ouch. It seems that one of my links is wrong, should've been this one I think:
https://gist.github.com/Whateverable/cedc8ef783acc22e8f07afa98f5ad7d6
On 2017-12-02 19:41:52, alex.jakime...@gmail.com wrote:
> Not sure how it golfs down to that, because it never produced the same
> error
> message. I
Tests in
https://github.com/perl6/roast/commit/ceabda6337364b5f1cec3c1c5bcb89787f9bcedf
On 2018-01-08 15:18:46, alex.jakime...@gmail.com wrote:
> Note that the error message is still LTA (says “corresponding starter”
> instead
> of mentioning “’”), for further progress see RT#125641.
>
> On 2018-0
🍕 Tests in
https://github.com/perl6/roast/commit/3ca315596c3283c8cd168428065f01062c4633a5
On 2016-11-18 10:51:38, alex.jakime...@gmail.com wrote:
> On 2016-11-18 10:38:48, coke wrote:
> > On Sun, 18 Sep 2016 03:14:30 -0700, elizabeth wrote:
> > > Fixed by reverting 1a03efe4e3b61a07b7df5 in 363a3a8
Tests in
https://github.com/perl6/roast/commit/3dab7c774587fbf8ae2afb561b02b3177659ace3
On 2017-10-07 15:55:27, alex.jakime...@gmail.com wrote:
> This was resolved in these commits:
> *
>
https://github.com/rakudo/rakudo/commit/ac97a4016196c1fb5c39365dfbe8980574fb929b
> *
>
https://github.com/raku
Test added in
https://github.com/perl6/roast/commit/a7590d6543e1d29bc935377c727e4d15e38ee713
Note that the test *does create* files with weird names, but that's totally OK
in /tmp I think.
On 2017-03-02 07:06:54, c...@zoffix.com wrote:
> Explanation and ideas on IRC: https://irclog.perlgeek.de/mo
Test in
https://github.com/perl6/roast/commit/195227f779f7441de1678e12941550271da799b2
On 2017-07-09 19:40:57, alex.jakime...@gmail.com wrote:
> 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
> reo
Does not seem to be fixed at all. But I've added some todo-ed tests:
https://github.com/perl6/roast/commit/f9f5034a1e66e068bfe21227e35f100f3c1e3fef
On 2017-10-07 13:43:30, alex.jakime...@gmail.com wrote:
> Should be fixed in https://github.com/rakudo/rakudo/commit/5747bc7121
>
> Testneeded. Slight
This was fixed, for more info see this still-open issue:
https://github.com/rakudo/rakudo/issues/1420
On 2018-01-19 07:36:32, steve.myn...@gmail.com wrote:
> Both builds are broken see #132741 but I believe the change to make
> these builds dependent on gmake isn't neccessary.
>
> None of the Make
This was fixed, for more info see this still-open issue:
https://github.com/rakudo/rakudo/issues/1420
On 2018-01-19 07:30:48, steve.myn...@gmail.com wrote:
> MoarVM build broken on FreeBSD 11 and OpenBSD 6.2
>
> ..
>
> Configuring and building MoarVM ...
> /usr/local/bin/perl5 Configure.pl --optim
Yes, it would be awesome to have warnings for unused params and variables.
On 2018-01-14 12:16:08, c...@zoffix.com wrote:
> On Sat, 14 Oct 2017 20:53:03 -0700, alex.jakime...@gmail.com wrote:
> > FWIW I made a throwaway script that looks for unused params, and
> > there
> > are many
> > of these
FWIW it was “working” before this commit:
https://github.com/rakudo/rakudo/commit/ec18f24d27ce61fa71d177ab76c4044ee1d1a75e
But that's probably irrelevant because I'm pretty sure it was cheating with
something.
On 2018-01-13 13:56:54, elizabeth wrote:
>
> > On 13 Jan 2018, at 22:38, Curt Tilmes (vi
FWIW it was “working” before this commit:
https://github.com/rakudo/rakudo/commit/ec18f24d27ce61fa71d177ab76c4044ee1d1a75e
But that's probably irrelevant because I'm pretty sure it was cheating with
something.
On 2018-01-13 13:56:54, elizabeth wrote:
>
> > On 13 Jan 2018, at 22:38, Curt Tilmes (vi
Note that the error message is still LTA (says “corresponding starter” instead
of mentioning “’”), for further progress see RT#125641.
On 2018-01-08 15:16:47, alex.jakime...@gmail.com wrote:
> Ah. This was fixed. Here's the pull request:
> https://github.com/rakudo/rakudo/pull/1183
> And here's th
Ah. This was fixed. Here's the pull request:
https://github.com/rakudo/rakudo/pull/1183
And here's the right commit:
https://github.com/rakudo/rakudo/pull/1183/commits/6542bb8032e7203b8736655075dbd3452856bc93
There should be tests for this already, I think.
On 2016-12-04 10:22:37, alex.jakime...@
Closable with rakudo tests then.
On 2018-01-06 12:59:07, jan-olof.hen...@bredband.net wrote:
> On Fri, 28 Jul 2017 15:52:53 -0700, timo wrote:
> > It could be that the commit i just pushed to moarvm fixes this,
> > please
> > verify (the code doesn't crash with the patch)
>
> Seems to work properl
Ah. Now I see why.
Consider this:
#`| foo |
↑ that does not DWIM. And it's right to assume that you can do it because s|||
works just fine. So either it should understand stuff like this, or it can give
an error message as todo-ed.
So no, this is not rejectable. And the actual issue is about no
FWIW this issue was noticed today:
https://irclog.perlgeek.de/perl6/2017-12-16#i_15587006
On 2016-04-11 20:40:43, ddgr...@gmail.com wrote:
> '@array[0, 3, 7]' is much slower than '(@array[0], @array[3], @array[7])'
>
>
> time perl6 -e 'my @a = ^500;my @f;my $s = @a.elems;loop (my $i1 = 0; $i1 <
>
I am pretty sure that this commit is relevant to this issue:
https://github.com/rakudo/rakudo/commit/fc52143beee3178c7f39d770f95c7d60b2a1a1e4
On 2017-10-07 17:20:37, alex.jakime...@gmail.com wrote:
> Zoffix++ pointed out that there is a problem with IntStr also:
>
> Code:
> enum Foo (:Bar(1), :Baz
Oh, by the way. The issue goes much farther than 2015.12, so the underlying
issue is not a regression.
On 2017-12-13 23:42:11, alex.jakime...@gmail.com wrote:
> We can, but I'd much rather have this particular case tested (and to
> make sure
> that it is, we'll close it with tests once the issue i
We can, but I'd much rather have this particular case tested (and to make sure
that it is, we'll close it with tests once the issue is resolved).
For example, here's this interesting bit:
https://github.com/rakudo/rakudo/blob/master/src/core/core_prologue.pm#L2 :
my class Pair { ... } # must be f
By the way, there is a pull request: https://github.com/rakudo/rakudo/pull/1020
But the work on it is kinda stalled.
On 2017-02-17 04:22:51, alex.jakime...@gmail.com wrote:
> Reopened for now.
>
> See RT #121807 and RT #125371 for more info. Basically, there will be
> no error
> after I'm done wi
Closing this ticket in favor of this one:
https://github.com/rakudo/rakudo/issues/1304
On 2017-12-01 11:03:43, alex.jakime...@gmail.com wrote:
> Still failing (2017.11, HEAD(5929887))
>
> On 2014-07-31 13:05:19, david.warring wrote:
> > I've added some fudged tests to S03-operators/relational.t. A
Fixed in
https://github.com/rakudo/rakudo/commit/2cd266fe08aa386b180dda14c15659c360623c99
Tests in
https://github.com/perl6/roast/commit/3ae26405385d5e496b401326e3252294b8a5785b
and
https://github.com/perl6/roast/commit/bc48eed6849cbbb873320052cb78a6e57b9c4a2a
tbrowder++
On 2015-11-26 11:33:47,
FWIW it never worked:
https://gist.github.com/Whateverable/d9dbebb0e985a3964845df2c8652cbdf
On 2017-11-27 17:36:22, comdog wrote:
> I previously asked about this unexpected Z behavior on Stackoverflow
> ( https://stackoverflow.com/q/45001820/2766176 ).
>
> I expected this to change several hash ke
Some *able info, if anyone is interested:
Output on all releases:
https://gist.github.com/a68b094519839b939f8c70d66a80d8c0
Some possibly relevant commits:
https://github.com/rakudo/rakudo/commit/92bd7e4f54a92fa660f99b4d056d33a08fb98bd2
https://github.com/rakudo/rakudo/commit/6dae179a8418bd2fcf5cc
So is the current behavior good or bad?
On 2014-10-15 05:16:27, barto...@gmx.de wrote:
> The current behaviour is:
>
> $ perl6-m -e 'my %h{Any}; %h=Any; %h //= "a"; say %h.perl'
> Hash[Any,Any].new("a" => "a")
>
> $ perl6-m -e 'my %h{Any}; %h //= "a"; say %h.perl'
> Hash[Any,Any].new("a" => "a")
>
Still NYI (2017.11,HEAD(e5b660e))
On 2014-10-14 01:02:45, masak wrote:
> m: grammar Test { token TOP { }; proto token
> Foo(Int) {*}; token Foo:sym(Int $a) { "a" }; token Foo:sym(Int
> $a) { "b" } }; say Test.parse("a");
> rakudo-moar 8b3e8c: OUTPUT«Too few positionals passed;
> expected 2 argu
Seems to be reproducible (2017.11,HEAD(e5b660e))
On 2014-10-16 13:43:34, masak wrote:
> camelia was having some indigestion in the below backlog, which is why
> I'm reporting some local evals (from "This is perl6 version
> 2014.09-202-g8b3e8c2 built on MoarVM version 2014.09-54-g03ac9a7").
>
> m:
Still reproducible (2017.11,HEAD(e5b660e))
On 2015-05-15 11:25:07, jdv79 wrote:
> The first example there should have been:
>
> [jdv@wieldy ~]$ perl6 -e 'role Foo[::T] { has Int @.a }; say
> Foo[Int].new.a.WHAT'
> (Array[Int])
> [jdv@wieldy ~]$ perl6 -e 'role Foo[::T] { has T @.a }; say
> Foo[Int]
Related doc ticket (with some discussion):
https://github.com/perl6/doc/issues/1695
On 2010-07-27 02:32:49, moritz wrote:
> alpha supported :dba('rule name'), current Rakudo doesn't, but should.
Still reproducible (2017.11,HEAD(e5b660e))
On 2015-09-09 22:28:41, larry wrote:
> 22:22 < TimToady> m: my Bool %hash{*;*}; %hash{"a"; "b"} = True;
> 22:22 <+camelia> rakudo-moar c54773: OUTPUT«Type check failed in assignment
> to '%hash'; expected 'Bool' but got 'Hash' in block
> at /tmp/NWldXMt
Still reproducible (2017.11,HEAD(e5b660e))
On 2015-09-20 09:07:10, zef...@fysh.org wrote:
> Because a type object is an (undefined) instance of that type, it can
> in general be stored in a variable constrained to that type. We can
> demonstrate this with a subroutine taking a type parameter:
>
>
As of today (2017.11,HEAD(e5b660e)) it gives this:
===SORRY!=== Error while compiling -e
Variable '$' is not declared
at -e:1
--> say defined ⏏$::
There was another ticket that had exactly the same change of an error message,
perhaps worth searching for it (ping me if you really want to find
As of today (2017.11,HEAD(e5b660e)) it prints this:
Cannot call method 'new' on a null object
in block at -e line 1
Which is arguably reasonable, but I guess it's not good enough.
On 2014-09-24 04:03:12, masak wrote:
> m: BEGIN GLOBAL:: = class { }; Test.new;
> rakudo-moar 682e03: OUTPUT«===S
Still reproducible (2017.11,HEAD(e5b660e)) (complains about
trait_mod:)
On 2014-10-16 13:07:07, masak wrote:
> m: class A { my @.foo handles }; A.push("OH", "HAI");
> say A.foo
> rakudo-moar a6f181: OUTPUT«(timeout)»
> locally: "Cannot call 'trait_mod:'; none of these
> signatures match" (Attr
All of these were fixed (2017.11,HEAD(e5b660e)).
Strings give compile-time errors, putting Any into something results in an Int.
Curious minds can ask bisectable for details.
「testneeded」
On 2015-09-20 17:26:00, zef...@fysh.org wrote:
> Extended case: if the "of" clause comes after an "is defaul
Still reproducible (2017.11,HEAD(e5b660e))
I don't know if it's NYI or @LARRY. I'd put LARRY first, and then one of the
LARRYs can turn it into a NYI.
On 2015-08-05 15:25:57, barto...@gmx.de wrote:
> The relevant sentences from the design docs (S06, introduced with
> commit 7846594ee4):
>
> "Sinc
Output on all releases:
https://gist.github.com/Whateverable/297882f4f84bb8362a0ce0523439c436
On 2013-02-16 09:14:04, masak wrote:
> r: https://gist.github.com/TimToady/4963642
> jnthn: that gets me an error Nominal type check failed for
> parameter '$payload'; expected T but got Int instead
>
This wasn't updated in a while. As of today (2017.11,HEAD(e5b660e)), it still
complains about final ) like mentioned in one of the recent comments. And yes,
this tickets seems to be rejectable.
On 2015-07-20 09:27:25, duff wrote:
> I'm not sure this is a bug. The postfix for is a statement modifie
Still reproducible (2017.11,HEAD(e5b660e))
On 2015-03-06 14:35:06, rayd...@cyberuniverses.com wrote:
> As seen at http://irclog.perlgeek.de/perl6/2015-03-06#i_10237611 :
>
> r: role R { method foo () handles { } }
> rakudo-moar 1b74e4: OUTPUT«===SORRY!=== Error while compiling
> /tmp/tmpfileMeth
Still reproducible (2017.11,HEAD(e5b660e))
On 2015-06-26 02:25:27, elizabeth wrote:
> [10:57:16] m: use nqp; my %h; %h := nqp::null()
> #h
> [10:57:16] <+camelia> rakudo-moar 3d645f: OUTPUT«Unexpected named
> parameter 'BIND' passed in block at /tmp/GYnIiEF0VO:1»
>
> This looks strange to
Still reproducible (2017.11,HEAD(e5b660e))
On 2013-10-28 02:49:38, masak wrote:
> p: class A { has $!x = 42; method get() { ::('$!x') } }; say
> A.new.get
> rakudo-parrot 3cef56: OUTPUT«No such symbol '$!x' [...]
> should that work?
> moritz: my first thought is "I don't see why it shouldn't".
Still reproducible (2017.11,HEAD(e5b660e)), almost identical error message.
On 2014-02-04 08:01:17, masak wrote:
> m: my $x; 'abc' ~~ /$x=(ab)/; say $x
> rakudo-moar 44ab3c: OUTPUT«===SORRY!===Error while
> compiling op bind: QAST::Block with cuid cuid_1_1391529188.76986 has
> not appeared»
>
Still reproducible (2017.11,HEAD(e5b660e))
On 2013-03-30 16:55:04, masak wrote:
> r: class A { has ::B $.b }; class B {}; print B.new; print
> A.new.b.new
> rakudo ba5e04: OUTPUT«B<-905822265>No such method 'new' for
> invocant of type 'B' in block at /tmp/TluLYMLqwz:1»
> masak: ^^ hmm
> th
This is very old and nobody was complaining about this issue since then. I
guess the problem is no longer there, but we won't be able to track it.
Therefore, rejected (but I'm hoping that the underlying issue was actually
resolved).
On 2014-12-26 23:16:35, ga...@szabgab.com wrote:
> During the "ma
Still reproducible (2017.11,HEAD(e5b660e))
On 2015-04-01 13:19:33, masak wrote:
> <[Tux]> m: class C { has Int $!x; method foo { ($!x, my $b) =
> (1,2);}};C.foo
> 19:45 <+camelia> rakudo-moar 6caf1d: OUTPUT«Cannot look up attributes
> in a type object in method foo [...]
> <[Tux]> is that explain
Alright.
On 2017-12-03 00:53:04, elizabeth wrote:
> Those are predecessors of the “react / whenever” syntax. I think that
> therefore this ticket can be closed now.
>
> > On 3 Dec 2017, at 04:58, Aleks-Daniel Jakimenko-Aleksejev via RT
> > wrote:
> >
> > wha
This ticket is replaced with https://github.com/rakudo/rakudo/issues/1296
Hmmm… Parrot is in the past as of today, and I wish it was possible to try this
on MoarVM. What's the way to reproduce this issue?
On 2014-07-14 02:31:54, teodozjan wrote:
> Evaling objects won't work if code that eval was preompiled
> independently. In this case class Planet and Class SpaceStatio
1 - 100 of 434 matches
Mail list logo