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 );
