Hash::Util and read-only values

[Father Chrysostomos]

With Hash::Util::hv_store and Hash::Util::unlock_value, it is possible
to turn off the read-only flag of any scalar.

There are cases where the core uses this flag to protect things that
must not be modified. So we need to stop Hash::Util from being able
to do this.

(I bring this up, because with lvalue references it will become easier
to do this by mistake.)

So we need to distinguish truly read-only values from values locked by
Hash::Util.

Hash::Util::unlock_value should croak for any read-only (as opposed to
locked) value. But should Hash::Util::lock_value croak for those, or
just return? I am inclined to think it should croak, as a successful
lock_value implies that later unlock_value will work.

Actually, since locking or unlocking an entire hash's values at
once is possible, should (un)locking silently do nothing with read-
only values?

[demerphq]

On 20 September 2014 00:48, Father Chrysostomos <spr...@cpan.org> wrote:

With Hash::Util::hv_store and Hash::Util::unlock_value, it is possible
to turn off the read-only flag of any scalar.

There are cases where the core uses this flag to protect things that
must not be modified.  So we need to stop Hash::Util from being able
to do this.

This suggests a deeper design problem that I think needs to be thought through independently of Hash::Util.

 

(I bring this up, because with lvalue references it will become easier
to do this by mistake.)

Yes, exactly, that is the problem. 

 

So we need to distinguish truly read-only values from values locked by
Hash::Util.

Or alternatively we need to change things that are using the read-only bit for different purposes.

 

Hash::Util::unlock_value should croak for any read-only (as opposed to
locked) value. 

There is no difference between a locked value and a read only value.

 

But should Hash::Util::lock_value croak for those, or
just return?  I am inclined to think it should croak, as a successful
lock_value implies that later unlock_value will work.

Actually, since locking or unlocking an entire hash's values at
once is possible, should (un)locking silently do nothing with read-
only values?

For me this has subject has XY problem written all over it.

I think we should solve the X problem, that we use the read only flag for multiple purposes.

Once we solve that there will be no Y problem, that Hash::Util does the wrong thing.

Independently, I think it is arguable that the locked hash implementation is broken to the point of being nearly unusable. 

Specifically there is no way to lock a hash so you can not modify, delete or add keys or values, but can still do things like fetch a missing key, call exists on a missing key etc.

Also related to this is the question of how to serialize a locked or read only value?

Yves

 

--
perl -Mre=debug -e "/just|another|perl|hacker/"

[Father Chrysostomos]

Yves Orton wrote:

> On 20 September 2014 00:48, Father Chrysostomos <sprout cpan.org> wrote:
>
> > With Hash::Util::hv_store and Hash::Util::unlock_value, it is possible
> > to turn off the read-only flag of any scalar.
> >
> > There are cases where the core uses this flag to protect things that
> > must not be modified. So we need to stop Hash::Util from being able
> > to do this.
> >
>
> This suggests a deeper design problem that I think needs to be thought
> through independently of Hash::Util.
>
>
> >
> > (I bring this up, because with lvalue references it will become easier
> > to do this by mistake.)
> >
> >
> Yes, exactly, that is the problem.
>
>
> > So we need to distinguish truly read-only values from values locked by
> > Hash::Util.
> >
> >
> Or alternatively we need to change things that are using the read-only bit
> for different purposes.
>
>
> > Hash::Util::unlock_value should croak for any read-only (as opposed to
> > locked) value.
>
>
> There is no difference between a locked value and a read only value.

Currently there is none, but introducing such a distinction is easy.

> > But should Hash::Util::lock_value croak for those, or
> > just return? I am inclined to think it should croak, as a successful
> > lock_value implies that later unlock_value will work.
> >
> > Actually, since locking or unlocking an entire hash's values at
> > once is possible, should (un)locking silently do nothing with read-
> > only values?
> >
>
> For me this has subject has XY problem written all over it.

In this case the solution for Y would be identical to the solu-
tion for X.

> I think we should solve the X problem, that we use the read only flag for
> multiple purposes.

In the perl core, the read-only flag only serves one purpose aside
from Hash::Util.

> Once we solve that there will be no Y problem, that Hash::Util does the
> wrong thing.

Since Hash::Util is the part of the core (if you will) that uses the
flag differently, we do need to discuss how it will behave, since that
is where the bugs in the design show through.

> Independently, I think it is arguable that the locked hash implementation
> is broken to the point of being nearly unusable.
>
> Specifically there is no way to lock a hash so you can not modify, delete
> or add keys or values, but can still do things like fetch a missing key,
> call exists on a missing key etc.

I am not interested in solving this at present (if ever).

> Also related to this is the question of how to serialize a locked or read
> only value?

Or this. (DDS already does make_ro though. Hey, do you know about
DDS? I recommend it.)

Okay, the two meanings for SvREADONLY are:

1) This value must not be modified and must be protected at all costs.
(Call this 'protected'.)
2) This value is temporarily read-only, at the user's request.
(Call this 'locked'.)

Every use of SvREADONLY_on in the perl core, aside from Hash::Util, is
for meaning 1. Hash::Util's use of it is for meaning 2.

(Before Hash::Util came along, no. 1 was the only meaning.)

So what should Hash::Util::(un)lock_value do when it encounters a pro-
tected value (assuming we have already introduced the distinction with
internal flags)? Croak? Silently do nothing?

Now, as for flag usage and XS macros, do we want to take into account
the various CPAN modules that do SvREADONLY_on/off (which modules have
always been buggy to some extent)?

Do we want SvREADONLY to refer to locked values or to protected
values? The former would make such CPAN modules safer, but
SvREADONLY_off would be effectively a silent no-op for protected val-
ues. The latter would have them continue to behave exactly as they do
(dangerously).

BTW, here is one symptom of the problem:

$ perl -MHash::Util=hv_store,unlock_value -MScalar::Util=weaken -e 'DESTROY{hv_store %h, k=>$_[0]; unlock_value %h, "k"; $x = $_[0]; weaken $_[0]; undef %h} $_ = bless[]'
panic: magic_killbackrefs (flags=ff) during global destruction.

I have managed to get variants of this to crash in the past.

[Aristotle Pagaltzis]

Hi FC,

* Father Chrysostomos <spr...@cpan.org> [2014-09-20 00:50]:

> Hash::Util::unlock_value should croak for any read-only (as opposed to
> locked) value. But should Hash::Util::lock_value croak for those, or
> just return? I am inclined to think it should croak, as a successful
> lock_value implies that later unlock_value will work.

to my mind, in unlocking a value there is no promise that the value will
be modifiable – it just reverts a previous locking, which in the case of
an immutable value is a noöp. So I will say the symmetry ought to go the
other way, i.e. locking and unlocking both should silently do nothing to
immutable values.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

[demerphq]

On 20 September 2014 05:03, demerphq <deme...@gmail.com> wrote:

On 20 September 2014 03:11, Father Chrysostomos <spr...@cpan.org> wrote:

Yves Orton wrote:
> On 20 September 2014 00:48, Father Chrysostomos <sprout cpan.org> wrote:
>

Since Hash::Util is the part of the core (if you will) that uses the
flag differently, we do need to discuss how it will behave, since that
is where the bugs in the design show through.

Again that isn't clear to me. Hash::Util simply uses Internals::SvREADONLY(), anything that uses it, and stuff does, is an issue.

 

I think we could add a new bit "locked", and then make SvREADONLY() use it. That would be a reasonable fix. But again it doesnt require changing Hash::Util at all. It requires changing universal.c XS_Internals_SvREADONLY

Yves

[demerphq]

On 20 September 2014 03:11, Father Chrysostomos <spr...@cpan.org> wrote:

Yves Orton wrote:
> On 20 September 2014 00:48, Father Chrysostomos <sprout cpan.org> wrote:
>
> > With Hash::Util::hv_store and Hash::Util::unlock_value, it is possible
> > to turn off the read-only flag of any scalar.
> >
> > There are cases where the core uses this flag to protect things that
> > must not be modified.  So we need to stop Hash::Util from being able
> > to do this.
> >
>
> This suggests a deeper design problem that I think needs to be thought
> through independently of Hash::Util.
>
>
> >
> > (I bring this up, because with lvalue references it will become easier
> > to do this by mistake.)
> >
> >
> Yes, exactly, that is the problem.
>
>
> > So we need to distinguish truly read-only values from values locked by
> > Hash::Util.
> >
> >
> Or alternatively we need to change things that are using the read-only bit
> for different purposes.
>
>
> > Hash::Util::unlock_value should croak for any read-only (as opposed to
> > locked) value.
>
>
> There is no difference between a locked value and a read only value.

Currently there is none, but introducing such a distinction is easy.

Well if it interferes with peoples using of Internals::SvREADONLY() then there is a problem. 

People use that independent of Hash::Util.

 

> > But should Hash::Util::lock_value croak for those, or
> > just return?  I am inclined to think it should croak, as a successful
> > lock_value implies that later unlock_value will work.
> >
> > Actually, since locking or unlocking an entire hash's values at
> > once is possible, should (un)locking silently do nothing with read-
> > only values?
> >
>
> For me this has subject has XY problem written all over it.

In this case the solution for Y would be identical to the solu-
tion for X.

Is it? It sounds like you want to change Hash::Util, when I would argue that Hash::Util simply uses Internals::SvREADONLY() and as such it is it, and how the internals uses the readonly flag that is the problem.

IOW, I think if there is a problem with something turning off the read-only flag then we should fix it so that the readonly flag doesnt matter.

 

> I think we should solve the X problem, that we use the read only flag for
> multiple purposes.

In the perl core, the read-only flag only serves one purpose aside
from Hash::Util.

Except that people think they can use Internals::SvREADONLY() directly and they do.

Note XS_constant__make_const() in universal.c uses SvREADONLY_on()

 

> Once we solve that there will be no Y problem, that Hash::Util does the
> wrong thing.

Since Hash::Util is the part of the core (if you will) that uses the
flag differently, we do need to discuss how it will behave, since that
is where the bugs in the design show through.

Again that isn't clear to me. Hash::Util simply uses Internals::SvREADONLY(), anything that uses it, and stuff does, is an issue.

 

> Independently, I think it is arguable that the locked hash implementation

> is broken to the point of being nearly unusable.
>
> Specifically there is no way to lock a hash so you can not modify, delete
> or add keys or values, but can still do things like fetch a missing key,
> call exists on a missing key etc.

I am not interested in solving this at present (if ever).

Well, that is fair enough. But I would say that if we arent going to solve this we should rip out locked hashes entirely. They complicate and slow down *all* hashes and hash accesses, and as far as I can tell, due to the reasons I mention above, they are pretty much unused and unusable. We tried to use them for a few applications at $work and basically it was a nightmare.

 

> Also related to this is the question of how to serialize a locked or read
> only value?

Or this.  (DDS already does make_ro though.  Hey, do you know about
DDS?  I recommend it.)

I am somewhat familiar with the module, I actually know the author.[1]

 

Okay, the two meanings for SvREADONLY are:

1) This value must not be modified and must be protected at all costs.
   (Call this 'protected'.)
2) This value is temporarily read-only, at the user's request.
   (Call this 'locked'.)

Every use of SvREADONLY_on in the perl core, aside from Hash::Util, is
for meaning 1.  Hash::Util's use of it is for meaning 2.

(Before Hash::Util came along, no. 1 was the only meaning.)

Well except that out in wild people use the readonly flag also for purpose 2. Perhaps they shouldn't have, but they do. Sereal for instance has two modes to mark every item it deserializes as read-only (but that doesnt work well for the reasons I mentioned above about hashes).

 

So what should Hash::Util::(un)lock_value do when it encounters a pro-
tected value (assuming we have already introduced the distinction with
internal flags)?  Croak?  Silently do nothing?

Now, as for flag usage and XS macros, do we want to take into account
the various CPAN modules that do SvREADONLY_on/off (which modules have
always been buggy to some extent)?

Do we want SvREADONLY to refer to locked values or to protected
values?  The former would make such CPAN modules safer, but
SvREADONLY_off would be effectively a silent no-op for protected val-
ues.  The latter would have them continue to behave exactly as they do
(dangerously).

IMO that boat has already sailed. SvREADONLY means locked, not protected. Even if the core thinks otherwise. This is what I mean by an XY problem. You are focusing on Hash::Util thinking it is the odd man out, I would contend that Internals::SvREADONLY() has been exposed for over a decade, and people are and have been using it in the "locked" form, so in fact the internals use as "protected" is the odd man out. (Even if that feels weird and is something that probably should not have happened.)

BTW, here is one symptom of the problem:

$ perl -MHash::Util=hv_store,unlock_value -MScalar::Util=weaken -e 'DESTROY{hv_store %h, k=>$_[0]; unlock_value %h, "k"; $x = $_[0]; weaken $_[0]; undef %h} $_ = bless[]'
panic: magic_killbackrefs (flags=ff) during global destruction.

I have managed to get variants of this to crash in the past.

Doesn't surprise me one bit. I think we need to separate out the internals use of the readonly flag and NOT expose it AT ALL to the user, and leave the current readonly flag alone, as it is in use in the wild and we arent going to change that. 

Yves

[1] For the uninitiated FC is being ironic here, as he knows I wrote DDS. What he might not know is I also wrote/fixed a big chunk of Hash::Utils recursive support.

[Father Chrysostomos]

Yves Orton wrote:
> [...] wild people [...]

:-)

> I think we need to separate out the internals
> use of the readonly flag and NOT expose it AT ALL to the user, and leave
> the current readonly flag alone, as it is in use in the wild and we arent
> going to change that.

OK, easy enough. Protected values get two flags and core read-only
checks check both.

[demerphq]

Er... Im not entirely sure if that is what I meant, but Ill assume it is.

I think my followup where I said:

<quote>

I think we could add a new bit "locked", and then make SvREADONLY() use it. That would be a reasonable fix. But again it doesnt require changing Hash::Util at all. It requires changing universal.c XS_Internals_SvREADONLY

</quote>

is the important part.

Yves

[Father Chrysostomos]

Yves Orton wrote:
> I think we could add a new bit "locked", and then make SvREADONLY() use it.
> That would be a reasonable fix. But again it doesnt require changing
> Hash::Util at all. It requires changing universal.c XS_Internals_SvREADONLY

We also have CPAN modules fiddling with SvREADONLY. So I think the
real solution is:

#defined SvREADONLY(sv) (SvFLAGS(sv) & (SVf_READONLY|SVf_PROTECTED))

and SvREADONLY_on/_off only flip the SVf_READONLY flag #ifndef
PERL_CORE.

[demerphq]

On 20 September 2014 06:30, Father Chrysostomos <spr...@cpan.org> wrote:

Yves Orton wrote:
> I think we could add a new bit "locked", and then make SvREADONLY() use it.
> That would be a reasonable fix. But again it doesnt require changing
> Hash::Util at all. It requires changing universal.c XS_Internals_SvREADONLY

We also have CPAN modules fiddling with SvREADONLY.  So I think the
real solution is:

#defined SvREADONLY(sv) (SvFLAGS(sv) & (SVf_READONLY|SVf_PROTECTED))

Ah right. Ok.

 

and SvREADONLY_on/_off only flip the SVf_READONLY flag #ifndef
PERL_CORE.

Yeah that works. Does universal.c get compiled with PERL_CORE enabled? 

Also, I wonder if any important modules define that. I know in Sereal we copied some code from core to avoid using it[1], and I wonder how many people have done the opposite. Which then makes me think of the madness of creating more defines... Imagine PERL_CORE_REALLY and PERL_CORE_NO_SERIOUSLY_I_MEAN_IT. :-)

Yves

[1]  https://github.com/Sereal/Sereal/blob/master/Perl/Decoder/srl_decoder.h#L87

[Father Chrysostomos]

Yves Orton wrote:
> On 20 September 2014 06:30, Father Chrysostomos <spr...@cpan.org> wrote:
> > and SvREADONLY_on/_off only flip the SVf_READONLY flag #ifndef
> > PERL_CORE.
> >
> >
> Yeah that works. Does universal.c get compiled with PERL_CORE enabled?

Yes it does, which means I *do* have to change XS_Internals_SvREADONLY.

> Which then makes me think of the madness of
> creating more defines... Imagine PERL_CORE_REALLY and
> PERL_CORE_NO_SERIOUSLY_I_MEAN_IT. :-)

#if defined(PERL_IN_SV_C) || defined(PERL_IN_OP_C) ...

[Reini Urban]

I don't like this. SvREADONLY should be the interface to
readonly-ness, and not a combination thereof.

To lock hash keys and hash values you simply unify the Hash::Util lock
keys and values API, and store the locked bit in the HE.
There's enough room there, but there's no room in the SV, and changing
the meaning of SvREADONLY again (with FAKE finally gone now)
is problematic.

--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/

[Father Chrysostomos]

Reini Urban wrote:
> I don't like this. SvREADONLY should be the interface to
> readonly-ness, and not a combination thereof.
>
> To lock hash keys and hash values you simply unify the Hash::Util lock
> keys and values API, and store the locked bit in the HE.

That cannot possibly protect the values.

for my $ro ($locked_hash{locked_elem}) {
# $ro now points to just the SV, so a HE flag would not prevent:
$ro = 42;

}

> There's enough room there, but there's no room in the SV,

There is plenty of room in the SV.

> and changing
> the meaning of SvREADONLY again (with FAKE finally gone now)
> is problematic.

SvREADONLY still means read-only.

[Reini Urban]

On Sat, Sep 20, 2014 at 11:59 AM, Father Chrysostomos <spr...@cpan.org> wrote:
> Reini Urban wrote:
>> I don't like this. SvREADONLY should be the interface to
>> readonly-ness, and not a combination thereof.
>>
>> To lock hash keys and hash values you simply unify the Hash::Util lock
>> keys and values API, and store the locked bit in the HE.
>
> That cannot possibly protect the values.
>
> for my $ro ($locked_hash{locked_elem}) {
> # $ro now points to just the SV, so a HE flag would not prevent:
> $ro = 42;
> }

Why should this be a problem? When you convert this locked HE to a SV,
you mark the SV as READONLY.

>> There's enough room there, but there's no room in the SV,
>
> There is plenty of room in the SV.

There's none. There was one left free bit, which you just took without asking,
and there's nothing left now.
Your solution is a mess, even worse then the FAKE mess we had until we cleared
READONLY to get rid of FAKE.

>> and changing
>> the meaning of SvREADONLY again (with FAKE finally gone now)
>> is problematic.
>
> SvREADONLY still means read-only.

No, you are adding a HE-only bit to every single SV,
instead of adding of to the HE to mark locked hashes entries.
SvREADONLY_on is now setting the protect bit on every non-HV.
Locked strings? You got it. Locked integers? You got it now.

Please revert.

It's not as bad as your recent GV change, because this affected
everybody globally immediately, but it affects all my efforts to have
clean compile-time readonly-ness to be able to do
compile-time const optimizations and fast coretype checks, esp. typed
hashes, arrays and scalars.

Looks like I really have to fork this mess now to fix the worst parts
you were doing recently.
But I cannot because I have better things to do.
So I'll stop watching this mess now, goodbye 5.22 and p5p.
Please come to your senses somewhen in the next years.
The latest version I can recommend is 5.14.4 still.

[Father Chrysostomos]

Reini Urban wrote:

> On Sat, Sep 20, 2014 at 11:59 AM, Father Chrysostomos <sprout cpan.org> wrote:
> > for my $ro ($locked_hash{locked_elem}) {
> > # $ro now points to just the SV, so a HE flag would not prevent:
> > $ro = 42;
> > }
>
> Why should this be a problem? When you convert this locked HE to a SV,
> you mark the SV as READONLY.

There is no conversion to SV at any point. Do you mean that
Hash::Util should refrain from turning off the read-only flag if the
HE does not have the bit set? That would not work if two hash ele-
ments point to the same SV.

> > There is plenty of room in the SV.
>
> There's none. There was one left free bit,

SVf_OOK and SVf_FAKE are never set together, so they could
be combined.

> No, you are adding a HE-only bit to every single SV,
> instead of adding of to the HE to mark locked hashes entries.
> SvREADONLY_on is now setting the protect bit on every non-HV.
> Locked strings? You got it. Locked integers? You got it now.

I think you misunderstand the purpose of the SVt_PROTECT flag. It's
the opposite of what you said. That flag is specifically designed to
protect &PL_sv_no, and other constant values to make sure that
Hash::Util and other modules do not accidentally make them mutable. I
suppose I should have called it SVp_READONLY. SVf_READONLY is effect-
ively the public flag, but you would have to turn off the private
flag, too, if you wanted to modify anything.

> It's not as bad as your recent GV change,

Do you still support 5.6 and 5.8 in your modules? They also had a
gp_flags field. How do you cope with it in those versions?

> but it affects all my efforts to have
> clean compile-time readonly-ness to be able to do
> compile-time const optimizations and fast coretype checks, esp. typed
> hashes, arrays and scalars.

How so? The new flag does not make things less read-only than before,
but more so.

[Ricardo Signes]

* Reini Urban <rur...@x-ray.at> [2014-09-21T00:41:52]

> Looks like I really have to fork this mess now to fix the worst parts
> you were doing recently.
> But I cannot because I have better things to do.
> So I'll stop watching this mess now, goodbye 5.22 and p5p.
> Please come to your senses somewhen in the next years.
> The latest version I can recommend is 5.14.4 still.

* Reini Urban <rur...@x-ray.at> [2014-09-22T11:43:12]
> I had to create my own replacement vm (p2), and I'm still maintaining the old
> vm (parrot), which ought to replace the outdated vm (perl5), until parrot was
> destroyed by a different set of poisonous people.
> [...]
> They are actively making things worse, actively blocking progress and actively
> destroying informed discussion (I called it trolling).
> You, management, just fail to call them out and revert them.

I understand that you are leaving p5p until such time as it changes into a
place that you find more to your liking, but for formality's sake, I am giving
you an official warning, atop my earlier personal warning. There is nothing
wrong with your technical complaints, and they do get discussed. (For example,
FC responded in detail to your complaint about PROTECTED.) Your repeated
attacks on p5p as a whole, and your continually unconstructive attitude is not
okay and not welcome.

If you choose to change your mind about ever posting on p5p again, please keep
that fact in mind.

--
rjbs

[Reini Urban]

Excuse me? Official warning for what? Unconstructive attitude?

I'm currently the only one who is trying to be constructive and who is
helping to improve
the product. I fixed the bits I could, which p5p destroyed. Most of
the destruction done
is out of my power. I have to maintain my own patchsets for the
Compiler, Security and
Performance (not yet).
I called out the repeatedly the unconstructive and harmful behaviour
and code of several
other members. In a civil and technical manner. Very much unlike
others who favor to
repeatedly call other people assholes or stupid when they have no
other arguments left.
You've dug yourself into a deep hole, without any progress to improve it.

> If you choose to change your mind about ever posting on p5p again, please keep
> that fact in mind.

Your attitude attacking the messenger to help with these issues is
also not welcome.
Good luck with that.
Disallowing fair and civil critic on the p5p process and the
unsuccessful track record in the
last 10 years at all is only helping yourself, nobody else.

Technically to the FC bit:
Adding a bit from a rare resource such as global SV bits (with only
one remainaing bit left) to specify
readonly-ness with just another name (protected) is no technical
argumentation to anybody but FC.
Readonly is good enough to specify readonly-ness. If you need to add
locked hash entry
support you'll either go with readonly (and ignore the compiler
problems with that in a BEGIN block, but this policy is even written
down), or add the missing locked bit to the HE. But to me a locked HE
is just a readonly HE.
* I don't accept FC's argumentation on this. I don't accept your
excuse that this was a proper discussion.
* He excused himself that we have "plenty of bits" left. Wrong.
* Protecting to-be readonly interpreter values (no, yes, undef) needs
to be done with readonly, not protect. There's no need for another
readonly bit. That's obvious to anybody. We just got rid of the last
harmful readonly combination with SVf_FAKE so that I could finally
implement proper const support (which could now be renamed to
readonly. oh sorry, not anymore).
* He posted directly to blead, not in a branch. Harmful disrespect.

But since nobody comes to rescue, I respect your decision to go on
with that behavior. I cannot.
That's now at least the 10th big unfixable issue in the last decade
out of my head. Nick Clark was first alone in started destroying
these: constant folding to i_ops, op_seq for the type checkers and
optimizations, dynamic optimizations, B::Bytecode.
But then more stepped up to follow with these: binary symbols, tr39
with unicode symbols, slower hash functions and tables, cow strings
not cowable anymore, smartmatch w/o types, given/when, switch,
unusable and backwards signatures. And for the lack thereof: still
unusable readonlyness, unshared unicode tables,
bloated carp, no mop help and plan, and then my optimization plans I
was caring about.
You have to bear that costs and take criticism for it.
That's why perl5 might need to be forked to finally get to a
maintenance community who will do the proper work and doing less harm,
and maybe even some good stuff eventually, as Zefram did with his
parser hooks. (To varying degree of good)
There are a lot of really good CPAN authors out there who code around
the worst p5p committers by lengths. I only see davem and tonyc with a
clean track record so far, but they are now completely alone, without
any help.

There might be still a few companies around who need a fast enough and
secure enough software to run their business on. You cannot hide all
internal problems with faster HW.
That's for the summary. I'm watching scalac closely how this fork will
work out. They had much less problems than p5p, as I understand Paul.
You will not agree with him at all on the issues he had.

[Dave Mitchell]

On Mon, Sep 22, 2014 at 02:08:03PM -0500, Reini Urban wrote:
> There are a lot of really good CPAN authors out there who code around
> the worst p5p committers by lengths. I only see davem and tonyc with a
> clean track record so far, but they are now completely alone, without
> any help.

Please leave me out of this. I fully support and endorse my fellow p5p
committers, and completely disagree with essentially everything you've
just said.

--
You're only as old as you look.

[Ricardo Signes]

Reini has been removed from p5p until October 23rd.

--
rjbs