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

error message talks about ~ but there is no ~ in my code (33..126 .pick.chr) #4795

Open
p6rt opened this issue Nov 28, 2015 · 8 comments
Open
Labels
LTA Less Than Awesome; typically an error message that could be better

Comments

@p6rt
Copy link

p6rt commented Nov 28, 2015

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

Searchable as RT126757$

@p6rt
Copy link
Author

p6rt commented Nov 28, 2015

From @AlexDaniel

Code​:
say (33..126 .pick.chr);

Result​:
Cannot convert string to number​: base-10 number must begin with valid
digits or '.' in '⏏~' (indicated by ⏏)
  in block <unit> at ./test3.pl​:2

Actually thrown at​:
  in block <unit> at ./test3.pl​:2

The solution is to put parens​:
say ((33..126).pick.chr);

But the error message is not even close to helping with that. The biggest
problem is that it does not show where the error is, instead it talks about
“~” which is probably used somewhere internally.

@p6rt
Copy link
Author

p6rt commented Nov 28, 2015

From @timo

This error occurs because 126.pick gives 126, 126.chr is "". Then the
.. operator tries to numify its RHS, which is "
". That goes wrong, of
course.

So this is just a precedence problem with ranges.

Do you have a better suggestion for the error message here? Otherwise
i'd close this as "NOTABUG".

@p6rt
Copy link
Author

p6rt commented Nov 28, 2015

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

@p6rt
Copy link
Author

p6rt commented Nov 28, 2015

From @AlexDaniel

Thanks! Indeed! I should have tried understanding the issue and golfing it
down myself.

So the snippet can be golfed down to​:
say +126.chr

The bug is still there, please don't close. In fact, the title is very
precise.

“126.chr” is still “126.chr”. It is less than awesome to whine about some
symbol that is not written in my code explicitly.

Awesome error message should go like this​:
Cannot convert string '~' to number​: base-10 number must begin with valid
digits or '.' in 'say +126.chr⏏' (indicated by ⏏)

On Sat, Nov 28, 2015 at 7​:29 PM, Timo Paulssen via RT <
perl6-bugs-followup@​perl.org> wrote​:

This error occurs because 126.pick gives 126, 126.chr is "". Then the
.. operator tries to numify its RHS, which is "
". That goes wrong, of
course.

So this is just a precedence problem with ranges.

Do you have a better suggestion for the error message here? Otherwise
i'd close this as "NOTABUG".

@p6rt
Copy link
Author

p6rt commented Oct 5, 2017

From @AlexDaniel

As far as I know, this ticket is impossible to resolve. At least not with what we have now in rakudo.

To produce an error message that is more precise we'll need more information than just a line number, but we don't have that during the run time.

See https://rt-archive.perl.org/perl6/Ticket/Display.html?id=128402

Maybe once RT #​128402 is resolved there will be something we could use for that ticket…

On 2015-11-28 11​:25​:00, alex.jakimenko@​gmail.com wrote​:

Thanks! Indeed! I should have tried understanding the issue and golfing it
down myself.

So the snippet can be golfed down to​:
say +126.chr

The bug is still there, please don't close. In fact, the title is very
precise.

“126.chr” is still “126.chr”. It is less than awesome to whine about some
symbol that is not written in my code explicitly.

Awesome error message should go like this​:
Cannot convert string '~' to number​: base-10 number must begin with valid
digits or '.' in 'say +126.chr⏏' (indicated by ⏏)

On Sat, Nov 28, 2015 at 7​:29 PM, Timo Paulssen via RT <
perl6-bugs-followup@​perl.org> wrote​:

This error occurs because 126.pick gives 126, 126.chr is "". Then the
.. operator tries to numify its RHS, which is "
". That goes wrong, of
course.

So this is just a precedence problem with ranges.

Do you have a better suggestion for the error message here? Otherwise
i'd close this as "NOTABUG".

@p6rt
Copy link
Author

p6rt commented Oct 6, 2017

From @smls

On Wed, 04 Oct 2017 22​:10​:22 -0700, alex.jakimenko@​gmail.com wrote​:

To produce an error message that is more precise we'll need more
information
than just a line number, but we don't have that during the run time.

Couldn't the confusing wording be fixed without additional information?

As I understand it, the problem with the current message is that the

  in '⏏~' (indicated by ⏏)

part leads people to think it's referring to a position in the source code, when it is actually referring to a position in a string. Especially because the "in block ... in file ... at line ..." line comes directly after it.

@p6rt
Copy link
Author

p6rt commented Oct 7, 2017

From @AlexDaniel

“Couldn't the confusing wording be fixed without additional information?”

Yes. But how? We can't *remove* this hint because sometimes it is super useful.

On 2017-10-06 11​:13​:34, smls75@​gmail.com wrote​:

On Wed, 04 Oct 2017 22​:10​:22 -0700, alex.jakimenko@​gmail.com wrote​:

To produce an error message that is more precise we'll need more
information
than just a line number, but we don't have that during the run time.

Couldn't the confusing wording be fixed without additional
information?

As I understand it, the problem with the current message is that the

in '⏏~' (indicated by ⏏)

part leads people to think it's referring to a position in the source
code, when it is actually referring to a position in a string.
Especially because the "in block ... in file ... at line ..." line
comes directly after it.

@p6rt
Copy link
Author

p6rt commented Oct 7, 2017

From @geekosaur

Is it possible to signal to the error handler that it is talking about a
value somewhere instead of the program source, at least? Even if you can't
reasonably say what value where?

On Sat, Oct 7, 2017 at 5​:18 PM, Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-followup@​perl.org> wrote​:

“Couldn't the confusing wording be fixed without additional information?”

Yes. But how? We can't *remove* this hint because sometimes it is super
useful.

On 2017-10-06 11​:13​:34, smls75@​gmail.com wrote​:

On Wed, 04 Oct 2017 22​:10​:22 -0700, alex.jakimenko@​gmail.com wrote​:

To produce an error message that is more precise we'll need more
information
than just a line number, but we don't have that during the run time.

Couldn't the confusing wording be fixed without additional
information?

As I understand it, the problem with the current message is that the

in '⏏~' (indicated by ⏏)

part leads people to think it's referring to a position in the source
code, when it is actually referring to a position in a string.
Especially because the "in block ... in file ... at line ..." line
comes directly after it.

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

@p6rt p6rt added the LTA Less Than Awesome; typically an error message that could be better label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better
Projects
None yet
Development

No branches or pull requests

1 participant