Front page | perl.perl5.porters |
Postings from May 2011
Re: [PATCH] export store_cop_label
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
May 30, 2011 08:09
Subject:
Re: [PATCH] export store_cop_label
Message ID:
20110530150858.GW23881@plum.flirble.org
On Mon, May 30, 2011 at 03:34:05PM +0200, Reini Urban wrote:
> 2011/5/30 Joshua ben Jore <twists@gmail.com>:
> > On Sat, May 28, 2011 at 11:40 PM, Konovalov, Vadim (Vadim)** CTR **
> > <vadim.konovalov@alcatel-lucent.com> wrote:
> >>> From: Konovalov, Vadim
> >>> > From: Jesse Vincent
> >>> > Based on a conversation with a few porters yesterday, it
> >>> > sounds like there's some
> >>> > desire for a more thought-out, comprehensive API here and
> >>> > that that is currently in Nick's backlog.
> >>
> >> Is it possible to elaborate once more please, what kind of API support
> >> is missing in Reini patch?
> >
> > The intention is to have a useful, properly granular API we can
> > support for a really long time. We'd like to come up with the API that
> > we actually intend to be publicly consumed. The existing function
> > under question wasn't developed with those goals in mind.
>
> This particular function was used in B::C and B::Bytecode since 1995.
That's a neat trick, given the function only dates from 2008.
To be fair, yes, the functionality was in use - see below for what *that*
implies.
> Since Linux/BSD/cygwin does not care about properly exported/not exported
> symbols nobody cares about Windows breakage.
That's not true either.
To my mind the correct fix is to properly not export symbols on Linux too,
which I believe is possible, at least in some cases. I think Rafl had a
look at this at one point, but we didn't find a way to make it work.
I hope we find time to look at it again.
> B::Generate also misses some exported functions from the very beginning on,
> for which I wrote the export patches some time ago. They were also
> warnocked resp. blocked by Nick. It's not my intent to bug p5p again
> and again. Three times is enough for me.
The consistent position is that we're prepared to add functionality as a
proper API if it's documented and tested. IIRC you've consistently stated
that the functions don't belong to the API, and should just be exported for
the private use of the compiler, so you refused to write tests.
If you ignore the feedback, what do you expect?
Secondly, as far as B::Generate goes, several the functions it "wants"
exported are for routines in that could never have worked. Routines in op.c
assume (or assert) that IN_PERL_RUNTIME is false, yet the XS wrappers called
it directly. Requesting changes for code that couldn't even work *with those
changes* is stupid, because it shows that that requester hasn't tested the
change locally.
As far as the patch for this particular function, the timing was unfortunate.
The patch was sent after Jesse had decreed "regressions only", and this
*isn't* a regression from 5.12.0. I don't think it's a regression from 5.10.0
Lack of bug reports is a reasonable indicator that this isn't an important
bug to the vast majority of Perl's userbase. Why should we bend the
maintenance policy for something relatively unimportant?
Looking at the proposed patch is on my (mental) list of things to do, but
not at the top, and as the policy means that it's not valid as a candidate
for 5.14.1. They are the priority for my free time.
> Since these modules are used in production, the maintainer tried to
> support it, but
> CORE still refuses to support it, I can only think of keeping
> maintaining private versions
> of perl. Which I do for myself.
We're not prepared to bend over and give you what you demand. We've offered
you a route, which you refuse to take.
Ad-hoc use of any function that seemed useful, rather that working to create
and update a well-behaved API, has got the perl core into the maintenance
hell that it currently is. We need to stop making those mistakes.
So, to this functionality, the "see below" above. I infer that when the core
saved memory by changing how labels are stored *in 2008*, then the compiler
code was changed to use a function *without checking whether it was part of
the API*. Only years later is a request made for that function to be in the
API, on the basis that "I'm already using it". That's not the way to create
a sane API.
You're welcome to maintain a fork - git should make this easy.
You're also welcome to keep implying that I have a vendetta against the
compiler. For reference:
Jarkko committed the API embedding and exporting changes back in 2002 into
maint-5.8 between 5.8.0 and 5.8.1, and Hugo merged it to blead in 2003
http://rt.perl.org/rt3/Ticket/Display.html?id=8610
http://perl5.git.perl.org/perl.git/commit/de37762f3a9822aa
Rafael removed the compiler from core in 2006
http://perl5.git.perl.org/perl.git/commit/de1254415ffeb03b
Nicholas Clark
Thread Previous
|
Thread Next