About VMConstruction-Plugins-OSProcessPlugin-dtl.27

 
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.

--
Best regards,
Igor Stasenko AKA sig.

 
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 am traveling but will look at this early next week. IIRC, the oscog
branch has some things added that do not work in VMMaker trunk (e.g use
of BytesPerWord, which should now be self bytesPerWord). I'll check and
see if I can merge it, but meanwhile you should probably continue using
the oscog branch with your builds.

Dave

 
On 31 August 2011 17:23, David T. Lewis <[hidden email]> wrote:
Thanks, Dave. It would be nice if we could merge branches and continue
development in a single line,
unless there are compelling reasons for keeping them separate.

> Dave
>


--
Best regards,
Igor Stasenko AKA sig.

 
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