Front page | perl.perl5.porters |
Postings from May 2011
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. 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 ld.so hack. JoshThread Previous | Thread Next