Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X::TypeCheck.gotn returns too short messages for displaying types in NativeCall #5931

Open
p6rt opened this issue Dec 29, 2016 · 6 comments
Open
Labels
LTA

Comments

@p6rt
Copy link

@p6rt p6rt commented Dec 29, 2016

Migrated from rt.perl.org#130434 (status was 'open')

Searchable as RT130434$

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Dec 29, 2016

From @titsuki

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.

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 17, 2017

From @zoffixznet

Can you please include code that actually reproduces the problem?

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 17, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 17, 2017

From @titsuki

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.

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 17, 2017

From @zoffixznet

On Tue, 17 Jan 2017 08​:08​:34 -0800, cookbook_000@​yahoo.co.jp wrote​:

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.

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Jan 21, 2017

From @zoffixznet

And it seems the reason this circumstance gets triggered is due to a bug​: https://irclog.perlgeek.de/perl6/2017-01-21#i_13966550

@p6rt p6rt added the LTA label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.