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
Thanks for finding that. Can we close this duplicate bug? Issue #128287 has
stronger steps to reproduce, and using that test case, I found this bug
goes back to at least 2015.12.
On Wed, Dec 13, 2017 at 11:56 PM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:
> On Wed, 06 Dec 2017 01:59
Thanks for finding that. Can we close this duplicate bug? Issue #128287 has
stronger steps to reproduce, and using that test case, I found this bug
goes back to at least 2015.12.
On Wed, Dec 13, 2017 at 11:56 PM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:
> On Wed, 06 Dec 2017 01:59
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
On Wed, 13 Dec 2017 19:23:38 -0800, c...@zoffix.com wrote:
> Also affects some methods:
>
> m: my %h; say %h.AT-KEY: 1|2
> rakudo-moar eaf609edb: OUTPUT: «Type check failed in binding
> to parameter '&call'; expected Callable but got Method+{is-nodal}
> (Method+{is-nodal}.new) in block at li
On Wed, 13 Dec 2017 19:23:38 -0800, c...@zoffix.com wrote:
> Also affects some methods:
>
> m: my %h; say %h.AT-KEY: 1|2
> rakudo-moar eaf609edb: OUTPUT: «Type check failed in binding
> to parameter '&call'; expected Callable but got Method+{is-nodal}
> (Method+{is-nodal}.new) in block at li
On Tue, 14 Jul 2015 22:32:47 -0700, elizabeth wrote:
>
> > On 14 Jul 2015, at 12:29, Carl Mäsak (via RT) > follo...@perl.org> wrote:
> >
> > # New Ticket Created by "Carl Mäsak"
> > # Please include the string: [perl #125614]
> > # in the subject line of all future correspondence about this iss
On Tue, 14 Jul 2015 22:32:47 -0700, elizabeth wrote:
>
> > On 14 Jul 2015, at 12:29, Carl Mäsak (via RT) > follo...@perl.org> wrote:
> >
> > # New Ticket Created by "Carl Mäsak"
> > # Please include the string: [perl #125614]
> > # in the subject line of all future correspondence about this iss
On Mon, 13 Nov 2017 07:31:44 -0800, alex.jakime...@gmail.com wrote:
> Unfortunately there's no easy way to know how many elements are there. If I
> recall correctly, stringy ranges may loop forever due to normalization and
> other things.
Can't think of anything reasonable either, especially since
On Mon, 01 Jun 2015 05:41:01 -0700, drf...@pobox.com wrote:
> I'm not even sure if the error text is correct, come to think of it. I'd
> think that a leading '=' outside of a here-doc or multi-line string
> regardless of q/qq/Q<[[ variant should be treated as a POD comment, so I
> would expect t
On Mon, 01 Jun 2015 05:41:01 -0700, drf...@pobox.com wrote:
> I'm not even sure if the error text is correct, come to think of it. I'd
> think that a leading '=' outside of a here-doc or multi-line string
> regardless of q/qq/Q<[[ variant should be treated as a POD comment, so I
> would expect t
On Sat, 30 Sep 2017 12:45:09 -0700, sjn-perl...@pvv.org wrote:
> I think this bug can be closed.
Agreed. Rejecting.
I see little reason to muddy up the Usage even more with type information,
where you're mostly limited to Int/Str types anyway, and variable name
helps know which to use.
The type
On Sat, 30 Sep 2017 12:45:09 -0700, sjn-perl...@pvv.org wrote:
> I think this bug can be closed.
Agreed. Rejecting.
I see little reason to muddy up the Usage even more with type information,
where you're mostly limited to Int/Str types anyway, and variable name
helps know which to use.
The type
On Sat, 02 Dec 2017 20:41:05 -0800, alex.jakime...@gmail.com wrote:
> Isn't it implemented as :update now?
> https://docs.perl6.org/routine/open
Yes, :update is it. Tests:
https://github.com/perl6/roast/blob/master/S32-io/open.t#L68-L92
>
> Or maybe you can even use :mode? (the documentation sa
On Sat, 02 Dec 2017 20:41:05 -0800, alex.jakime...@gmail.com wrote:
> Isn't it implemented as :update now?
> https://docs.perl6.org/routine/open
Yes, :update is it. Tests:
https://github.com/perl6/roast/blob/master/S32-io/open.t#L68-L92
>
> Or maybe you can even use :mode? (the documentation sa
On Sat, 09 Dec 2017 15:26:25 -0800, c...@zoffix.com wrote:
> On Sat, 09 Dec 2017 13:19:23 -0800, elizabeth wrote:
> > If that shouldn’t work, or work differently, it can be ripped
> > out / replaced. If that should work, then we need to look at fixing
> > -put-.
>
> IMO it should work, considerin
On Sat, 09 Dec 2017 15:26:25 -0800, c...@zoffix.com wrote:
> On Sat, 09 Dec 2017 13:19:23 -0800, elizabeth wrote:
> > If that shouldn’t work, or work differently, it can be ripped
> > out / replaced. If that should work, then we need to look at fixing
> > -put-.
>
> IMO it should work, considerin
I just tried doing this:
> map *(1), *+1, *+2, *+3
But I get an error: "No such method 'CALL-ME' for invocant of type
'Whatever'". Fair enough.
This works:
> map { $_(1) }, *+1, *+2, *+3
(2 3 4)
Is there any alternative way to call a function through a whatever-star, as
in my first example?
Just for the records: As far as I can tell, the bug that caused the above
failures was an "off by one" in the multi cache implementation. It was fixed
with https://github.com/perl6/nqp/commit/7eaebf5abd
On Wed, 06 Dec 2017 01:59:42 -0800, d...@zwell.net wrote:
> A git bisect showed that this error began in commit
> 22b4ef05b1f72b50d63e4599d5e037bccf1f08ed, but there must be have been
> an
> underlying problem that was already present, since this commit did not
> change the type system.
>
> On Fri
On Wed, 06 Dec 2017 01:59:42 -0800, d...@zwell.net wrote:
> A git bisect showed that this error began in commit
> 22b4ef05b1f72b50d63e4599d5e037bccf1f08ed, but there must be have been
> an
> underlying problem that was already present, since this commit did not
> change the type system.
>
> On Fri
22 matches
Mail list logo
