>Undetermined which. Is this normal? e.g. I was trying to test
>$r->dir_config->get('key'), and there are a few values for 'key' (added
>via PerlAddVar),
>
>
my @arr = $r->dir_config->get('key');
>>
>>so in the scalar context it brings the first key found and in th
[crossposting docs-dev and dev since I'm not sure whether all those who
can help and care to, are on both lists, and this is a very very
important issue, IMHO of course]
Here is my try on defining the API documentation style, I think it can
help to generate the skeleton automatically, I'll tak
we expose apr_table_overlap() via APR::Table. It needs a definition of
two constants: APR_OVERLAP_TABLES_SET and APR_OVERLAP_TABLES_MERGE. Do
we have them defined somewhere? Should we?
_
Stas Bekman JAm_pH --
On Tue, Sep 25, 2001 at 01:09:48PM +0800, Stas Bekman wrote:
> Philippe M . Chiasson wrote:
>
> > On Mon, Sep 24, 2001 at 09:29:10PM -0400, Geoffrey Young wrote:
> >
> >>>currently we just grab the apr_table_get implementation for
> >>>APR::Table::get(). The problem is that if there is more tha
Philippe M . Chiasson wrote:
> On Mon, Sep 24, 2001 at 09:29:10PM -0400, Geoffrey Young wrote:
>
>>>currently we just grab the apr_table_get implementation for
>>>APR::Table::get(). The problem is that if there is more than one value
>>>added for the same key, get() will return one of these va
On Mon, Sep 24, 2001 at 09:29:10PM -0400, Geoffrey Young wrote:
>
> >currently we just grab the apr_table_get implementation for
> >APR::Table::get(). The problem is that if there is more than one value
> >added for the same key, get() will return one of these values.
>
> in 1.x this is only
>currently we just grab the apr_table_get implementation for
>APR::Table::get(). The problem is that if there is more than one value
>added for the same key, get() will return one of these values.
in 1.x this is only true in a scalar context (and is documented as such in
the Apache::Table doc
currently we just grab the apr_table_get implementation for
APR::Table::get(). The problem is that if there is more than one value
added for the same key, get() will return one of these values.
Undetermined which. Is this normal? e.g. I was trying to test
$r->dir_config->get('key'), and there
Stas Bekman wrote:
> If you follow the docs-cvs mailing list you have noticed that I've been
> working recently on writing the doc on writing tests. The problem is
> that I cannot decide where the documents should go:
>
> On one side we need to have inlined docs of the functions so one can
>
Philippe M . Chiasson wrote:
> On Tue, Sep 25, 2001 at 01:02:18AM +0800, Stas Bekman wrote:
>
>>I'm talking here about having a set of helper functions, that do things
>>like Data::Dumper, per my example function I've sent, to be used mainly
>>during development, when it's not easy to look at
On Tue, Sep 25, 2001 at 01:02:18AM +0800, Stas Bekman wrote:
> Philippe M . Chiasson wrote:
>
> > On Mon, Sep 24, 2001 at 11:48:44PM +0800, Stas Bekman wrote:
> >
> >>Where do we put debug functions? debugger doesn't really help in dumping
> >>complicated data structures like apr_table_t.
>
>
Philippe M . Chiasson wrote:
> On Mon, Sep 24, 2001 at 11:48:44PM +0800, Stas Bekman wrote:
>
>>Where do we put debug functions? debugger doesn't really help in dumping
>>complicated data structures like apr_table_t.
>>I guess I can also think of .gdbinit macro to do the same or even based
>>
Now, this patch should be very close to what it will end up being.
Worth noting now, I generalized the tie'ing mechanism and ended up with:
SV *mpxs_typemap_output_tied()
void *mpxs_typemap_input_tied()
If something else needs a tied interface, output_tied will make a magical tie
On Mon, Sep 24, 2001 at 11:48:44PM +0800, Stas Bekman wrote:
> Where do we put debug functions? debugger doesn't really help in dumping
> complicated data structures like apr_table_t.
>
> For example I wrote the following debug print:
>
> /* dump the values of the table */
> void debug_dump_tab
On Tue, Sep 25, 2001 at 12:31:38AM +0800, Stas Bekman wrote:
> Philippe M . Chiasson wrote:
>
> > On Mon, Sep 24, 2001 at 01:08:47AM +0800, Stas Bekman wrote:
>
> >>cc -I/home/stas/apache.org/gozer/src/modules/perl
> >>-I/home/stas/apache.org/gozer/xs -I/home/stas/httpd/prefork/include
> >>-D_RE
Philippe M . Chiasson wrote:
> On Mon, Sep 24, 2001 at 01:08:47AM +0800, Stas Bekman wrote:
>>cc -I/home/stas/apache.org/gozer/src/modules/perl
>>-I/home/stas/apache.org/gozer/xs -I/home/stas/httpd/prefork/include
>>-D_REENTRANT -DDEBUGGING -fno-strict-aliasing -I/usr/local/include
>>-I/home/sta
Where do we put debug functions? debugger doesn't really help in dumping
complicated data structures like apr_table_t.
For example I wrote the following debug print:
/* dump the values of the table */
void debug_dump_table(apr_table_t *table, char *desc)
{
apr_array_header_t *arr = apr_tab
On Mon, Sep 24, 2001 at 06:00:48PM +0800, Stas Bekman wrote:
> Doug, what's the correct style for #define?
>
> a)
> #define foo \
> bar...
>
> or
>
> b)
> #define foo \
> bar...
>
>
> e.g. in modperl_config.c you have used both:
>
>
> #define merge_item(item) \
> mrg->item = add->i
Doug, what's the correct style for #define?
a)
#define foo \
bar...
or
b)
#define foo \
bar...
e.g. in modperl_config.c you have used both:
#define merge_item(item) \
mrg->item = add->item ? add->item : base->item
#define merge_handlers(merge_flag, array) \
if (merge_flag(mrg
19 matches
Mail list logo
