Hello, now that 0.4.10 has released I would like to merge rt# 41908 which introduces extension guessing. The current implementation does not affect the behavior of existing code. No new test-suite regressions are introduced.
the .load_byte_code op will now accept "foo" trying ".pbc",".pasm",".pir" in order. compatibility with existing code is preserved by trying "foo" as-is first so "foo.pir" will still be preferred over a compiled version in the search paths. I have considered that this functionality may need to be presented in a perl5'ish way. If it is possible for the argument to .load_bytecode to be unquoted then .load_bytecode "foo.pir" # provide the current behavior. .load_bytecode foo # provide the extension guessing similar to perl5 use. As mentioned in the proposals in the RT ticket, PARROT_LOAD_PREFER=compile|source could be used to control whether source or compiled objects are preferred in loading. This allows the development cycle to retain it's scripting interactivity with a single environment variable set, and efficient default (installed) behavior of preferring a compiled object. Note that the latter is how perl5 currently behaves. Future: It may make since for byte-code and shared object loading to be unified in a new interface. An opcode such as .load_module could intelligently load shared objects, byte-code, and source. This could be the path to implementing the API cleanup proposed at the end of rt #41908 , where locating the file, and detecting the type of file is cleanly separated; getting dynext.c out of library.c's internals. This does not necessarily have to replace the existing functions. Cheers, Mike Mattie ([EMAIL PROTECTED])
signature.asc
Description: PGP signature
