Jeff Horwitz <[EMAIL PROTECTED]> wrote:
> 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
