On Mar 23, 2007, at 7:51 AM, Mike Mattie wrote:
On Wed, 21 Mar 2007 18:39:51 -0700
Allison Randal <[EMAIL PROTECTED]> wrote:
chromatic wrote:
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.
Actually, I don't believe that it would be that difficult. All that
should need to happen is change which parrot is ran. A
"test_installed" target that isn't dependent on building
parrot(confusing, but think of how the Makefile works) that runs the
installed parrot, and using the local perl modules should suffice. I
imagine it'd be one of the easier parts of a complete installed parrot.
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])
