Re: Automatic generation of API doc ?

2001-10-07 Thread Stas Bekman
Gerald Richter wrote: > I have still some work with the XS generation and generation docs will be > the next step, so it may take a few weeks until the work is done, but as > soon as I have anything to show I will post here so you can comment on it, > if this would be a reasonable way to go. S

Re: ParseSource etc.

2001-10-07 Thread Gerald Richter
> > > These two things would need a extention of the xxx_types.map files. I would > > suggest simply append two addtional (optional) parameters for each line. The > > first holds the name used in the typemap file (%typemap) and the second the > > alias for the sv_convert.h file (%convert) > > all

Re: ParseSource etc.

2001-10-07 Thread Doug MacEachern
On Sun, 7 Oct 2001, Gerald Richter wrote: > I think we could easily remove this line and put the package name for these > three functions in the map file. That would make much more sense to me. If > you agree to that, I will do it and you don't have to take care about it. already taken care of

Re: ParseSource etc.

2001-10-07 Thread Gerald Richter
> > putting some trace statements in there, there's only 3 places where > return_type is actually used: > using Apache::Filter for ap_add_input_filter > using Apache::RequestRec for ap_read_request > using APR::IpSubnet for apr_ipsubnet_create > > i suppose we could probably get by without it, i'l

Re: Automatic generation of API doc ?

2001-10-07 Thread Gerald Richter
Hi Stas, > > I've posted a question about this issue a while ago, but received no answer. > I remembered something, but didn't find it my mail folders anymore > Your proposal is almost perfect. The only flaw it has is that once you > do manual adjustments you cannot use the automatic retri

Re: ParseSource etc.

2001-10-07 Thread Doug MacEachern
On Sun, 7 Oct 2001, Gerald Richter wrote: > I do that anyway, because the first_class method contains other Apache > specific things (like checking for pool). I have done this in many places to > spearate generic code from mod_perl specific. The difference here is, that I > don't understand unde

Re: [patch] automatic available port selection

2001-10-07 Thread Doug MacEachern
On Sun, 7 Oct 2001, Stas Bekman wrote: > I guess I could change the script to do: > > perl Makefile.PL [opts] && make && ./t/TEST -port select yup. or use the APACHE_TEST env var. - To unsubscribe, e-mail: [EMAIL PROTECT

Re: Automatic generation of API doc ?

2001-10-07 Thread Stas Bekman
Gerald Richter wrote: > Hi, > > as some of you have noticed I currently working on mod_perl's XS generation > system. One thing I have done is to replace C::Scan with an parser based on > Parse::RecDescend. One benefit of this is, that it is very easy to extent > what is parsed. So additionaly t

Automatic generation of API doc ?

2001-10-07 Thread Gerald Richter
Hi, as some of you have noticed I currently working on mod_perl's XS generation system. One thing I have done is to replace C::Scan with an parser based on Parse::RecDescend. One benefit of this is, that it is very easy to extent what is parsed. So additionaly to the function and structures I cur

Re: ParseSource etc.

2001-10-07 Thread Gerald Richter
> > > sub first_class { > > couldn't you just override this method to make it do what works best for > dav? > I do that anyway, because the first_class method contains other Apache specific things (like checking for pool). I have done this in many places to spearate generic code from mod_perl spe