Mailing List Archive

I love both of these suggestions. Let me put on my Perl novice hat and
respond directly:

1.

One of my favorite things about |git| is that when something is
wrong with your working state, or you issue an incorrect command,
|git| tells you not only that there is an error, but also what the
most likely fix is. This has saved me numerous times from having to
stop what I’m doing and Google the specific error. Simple one line
errors suggestions like that can save a lot of time and frustrations.

2.

It would be great if the strings were Globally unique so theywere
easily searchable in Google. I know we’re all old Perlprogrammers
and are really comfortable with |perldoc| but the novice Perl
programmer is going to hit Google first. If the codes were something
like |Perl-Q1793| or |Perl_W18| then a Google search will always
turn up the right documentation.

I imagine there will be a lot of work to implement this, as we'd have to
go back through all the common warnings/errors. We could do them slowly
over time, we're not forced to do them all en masse in one release.

?
On 1/25/2022 1:04 PM, Felipe Gasper wrote:
> PART 1:
>
> -----
>> perl -e'print "\x{100}"'
> Wide character in print at -e line 1.
> ?
> -----
>
> ^^ Would it benefit if that warning instead were something like:
>
> -----
> Wide character in print (you forgot to encode) at -e line 1.
> -----
>
> The status quo merely describes the problem; I’d like to add a bit that points to the fix.
>
> --------------------------------------------
>
> PART 2:
>
> While I’m raising the issue, what would it take for Perl-issued warnings (and exceptions?) writ-large to include some sort of searchable, indexed lookup code, something like:
>
> -----
> W.18: Wide character in print (you forgot to encode) at -e line 1.
> -----
>
> Then users could search on that code in Perl’s documentation, maybe like:
>
> -----
> perldoc W.18
> -----
>
> Thoughts?
>
> -FG

On Wed, 26 Jan 2022 at 07:54, Scott Baker <scott@perturb.org> wrote:

> I love both of these suggestions. Let me put on my Perl novice hat and
> respond directly:
>
> 1.
>
> One of my favorite things about git is that when something is wrong
> with your working state, or you issue an incorrect command, git tells
> you not only that there is an error, but also what the most likely fix is.
> This has saved me numerous times from having to stop what I’m doing and
> Google the specific error. Simple one line errors suggestions like that can
> save a lot of time and frustrations.
>
> indeed - and there's precedent for this in the `(you may need to install
the XYZ module)` error shown when trying to use/require a module that isn't
found.

RFC seems unnecessary for this - might as well go straight for the Github
pull request? As long as the extra text goes at the end of the warning, the
change does not seem overly controversial!

2022-1-26 6:04 Felipe Gasper <felipe@felipegasper.com> wrote:

> PART 1:
>
> -----
> > perl -e'print "\x{100}"'
> Wide character in print at -e line 1.
> ?
> -----
>
> ^^ Would it benefit if that warning instead were something like:
>
> -----
> Wide character in print (you forgot to encode) at -e line 1.
> -----
>
> The status quo merely describes the problem; I’d like to add a bit that
> points to the fix.
>
> --------------------------------------------
>
> PART 2:
>
> While I’m raising the issue, what would it take for Perl-issued warnings
> (and exceptions?) writ-large to include some sort of searchable, indexed
> lookup code, something like:
>
> -----
> W.18: Wide character in print (you forgot to encode) at -e line 1.
> -----
>
> Then users could search on that code in Perl’s documentation, maybe like:
>
> -----
> perldoc W.18
> -----
>
> Thoughts?
>
> -FG
>

I think this is a good idea because users don't know the meaning of "Wide
Character" .

On Tue, Jan 25, 2022 at 7:57 PM Tom Molesworth via perl5-porters <
perl5-porters@perl.org> wrote:

> On Wed, 26 Jan 2022 at 07:54, Scott Baker <scott@perturb.org> wrote:
>
>> I love both of these suggestions. Let me put on my Perl novice hat and
>> respond directly:
>>
>> 1.
>>
>> One of my favorite things about git is that when something is wrong
>> with your working state, or you issue an incorrect command, git tells
>> you not only that there is an error, but also what the most likely fix is.
>> This has saved me numerous times from having to stop what I’m doing and
>> Google the specific error. Simple one line errors suggestions like that can
>> save a lot of time and frustrations.
>>
>> indeed - and there's precedent for this in the `(you may need to install
> the XYZ module)` error shown when trying to use/require a module that isn't
> found.
>
> RFC seems unnecessary for this - might as well go straight for the Github
> pull request? As long as the extra text goes at the end of the warning, the
> change does not seem overly controversial!
>

I would like to give the wording a few passes, and the interesting bit will
be how it updates the perldiag entries, but agreed that this seems a good
idea and does not need an RFC.

-Dan

Hi Felipe,

We discussed part 1 – improving the wording of the wide character messages – and agreed that we’d like to see this, and also that it doesn’t need to go via an RFC.

So we encourage you to propose some wording on p5p, and then submit a PR.

We’ve marked your Pre-RFC as "N/A" in the tracker. You could start a separate Pre-RFC thread if you want to raise the idea of codes for warnings and error messages.

Neil

We’ve marked your Pre-RFC as "N/A" in the tracker. You could start a
> separate Pre-RFC thread if you want to raise the idea of codes for warnings
> and error messages.
>
>
Hi Neil,

pointing out earlier discussion in this list related errors and warnings
"RFC - core exception catalogue"
(though to be honest I just gave up on that)

Best regards,
Brano

On Tue, Jan 25, 2022 at 5:04 PM Felipe Gasper <felipe@felipegasper.com>
wrote:

> PART 2:
>
> While I’m raising the issue, what would it take for Perl-issued warnings
> (and exceptions?) writ-large to include some sort of searchable, indexed
> lookup code, something like:
>
> -----
> W.18: Wide character in print (you forgot to encode) at -e line 1.
> -----
>
> Then users could search on that code in Perl’s documentation, maybe like:
>
> -----
> perldoc W.18
> -----
>
> Thoughts?
>
> -FG
>

Note that you can get the docs by running the program with -Mdiagnostics

This is on my list of things to circle back to. I would *LOVE* it if the
warnings and errors spit our a searchable code to offer more explanation.

It would just require writing up some docs and finding a standard
"naming scheme" on what to call the codes.

- Scott

On 6/7/2022 8:47 AM, Eric Brine wrote:
>
>
> On Tue, Jan 25, 2022 at 5:04 PM Felipe Gasper
> <felipe@felipegasper.com> wrote:
>
> PART 2:
>
> While I’m raising the issue, what would it take for Perl-issued
> warnings (and exceptions?) writ-large to include some sort of
> searchable, indexed lookup code, something like:
>
> -----
> W.18: Wide character in print (you forgot to encode) at -e line 1.
> -----
>
> Then users could search on that code in Perl’s documentation,
> maybe like:
>
> -----
> perldoc W.18
> -----
>
> Thoughts?
>
> -FG
>
>
> Note that you can get the docs by running the program with -Mdiagnostics
>

Can we please skip the string-using intermediate step and go right to how
Python does it with exception classes?

I really wonder that I've never read a blog post or mailing list thread
about the lack in exception handling in Perl 5. It's my biggest pain point
with Perl 5 and I'd love to help to improve the situation!

On Wed, 8 Jun 2022 at 09:05, Alexander Hartmaier <alex.hartmaier@gmail.com>
wrote:

> Can we please skip the string-using intermediate step and go right to how
> Python does it with exception classes?
>
>
There already was such discussions
- https://www.nntp.perl.org/group/perl.perl5.porters/2021/06/msg260676.html

Regarding exception classes, I though that as as well, introducing classes
with overloaded stringify should do the trick
but I was told otherwise (I don't remember enough to find that discussion
as well, maybe it was on IRC)
so result: behaviour of "if (ref $@)" to detect perl and custom exception
will change

As result, I also played with internals with implementation of stash-to-sv
relation (so -> operator can call methods even on non-refs)
that is possible but raises another problem (if you are in "cannot do"
mood) - it will prohibit "$class->method"

This can be mitigated by two approaches:
a) limit this behaviour to exceptions
b) introduce mandatory usage of class literal (ie, requires new internals)

Syntax
- My::Package:: - already supported, treated specially but producing
BAREWORD token
- ${var}:: - new syntax, convert dynamic string into class literal

Class literal can still be allowed to use indirect syntax (especially with
"new" and "throw")

Best regards,
Brano