Hi,
On Thursday 20 May 2004, Leopold Toetsch wrote:
> I know that's too early to comment much WRT these changes. Could you
> please outline the goals that you want to achieve?
My goal is to replace the path handling code (imcc's include_file,
Parrot_load_bytecode and Parrot_load_lib) with bytecode versions
("parrotlib").
The problem is how to actually load (byte)code without the help of these
functions. Thats why I've added Parrot_load_bytecode_direct. The "not direct"
version can use parrotlib code to locate the specified file by iterating
through a list of "directories" (or better Sub PMCs, as outlined by Dan).
The parrotlib bytecode can be located with the help of parrot's "config
system" (if it is not part of parrotlib), with an hardcoded file location or
maybe even linked directly to parrot on platforms supporting the "exec"
functionality.
> That code following here is for loading C extensions: NCI, dynamic opcode
> libraries and dynamic classes. How will you load these shared libs, when
> you deactivate the loader?
I think it is possible to do the load and init stuff completely with bytecode.
If this is not feasible, the bytecode can at least be used to get the absolute
filename of the library to load.
> But the first problem we have to address is: where is the runtime stuff.
> Your patch just adds one more hardcoded path. We have *first* to do
> something for running parrot{,exe} outside it's build dir, e.g.:
>
> $ cd languages/bf
>
> $ make
> ../../parrot -o bf.pbc bf.pasm
> string_set_data_directory: ICU data files not found(apparently) for \
> directory [blib/lib/icu/2.6.1]make: *** [build] Error 1
Yes, thats one of the problems I want to tackle.
We should IMO hardcode the location of parrot's runtime directory (as
discussed some time ago), and make it overrideable with an environment
variable and command line switch.
Maybe we can also use parrotlib to setup the ICU's data files? I have not
looked at the ICU stuff yet.
Parrotlib has an initialization function that creates an hash with function
names as keys, and signatures as values. If you use
Parrot_library_query(interpreter, "foo", ...)
the hash is used to lookup the signature of "foo", and if one is found the
method with the same name is called with this signature. The return value of
the bytecode function will be the value returned by Parrot_library_query.
Example:
STRING *name = string_from_cstring(...);
name = Parrot_library_query(interpreter, "include_file_location", name);
After this, name will be either a null string (if the file was not found), or
the full name of the given file.
Whether its an absolute or relative path is up in the air...
jens
PS: we need the stat op!
