Re: Porting to Darwin

On Jun 19, 6:29 am, Brian de Alwis <[email protected]> wrote:
> Hi Steve.  Your patch works.  Execution proceeds further, and now the
> start up fails as '__fxstat' cannot be resolved.  Which is good news:
> it means that the previously-failing open call was completed
> successfully -- the stack alignment code works.

Excellent. A step in the right direction at least.

>
> Re: __fxstat is a Linuxism, unfortunately.  With the plethora of unix-
> like OSs and their different representations (e.g., 32-bit or 64-bit
> file offsets), it seems to me that we're better off trying to define a
> minimal spec for handling files and embed those as primitives.  I
> think it would greatly simplify moving to bootstrapping the VM.
>

Actually, I think it's a libc-ism, but it doesn't really matter. The
core problem is the same - it doesn't work in OSX. I'm not sure that I
agree with the remedy though. I would prefer to avoid adding file
support primitives which would then need to hook into additional os::
functions for each platform. This implies more work in C++ to get each
platform up and running. It seems better to try to minimise the
additional work in C++ in order to port to a new platform.  I had to
add one primitive for the Linux port, in order to give access to the
command line arguments, since Linux doesn't provide access to these
via a library function, but that primitive doesn't rely on any new OS-
related functionality - it just picks up the previously saved values.

The next thing would be to add primitives for UI support, so that we
can plugin XYZ whizzy UI framework and thus begins the slippery slope
to primitive overload.

We have a hook - through the os::platform_class_name() function - to
plug in different platform classes in the Smalltalk image. In this
case we appear to need to override the platform class with a new
"OSXPlatform" or "DarwinPlatform", which could possibly subclass the
existing UnixPlatform if the differences are small enough. Not that
the UnixPlatform class is not complete. I took a very opportunistic
approach with the Linux port.

Basically, I cloned the original Platform class as Win32Platform and
UnixPlatform and then modified those things that I needed to to get
the Linux VM to run the command line test script. I also created
clones of the Win32FilePath and Win32FilePattern classes for file
handling.

> > Actually, a failure to find a shared library (DLL or .so) results in
> > an assertion failure being logged in the console. So does a failure to
> > find a named function within a library. The problem here is that we
> > are very early in the image start up code, and if it can't load libc
> > (or equivalent) then if can't open the test script, and since there is
> > no UI yet for non-Windows it can't do diddly! One issue is that the
> > Foreign Function interface in Smalltalk (see this page on the Wiki -http://code.google.com/p/strongtalk/wiki/ForeignFunctions) doesn't
> > provide a Smalltalk fail block for DLL lookup failures. It just
> > assumes that the DLL is available. If the DLL is missing, it is
> > essentially a pretty major error. Going forward we should probably add
> > some generic failure code to throw an appropriate Smalltalk exception.
> > We can then add an exception handler to handle this in the normal way,
> > when it makes sense.
>
> I see -- and once your ANSI exceptions are in there, then
> Object>>#error: can be redefined and handled properly.  Sound cool.

Actually the ANSI exception support already does this for error:,
doesNotUnderstand: and halt to signal the relevant exceptions (Error,
MessageNotUnderstood and Halt, respectively). Actually Halt is not an
ANSI exception, but it seemed to make sense. I haven't yet touched any
of the other process errors.

>
> If I can trouble you with one more question: what's the easiest or
> recommended way to modify the ST code (e.g., so as to fixup the
> __fxstat problem above) and dump a new image?  A quick scan of the
> strongtalk web and googlecode sites didn't show anything.  I assume it
> has to be done from Windows...?
>
> Brian.

At the moment UI-based development (ie. using the programming
environment) has to be done from Windows. If you have access to a
Linux environment you can file-in changes and save the image using the
command line script, but that gets old quite quickly and I wouldn't
recommend it unless you are rabidly anti-Windows. I found it much
easier to make changes in the UI programming environment under
Windows.

Do you have Parallels or dual boot access to Windows?

In any case, I feel quite strongly that we should avoid forking the VM
code in order to support a new platform (not that anyone has suggested
it yet). We have precious few people contributing to the VM at the
moment and we don't want to make that work any harder. For that reason
we need to ensure that when we do make changes in order to support a
new platform that those changes don't break our existing platforms. In
particular, since the Windows environment is by far the most complete
we should make every effort to avoid breaking it. That means that
everyone who is tinkering with the VM code really needs access to a
Win32 environment (ideally all platforms, but most people don't have
the resources for that) where they can check that they haven't broken
anything.

Regards, Steve
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---