Skip Menu |
Report information
Id: 130434
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: cookbook_000 [at] yahoo.co.jp <titsuki [at] cpan.org>
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Date: Thu, 29 Dec 2016 12:39:06 +0900 (JST)
To: "rakudobug [...] perl.org" <rakudobug [...] perl.org>
From: cookbook_000 [...] yahoo.co.jp
Subject: [LTA] X::TypeCheck.gotn returns too short messages for displaying types in NativeCall
Download (untitled) / with headers
text/plain 734b
See the following results: $ perl6 -Ilib t/01-basic.t  Type check failed in binding; expected NativeCall::Types::CArray[num64] but got NativeCall::Types::CA...   in submethod BUILD at /home/itoyota/Programs/p6-Algorithm-LibSVM/lib/Algorithm/LibSVM/Parameter.pm6 (Algorithm::LibSVM::Parameter) line 28   in block <unit> at t/01-basic.t line 9 X::TypeCheck.gotn: https://github.com/rakudo/rakudo/blob/nom/src/core/Exception.pm#L1972-L1979 $ perl6 -e '"NativeCall::Types::CA".chars.say' 21 I think that that limitation of the number of characters (i.e. 21) is too short for displaying types in NativeCall. $ perl6 --version This is Rakudo version 2016.12-14-g9120ace built on MoarVM version 2016.12 implementing Perl 6.c.
Can you please include code that actually reproduces the problem?
Download (untitled) / with headers
text/plain 284b
On Tue, 17 Jan 2017 06:08:04 -0800, cpan@zoffix.com wrote: Show quoted text
> Can you please include code that actually reproduces the problem?
I'm very sorry. I can't remember exactly how to generate this error, I just remember is that I assigned a CArray[num64] object to a CArray[num64] variable.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 794b
On Tue, 17 Jan 2017 08:08:34 -0800, cookbook_000@yahoo.co.jp wrote: Show quoted text
> On Tue, 17 Jan 2017 06:08:04 -0800, cpan@zoffix.com wrote:
> > Can you please include code that actually reproduces the problem?
> > I'm very sorry. I can't remember exactly how to generate this error, I > just remember is that I assigned a CArray[num64] object to a > CArray[num64] variable.
Well, that's very unfortunate, as that means I have no way to reproduce the issue you're reporting. You point at a line of core code, but it's not causing any issues in all of the type check errors I've managed to reproduce (and people on IRC whom I asked this question twice managed to reproduce). I don't want to twiddle random length limits, when the correct solution is to not cut off any names when they're significant.
Download (untitled) / with headers
text/plain 128b
And it seems the reason this circumstance gets triggered is due to a bug: https://irclog.perlgeek.de/perl6/2017-01-21#i_13966550


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org