Kenneth Graves <[EMAIL PROTECTED]> wrote: > Is load_bytecode supposed to provide "do" semantics (reload the packfile > every time the op is executed) or "require" semantics (load the packfile > only if it hasn't been loaded already)?
It loads the file on each execution of the opcode. But it should really be done only once. I don't know if its up to Parrot to keep track of loaded files. > ... I think the only distinction > at the moment would be whether the extra time of rereading the file is > performed. Might there be an "init" function of some sort called at > load time, or is that better left to the high-level language? Me thinks: HLL should do that. > Load_bytecode "foo.pbc" seems solid now. Load_bytecode "foo.imc" is > still giving me a few problems. > 1) Two instances of C<load_bytecode "stream.imc"> in the same file > causes segmentation fault when returning from the second call into > stream.imc. Shouldn't segfault. But we have first to define, what a second load_bytecode with the same file should do. > 2) C<$P0 = global "_sub_in_the_current_file"> works when running PBC. > When doing a compile&run from PIR, it seg faults. > Should I write tests for these two cases? Always. Yes, very appreciated. > What is the plan for extracting linking information from packfiles? > For the moment, I'm defining a sub "__du" (description unit) that > provides the CLU-specific information my compiler needs. The Eval PMC class (which actually is a PackFile) should have some methods to get at this information at runtime. > My understanding is that the information necessary for PCC calls > (subroutine type, proto/unproto, register types of params and returns > for proto) will be in the packfile within a few versions. What about > other information the higher-level language wants to store (a list of > exceptions thrown, type information beyond register type, typedefs, > constants, etc.)? I'm picturing something like CORBA's IDL, only > hopefully not as ugly. Yeah. We need metadata specs. > --kag leo
