Front page | perl.perl5.porters |
Postings from September 2010
Re: [PATCH] Support B::Generate and B::C
From: Reini Urban
September 3, 2010 05:39
Re: [PATCH] Support B::Generate and B::C
Message ID: 4C80EC72.email@example.com
Nicholas Clark schrieb:
> On Sun, Aug 29, 2010 at 04:53:44PM +0200, Reini Urban wrote:
>> 2010/8/29 Nicholas Clark<firstname.lastname@example.org>:
>>> On Sun, Aug 29, 2010 at 12:10:56PM +0200, Reini Urban wrote:
>>>> The only way out seems to through away those modules, or to have a plan
>>>> for 5.14 to support them again.
>>>> It makes me sick to rewrite most parts of core just because someone went
>>>> berserk and enforces the believe it should not be used outside core
>>> I am *not* berserk. I did not *go* berserk.
>>> Your choice of words continues to be extremely undiplomatic.
>>> I repeat, I repeat:
>> I would rather consider deprecating whole B undiplomatic.
>> The only remaining goodies in B which work are Concise and Lint.
> and B::Deparse, and likely B::Deobfuscate
>>> 1: At the time, I unpacked the current indexed version of CPAN, and checked
>>> which non-API functions were used by modules. I only made static those
>>> which were unused by indexed versions. I was quite methodical about this.
>>> Yes, I realise now, that this was not as comprehensive as I perhaps could have
>>> been, as I didn't check all unindexed distributions.
>> On my first cry you said my fault, not yours.
> IIRC said "the author". Currently on CPAN *six* people have uploaded
> tarballs of B-Generate - ABERGMAN, JCROMIE, JJORE, RURBAN, SIMON, SWALTERS
> I thought it reasonable to assume that the current index would contain the
> most current release *of all modules*. It wasn't special treatment for
> B-Generate. I unpacked all of CPAN using the standard tools, and searched
>> Please my understand also my situation. I took long abandoned modules,
>> ported it successfully to the new 5.10 refactoring and than after several
>> years I have to find out that those modules use functions which they
>> should not have, according to some strict perl policy.
> Yes, I understand this.
>> Going "berserk" is enforcing a policy which should never have been that strict,
>> simply because it makes technically and API wise no sense to forbid usage
>> of actually used functions.
> Why should it never have been that strict?
>> I cried then, nothing happened, now we have two major versions 5.10 and 5.12
>> which cannot be supported if we go into the strict policy mode.
>> This happened with S_ and then when someone added
>> PERL_DL_NONLAZY=1 to the tests all tests using B::Generate fail now.
>> I didn't add them to the public API. They are X, not A.
>> Nobody else should use them, but they can be used.if needed.
>> That's my understanding of X.
> Why should they be X?
> Whilst I have no objections to adding suitable functions to the API with
> documentation and tests to ensure that they keep working, I *do* have
> objections to exporting arbitrary functions with no tests.
> That's a recipe for future breakage.
>>> You patch has no tests.
>> I'm not qualified enough to write such tests for core functions.
>> I just need the exports.
>> We never had global sym tests, otherwise we would have detected
>> breakage earlier.
> If you're not qualified to write the tests then:
>> This documentation of such X non-APIs should give potential core hackers
>> some ideas. If actual core hackers know it better than they should document it.
>> I'm for sure no core hacker, I just have to deal with them.
> why is your code competent to use them?
>> And I bet there is a silent mass which supports my point and disagrees
>> with your policy.
> Well then, let them speak up.
> My experience has been that there is a silent apathetic majority who
> couldn't care less unless everything keeps working. Except that they also
> want bug fixes (that don't break anything) and they don't want to pay for
> any of this, or help with testing release candidates.
I got bug reports reporting brokenness on windows, reported it to core,
got a silly response by you, ("add tests and docs, otherwise we will not
fix it"), so I tried to work around it, this is just even more stuopid,
so I posted my patch.
Again it is refused to be fixed, so we can declare it officially broken
and unsupported by p5p.
> And having arbitrary internal routines exported, with no tests, and external
> code dependent on them, is not a scalable sane way to continue to make
> perl maintenance releases.
It's already insane. Of course it would be nice that *you* will be able
to detect the *future* breakage, not me or some poor users.
But there's no framework to test the public API , and coming with such a
beast is a lot more work, than fixing the *already known* breakage before.
I was thinking about such tests the last days, and it looks like a lot
of work. XS-APItest does not help in this regard.
You have to test all publically used variables, structs, macros and
functions. You cannot compile to exe, only to so/dll's, as perl does not
support that out-of-the box. So you have to compile to an extension in
the right context (args and types), ignoring the return types.
First you need a modules to parse all existing external CPAN XS
functions, throw out all external functions and construct an extension
with all perl.h++ API's. store_cop_label e.g. went from the exported
macro CopLABEL_set to a private function, there are no rules for
deprecating macros. Well there are, but they are ignored by single
You can do your work by constructing such a framework, so that you can
better tests for future breakage,
and I do my work by reporting breakage, until we have tests.
I find it extremely offensive to burden me with writing such tests to
help you in not breaking modules your various reorganizations. I know
that you tests against CPAN, but I have no idea how.
I simply demand to fix the *known* breakage of my modules.
I even wrote a patch for that, but if think you can do better, do it by
Coming up with better tests is desired but not related to that.
Looks like you want to destroy 5.14 also, as you already destroyed
5.12 by refusing to unbreak it with political arguments.
>> I can also make it simple as you, and just declare those modules
>> and all dependent modules broken and unsupported since 5.10,
>> and will refuse all patches which re-implement half of core. This point is near.
> pad_alloc looks reasonable to add to the public API, albeit with its I32
> parameter changed to U32. That's the sort of review I'd expect before anything
> becomes public and hence very hard to change.
I never said public API. I explictly said XE and M. Public API is A.
You can do your part when moving it to A. I just requested to be
And I do not want to trample on p5p business. If p5p thinks it should be
U32, no problem. But we used it for years as I32. The first bit is not
> cv_clone *seems* sane enough, doing one thing, but I'm not sure how tightly
> coupled it is to its inputs.
> fold_constants *as is* is a hairy mess. It's not a sane API to export under
> that name.
In my eyes it's a pretty simple constant folding, on one level only, so
it cannot fold subtrees. Normal constant folders are recursive.
I didn't ask for that neither.
As constant folder it no mess, it just does what it is supposed to under
the name "fold_constants". It is part of the optimizer, and everything
which can be done in this was done (until you removed the intops part).
> a: Does it need to do the 4 or 5 unrelated things that it currently does?
> If so, it should be renamed.
It should do what ever p5p thinks it should do. op->convert just wanted
to use that for an additional feature, I guess.
To be consistent, or to safe some coding.
> b: Does it just need to do constant folding?
It's no must, but that's really not your business. constant folding has
side-effects, and those side-effects are dependant on the optimizer,
types and ops.
It was used asis for 8 years, until you moved it to the S_ prefix.
If I want better constant folding I'd go to core and add it there.
As I already did.
The export has nothing to do with that.
How to improve constant folding should be discussed in another thread.
Since you don't seem to understand it I'll explain line by line what it
currently does and what it should do, resp. did previously, until you