user-configurable site classpath

[GoogleCodeExporter]

Currently there is no easy way to add new site classes to Orc programs
running via the GUI (either on Mac OS X or Windows). To fix this we need
two things:

1. make the site classpath part of the Config object. This implies
Config#setClasspath(String) and Config#loadClass(String name). Anything
which loads sites needs to do so through the configured classloader rather
than the default one.

2. make this a command-line option and also part of orc.gui.ConfigPanel so
that it can be set from the GUI or CLI.

Original issue reported on code.google.com by adrianqu...@gmail.com on 18 Apr 2009 at 9:01

[GoogleCodeExporter]

I'd like this to be a part of the next release so that people can use the Mac 
OS X
and Windows GUI clients to run OrcSites demos.

Original comment by adrianqu...@gmail.com on 21 Apr 2009 at 6:59

• Added labels: Milestone-Next

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

(This is an edited version of a previous comment which I'm deleting.)

This is turning out to be more complicated than I thought. The issue is that 
sites
are currently instantiated willy nilly as needed, for example as early as
typechecking and as late as when a token resolves an argument value. This is
inefficient since sites can be instantiated multiple times, and awkward since 
the
Config object must be passed through all kinds of methods not directly related 
to
instantiating sites.

I think this exposes a fundamental design issue with orc.ast.oil; it is used for
several phases with different requirements: optimization, import and export,
typechecking, and compilation. For example, import and export require that all 
parts
of the AST be serializable (so no instantiated sites or generated types), while 
for
optimization and typechecking you may need such information. My proposed 
long-term
solution:

1. add a new AST representation (I'll call it ast.typed) which replaces ast.oil 
as
the de-facto rich internal representation for optimization, type-checking, and
compilation.

2. add methods to convert from ast.oil to ast.typed and back, so that programs 
can be
imported, optimized, then exported again. Sites are resolved in the
ast.oil->ast.typed transformation.

3. since ast.oil no longer has to support any rich semantics, we can get rid of
ast.oil.xml and make ast.oil directly support XML serialization.

This is a significant refactoring so I want to discuss with David before going 
forward.

In the meantime, I've introduced a band-aid: I added support in ast.oil for
instantiating sites. There is a conceptual ast.oil and ast.typed distinction 
but the
implementation actually shares the same implementation classes for most of 
both, so
it's much easier to screw up and forget to apply the necessary transformation.

Original comment by adrianqu...@gmail.com on 24 Apr 2009 at 11:21

[GoogleCodeExporter]

This is implemented in r1141 for GUI and command line. Need to verify on OS X.

Original comment by adrianqu...@gmail.com on 25 Apr 2009 at 6:36

• Changed state: Fixed

[GoogleCodeExporter]

OK on Mac OS X

Original comment by jthywissen on 3 Mar 2010 at 10:43

• Changed state: Verified