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

Reply via email to