embedding/extending issues
Jeff Horwitz
developing mod_parrot. following are the problems i've encountered.
---
i currently get parrot's configuration from config_lib.pasm. however, it
is not readily apparent from the configuration the libraries and flags
required to link with libparrot.a. in particular:
* if linking with ICU, which ICU should we use, and which libraries
and linker flags are required?
* if parrot is linked with libstdc++ behind the scenes (ICU?), it is not
listed in the configuration, so i have to add -lstdc++ manually. i may
just have to get this from ICU's configuration, but i think parrot, like
perl 5 right now, should be able to list all its required dependencies
in one place to make life easier for embedders.
---
many of the functions i need to perform in an embedding environment (PMC
value manipulation, calling parrot subroutines, etc.) are only available
if i include extend.h in addition to embed.h. if these headers are to be
mutually exclusive (i believe they were meant to be), then all the
functionality i just mentioned should be availble to both embedders and
extenders in another "environment neutral" header.
---
there is no NCI signature for (char **), which i need this for calling
ap_get_basic_auth_pw(request_rec *r, char **). 'B', which is (void **)
doesn't seem to work for this situation. the function returns the pointer
to the password in a buffer allocated by apache, and that would have to be
converted to a parrot string. as for the buffer, in mod_parrot's case
memory leaks won't really be a problem here due to apache's memory pools,
but i'd say apache is the exception, not the rule.
right now i have a small C wrapper that calls ap_get_basic_auth_pw and
returns the "parrot stringified" password in a register, but it's not as
clean as it should be. i'm not sure if this is something that can be
fixed for all applications of char **, but it doesn't hurt to ask. :)
---
that's it -- really no *major* problems to report, and that says a lot
about the state of parrot right now.
-jeff
Leopold Toetsch
> dan asked to keep everyone up to date on any issues i've had while
> developing mod_parrot.
Great thanks.
> ... following are the problems i've encountered.
> ---
> i currently get parrot's configuration from config_lib.pasm. however, it
> is not readily apparent from the configuration the libraries and flags
> required to link with libparrot.a. in particular:
If something is missing, we'll add it. Patches welcome. config_lib.pasm
is created by config/gen/config_pm.pl. All keys that have "TEMP_" in
front are skipped.
> many of the functions i need to perform in an embedding environment (PMC
> value manipulation, calling parrot subroutines, etc.) are only available
> if i include extend.h in addition to embed.h.
extend.h is for sure incomplete. But it should only wrap existing
functionality AFAIK. I really don't know how embedding/extending
should look like.
> there is no NCI signature for (char **),
All the non-trivial signatures should be accessible via the
{Un,}ManagedStruct PMCs, albeit I'm not sure, if "char *" is handled. But
pointer to structs are handled as well as the issue, who's the owner of
the struct aka memory freeing. So "char **" is a pointer to a structure
with one element "char *".
There are BTW ugly looking and under-documented special signatures like
"L" or "T", which should be dropped in favor of {Un,}ManagedStructs.
> that's it -- really no *major* problems to report, and that says a lot
> about the state of parrot right now.
Sounds good, thanks for your report.
> -jeff
leo