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