develooper Front page | perl.perl5.porters | Postings from June 2011

Re: [PATCH] export store_cop_label

Thread Previous | Thread Next
From:
Reini Urban
Date:
June 21, 2011 06:12
Subject:
Re: [PATCH] export store_cop_label
Message ID:
BANLkTimLujfnBEWX00nJWt6uimctz9TZOw@mail.gmail.com
Attached is a slightly revised patch. make regen required.

Did not touch global.sym perms
The utf-8 codepoint is now actually utf-8.
Fully exported not just experimental.

This needs to go to blead, 5.14 and 5.12

2011/6/18 Reini Urban <rurban@x-ray.at>:
> 2011/6/13 Jan Dubois <jand@activestate.com>:
>> On Mon, 13 Jun 2011, Nicholas Clark wrote:
>>> On Mon, Jun 13, 2011 at 01:13:38PM -0700, Jan Dubois wrote:
>>> > The issue (as far as I am concerned) is that none of the porters has "blessed"
>>> > the now documented API as something they want to support going forward.  Instead
>>> > I read that Nicholas has a plan to implement a proper API for this kind of
>>> > functionality.  So I think we are all waiting for this to happen.
>>>
>>> What I thought I'd written was that
>>>
>>> a: I got the impression that there were doubts over whether this was a sane
>>>    API (to support indefinitely)(I know that fetch_cop_label changed about a
>>>    year ago - it wasn't "right" the first time)
>>> b: If no-one else gets there first, I was intending to look at it
>>
>> Sorry to put words into your mouth (and thereby kind of volunteering
>> you, when you were still hoping for someone else to get to it first). I
>> guess I need to increase the font size on my browser/email/IRC client.
>>
>>> but
>>>
>>> > Exporting the current symbol in maintenance branches is a completely separate
>>> > issue.  Personally I don't see a big issue with it, as it can't possibly
>>> > break other code; it simply exports an additional symbols that is already
>>> > exported on most platforms anyways, although technically this may not be covered
>>> > by our maintenance policy.  The biggest issues is that it will create
>>> > the expectation that the symbol will continue to be exported in newer releases.
>>> > This should cease to be a problem once the new API materializes.
>>>
>>> c: because the current maint policy that Jesse is working to is strict about
>>>    what can go into a maint branch, and because this change is *not* something
>>>    that the policy permits, then (on the assumption that the policy isn't going
>>>    to change) there wasn't an urgency for me to look at it "yesterday", as not
>>>    looking at this month it does not cause a (further) delay.
>>>
>>> By the current maint policy, this would be for 5.16.0, not for 5.14.anything.
>
> No, I consider it as a regression to be fixed for 5.12 and 5.14.
>
> COP labels could be written until then,
> they where written via the public API in the headers,
> and they are broken since the public macro was rewritten as private function.
>
>> Absolutely.  I was trying to say that when we have a proper solution for 5.16,
>> then there is no longer an expectation that the old symbol would be exported
>> as well.  Therefore it would do little harm in exporting it as-is in older maint
>> versions.  I'm just saying it is not *obvious* if this would be allowable
>> under the current maint policy; it would essentially be a judgement call by Jesse.
>
> Better an unsane API as a removed API at all.
>
> There was only the vague objection from Nick that it is a new API, he
> need to think it over.
> I saw no other objections, I see no technical arguments why it "could"
> be a bad API and I see
> no risks exposing it as there are only two experimental modules using
> it, and I am the
> maintainer of both. So I can adjust to next changes fast.
> Two main releases thinking about it and blocking it hereby is
> definitely too long.
>
> The compiler can not be used for windows users for 5.12 and 5.14.
> The cygwin package has store_cop_label exported (by emulating the linux policy
> -Wl,--export-all-symbols), and I recommend that ActiveState and
> strawberry flip this
> one-char flag also in their subsequent updates for 5.12 an 5.14.
> --
> Reini
>



-- 
Reini Urban
http://phpwiki.org/           http://murbreak.at/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About