Re: Assistance requested with B::Utils

2015-07-29 14:55 GMT+02:00 Dave Mitchell <dav...@iabyn.com>:
> On Wed, Jul 29, 2015 at 02:34:04PM +0200, Reini Urban wrote:>> I’ll have to stay with the incompetence accusation generally,>> Because of course your whole modus operandi on this list is to throw> out inflammatory unevidenced assertions.

Unevidenced? I thought you hated my evidence, so I stopped repeating
my arguments for your sake and your new policies, which disallows
being unrespectful to the maintainers.
They are still valid arguments though, even if you refuse to read them.
And I cannot blog anymore because the blog maintainers decided to
forbid criticism on destructive maintainers now, so I just fix the
issues and stopped complaining. You can pick up a tiny subset on my
github if you care.

And it is only inflammatory if you miss the context.
For you the world is shiny and every new perl5 release is better.

From the outside perl5 is losing, development stalled, and devs are
infighting. Not a single new feature implemented in the last 13 years
was successful, besides //=.  (I take out Oleg here, but he is no
maintainer.)
Every new perl release makes it worse, adds no new worthwhile
features, adds more risc, adds more memory bloat, adds more new bugs
than fixed bugs, changes policies and is extremely defensive. For good
reasons. (use experimental, no core changes from outside, ...)
Still no object system, no optional type system, no optimizations, no
compiler support, no method inlining, no signature-based method
dispatch, no macros, no parser hooks, a slow and horrible regex
engine, no improved vm. A disaster.
Hell, 5.6.2 is still the best and fastest version out there. How can that be?
Even if experts from the outside speak up, they are ridiculed by p5p
nobs. It's not funny from outside, it's rather dramatic.

Many CPAN modules are being unmaintained, dev tools like the toolchain
is being seriously harmed by silly demands.
E.g. no 5.6 because we need the LICENSE meta tag, better packager
support and it's OLD and buggy - Ha. It was still good in the golden
times than compared to now. perl 5.18 has certainly more bugs than
5.6.2 and 5.14.4, and 5.6 still had capable devs. I mostly have to fix
bugs from 5.16.
Devel::PPPort for XS devs is unmaintained since years.
Module::Build and other harmful experiments are thanksfully over, but
the new folks started with even worse tools, which require half of
CPAN to maintain a module. No thanks. I do better with EUMM still.

Note: I was very sceptical on the Test::Builder changes but he
convinced me eventually.

At least perl has not the silly name culture as ruby, and not the even
more incompetent devs as in python. But they have at least proper
management going on. Even php does so now.

From the inside:
The folks who are being paid to advance perl are doing simple
maintenance work and make the horrible codebase even more
unmaintainable, which could be done by anybody. Capable devs as you
see on their CPAN development are being kept out. Excessive
inbreeding.

Features that I need to advance perl5 are being kept out, bugs not
fixed, improvements blocked on purpose, modules badmouthed.
Horrible implementations are being added all the time. Don't get me
started on that.
Horrible policies are being invented, which explicitly go against
common sense and the old policies.
Normal technical discussions are not possible. So any feature which
should have been discussed is just added silently. By the powerful. To
avoid that. That's not healthy.

Harmful changes are being politically spinned after the fact.
* E.g. the addition of binary name support was labeled "Unicode Symbol
Names". In fact unicode names were supported since 5.8.4, with
negative lengths in the HEK. Nobody needs to add a new len arg just to
support utf8. How did did your argue for that? Not a single word in
the delta. `g grep -i binary pod/perl5160delta.pod` vs "Unicode Symbol
Names" and a *$foo bug, which lost the utf8 flag.
Not many modules support binary names still since PPPort didn't care,
so potential attackers are very happy. I'm not talking about silly
hash ddos games here.
* B::Generate is being told it cannot work, because one developer
decided with his powers that it should not work anymore. So dynamic
run-time optimizations are out, and "it's B::Generate fault". Ha.
Harmful political games on the back of the user-base. But all went on
unpunished. By people who were not even able to maintain it.
* B for the Bytecode compiler is kept being broken on purpose for how
long now? 4 years? Because this dev "does not understand it and does
not want to revert the breakage"? The a***le rule obviously doesn't
apply to a committer.
* The wonderful new double readonly system which took away the last
free sv bit, where still the main one readonly flag is not even used
yet, and I used the free bit. Why do we need two now? Not for the
stated reason "hash unlocking" for sure, because this is technically
not justified. It's rather horrible. hash unlocking is still not fixed
btw. But who cares.
* The wonderful new discussion which new strict flags people want,
when they do not know that they have no free bit. I earned 2 bits but
I don't give them to you, because you cannot be trusted with them.
Sorry. That's how it went down.

Harmful and destructive devs are being rewarded, and stick together.
The new code of conduct policies would be a good fit for the people
here, but are not used on them, rather on the critics on these
practices.
Still, it's a shame to come up with such policies, similar to github.
Devs who fix and improve issues and care for better code are being
ignored, do not care to speak up, or are being badmouthed.
Incompetent middle management has taken over.

Maybe a word about your op_signatures branch:
Coding a parse into the lexer (toke.c) led to spaghetti. The whole
patch is spaghetti. It doesn't only look horrible, it does the wrong
thing and is also unmaintainable. When I added alias support and using
the stack directly to skip @_ I had to rewrite most of it. Just the
action compression PV is nice. Supporting sigs and protos together is
a parser job, not for a smart lexer generating a single token. A
parser is there to parse, the lexer should be used only for the crazy
dynamic parts. sigs and protos are both static. Besides the types, but
this is a seperate token.
A lexer doesn't know how to reset state to the previous parse.
My signature code is 2x faster, has more features, and is readable and
maintainable.

COW is such a mess it hurts my eyes. ~20 unmaintainable spaghetti
rules by a different developer. For a cow refcount which is in the
read-write section?
I could only barely fix that. Fixing that I wished nick was back who
could at least write readable code, even if he should be suspended for
life in this new fancy coc of yours.
Anybody heard how expensive branches are? And that's why we still have
4 tests in the inner hash loop, instead of one or a second for utf8
unstrictness.

But I need to be able to support 5.22, which looks like a good target
to work for. Eventually, if I can get the horrible memory bloat down
to reasonable 5.14 values. Not even thinking about 5.6 levels yet, as
this might be out of reach.

There's much more evidence I brought up, which you like to ignore but
eventually have to react. In rather mysterious ways not to loose your
face.
sv_grow? asan support? safesyscalls?
And the still unresolved mess with hash functions and hash tables,
cow, sigs, types, lexical warnings, dispatch, inlining, ...
Sorry for B::OP::parent, apparently this was my mistake. But I fixed it ASAP.

Ok, this was pretty inflammatory now. Sorry if that offended anybody.
But I need to speak out from time to time because I saw parrot going
down for the same reasons with the same effects. You don't like it,
but that's how it is.
Do something against it. Start listening. Stop being ***. Attract
people who do have an idea what they are doing. Enable discussions and
do not kill them. At least get a manager who has an idea what the devs
are doing and can react to that. Optimizations should be fun and not
forbidden.
Back to work.
-- 
Reini