Nick Glencross wrote:
Guys,
I shall shortly update the relevant calls, but I'd just like to check
a few things first.
These patches update the patches in #37303 and #36836, relating to
parrot_get_config_string and cygwin dynclasses.
The first patch modifies the parrot VM so as not to call
parrot_get_config_string on startup, which currently resides in the
calling executable. Instead, the executable (optionally) calls
Parrot_set_config_hash to set the config environment.
Looks good.
A couple of questions arise:
* Currently only the interpreter that is explicitly created by the
application will have configuration settings. What's the best way to
make sure that each interpreter will have access to it? Will future
Interpreters clone the environment, or will it explicitly need to be
set on each new interpreter? (If need be, I can preserve the hash in
the VM and seed future interpreters with it)
This question of course arises with a lot more interpreter structures,
the config hash is just one of these. For the config hash my answer is:
config is read-only, non-mutable, therefore it should be created as a
constant, read-only hash, which of course means that keys and values are
also constant and read-only.
The little problem is that we don't have interfaces yet and the
necessary API calls, to create such a hash. Anyway, read-only items can
easily be shared between multiple interpreters and threads.
* The function call parrot_get_config_hash is shared between the
*_config.o object files and the calling executable (but *not* the VM
itself). What's the most suitable header file to declare it in?
There should be just one API call ...
Parrot_set_config_hash (interpreter);
... which calls parrot_get_config_* [1], the prototype should be in embed.h.
[1] It's probably simpler to just return the config bytes and the
length, so that parrot_config.c doesn't need any parrot headers (which
possibly pull in some extern globals like _environ).
That is Parrot_set_config_hash() calls parrot_get_config_bytes, converts
to string, thaws it and sets the config hash.
There was talk the other day about whether install_config.o needed to
be distributed in a dev distribution, and while the answer is still
yes, after these changes it becomes up to the application as to
whether it needs to link with it.
Good.
A solution to the dynclasses on cygwin (and mingw?) [#36836] issue
becomes possible with these patches, and yesterday's shared library
work. Since (as far as I'm aware) cygwin doesn't have rpath
functionality, it is necessary to add blib/lib to the PATH for it to
find the parrot DLL.
Or set LD_LIBRARY_PATH ?
Cheers,
Nick
leo
