On Mon, Jun 09, 2003 at 02:29:38PM -0700, Tim Rowledge wrote:
> 
> > So running OSProcess requires installing 3D support. More annoyingly, 
> > Balloon3D's download location isn't responding to http requests.
> Yes, isn't it annoying to have all that complication?
> 
> Actually I can't quite see why OSProcess would need the vm code but you
> might be right. The VM package needs the Balloon3D stuff for now because
> of the pool dictioanary issue that we have been working on under the
> thread 'Declarative Pools'.

I was a bit worried there for a minute. OSProcess is strictly a 1-D package,
so I was trying to figure out where the dependency on Balloon3D came from ;-)

The problem is that class OSProcessPlugin gets subclassed from ProtoObject
instead of InterpreterPlugin when you try to load OSProcess after the VM
generation removal. Presumably any plugin class would have this problem.

Unfortunately, I violated a cardinal rule of Squeak by trying to document
part of my work. The walkback happens in a change set postscript, which
is attempting to display some documentation about the OSPP plugin, and
chokes when calling methods that it expected to exist in InterpreterPlugin.
Proceed through the debugger notifications, and you'll find that OSProcess
and CommandShell work fine on Squeak 3.6alpha, and pass their SUnit tests.
And of course if you load OSProcess into the 3.6 image with VM generation
tools still in place, there is no problem at all.

Probably it would be a good idea to separate the plugin classes from the
rest of OSProcess to make it easier for folks who want to use just the run
time OSProcess, and don't care about building the plugin.

Dave