Re: stack question

2002-03-08 Thread Stas Bekman
Doug MacEachern wrote: > On Fri, 8 Mar 2002, Stas Bekman wrote: > > >>Doug, >> >>This kind of construct: >> >> int mpxs_Apache__Foo_bar(pTHX_ I32 items, SV **MARK, SV **SP) >> >>is special to WrapXS, isn't it? >> > > dunno if i'd call it special. usage is derived from PP() functions in the

Re: autogenerating .gdbinit

2002-03-08 Thread Doug MacEachern
if you do this, you should coordinate with p5p who was looking to include these macros in the core. and don't forget about Devel::DebugInit. would be great to have a .gdb-perl-macros and .gdb-perl-macros-ithreads, which could then be source-d by a user's .gdbinit

Re: stack question

2002-03-08 Thread Doug MacEachern
On Fri, 8 Mar 2002, Stas Bekman wrote: > Doug, > > This kind of construct: > >int mpxs_Apache__Foo_bar(pTHX_ I32 items, SV **MARK, SV **SP) > > is special to WrapXS, isn't it? dunno if i'd call it special. usage is derived from PP() functions in the perl core. > you cannot really use

autogenerating .gdbinit

2002-03-08 Thread Stas Bekman
I've fixed some of the perl api gdb macros in .gdbinit from modperl-1.x to work with threaded perl. The threaded and non-threaded versions of perl need different gdb macros because of the pTHX_ part in the perl API, which gets scratched for the non-threaded perl. I'm thinking to generate this