On Wed, 21 Mar 2007 18:39:51 -0700 Allison Randal <[EMAIL PROTECTED]> wrote:
> chromatic wrote:
> >
> > My theory: the "all Parrot developers work from within the tree, so
> > installation paths are either not present or wrong" problem is a
> > big problem.
>
> Agreed. And we don't work from the installation paths because the
> installation paths are broken. Can we break out of this cycle with
> some automated tests for the installed Parrot?
>
> Allison
I have already suggested in a previous mail "the value of a install target"
the goal of making the working copy and the install target exercise the
loader in the same way.
The reason I chose the language: "exercise the loader" was to dodge this testing
bullet.
Expanding the test-suite to cover the install target is alot of work, and
an unpleasant administrative burden to remind and cajole the developers into
passing the install tests; which they may not even care about.
If it was built in a traditional way the test-suite would also have to
be extended as the project grew with coverage testing, it's a vicious cycle :)
The answer is to make a guarantee of a flat search space for modules.
Authors can insert into that search space foo.pir or myproject/foo.pir.
This flat search space needs to be assembled in the *working-copy* and
in the install tree.
In fact parrot does this already !
here is a snip from src/library.c:90
<snip>
entry = CONST_STRING(interp, "runtime/parrot/library/");
VTABLE_push_string(interp, paths, entry);
</snip>
and from src/library.c:94
<snip>
entry = CONST_STRING(interp, "lib/parrot/library/");
VTABLE_push_string(interp, paths, entry);
</snip>
This hack is built-in for the runtime core. What is really missing is a
comprehensive design that de-couples policy (where things go) from
hand-editing source files.
Once this table in library.c is generated from a policy spec, that policy
can either describe what the install should be, _and_ what the working-copy is.
Ideally an author should be able to create
project/main.pir
project/foo/bar/install.spec
project/foo/bar/bar.pbc
project/foo/bar/mystuff/util.pbc
and in main.pir do this:
.load_bytecode "bar"
.load_bytecode "mystuff/util"
and this would work because install.spec ( name doesn't matter at this point )
has specified that the files and directories below are relative to the flat
search space.
Note that ideally the author would simply setup such a install.spec file at the
beginning, update parrot with the new policy, and at that point ignore the
file except occasionally adding/removing pieces to install. Once the path has
been added to the search path list it is a true member of the unified
name-space.
With this scheme the testing is focused on a single point: the loader. The
loader
is significantly enhanced with powerful features integrated into a comprehensive
design. Once that basket is well-built things either load or they don't ,
irrespective
of whether it is installed or not.
In short this will make things work, because things will break for developers
as they
would for users, a isomorphic mapping that sidesteps non-linear growth in the
test-suite.
The key is the design, which unfortunately I don't have the time to put out in
this mail.
I have it in my head, and I will sketch it out in a diagram.
If someone could point me at a suitable related wiki, or other hosting location
where I could
upload a .png diagram, and some text describing the design I have developed I
should be able
to assemble this sometime within the next week or two.
Cheers,
Mike Mattie ([EMAIL PROTECTED])
signature.asc
Description: PGP signature
