On Mon Apr 30 12:22:21 2007, mdiep wrote: > On Wed Mar 21 03:44:10 2007, codermattie wrote: > > 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. > > I'd like to get this ticket (#41908) resolved. The patch was applied, > so everything is good > there, but your reply here has left me wondering. If there is more to > be done, could you open > another ticket? > > It's better to split off new requests/bugs into new tickets rather > than keep them in the patch > ticket because it cuts down the amount of reading that needs to be > done when sorting > through tickets. The patch itself doesn't seem that relevant that it > couldn't be a separate > ticket.
The discussion of the solution to the install target problem has been split out into a separate ticket: RT#42901 Closing the current ticket.
