develooper Front page | perl.perl5.porters | Postings from September 2014

Re: Hash::Util and read-only values

Thread Previous | Thread Next
Reini Urban
September 22, 2014 19:08
Re: Hash::Util and read-only values
Message ID:
On Mon, Sep 22, 2014 at 11:22 AM, Ricardo Signes
<> wrote:
> * Reini Urban <> [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 <> [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.

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.
Reini Urban

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About