Re: [perl #126757] [LTA] error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)
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-follo...@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, sml...@gmail.com wrote: > > On Wed, 04 Oct 2017 22:10:22 -0700, alex.jakime...@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 allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #126757] [LTA] error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)
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-follo...@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, sml...@gmail.com wrote: > > On Wed, 04 Oct 2017 22:10:22 -0700, alex.jakime...@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 allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
[perl #126757] [LTA] error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)
“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, sml...@gmail.com wrote: > On Wed, 04 Oct 2017 22:10:22 -0700, alex.jakime...@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.
[perl #126757] [LTA] error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)
On Wed, 04 Oct 2017 22:10:22 -0700, alex.jakime...@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.
[perl #126757] [LTA] error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)
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.perl.org/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.jakime...@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-follo...@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". > > > > > >
[perl #126757] LTA error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)
# New Ticket Created by Alex Jakimenko # Please include the string: [perl #126757] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126757 > 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 at ./test3.pl:2 Actually thrown at: in block 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.
Re: [perl #126757] LTA error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)
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".
Re: [perl #126757] LTA error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)
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-follo...@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". > > >
