I am trying to load and run OSProcess in Cog. I loaded:
OSProcess-Base OSProcess-AIO OSProcess-Win32 OSProcess-Unix OSProcess-Tests
Then ran the tests. Many failures.
I looked at the vm and there is no ProcessPlugin or OSProcessPlugin. Should there be?
What should I do?
Thanks, Rob
On Sun, Jul 25, 2010 at 10:59:04AM -0400, Rob Withers wrote:
I am trying to load and run OSProcess in Cog. I loaded:
OSProcess-Base OSProcess-AIO OSProcess-Win32 OSProcess-Unix OSProcess-Tests
Then ran the tests. Many failures.
I looked at the vm and there is no ProcessPlugin or OSProcessPlugin. Should there be?
OSProcess will not work without the OSProcessPlugin. AFAIK no one has tried this yet (including me - sorry I've been quite busy lately).
What should I do?
If you are compiling your own COG VM, then load OSProcessPlugin from SqueakSource and give it a try. But just to set expectations, I will be (pleasantly) surprised if it works the first time without modifications, so consider it pre-alpha at this point.
Dave
-------------------------------------------------- From: "David T. Lewis" lewis@mail.msen.com Sent: Sunday, July 25, 2010 11:58 AM To: "Squeak Virtual Machine Development Discussion" vm-dev@lists.squeakfoundation.org Cc: "Squeak Dev" squeak-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] OSProcess in Cog
On Sun, Jul 25, 2010 at 10:59:04AM -0400, Rob Withers wrote:
I am trying to load and run OSProcess in Cog. I loaded:
OSProcess-Base OSProcess-AIO OSProcess-Win32 OSProcess-Unix OSProcess-Tests
Then ran the tests. Many failures.
I looked at the vm and there is no ProcessPlugin or OSProcessPlugin. Should there be?
OSProcess will not work without the OSProcessPlugin. AFAIK no one has tried this yet (including me - sorry I've been quite busy lately).
What about the AIOPlugin?
What should I do?
If you are compiling your own COG VM, then load OSProcessPlugin from SqueakSource and give it a try. But just to set expectations, I will be (pleasantly) surprised if it works the first time without modifications, so consider it pre-alpha at this point.
I loaded the OSProcessPlugin package and generated sources under Windows. I built using Cygwin. It gave me a Win32OSProcessPlugin.dll.
I ran the tests. It said I don't have the AIOPlugin so it was using polling (I think that is what it said). Tests failed in AioEventHandlerTestCase (failures) and OSPipeTestCase (errors). Many OSPipeTestCase failures have to do with AttachableFileStream being closed.
I tried the following code and it failed because stdout was closed:
ThisOSProcess thisOSProcess openConsole. ThisOSProcess thisOSProcess stdOut nextPutAll: ('error count: ', CryptoDESTest suite run errorCount asString); flush.
Which is what I need OSProcess for.
Another issue: I am trying to generate sources so I can move them from Win32 to Unix and compile the vm there. I cannot run VMMaker on linux - it is headless/no X. I noticed that the OSProcessPlugin generates per platform, and in fact there is platform support code. So under Windows, we generate a Win32OSProcessPlugin. Under Unix I assume it generates a UnixOSProcessPlugin. Is there any way I can generate a UnixOSProcessPlugin under Windows?
Many thanks, Rob
Dave
On Sun, Jul 25, 2010 at 12:24:33PM -0400, Rob Withers wrote:
From: "David T. Lewis" lewis@mail.msen.com Sent: Sunday, July 25, 2010 11:58 AM To: "Squeak Virtual Machine Development Discussion" vm-dev@lists.squeakfoundation.org Cc: "Squeak Dev" squeak-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] OSProcess in Cog
On Sun, Jul 25, 2010 at 10:59:04AM -0400, Rob Withers wrote:
I am trying to load and run OSProcess in Cog. I loaded:
OSProcess-Base OSProcess-AIO OSProcess-Win32 OSProcess-Unix OSProcess-Tests
Then ran the tests. Many failures.
I looked at the vm and there is no ProcessPlugin or OSProcessPlugin. Should there be?
OSProcess will not work without the OSProcessPlugin. AFAIK no one has tried this yet (including me - sorry I've been quite busy lately).
What about the AIOPlugin?
AIOPlugin is Unix only, and totally optional. OSProcess and CommandShell will both work without it.
What should I do?
If you are compiling your own COG VM, then load OSProcessPlugin from SqueakSource and give it a try. But just to set expectations, I will be (pleasantly) surprised if it works the first time without modifications, so consider it pre-alpha at this point.
I loaded the OSProcessPlugin package and generated sources under Windows. I built using Cygwin. It gave me a Win32OSProcessPlugin.dll.
I ran the tests. It said I don't have the AIOPlugin so it was using polling (I think that is what it said). Tests failed in AioEventHandlerTestCase (failures) and OSPipeTestCase (errors). Many OSPipeTestCase failures have to do with AttachableFileStream being closed.
I tried the following code and it failed because stdout was closed:
ThisOSProcess thisOSProcess openConsole. ThisOSProcess thisOSProcess stdOut nextPutAll: ('error count: ', CryptoDESTest suite run errorCount asString); flush.
Which is what I need OSProcess for.
On Windows, you will need to do one hack in order for this to work. In the platforms sources, edit platforms/win32/vm/sqWin32HandleTable.h and disable the handle registry checking. IIRC, you can just hack the IsHandleInTable() function to always return true.
Another issue: I am trying to generate sources so I can move them from Win32 to Unix and compile the vm there. I cannot run VMMaker on linux - it is headless/no X. I noticed that the OSProcessPlugin generates per platform, and in fact there is platform support code. So under Windows, we generate a Win32OSProcessPlugin. Under Unix I assume it generates a UnixOSProcessPlugin. Is there any way I can generate a UnixOSProcessPlugin under Windows?
Open your VMMaker window in Squeak, click the "Find platform" button, and change from "Win32" to "unix". Generate your sources, and you should have the Unix variant of OSProcessPlugin rather than the Windows flavor.
In principle should should work for all of the sources, although I have not tried. It definitely should produce correct Unix sources for OSProcessPlugin, AIOPlugin, and XDisplayControlPlugin (though I don't have a Windows system handy to check).
Note that the handle registry issue mentioned above applies only for building the Windows plugin to run on a Windows platform. There is no such handle registry on Unix and Mac.
Dave
-------------------------------------------------- From: "David T. Lewis" lewis@mail.msen.com Sent: Sunday, July 25, 2010 3:01 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Virtual Machine Development Discussion" vm-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
On Sun, Jul 25, 2010 at 12:24:33PM -0400, Rob Withers wrote:
From: "David T. Lewis" lewis@mail.msen.com Sent: Sunday, July 25, 2010 11:58 AM To: "Squeak Virtual Machine Development Discussion" vm-dev@lists.squeakfoundation.org Cc: "Squeak Dev" squeak-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] OSProcess in Cog
On Sun, Jul 25, 2010 at 10:59:04AM -0400, Rob Withers wrote:
I am trying to load and run OSProcess in Cog. I loaded:
OSProcess-Base OSProcess-AIO OSProcess-Win32 OSProcess-Unix OSProcess-Tests
Then ran the tests. Many failures.
I looked at the vm and there is no ProcessPlugin or OSProcessPlugin. Should there be?
OSProcess will not work without the OSProcessPlugin. AFAIK no one has tried this yet (including me - sorry I've been quite busy lately).
What about the AIOPlugin?
AIOPlugin is Unix only, and totally optional. OSProcess and CommandShell will both work without it.
I see. I am including in hopes that I get the cross-platform thing working for unix.
What should I do?
If you are compiling your own COG VM, then load OSProcessPlugin from SqueakSource and give it a try. But just to set expectations, I will be (pleasantly) surprised if it works the first time without modifications, so consider it pre-alpha at this point.
I loaded the OSProcessPlugin package and generated sources under Windows. I built using Cygwin. It gave me a Win32OSProcessPlugin.dll.
I ran the tests. It said I don't have the AIOPlugin so it was using polling (I think that is what it said). Tests failed in AioEventHandlerTestCase (failures) and OSPipeTestCase (errors). Many OSPipeTestCase failures have to do with AttachableFileStream being closed.
I tried the following code and it failed because stdout was closed:
ThisOSProcess thisOSProcess openConsole. ThisOSProcess thisOSProcess stdOut nextPutAll: ('error count: ', CryptoDESTest suite run errorCount asString); flush.
Which is what I need OSProcess for.
On Windows, you will need to do one hack in order for this to work. In the platforms sources, edit platforms/win32/vm/sqWin32HandleTable.h and disable the handle registry checking. IIRC, you can just hack the IsHandleInTable() function to always return true.
I did this, recompiled, launched Cog with my test image, and I am still getting the same failures and errors.
Another issue: I am trying to generate sources so I can move them from Win32 to Unix and compile the vm there. I cannot run VMMaker on linux - it is headless/no X. I noticed that the OSProcessPlugin generates per platform, and in fact there is platform support code. So under Windows, we generate a Win32OSProcessPlugin. Under Unix I assume it generates a UnixOSProcessPlugin. Is there any way I can generate a UnixOSProcessPlugin under Windows?
Open your VMMaker window in Squeak, click the "Find platform" button, and change from "Win32" to "unix". Generate your sources, and you should have the Unix variant of OSProcessPlugin rather than the Windows flavor.
First thing is Cog doesn't use the window, it uses this script:
(VMMaker generate: CoInterpreter to: (FileDirectory default / '..\src') fullName platformDir: (FileDirectory default / '..\platforms') fullName excluding:#(BrokenPlugin IA32ABIPluginSimulator SlangTestPlugin TestOSAPlugin))
Second, I tried using the window, changes the intepreterClass to 'CoInterpreter', set the platform path, set the sources path, and clicked "Find platform" and selected "unix". This did not change the text entry value.
Third, I set self halts in UnixOSProcessPlugin class>>#shouldBeTranslated and Win32OSProcessPlugin class>>#shouldBeTranslated. The unix side eventually calls:
UnixOSProcessPlugin class>>#isResponsibleForThisPlatform "Answer true is this is an instance of the class which is responsible for representing the OS process for the Squeak VM running on the current platform. A false answer is usually the result of running the image on a different platform and VM. Note: Keep this method is sync with OSProcess>>isUnix."
| numericOsVersion |
^ (self platformName = 'unix') or: [numericOsVersion := self osVersion asInteger ifNil: [0]. (self platformName = 'Mac OS') and: [numericOsVersion >= 1000]]
and this calls:
OSProcessPlugin class>>#platformName "After Squeak version 3.6, #platformName was moved to SmalltalkImage "
^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk platformName]) current platformName
which kills any hope of being a cross-compiled source.
I would really like to fix the Win32 bugs first. Could you help me with that?
Thanks, Rob
In principle should should work for all of the sources, although I have not tried. It definitely should produce correct Unix sources for OSProcessPlugin, AIOPlugin, and XDisplayControlPlugin (though I don't have a Windows system handy to check).
Note that the handle registry issue mentioned above applies only for building the Windows plugin to run on a Windows platform. There is no such handle registry on Unix and Mac.
Dave
On Sun, Jul 25, 2010 at 11:01:12PM -0400, Rob Withers wrote:
From: "David T. Lewis" lewis@mail.msen.com Sent: Sunday, July 25, 2010 3:01 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Virtual Machine Development Discussion" vm-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
On Sun, Jul 25, 2010 at 12:24:33PM -0400, Rob Withers wrote:
From: "David T. Lewis" lewis@mail.msen.com Sent: Sunday, July 25, 2010 11:58 AM To: "Squeak Virtual Machine Development Discussion" vm-dev@lists.squeakfoundation.org Cc: "Squeak Dev" squeak-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] OSProcess in Cog
On Sun, Jul 25, 2010 at 10:59:04AM -0400, Rob Withers wrote:
I am trying to load and run OSProcess in Cog. I loaded:
OSProcess-Base OSProcess-AIO OSProcess-Win32 OSProcess-Unix OSProcess-Tests
Then ran the tests. Many failures.
I looked at the vm and there is no ProcessPlugin or OSProcessPlugin. Should there be?
OSProcess will not work without the OSProcessPlugin. AFAIK no one has tried this yet (including me - sorry I've been quite busy lately).
What about the AIOPlugin?
AIOPlugin is Unix only, and totally optional. OSProcess and CommandShell will both work without it.
I see. I am including in hopes that I get the cross-platform thing working for unix.
What should I do?
If you are compiling your own COG VM, then load OSProcessPlugin from SqueakSource and give it a try. But just to set expectations, I will be (pleasantly) surprised if it works the first time without modifications, so consider it pre-alpha at this point.
I loaded the OSProcessPlugin package and generated sources under Windows. I built using Cygwin. It gave me a Win32OSProcessPlugin.dll.
I ran the tests. It said I don't have the AIOPlugin so it was using polling (I think that is what it said). Tests failed in AioEventHandlerTestCase (failures) and OSPipeTestCase (errors). Many OSPipeTestCase failures have to do with AttachableFileStream being closed.
I tried the following code and it failed because stdout was closed:
ThisOSProcess thisOSProcess openConsole. ThisOSProcess thisOSProcess stdOut nextPutAll: ('error count: ', CryptoDESTest suite run errorCount asString); flush.
Which is what I need OSProcess for.
On Windows, you will need to do one hack in order for this to work. In the platforms sources, edit platforms/win32/vm/sqWin32HandleTable.h and disable the handle registry checking. IIRC, you can just hack the IsHandleInTable() function to always return true.
I did this, recompiled, launched Cog with my test image, and I am still getting the same failures and errors.
Another issue: I am trying to generate sources so I can move them from Win32 to Unix and compile the vm there. I cannot run VMMaker on linux - it is headless/no X. I noticed that the OSProcessPlugin generates per platform, and in fact there is platform support code. So under Windows, we generate a Win32OSProcessPlugin. Under Unix I assume it generates a UnixOSProcessPlugin. Is there any way I can generate a UnixOSProcessPlugin under Windows?
Open your VMMaker window in Squeak, click the "Find platform" button, and change from "Win32" to "unix". Generate your sources, and you should have the Unix variant of OSProcessPlugin rather than the Windows flavor.
First thing is Cog doesn't use the window, it uses this script:
(VMMaker generate: CoInterpreter to: (FileDirectory default / '..\src') fullName platformDir: (FileDirectory default / '..\platforms') fullName excluding:#(BrokenPlugin IA32ABIPluginSimulator SlangTestPlugin TestOSAPlugin))
Second, I tried using the window, changes the intepreterClass to 'CoInterpreter', set the platform path, set the sources path, and clicked "Find platform" and selected "unix". This did not change the text entry value.
Third, I set self halts in UnixOSProcessPlugin class>>#shouldBeTranslated and Win32OSProcessPlugin class>>#shouldBeTranslated. The unix side eventually calls:
UnixOSProcessPlugin class>>#isResponsibleForThisPlatform "Answer true is this is an instance of the class which is responsible for representing the OS process for the Squeak VM running on the current platform. A false answer is usually the result of running the image on a different platform and VM. Note: Keep this method is sync with OSProcess>>isUnix."
| numericOsVersion |
^ (self platformName = 'unix') or: [numericOsVersion := self osVersion asInteger ifNil: [0]. (self platformName = 'Mac OS') and: [numericOsVersion >= 1000]]
and this calls:
OSProcessPlugin class>>#platformName "After Squeak version 3.6, #platformName was moved to SmalltalkImage "
^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk platformName]) current platformName
which kills any hope of being a cross-compiled source.
No worries there. The C source is not supposed to be cross-compiled. The implementations in Slang/Smalltalk are completely different for Unix and Windows, and the resulting generated code (UnixOSProcessPlugin.c and Win32OSProcessPlugin.c respectively) are completely different as well. When building a VM to run on Unix/Linux/OSX you would be compiling the UnixOSProcessPlugin.c, and when compiling a VM for Windows you would compile Win32OSProcessPlugin.c.
I checked that generating the Windows plugin source from a Linux machine using VMMakerTool (from VMMaker-dtl.183) works as expected. I am not able to test the Windows host generating Unix plugin source (I am away on vacation with limited time for Squeak), but I certainly expect that to work also.
The most likely explanation is that the new CrossPlatformVMMaker in the Cog VMMaker package does not know that OSPP is trying to generate different sources for different target platforms, so this mechanism no longer works.
Short term you can probably work around the issue by editing the #shouldBeTranslated and #shouldBeTranslatedFor: methods in UnixOSProcessPlugin and Win32OSProcessPlugin.
I would really like to fix the Win32 bugs first. Could you help me with that?
I cannot help right now, but hopefully others can step forward with suggestions.
Dave
Hi David,
On Mon, Jul 26, 2010 at 7:13 AM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 25, 2010 at 11:01:12PM -0400, Rob Withers wrote:
From: "David T. Lewis" lewis@mail.msen.com Sent: Sunday, July 25, 2010 3:01 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Virtual Machine Development Discussion" vm-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
On Sun, Jul 25, 2010 at 12:24:33PM -0400, Rob Withers wrote:
From: "David T. Lewis" lewis@mail.msen.com Sent: Sunday, July 25, 2010 11:58 AM To: "Squeak Virtual Machine Development Discussion" vm-dev@lists.squeakfoundation.org Cc: "Squeak Dev" squeak-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] OSProcess in Cog
On Sun, Jul 25, 2010 at 10:59:04AM -0400, Rob Withers wrote:
I am trying to load and run OSProcess in Cog. I loaded:
OSProcess-Base OSProcess-AIO OSProcess-Win32 OSProcess-Unix OSProcess-Tests
Then ran the tests. Many failures.
I looked at the vm and there is no ProcessPlugin or OSProcessPlugin. Should there be?
OSProcess will not work without the OSProcessPlugin. AFAIK no one has tried this yet (including me - sorry I've been quite busy lately).
What about the AIOPlugin?
AIOPlugin is Unix only, and totally optional. OSProcess and CommandShell will both work without it.
I see. I am including in hopes that I get the cross-platform thing
working
for unix.
What should I do?
If you are compiling your own COG VM, then load OSProcessPlugin from SqueakSource and give it a try. But just to set expectations, I will be (pleasantly) surprised if it works the first time without modifications, so consider it pre-alpha at this point.
I loaded the OSProcessPlugin package and generated sources under
Windows.
I built using Cygwin. It gave me a Win32OSProcessPlugin.dll.
I ran the tests. It said I don't have the AIOPlugin so it was using polling (I think that is what it said). Tests failed in AioEventHandlerTestCase (failures) and OSPipeTestCase (errors). Many OSPipeTestCase failures have to do with AttachableFileStream being closed.
I tried the following code and it failed because stdout was closed:
ThisOSProcess thisOSProcess openConsole. ThisOSProcess thisOSProcess stdOut nextPutAll: ('error count: ', CryptoDESTest suite run errorCount asString); flush.
Which is what I need OSProcess for.
On Windows, you will need to do one hack in order for this to work. In the platforms sources, edit platforms/win32/vm/sqWin32HandleTable.h and disable the handle registry checking. IIRC, you can just hack the IsHandleInTable() function to always return true.
I did this, recompiled, launched Cog with my test image, and I am still getting the same failures and errors.
Another issue: I am trying to generate sources so I can move them from Win32 to Unix and compile the vm there. I cannot run VMMaker on linux
it is headless/no X. I noticed that the OSProcessPlugin generates per platform, and in fact there is platform support code. So under
Windows,
we generate a Win32OSProcessPlugin. Under Unix I assume it generates a UnixOSProcessPlugin. Is there any way I can generate a UnixOSProcessPlugin under Windows?
Open your VMMaker window in Squeak, click the "Find platform" button, and change from "Win32" to "unix". Generate your sources, and you should have the Unix variant of OSProcessPlugin rather than the Windows flavor.
First thing is Cog doesn't use the window, it uses this script:
(VMMaker generate: CoInterpreter to: (FileDirectory default / '..\src') fullName platformDir: (FileDirectory default / '..\platforms') fullName excluding:#(BrokenPlugin IA32ABIPluginSimulator SlangTestPlugin TestOSAPlugin))
Second, I tried using the window, changes the intepreterClass to 'CoInterpreter', set the platform path, set the sources path, and clicked "Find platform" and selected "unix". This did not change the text entry value.
Third, I set self halts in UnixOSProcessPlugin class>>#shouldBeTranslated and Win32OSProcessPlugin class>>#shouldBeTranslated. The unix side eventually calls:
UnixOSProcessPlugin class>>#isResponsibleForThisPlatform "Answer true is this is an instance of the class which is responsible for representing the OS process for the Squeak VM running on the current platform. A false answer is usually the result of running the image on a different platform and VM. Note: Keep this method is sync with OSProcess>>isUnix."
| numericOsVersion | ^ (self platformName = 'unix') or: [numericOsVersion := self osVersion asInteger ifNil: [0]. (self platformName = 'Mac OS') and: [numericOsVersion >= 1000]]
and this calls:
OSProcessPlugin class>>#platformName "After Squeak version 3.6, #platformName was moved to
SmalltalkImage
" ^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk platformName]) current platformName
which kills any hope of being a cross-compiled source.
No worries there. The C source is not supposed to be cross-compiled. The implementations in Slang/Smalltalk are completely different for Unix and Windows, and the resulting generated code (UnixOSProcessPlugin.c and Win32OSProcessPlugin.c respectively) are completely different as well. When building a VM to run on Unix/Linux/OSX you would be compiling the UnixOSProcessPlugin.c, and when compiling a VM for Windows you would compile Win32OSProcessPlugin.c.
Cross-compilation is quite separate from generation. Cog is intentionally modified to spit out exactly the same source tree irrespective of platform. Needing a different VMMaker generation step for each platform is IMO an absurdity. Whether a plugin is compiled or not then depends on the plugins.int and plugins.ext files in each build directory. So the intent is to always spit out the UnixOSProcessPlugin source but only compile it on Unix platforms, as selected by plugins.int & plugins.ext.
I notice I've not included my version of Win32OSProcessPlugin in Cog. I'll rectify that this evening.
I checked that generating the Windows plugin source from a Linux
machine using VMMakerTool (from VMMaker-dtl.183) works as expected. I am not able to test the Windows host generating Unix plugin source (I am away on vacation with limited time for Squeak), but I certainly expect that to work also.
The most likely explanation is that the new CrossPlatformVMMaker in the Cog VMMaker package does not know that OSPP is trying to generate different sources for different target platforms, so this mechanism no longer works.
See above.
Short term you can probably work around the issue by editing the #shouldBeTranslated and #shouldBeTranslatedFor: methods in UnixOSProcessPlugin and Win32OSProcessPlugin.
I would really like to fix the Win32 bugs first. Could you help me with that?
I cannot help right now, but hopefully others can step forward with suggestions.
Dave
HTH Eliot
On Mon, Jul 26, 2010 at 11:21:10AM -0700, Eliot Miranda wrote:
On Mon, Jul 26, 2010 at 7:13 AM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 25, 2010 at 11:01:12PM -0400, Rob Withers wrote:
<snip>
Third, I set self halts in UnixOSProcessPlugin class>>#shouldBeTranslated and Win32OSProcessPlugin class>>#shouldBeTranslated. The unix side eventually calls:
UnixOSProcessPlugin class>>#isResponsibleForThisPlatform "Answer true is this is an instance of the class which is responsible for representing the OS process for the Squeak VM running on the current platform. A false answer is usually the result of running the image on a different platform and VM. Note: Keep this method is sync with OSProcess>>isUnix."
| numericOsVersion | ^ (self platformName = 'unix') or: [numericOsVersion := self osVersion asInteger ifNil: [0]. (self platformName = 'Mac OS') and: [numericOsVersion >= 1000]]
and this calls:
OSProcessPlugin class>>#platformName "After Squeak version 3.6, #platformName was moved to
SmalltalkImage
" ^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk platformName]) current platformName
which kills any hope of being a cross-compiled source.
No worries there. The C source is not supposed to be cross-compiled. The implementations in Slang/Smalltalk are completely different for Unix and Windows, and the resulting generated code (UnixOSProcessPlugin.c and Win32OSProcessPlugin.c respectively) are completely different as well. When building a VM to run on Unix/Linux/OSX you would be compiling the UnixOSProcessPlugin.c, and when compiling a VM for Windows you would compile Win32OSProcessPlugin.c.
Cross-compilation is quite separate from generation. Cog is intentionally modified to spit out exactly the same source tree irrespective of platform.
Understood.
Needing a different VMMaker generation step for each platform is IMO an absurdity. Whether a plugin is compiled or not then depends on the plugins.int and plugins.ext files in each build directory. So the intent is to always spit out the UnixOSProcessPlugin source but only compile it on Unix platforms, as selected by plugins.int & plugins.ext.
I notice I've not included my version of Win32OSProcessPlugin in Cog. I'll rectify that this evening.
I updated OSProcessPlugin, AioPlugin, and XDisplayControlPlugin to work properly with CrossPlatformVMMaker, and to continue working as before with the traditional VMMakerTool. This lets CrossPlatformVMMaker produce the expected sources for Win32OSProcessPlugin and UnixOSProcessPlugin, and should result in all of these being generated when running Squeak on Windows.
www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.23 www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-dtl.10 www.squeaksource.com/XDCP/VMConstruction-Plugins-XDisplayControlPlugin-dtl.8
Dave
Thanks, David, I was able to generate unix plugins on Windows and build them on unix.
I am still having problems outputting to stdOut on both unix and Windows. I cannot tell the issue on unix since I am headless. On Windows it complains that stdOut accessor is closed. Here is the script I am using in both cases:
ThisOSProcess thisOSProcess stdOut nextPutAll: 'hello world'; flush.
Is the something I need to be doing to open the accessors before using them?
Thanks, Rob
-------------------------------------------------- From: "David T. Lewis" lewis@mail.msen.com Sent: Monday, July 26, 2010 11:31 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
On Mon, Jul 26, 2010 at 11:21:10AM -0700, Eliot Miranda wrote:
On Mon, Jul 26, 2010 at 7:13 AM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 25, 2010 at 11:01:12PM -0400, Rob Withers wrote:
<snip>
Third, I set self halts in UnixOSProcessPlugin class>>#shouldBeTranslated and Win32OSProcessPlugin class>>#shouldBeTranslated. The unix side eventually calls:
UnixOSProcessPlugin class>>#isResponsibleForThisPlatform "Answer true is this is an instance of the class which is responsible for representing the OS process for the Squeak VM running on the current platform. A false answer is usually the result of running the image on a different platform and VM. Note: Keep this method is sync with OSProcess>>isUnix."
| numericOsVersion | ^ (self platformName = 'unix') or: [numericOsVersion := self osVersion asInteger ifNil:
[0]. (self platformName = 'Mac OS') and: [numericOsVersion
=
1000]]
and this calls:
OSProcessPlugin class>>#platformName "After Squeak version 3.6, #platformName was moved to
SmalltalkImage
" ^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk platformName]) current platformName
which kills any hope of being a cross-compiled source.
No worries there. The C source is not supposed to be cross-compiled. The implementations in Slang/Smalltalk are completely different for Unix and Windows, and the resulting generated code (UnixOSProcessPlugin.c and Win32OSProcessPlugin.c respectively) are completely different as well. When building a VM to run on Unix/Linux/OSX you would be compiling the UnixOSProcessPlugin.c, and when compiling a VM for Windows you would compile Win32OSProcessPlugin.c.
Cross-compilation is quite separate from generation. Cog is intentionally modified to spit out exactly the same source tree irrespective of platform.
Understood.
Needing a different VMMaker generation step for each platform is IMO an absurdity. Whether a plugin is compiled or not then depends on the plugins.int and plugins.ext files in each build directory. So the intent is to always spit out the UnixOSProcessPlugin source but only compile it on Unix platforms, as selected by plugins.int & plugins.ext.
I notice I've not included my version of Win32OSProcessPlugin in Cog. I'll rectify that this evening.
I updated OSProcessPlugin, AioPlugin, and XDisplayControlPlugin to work properly with CrossPlatformVMMaker, and to continue working as before with the traditional VMMakerTool. This lets CrossPlatformVMMaker produce the expected sources for Win32OSProcessPlugin and UnixOSProcessPlugin, and should result in all of these being generated when running Squeak on Windows.
www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.23 www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-dtl.10
www.squeaksource.com/XDCP/VMConstruction-Plugins-XDisplayControlPlugin-dtl.8
Dave
This is probably because of the Windows handle registry that I mentioned earlier in this thread. You will need to disable the handle check.
What is happening here is that the FilePlugin (on Windows) is maintaining a registry of valid handles, and it only recognizes handles created by itself as valid. When OSProcess gives it some other handle (e.g. the handle for standard output or for an OS pipe handle) the primitives in FilePlugin will fail. This is a feature that was added to Windows FilePlugin some time after I wrote the Windows OSProcess stuff (long ago), and for now the workaround is just to disable the registry check.
Dave
On Tue, Jul 27, 2010 at 03:47:02AM -0400, Rob Withers wrote:
Thanks, David, I was able to generate unix plugins on Windows and build them on unix.
I am still having problems outputting to stdOut on both unix and Windows. I cannot tell the issue on unix since I am headless. On Windows it complains that stdOut accessor is closed. Here is the script I am using in both cases:
ThisOSProcess thisOSProcess stdOut nextPutAll: 'hello world'; flush.
Is the something I need to be doing to open the accessors before using them?
Thanks, Rob
From: "David T. Lewis" lewis@mail.msen.com Sent: Monday, July 26, 2010 11:31 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
On Mon, Jul 26, 2010 at 11:21:10AM -0700, Eliot Miranda wrote:
On Mon, Jul 26, 2010 at 7:13 AM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 25, 2010 at 11:01:12PM -0400, Rob Withers wrote:
<snip>
Third, I set self halts in UnixOSProcessPlugin class>>#shouldBeTranslated and Win32OSProcessPlugin class>>#shouldBeTranslated. The unix side eventually calls:
UnixOSProcessPlugin class>>#isResponsibleForThisPlatform "Answer true is this is an instance of the class which is responsible for representing the OS process for the Squeak VM running on the current platform. A false answer is usually the result of running the image on a different platform and VM. Note: Keep this method is sync with OSProcess>>isUnix."
| numericOsVersion | ^ (self platformName = 'unix') or: [numericOsVersion := self osVersion asInteger ifNil:
[0]. (self platformName = 'Mac OS') and: [numericOsVersion
=
1000]]
and this calls:
OSProcessPlugin class>>#platformName "After Squeak version 3.6, #platformName was moved to
SmalltalkImage
" ^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk platformName]) current platformName
which kills any hope of being a cross-compiled source.
No worries there. The C source is not supposed to be cross-compiled. The implementations in Slang/Smalltalk are completely different for Unix and Windows, and the resulting generated code (UnixOSProcessPlugin.c and Win32OSProcessPlugin.c respectively) are completely different as well. When building a VM to run on Unix/Linux/OSX you would be compiling the UnixOSProcessPlugin.c, and when compiling a VM for Windows you would compile Win32OSProcessPlugin.c.
Cross-compilation is quite separate from generation. Cog is intentionally modified to spit out exactly the same source tree irrespective of platform.
Understood.
Needing a different VMMaker generation step for each platform is IMO an absurdity. Whether a plugin is compiled or not then depends on the plugins.int and plugins.ext files in each build directory. So the intent is to always spit out the UnixOSProcessPlugin source but only compile it on Unix platforms, as selected by plugins.int & plugins.ext.
I notice I've not included my version of Win32OSProcessPlugin in Cog. I'll rectify that this evening.
I updated OSProcessPlugin, AioPlugin, and XDisplayControlPlugin to work properly with CrossPlatformVMMaker, and to continue working as before with the traditional VMMakerTool. This lets CrossPlatformVMMaker produce the expected sources for Win32OSProcessPlugin and UnixOSProcessPlugin, and should result in all of these being generated when running Squeak on Windows.
www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.23 www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-dtl.10
www.squeaksource.com/XDCP/VMConstruction-Plugins-XDisplayControlPlugin-dtl.8
Dave
Ok. I thought I had done this as you asked, but perhaps I regenerated and it overwrote this again. I'll check tonight, after work.
Thanks, Rob
-------------------------------------------------- From: "David T. Lewis" lewis@mail.msen.com Sent: Tuesday, July 27, 2010 9:09 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
This is probably because of the Windows handle registry that I mentioned earlier in this thread. You will need to disable the handle check.
What is happening here is that the FilePlugin (on Windows) is maintaining a registry of valid handles, and it only recognizes handles created by itself as valid. When OSProcess gives it some other handle (e.g. the handle for standard output or for an OS pipe handle) the primitives in FilePlugin will fail. This is a feature that was added to Windows FilePlugin some time after I wrote the Windows OSProcess stuff (long ago), and for now the workaround is just to disable the registry check.
Dave
On Tue, Jul 27, 2010 at 03:47:02AM -0400, Rob Withers wrote:
Thanks, David, I was able to generate unix plugins on Windows and build them on unix.
I am still having problems outputting to stdOut on both unix and Windows. I cannot tell the issue on unix since I am headless. On Windows it complains that stdOut accessor is closed. Here is the script I am using in both cases:
ThisOSProcess thisOSProcess stdOut nextPutAll: 'hello world'; flush.
Is the something I need to be doing to open the accessors before using them?
Thanks, Rob
From: "David T. Lewis" lewis@mail.msen.com Sent: Monday, July 26, 2010 11:31 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
On Mon, Jul 26, 2010 at 11:21:10AM -0700, Eliot Miranda wrote:
On Mon, Jul 26, 2010 at 7:13 AM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 25, 2010 at 11:01:12PM -0400, Rob Withers wrote:
<snip>
Third, I set self halts in UnixOSProcessPlugin class>>#shouldBeTranslated and Win32OSProcessPlugin class>>#shouldBeTranslated. The unix side eventually calls:
UnixOSProcessPlugin class>>#isResponsibleForThisPlatform "Answer true is this is an instance of the class which is responsible for representing the OS process for the Squeak VM running on the current platform. A false answer is usually the result of running the image on a different platform and VM. Note: Keep this method is sync with OSProcess>>isUnix."
| numericOsVersion | ^ (self platformName = 'unix') or: [numericOsVersion := self osVersion asInteger ifNil:
[0]. (self platformName = 'Mac OS') and: [numericOsVersion >= 1000]]
and this calls:
OSProcessPlugin class>>#platformName "After Squeak version 3.6, #platformName was moved to
SmalltalkImage
" ^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk platformName]) current
platformName
which kills any hope of being a cross-compiled source.
No worries there. The C source is not supposed to be cross-compiled. The implementations in Slang/Smalltalk are completely different for Unix and Windows, and the resulting generated code (UnixOSProcessPlugin.c and Win32OSProcessPlugin.c respectively) are completely different as well. When building a VM to run on Unix/Linux/OSX you would be compiling the UnixOSProcessPlugin.c, and when compiling a VM for Windows you would compile Win32OSProcessPlugin.c.
Cross-compilation is quite separate from generation. Cog is intentionally modified to spit out exactly the same source tree irrespective of platform.
Understood.
Needing a different VMMaker generation step for each platform is IMO an absurdity. Whether a plugin is compiled or not then depends on the plugins.int and plugins.ext files in each build directory. So the intent is to always spit out the UnixOSProcessPlugin source but only compile it on Unix platforms, as selected by plugins.int & plugins.ext.
I notice I've not included my version of Win32OSProcessPlugin in Cog. I'll rectify that this evening.
I updated OSProcessPlugin, AioPlugin, and XDisplayControlPlugin to work properly with CrossPlatformVMMaker, and to continue working as before with the traditional VMMakerTool. This lets CrossPlatformVMMaker produce the expected sources for Win32OSProcessPlugin and UnixOSProcessPlugin, and should result in all of these being generated when running Squeak on Windows.
www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.23 www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-dtl.10
www.squeaksource.com/XDCP/VMConstruction-Plugins-XDisplayControlPlugin-dtl.8
Dave
David,
Here is my IsHandleInTable function. It is still not working.
Rob
/* Public. Test if a handle is in this table */ static int IsHandleInTable(HandleTable *table, HANDLE item) { return 1; }
-------------------------------------------------- From: "David T. Lewis" lewis@mail.msen.com Sent: Tuesday, July 27, 2010 9:09 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
This is probably because of the Windows handle registry that I mentioned earlier in this thread. You will need to disable the handle check.
What is happening here is that the FilePlugin (on Windows) is maintaining a registry of valid handles, and it only recognizes handles created by itself as valid. When OSProcess gives it some other handle (e.g. the handle for standard output or for an OS pipe handle) the primitives in FilePlugin will fail. This is a feature that was added to Windows FilePlugin some time after I wrote the Windows OSProcess stuff (long ago), and for now the workaround is just to disable the registry check.
Dave
On Tue, Jul 27, 2010 at 03:47:02AM -0400, Rob Withers wrote:
Thanks, David, I was able to generate unix plugins on Windows and build them on unix.
I am still having problems outputting to stdOut on both unix and Windows. I cannot tell the issue on unix since I am headless. On Windows it complains that stdOut accessor is closed. Here is the script I am using in both cases:
ThisOSProcess thisOSProcess stdOut nextPutAll: 'hello world'; flush.
Is the something I need to be doing to open the accessors before using them?
Thanks, Rob
From: "David T. Lewis" lewis@mail.msen.com Sent: Monday, July 26, 2010 11:31 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
On Mon, Jul 26, 2010 at 11:21:10AM -0700, Eliot Miranda wrote:
On Mon, Jul 26, 2010 at 7:13 AM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 25, 2010 at 11:01:12PM -0400, Rob Withers wrote:
<snip>
Third, I set self halts in UnixOSProcessPlugin class>>#shouldBeTranslated and Win32OSProcessPlugin class>>#shouldBeTranslated. The unix side eventually calls:
UnixOSProcessPlugin class>>#isResponsibleForThisPlatform "Answer true is this is an instance of the class which is responsible for representing the OS process for the Squeak VM running on the current platform. A false answer is usually the result of running the image on a different platform and VM. Note: Keep this method is sync with OSProcess>>isUnix."
| numericOsVersion | ^ (self platformName = 'unix') or: [numericOsVersion := self osVersion asInteger ifNil:
[0]. (self platformName = 'Mac OS') and: [numericOsVersion >= 1000]]
and this calls:
OSProcessPlugin class>>#platformName "After Squeak version 3.6, #platformName was moved to
SmalltalkImage
" ^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk platformName]) current
platformName
which kills any hope of being a cross-compiled source.
No worries there. The C source is not supposed to be cross-compiled. The implementations in Slang/Smalltalk are completely different for Unix and Windows, and the resulting generated code (UnixOSProcessPlugin.c and Win32OSProcessPlugin.c respectively) are completely different as well. When building a VM to run on Unix/Linux/OSX you would be compiling the UnixOSProcessPlugin.c, and when compiling a VM for Windows you would compile Win32OSProcessPlugin.c.
Cross-compilation is quite separate from generation. Cog is intentionally modified to spit out exactly the same source tree irrespective of platform.
Understood.
Needing a different VMMaker generation step for each platform is IMO an absurdity. Whether a plugin is compiled or not then depends on the plugins.int and plugins.ext files in each build directory. So the intent is to always spit out the UnixOSProcessPlugin source but only compile it on Unix platforms, as selected by plugins.int & plugins.ext.
I notice I've not included my version of Win32OSProcessPlugin in Cog. I'll rectify that this evening.
I updated OSProcessPlugin, AioPlugin, and XDisplayControlPlugin to work properly with CrossPlatformVMMaker, and to continue working as before with the traditional VMMakerTool. This lets CrossPlatformVMMaker produce the expected sources for Win32OSProcessPlugin and UnixOSProcessPlugin, and should result in all of these being generated when running Squeak on Windows.
www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.23 www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-dtl.10
www.squeaksource.com/XDCP/VMConstruction-Plugins-XDisplayControlPlugin-dtl.8
Dave
Hi Rob,
I probably can't be of much further help here, other than to suggest that you poke around with the debugger in Squeak and see if you can tell what's missing.
Have a look at "OSProcess thisOSProcess stdOut" and "OSProcess thisOSProcess stdErr". If these are instances of AttachableFileStream, and if the fileID instance variables contain some plausible looking byte array values, then the Win32OSProcessPlugin is probably working. If you do a #nextPutAll: on one of these streams and get a failure, then it's probably failing a primitive to the FilePlugin. I know that the handle registry in the Windows FilePlugin will cause this, but there might be other issues as well.
I'm doing the from memory because I don't have a Windows system available to check, so apologies if I'm sending you down a rabbit hole.
Dave
On Wed, Jul 28, 2010 at 05:58:19AM -0400, Rob Withers wrote:
David,
Here is my IsHandleInTable function. It is still not working.
Rob
/* Public. Test if a handle is in this table */ static int IsHandleInTable(HandleTable *table, HANDLE item) { return 1; }
From: "David T. Lewis" lewis@mail.msen.com Sent: Tuesday, July 27, 2010 9:09 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
This is probably because of the Windows handle registry that I mentioned earlier in this thread. You will need to disable the handle check.
What is happening here is that the FilePlugin (on Windows) is maintaining a registry of valid handles, and it only recognizes handles created by itself as valid. When OSProcess gives it some other handle (e.g. the handle for standard output or for an OS pipe handle) the primitives in FilePlugin will fail. This is a feature that was added to Windows FilePlugin some time after I wrote the Windows OSProcess stuff (long ago), and for now the workaround is just to disable the registry check.
Dave
On Tue, Jul 27, 2010 at 03:47:02AM -0400, Rob Withers wrote:
Thanks, David, I was able to generate unix plugins on Windows and build them on unix.
I am still having problems outputting to stdOut on both unix and Windows. I cannot tell the issue on unix since I am headless. On Windows it complains that stdOut accessor is closed. Here is the script I am using in both cases:
ThisOSProcess thisOSProcess stdOut nextPutAll: 'hello world'; flush.
Is the something I need to be doing to open the accessors before using them?
Thanks, Rob
From: "David T. Lewis" lewis@mail.msen.com Sent: Monday, July 26, 2010 11:31 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [Vm-dev] OSProcess in Cog
On Mon, Jul 26, 2010 at 11:21:10AM -0700, Eliot Miranda wrote:
On Mon, Jul 26, 2010 at 7:13 AM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 25, 2010 at 11:01:12PM -0400, Rob Withers wrote:
<snip>
> Third, I set self halts in UnixOSProcessPlugin > class>>#shouldBeTranslated > and Win32OSProcessPlugin class>>#shouldBeTranslated. The unix > side > eventually calls: > > UnixOSProcessPlugin class>>#isResponsibleForThisPlatform > "Answer true is this is an instance of the class which is > responsible for representing > the OS process for the Squeak VM running on the current > platform. A > false answer is > usually the result of running the image on a different > platform > and > VM. > Note: Keep this method is sync with OSProcess>>isUnix." > > | numericOsVersion | > > ^ (self platformName = 'unix') or: > [numericOsVersion := self osVersion asInteger ifNil: > [0]. > (self platformName = 'Mac OS') and: [numericOsVersion > >= > 1000]] > > and this calls: > > OSProcessPlugin class>>#platformName > "After Squeak version 3.6, #platformName was moved to SmalltalkImage > " > > ^ ((Smalltalk classNamed: 'SmalltalkImage') > ifNil: [^ Smalltalk platformName]) current > platformName > > which kills any hope of being a cross-compiled source.
No worries there. The C source is not supposed to be cross-compiled. The implementations in Slang/Smalltalk are completely different for Unix and Windows, and the resulting generated code (UnixOSProcessPlugin.c and Win32OSProcessPlugin.c respectively) are completely different as well. When building a VM to run on Unix/Linux/OSX you would be compiling the UnixOSProcessPlugin.c, and when compiling a VM for Windows you would compile Win32OSProcessPlugin.c.
Cross-compilation is quite separate from generation. Cog is intentionally modified to spit out exactly the same source tree irrespective of platform.
Understood.
Needing a different VMMaker generation step for each platform is IMO an absurdity. Whether a plugin is compiled or not then depends on the plugins.int and plugins.ext files in each build directory. So the intent is to always spit out the UnixOSProcessPlugin source but only compile it on Unix platforms, as selected by plugins.int & plugins.ext.
I notice I've not included my version of Win32OSProcessPlugin in Cog. I'll rectify that this evening.
I updated OSProcessPlugin, AioPlugin, and XDisplayControlPlugin to work properly with CrossPlatformVMMaker, and to continue working as before with the traditional VMMakerTool. This lets CrossPlatformVMMaker produce the expected sources for Win32OSProcessPlugin and UnixOSProcessPlugin, and should result in all of these being generated when running Squeak on Windows.
www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.23 www.squeaksource.com/AioPlugin/VMConstruction-Plugins-AioPlugin-dtl.10
www.squeaksource.com/XDCP/VMConstruction-Plugins-XDisplayControlPlugin-dtl.8
Dave
squeak-dev@lists.squeakfoundation.org