[squeak-dev] Re: [Vm-dev] OSProcess in Cog

David T. Lewis lewis at mail.msen.com
Wed Jul 28 15:46:51 UTC 2010


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 at mail.msen.com>
> Sent: Tuesday, July 27, 2010 9:09 AM
> To: "The general-purpose Squeak developers list" 
> <squeak-dev at 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 at mail.msen.com>
> >>Sent: Monday, July 26, 2010 11:31 PM
> >>To: "The general-purpose Squeak developers list"
> >><squeak-dev at 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 at 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
> >>>
> >>>
> >



More information about the Squeak-dev mailing list