Front page | perl.perl5.porters |
Postings from June 2011
Re: [PATCH] export store_cop_label
Thread Previous
|
Thread Next
From:
Reini Urban
Date:
June 5, 2011 16:16
Subject:
Re: [PATCH] export store_cop_label
Message ID:
BANLkTin8vWoxbHi=TJ3e9LvSME5Z0z8kuQ@mail.gmail.com
2011/5/30 Nicholas Clark <nick@ccl4.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?
I expect to have the limitations being fixed in time.
"In time" means to the next major release, not blocking two major releases.
Currently 5.12 and 5.14 are broken for Windows users at least.
> 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.
Excuse me, B::Generate has a test suite. Which works on Linux and such.
And it is used in useful modules. I see that you don't find it useful and you
claim that they will not work at all. Maybe someone else sees the usefulness
and will fix it.
For the records: optree manipulation should be done at compile-time of course.
Every module I know of uses it at compile-time.
Currently it also works at run-time on non-threaded code without DEBUGGING.
> 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
It's a regression as it worked until 5.10 and does not work since 5.12.
Technically, it was part of the public API before (via a macro in the header),
and was then moved to a private function, thus effectively breaking Windows.
> 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?
Pardon me? "Bending the maintenance policy" is ridiculous.
People want it to be fixed.
What is the timeframe for the outstanding fixes?
Will the fixes be applied to the next minor releases or not?
I know of two B::Generate bugs being ignored by p5p and two compiler bugs
being ignored by p5p for ages - one to two major release cycles.
Windows users certainly lost faith.
> 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.
We know that you failed to address these issues for two last major releases.
I propose that someone else will fix these issues.
I posted patches to be applied. If you don't like them p5p can fix in
any way you see fit.
>> 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.
"You" proposed that route, not "we".
I'm not demanding that "you" fix these issues, I don't care who will fix it.
But they should be fixed.
I offered help, but it was not accepted so far.
> 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*.
Wrong. It was part of the API before, and when it was removed I
complained immediately.
> 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.
Wrong. It's now "years later" because you blocked it for years.
You are also blocking other bugfixes because you don't like it or have no time.
Who can step up now?
> 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
Interesting, it was Rafael not you. I certainly remembered it differently.
http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse2html/perl5-porters/2006-09/msg00230.html?58#mfs
I'm wondering why he was able to remove it without any discussion and
with such a bold statement. Ok, p5p was not able to support it
anymore.
But PAR is by far no comparable solution. PAR makes perl scripts
slower not faster.
--
Reini Urban
Thread Previous
|
Thread Next