Front page | perl.perl5.porters |
Postings from April 2011
RE: [PATCH 5.13.11] make store_cop_label exportable
Thread Previous
|
Thread Next
From:
Konovalov, Vadim ** CTR **
Date:
April 11, 2011 12:39
Subject:
RE: [PATCH 5.13.11] make store_cop_label exportable
Message ID:
35BF8D9716175C43BB9D67CA60CC345E27A82C23@FRMRSSXCHMBSC2.dc-m.alcatel-lucent.com
> From: Jan Dubois
> On Thu, 07 Apr 2011, Konovalov, Vadim (Vadim)** CTR ** wrote:
> > I would like to raise the problem again,
> > at least to hear clear conclusion on this.
>
> It is not a simple yes/no thing... But I guess it should
> receive a public
> answer on the list.
ok, thanks, now its much better :)
>
> > store_cop_label is not exported while it should.
>
> It is not exported because it is not a public API, and it is not used
> by any of the core-specific XS extensions either, so it should not be
> used from CPAN modules at all.
Obviously this B::C CPAN module is too tight related to the CORE, and here its problem.
It just designed to use all perl OP functions.
>
> > A one-bit patch is at
> >
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-03/msg00646.html
>
> That patch is not acceptable. If the API is supposed to be
> available to
> CPAN modules, then it needs to be marked as a public API, needs
> documentation, and ideally also tests. (and BTW, just adding an 'X' in
> embed.fnc is *never* correct; all exported symbols should be either
> 'A', or 'EX'.)
good.
Can you please advice whether "EX" is better - maybe I should work out better patch?
:)
>
> Given the code freeze, and also given that this is not a
> regression from
> 5.12, this is not the right time to make the change to make
> an internal
> API public.
its not regression from 5.12 - where things were broken - but this *is* a regression from 5.6.x (do not know about 5.8) where this function was not existent, so B::C in 5.6 was behaving o-kay.
ok, this will not be included into 5.14. This is no problem.
But please consider, that
- on linux systems, B::C uses this mentioned "store_cop_label" anyway,
despite of fact it is not API-ized (will it ever be?)
- on win32 (and other where this "embed.fnc" server) this place just not work. Please see my other mail on that.
so some things should be done for win32 to be on par with linux again.
Actually, I very much think that this - precompiling of perl modules - is underestimated.
Sometimes people tend to say that compiling perl is faster than thawing its bytecodes,
but I simply do not believe this.
If there will be efficient freeze/thaw of compiled code, significant speedup could be gained, IMHO.
and good applying area is Moose - which is often criticized for its startup time - here could be a good win, if startup code could be done faster.
>
> Furthermore, there first needs to be discussion if this
> really is an API
> that should be made public in its current form in the first
> place (maybe it is, I simply don't know).
this word - "API" - is something that will never be done, I afraid.
Vadim.
Thread Previous
|
Thread Next