[Vm-dev] About VMConstruction-Plugins-OSProcessPlugin-dtl.27

[David T. Lewis]

On Wed, Aug 31, 2011 at 02:30:05PM +0200, Igor Stasenko wrote:
>  
> Hello, David
> 
> is it possible to merge with
> VMConstruction-Plugins-OSProcessPlugin.oscog-eem.31 ?
> Since for Cog i using this version.
> I guess there is no functional changes, only pruning/cleaning
> unnecessary stuff, but i want to know for sure.

Hi Igor,

I merged changes from VMConstruction-Plugins-OSProcessPlugin.oscog-eem.32
into VMConstruction-Plugins-OSProcessPlugin-dtl.30, which should be
suitable for use in both Cog and Interpreter VMs.

I did not build a Windows plugin, so if you can let me know if that
builds and runs cleanly I would appreciate any feedback.

Another thing I would appreciate help on is the following, which
apparently should be included in the win32 build:

  #if !defined(STACK_SIZE_PARAM_IS_A_RESERVATION);	
  #define STACK_SIZE_PARAM_IS_A_RESERVATION 0x10000;
  #endif;

In VMConstruction-Plugins-OSProcessPlugin.oscog-eem.31, this is
generated by the slang code, but it would be better if we can
make it part of the build scripts (so I did not include the slang
version in VMConstruction-Plugins-OSProcessPlugin-dtl.30).

Eliot,

The #primitiveGetStd[In|Out|Err]Handle methods are reimplemented
in the oscog branch, but these changes are not correct. See
UnixProcessAccessorTestCase>>testRedirectStdOutTo in the latest
version of OSProcess to illustrate the problem.

A few of the simulation support changes led to issues in trunk
VMMaker and I was too lazy to fix it, so I left these out.
You may need to keep these in an oscog branch for now, but
hopefully I've captured most of the other updates.

If you do keep an oscog branch, there is a lot of obsolete
cruft that you can get rid of by merging back from
VMConstruction-Plugins-OSProcessPlugin-dtl.30. In particular,
there was one patch to signal handling that can go away
because the method was deprecated and has now been removed
from OSPP.

- Dave