On Friday 28 July 2006 07:26, Guest via RT wrote: > This should be fixed now with r13613.
Hm, sort of. Is there any reason not to call it from Parrot_new() and not make the C API users do it? I don't really want to require them to understand the use of packfiles or pull in parrot/packfile.h either. (I don't understand the use of returning a packfile from PackFile_new_dummy() either; is there a reason it's not void?) I applied this patch and things still work. -- c
=== src/embed.c ================================================================== --- src/embed.c (revision 19589) +++ src/embed.c (local) @@ -45,7 +45,13 @@ Parrot_new(Parrot_Interp parent) { /* interpreter.c:make_interpreter builds a new Parrot_Interp. */ - return make_interpreter(parent, PARROT_NO_FLAGS); + Parrot_Interp interp; + struct PackFile *pf; + + interp = make_interpreter(parent, PARROT_NO_FLAGS); + PackFile_new_dummy( interp, "dummy" ); + + return interp; } extern void Parrot_initialize_core_pmcs(Interp *interp); C<signature> denotes the return value. Next chars are arguments. The return value of this function can be void or a pointer type. === t/src/extend.t ================================================================== --- t/src/extend.t (revision 19589) +++ t/src/extend.t (local) @@ -598,15 +598,12 @@ STRING * code_type; STRING * error; STRING * foo_name; - Parrot_PackFile packfile; if (!interp) { printf( "Hiss\n" ); return 1; } - packfile = PackFile_new_dummy(interp, "dummy"); - code_type = const_string( interp, "PIR" ); retval = Parrot_compile_string( interp, code_type, code, &error );