Allison and Chip expressed their go-ahead with a .loadlib pragma, to
replace this current use:
.sub foo :immediate
$I0 = loadlib "XXX"
.end
With this:
.loadlib "XXX"
This might be done as part of vsoni's IMCC refactoring, or as a lexer
action that loads the
library as soon as this directive is seen.
In any case, this will let dependency checkers have a much easier
time to figure out what
dynamic libraries a .pir file is loading, without actually have to
invoke Parrot themselves.
Audrey
This apparently isn't quite ready yet, as converting tcl to use the new syntax results in a nearly-
complete fail of the test suite.
Per Audrey: .loadlib 'dynlexpad' stopped working, because Parrot_register_HLL breaks on non-
HLL-group .so files.
Err, t/dynpmc/dynlexpad.t is using .loadlib and is testing fine. Please try to
provide a minimal parrot test showing the problem.
Thanks,
leo
> Err, t/dynpmc/dynlexpad.t is using .loadlib and is testing fine.
> Please try to
> provide a minimal parrot test showing the problem.
Trying (though it remained a bit elusive), but if you "make
realclean", and then change
languages/tcl/src/tclsh.pir so that it uses .loadlib instead
of :immediate, and then
"make", cd into languages/tcl and "make test", you'll notice that all
tests fail with:
# got: 'set_string_keyed() not implemented in class 'TclObject'
# current instr.: '__prepare_lib' pc 19483 (runtime/tcllib.pir:122)
# called from Sub '_main' pc 3 (src/tclsh.pir:42)
Changing it back to :immediate makes tests pass again.
Alternately, skipping the Parrot_register_HLL part in IMCC makes
tests pass again.
Thanks,
Audrey
After several rounds of trial-and-error, I've committed r13294 that
works around the problem:
* Tcl: Change back to .loadlib.
Simply adding this line to tcllib.pir:
.loadlib 'dynlexpad'
appears to fix the problem.
According to leo, .loadlib acts like a dummy HLL, so there is
an order dependency to be observed by .loadlib calls.
This may not be a problem if Parrot_register_HLL_type takes the
HLL name instead of the current max HLL_idx, but the current state
renders this workaround neccessary.
So this ticket is probably good to be closed again, though it still
leaves me somewhat puzzled. :)
Audrey
Regards.
--
Will "Coke" Coleda
wi...@coleda.com
This ticket is over two years old. Does the ".loadlib" pragma work
without problems now? Does it still appear to interact negatively with
the .HLL pragma?
If the .loadlib pragma is implemented and doesn't cause any problems, we
should close this ticket.
--
Andrew Whitworth
a.k.a Whiteknight