On Fri, 21 Sep 2001, Philippe M . Chiasson wrote:
> Hrm.. interesting. But looking at the underlying implementation, I am really
> curious at the speed trade-off. Having them tied all the time completely
> transparently simplifies a lot of things, like $r->headers_out() doesn't have
> to do anything 'magical' to return a tied hash. just return a apr_table_t *
> and everything else is taken care of.
it's just a thought at the moment to consider, could be that it is not
worthwhile.
> Wich makes me thing about a question I had. If I wanted to implement a piece
> of, say APR::Table->foo() in pure perl, would it be possible ? I don't think
> it is since the .xs and .pm are auto generated ?
if you create xs/APR/Table/Table_pm the contents of that file will be
included in the generated WrapXS/APR/Table/Table.pm
but hopefully we will not need any pure perl :)
> Not what I mean is this :
>
> in xs/typemap:
> OUTPUT
> T_APRTABLEOBJ
> $arg = _mpxs_apr_table_tie(aTHX_ $arg, $var);
>
> INPUT
> T_APRTABLEOBJ
> $var = _mpxs_apr_table_untie(aTHX_ $arg);
well, i suppose we could generate that, $package based on the %typemap
entry name:
OUTPUT
T_APRTABLEOBJ
$arg = mpxs_typemap_output_$package(aTHX_ $arg, $var);
INPUT
T_APRTABLEOBJ
$var = mpxs_typemap_input_$package(aTHX_ $arg);
> And adding
> my %typemap = (
> 'Apache::RequestRec' => 'T_APACHEOBJ',
> 'apr_time_t' => 'T_APR_TIME',
> > 'APR::Table' => 'T_APRTABLEOBJ',
> );
> in ModPerl/WrapXS.pm
>
> It feels a bit to obscure and complicated to me ... I assumed there was a simpler
> way that I didn't know of...
will need the %typemap entry there at least.
> >
> #define mp_xs_sv2_APR__Table(sv) _mpxs_apr_table_untie(aTHX_ sv)
>
> Otherwise it's automagically assumed that the underlying pointer is hidden
> in a simple scalar, not a blessed thing...
oh right. i'll think about that.
> I am not sure I get that... Care to point me a little bit more in the right
>direction ?
you can create a structure where the first member is the "base" type and
the rest can be whatever. this structure can then be cast to the base
type and passed to functions that operate on that type, with extra data
ignored. for example:
typedef struct {
char *name;
} foo_t;
typedef struct {
foo_t *foo; /* "base" structure */
int val; /* extra data */
} my_foo_t;
static void print_name(foo_t *foo)
{
fprintf(stderr, "foo=%s\n", foo->name);
}
static my_foo_t *my_foo_new(void)
{
my_foo_t *my_foo = malloc(sizeof(*my_foo));
my_foo->foo = malloc(sizeof(*my_foo->foo));
return my_foo;
}
int main(int argc, char **argv, char **env)
{
my_foo_t *my_foo = my_foo_new();
foo_t *foo = (foo_t *)my_foo;
foo->name = "bar";
print_name(foo);
return 1;
}
so for apr_table_t you can do something like:
typedef struct {
apr_table_t *table;
foo *nextkey;
bar *iternext;
} modperl_apr_table_t;
> I forgot about the _ prefix, sorry about that. I wish there was a way to identify
> a specific function as 100% private and make sure it's completely ignored by the
> make source_scan
its ok if source_scan picks it up, it'll just be ignored.
> As for the style, I must confess since I knew this patch would not be final,
> I didn't bother going thru every single line double-checking the style ;-p
> I am lazy and not used to the ASF style quite yet.
no problem :)
> Oh, I thought we were relying on some fixes only in perl-devel, so I was only
> testing against 5.7.2-rsync... Is it supposed to work flawlessly with 5.6.1 ?
> If so, I will make sure I test against it.
well, for threaded mpms, 5.8.0 will be prefered over 5.6.1, but we should
still be supporting 5.6.1 in the meantime.
> So, thanks for the feedback, as this was what I was mostly interested in. Really
> surprised that it actually works, but I wanted to know as soon as possible how far
> from the right path I was.
looks like you're on the right path.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
