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

Re: [PATCH] export store_cop_label

Thread Previous | Thread Next
Joshua ben Jore
May 29, 2011 15:25
Re: [PATCH] export store_cop_label
Message ID:
On Sat, May 28, 2011 at 11:40 PM, Konovalov, Vadim (Vadim)** CTR **
<> 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. We're also
avoiding catering to non-public functions finding use within the
public CPAN. This already happens but it makes life difficult for
release managers. I have APIs I'm violating that probably ought to
become public available. I mostly get by and ignore that this just
won't work on platforms like Windows.

I looked at my heap of steaming CPAN code and it looks like several
additional APIs that don't exist but would need to if the existing
code were to ever transition into using supported APIs.

- closure environment
- stack inspection and manipulation
- rewriting compiled optrees
- injecting debuggers
- memory walking and inspection
- built-in primitive replacement
- a hook into our malloc/free?

I found earlier this year that I would really have appreciated an
ability to hook into perl's memory alloc to take remedial action like
a stack trace in emergencies (the server had accidental infinite
recursion). Maybe I just wasn't clever enough and should have learned
to write an hack.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About