[perl #34994] [TODO] make useful parts of Parrot config available at runtime
Leopold Toetsch
# Please include the string: [perl #34994]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34994 >
A Python example first:
$ python
>>> import sys
>>> print sys.maxint
2147483647
>>> help(sys)
...
I'd like to have a similar[1] capability inside Parrot. The general plan
was already discussed, when "make install" came up first.
1) We have F<runtime/parrot/include/config.fpmc>, which is a frozen
image of the config hash generated by F<config_lib.pasm>. Creating the
frozen image needs already parrot (a possibly already existing parrot or
miniparrot in the long run). But locating this file needs the library or
include path, with resides in this file. We got a typical hen and egg
problem.
2) instead of creating e.g. src/revision.c (and possibly other similar
files), we create a C-readable representation of the frozen config hash
and re-link with that file: src/parrot_config.c. Now we have parrot$EXE
with the config inside.
3) "make install" creates src/parrot_config_install.c and links that
into parrot_install$EXE, which during installation becomes
.../bin/parrot$EXE. With this step we get rid of the problem with
runtime vs build directory library usage.
4) at program start the frozen config string gets thawed and we populate
appropriate namespaces[2] with hash entries. Language folks and our
fearless leader may please define the term appropriate :)
5) along with bringing the config online, some cleanup and renaming
wouldn't harm e.g. "iv" vs "opcode_t", "intvalsize" vs "intsize" vs
"opcode_t_size" ...
6) the config information could be available as attributes of the
respective namespace:
ns = getclass "ParrotInterpreter"
PINTVAL_size = ns."INTVAL_size" # getattribute shortcut
or with global namespace ops
PINTVAL_size = find_global "ParrotInterpreter", "INTVAL_size"
Comments, improvements, takers welcome,
leo
[1] w/o Python quirks
>>> sys.maxint = 2
>>> sys.maxint
2
[2] a remark about namespaces
We currently have:
/ (namespace root)
__parrot_core ... MMD multi subs
Integer
Float
.... Parrot PMC class namespaces
The PMC class namespaces should probably reside under "__parrot_core" to
get rid of the namespace pollution. Or alternatively, we prepend two
underscores:
/
__parrot_core
__ParrotInterpreter aka __sys
__ParrotIO aka __io
Leopold Toetsch
[ cc'ed list, so that folks know about takers ]
> On 15 Apr, Leopold Toetsch wrote:
>
> : 5) along with bringing the config online, some cleanup and renaming
> : wouldn't harm e.g. "iv" vs "opcode_t", "intvalsize" vs "intsize" vs
> : "opcode_t_size" ...
>
> This part seems appealing to me, but bear in mind, I've never tampered
> with the Parrot C sources, although I've been heavily involved in other
> C-based projects (GNU coreutils et al.)
That stuff is all in Perl code under the config dir, e.g:
$ find config -type f | xargs grep -w intsize
> And do you have more examples or should I follow my guts?
I think we should have:
INTVAL_t # type of the INTVAL
FLOATVAL_t
INTVAL_size
int_size # native c type
and so on. See also include/parrot/datatypes.h
> Steven
leo
Steven Philip Schubiger
: That stuff is all in Perl code under the config dir, e.g:
:
: $ find config -type f | xargs grep -w intsize
This clarifies some of my unapproved assumptions, although src has
some files containing these keywords too.
: I think we should have:
:
: INTVAL_t # type of the INTVAL
: FLOATVAL_t
: INTVAL_size
: int_size # native c type
:
: and so on. See also include/parrot/datatypes.h
I will.
: leo
Steven
Leopold Toetsch
> 1) We have F<runtime/parrot/include/config.fpmc>, which is a frozen
> image of the config hash generated by F<config_lib.pasm>. Creating the
> frozen image needs already parrot (a possibly already existing parrot or
> miniparrot in the long run). But locating this file needs the library or
> include path, with resides in this file. We got a typical hen and egg
> problem.
>
> 2) instead of creating e.g. src/revision.c (and possibly other similar
> files), we create a C-readable representation of the frozen config hash
> and re-link with that file: src/parrot_config.c. Now we have parrot$EXE
> with the config inside.
[ ... ]
I've started now implementing this. Done so far:
1) make builds first "miniparrot$(EXE)"[1] which links with
src/null_config.o
2) this miniparrot creates the frozen config image
runtime/parrot/include/config.fpmc
3) build_tools/parrot_config_c.pl creates src/parrot_config.c
4) parrot is built, which links with src/parrot_config.o
Next is to make the config available inside parrot.
The runtime path set with Configure --prefix is currently not available.
leo
[1] this isn't really miniparrot, it's all but the config string from
src/parrot_config.c, but it should eventually be miniparrot.
Leopold Toetsch
> 3) "make install" creates src/parrot_config_install.c and links that
> into parrot_install$EXE, which during installation becomes
> .../bin/parrot$EXE. With this step we get rid of the problem with
> runtime vs build directory library usage.
Done (rev 8028), with slightly different files:
installable_parrot$EXE links with src/install_config.o
and
installable_parrot$EXE is installed as $PREFIX/bin/parrot$EXE
This step can be verified (after a make test has run) by:
./parrot t/pmc/config_2.pir # build_dir
./installable_parrot t/pmc/config_2.pir # --prefix dir
and after "make install"
$PREFIX/bin/parrot t/pmc/config_2.pir # same
(The test prints the --prefix pathh from parrot's builtin config hash.)
See also this test, how to currently access the runtime prefix (and
possibly other config items).
More of this TODO ticket:
Leopold Toetsch
If you are embedding or extending Parrot and linked against libparrot
you now have to additionally link with one of:
src/null_config.o
src/parrot_config.o # prefix := build-dir
src/install_config.o # prefix := --prefix dir
leo
Leopold Toetsch
> On Mon May 09 07:36:14 2005, leo wrote:
> > If you are embedding or extending Parrot and linked against libparrot
> > you now have to additionally link with one of:
> >
> > src/null_config.o
> > src/parrot_config.o # prefix := build-dir
> > src/install_config.o # prefix := --prefix dir
>
> we link those into the single shared library and offer some API to
> access this configuration information? Alternately, is it workable to
> encode it as constants in the installed headers somehow?
We tried hard several times to get rid of that, w/o any success.
We wanted to have a path to the config/lib/whatever-add-on-files-for-parrot
inside parrot itself, so that any parrot executables will know to look for
that stuff. An installed and an uninstalled parrot have different library
paths ...
The only scheme we got working is to link with an object file having that path
inside. The extra config info also linked in is just some bonus but not
needed.
leo