Mailing List Archive

PSC #033 2021-08-13
PSC #033 2021-08-13
Present: Paul, Rik, Neil


Source encoding stricture

We had a follow-up discussion on the proposal that came out of last week's meeting, for a source encoding stricture[1]. One issue raised on p5p was the question of having a file with two different encodings in it. This is independent of the proposal – if you `use utf8` now, you still have this problem. And is this a real life problem? We don't think so.

The other topic was the fact that if you have non-ASCII UTF-8 in your source and the pod, then you need `use utf8` and `=encoding utf8`. Naively it would be nice if you could get away with just `use utf8` at the top of the file, but pod parsers aren't (and shouldn't be) expected to parse the non-pod parts of your source, and the utf8 pragma could be used by some module you're using, and so wouldn't be seen by the pod parser anyway.

The proposal doesn't fix everything, but it's a step in the right direction. We'll let the discussion another week or so, then make a decision on whether to go to a formal RFC.

[1] https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261164.html


Communicating beyond p5p

On p5p we're discussing things that are going to affect all Perl programmers, but often they're not aware of what's coming until it's released, or about to be. For most discussion points that's ok. But we agreed that for some topics the PSC should let the broader communities know of changes being considered, to give people a chance to comment, and at least set expectations.

An example of this is the change we're considering with respect to taint[2]. Neil will do a short blog post on this.

[2] https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261262.html


PV vs IV/NV discussion and PR

Following the discussion on improving how Perl decides whether to render a scalar as a string or number[3], we're keen to see Nick's PR[4] merged, but before we can do that the last concern is performance. We don't have tools, or even an agreed process on how to benchmark changes. This applies to the proposal for dropping taint – we believe this will bring a good performance boost, but how confident are we, and what kind of things will see the benefit?

Paul will talk to Nick to come up with something for this specific case, which we can then hopefully look to generalise.

[3] https://www.nntp.perl.org/group/perl.perl5.porters/2021/07/msg260916.html
[4] https://github.com/Perl/perl5/pull/18958


Lord of the Quirks

We continued our review of the quirks document, but didn't get through too many, as the previous discussions took up most of the hour that was available today.

One of them was use of ' as package name separator. Rik has already kicked off that thread on p5p.


Neil
Re: PSC #033 2021-08-13 [ In reply to ]
The Intel Emulator:
https://software.intel.com/content/www/us/en/develop/articles/intel-software-development-emulator.html
gives an exact count of the instructions executed by a program. Please
consider using the number of instructions executed (amongst many other
useful statistics) to see whether a proposed change is going to increase
or decrease the number of instructions executed and thus have a possibly
negative or positive effect on execution speed?

Please tell me how you intend to perform the action: *Communicating beyond
p5p *so that I know where to look for such information?




On Mon, Aug 16, 2021 at 12:27 AM Neil Bowers <neilb@neilb.org> wrote:

> PSC #033 2021-08-13
> Present: Paul, Rik, Neil
>
>
> *Source encoding stricture*
>
> We had a follow-up discussion on the proposal that came out of last week's
> meeting, for a source encoding stricture[1]. One issue raised on p5p was
> the question of having a file with two different encodings in it. This is
> independent of the proposal – if you `use utf8` now, you still have this
> problem. And is this a real life problem? We don't think so.
>
> The other topic was the fact that if you have non-ASCII UTF-8 in your
> source and the pod, then you need `use utf8` and `=encoding utf8`. Naively
> it would be nice if you could get away with just `use utf8` at the top of
> the file, but pod parsers aren't (and shouldn't be) expected to parse the
> non-pod parts of your source, and the utf8 pragma could be used by some
> module you're using, and so wouldn't be seen by the pod parser anyway.
>
> The proposal doesn't fix everything, but it's a step in the right
> direction. We'll let the discussion another week or so, then make a
> decision on whether to go to a formal RFC.
>
> [1]
> https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261164.html
>
>
> *Communicating beyond p5p*
>
> On p5p we're discussing things that are going to affect all Perl
> programmers, but often they're not aware of what's coming until it's
> released, or about to be. For most discussion points that's ok. But we
> agreed that for some topics the PSC should let the broader communities know
> of changes being considered, to give people a chance to comment, and at
> least set expectations.
>
> An example of this is the change we're considering with respect to
> taint[2]. Neil will do a short blog post on this.
>
> [2]
> https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261262.html
>
>
> *PV vs IV/NV discussion and PR*
>
> Following the discussion on improving how Perl decides whether to render a
> scalar as a string or number[3], we're keen to see Nick's PR[4] merged, but
> before we can do that the last concern is performance. We don't have tools,
> or even an agreed process on how to benchmark changes. This applies to the
> proposal for dropping taint – we believe this will bring a good performance
> boost, but how confident are we, and what kind of things will see the
> benefit?
>
> Paul will talk to Nick to come up with something for this specific case,
> which we can then hopefully look to generalise.
>
> [3]
> https://www.nntp.perl.org/group/perl.perl5.porters/2021/07/msg260916.html
> [4] https://github.com/Perl/perl5/pull/18958
>
>
> *Lord of the Quirks*
>
> We continued our review of the quirks document, but didn't get through too
> many, as the previous discussions took up most of the hour that was
> available today.
>
> One of them was use of ' as package name separator. Rik has already kicked
> off that thread on p5p.
>
>
> Neil
>
Re: PSC #033 2021-08-13 [ In reply to ]
2021-8-16 8:27 Neil Bowers <neilb@neilb.org> wrote:


> *Communicating beyond p5p*
>
> On p5p we're discussing things that are going to affect all Perl
> programmers, but often they're not aware of what's coming until it's
> released, or about to be. For most discussion points that's ok. But we
> agreed that for some topics the PSC should let the broader communities know
> of changes being considered, to give people a chance to comment, and at
> least set expectations.
>
> An example of this is the change we're considering with respect to
> taint[2]. Neil will do a short blog post on this.
>
> [2]
> https://www.nntp.perl.org/group/perl.perl5.porters/2021/08/msg261262.html
>
>
>
I feel it is good for the Perl core team to be interested in customers,
CPAN authors, lite users, and web developers, etc.

Perl has a practical culture, so I want our Perl Core team to communicate
with the users who are actually using Perl practically.
Re: PSC #033 2021-08-13 [ In reply to ]
> Please tell me how you intend to perform the action:  Communicating beyond p5p  so that I know where to look for such information?

I just posted to blogs.perl.org:

http://blogs.perl.org/users/neilb/2021/08/making-taint-support-optional-in-perl.html
Re: PSC #033 2021-08-13 [ In reply to ]
2021-8-18 19:20 Neil Bowers <neilb@neilb.org> wrote:

> Please tell me how you intend to perform the action: Communicating beyond
> p5p so that I know where to look for such information?
>
>
> I just posted to blogs.perl.org:
>
>
> http://blogs.perl.org/users/neilb/2021/08/making-taint-support-optional-in-perl.html
>

Thank you for sharing and writing this entry.
Re: PSC #033 2021-08-13 [ In reply to ]
On Mon, Aug 16, 2021 at 12:41:54AM +0100, Philip R Brenan wrote:
> The Intel Emulator:
> https://software.intel.com/content/www/us/en/develop/articles/intel-software-development-emulator.html
> gives an exact count of the instructions executed by a program. Please
> consider using the number of instructions executed (amongst many other
> useful statistics) to see whether a proposed change is going to increase
> or decrease the number of instructions executed and thus have a possibly
> negative or positive effect on execution speed?


We already have a tool, Porting/bench.pl, which uses cachegrind to
count the total number of instructions, memory reads, branches etc that
small snippets of code execute. It is sensitive to very small changes
in the code (like removing a conditional) and is almost completely immune
to noise (such as CPU load). It can run in parallel on as many CPUs as you
have, and can compare multiple perl binaries.

There is a companion file, t/perf/benchmarks, which currently contains
around 400 benchmarks (although it would benefit from many more being
added).


--
Indomitable in retreat, invincible in advance, insufferable in victory
-- Churchill on Montgomery