Re: Porting to Darwin

On Jun 20, 2:41 am, Brian de Alwis <[email protected]> wrote:
> You're right, __fxstat is a glibcism.  It won't work in the *BSDs
> either.
>
> I do have VMWare Fusion.  I tried rebuilding an image last night from
> the Strongtalk 2.0 binary distribution, but it failed and I didn't
> have time to investigate why.  From searching on the newsgroups, it
> appeared that rebuilding the image only used the in-memory source
> code, and not the changes on disk.  Is that correct?  Is there a way
> to instead load the file-outs from disk?

I'm not sure I know what you mean when you talk about "rebuilding an
image". Do you mean recompileWorld? If so, that works not from source
code in memory, but from the source code in the source database in the
source directory. This contains a largish strongtalkchange.log that
contains the filed-in source, a strongtalkrestore.log that contains
sources filed in since the image was last saved and lots of little
files describing the source locations within the change log of all the
classes and methods in the image.

Recompile world was broken, but is fixed in later images including the
one on the download page of the wiki, though this won't work with the
Strongtalk 2.0 binary.

To obtain a Windows binary that does work with later images you will
probably need to build one. That's not as bad as it sounds, since MS
now offer an edition of VC++ Express 2008 that you can download for
free. You can then use that to build the binary. As I mentioned in my
earlier email, this would be a good thing to have anyway as it would
let you check that any VM changes you make don't break the Windows
build.

If that is too daunting, I can build you a stripped binary that you
should be able to use for image editing. It will have to wait until
the weekend though.
>
> I'm only pushing file prims as I'm seeking a way for new ports to
> escape from my same bootstrapping catch-22: I can't get a headless VM
> running because of the __fxstat issue causes it to crash, but I can't
> file in a change (even if only a hack) to rewrite the file I/O code to
> get the VM working as filing in uses the file I/O code which refers to
> non-existent OS functions like __fxstat.  Perhaps we could have just
> two simple primitive for bootstrapping purposes only: get-directory-
> contents and read-file-contents.  And port SWIG to access everything
> else.

I understand the reasoning but it's not just a couple of functions.
From my somewhat hazy memory there were about 6 or so foreign function
calls that were necessary in order to be able to execute the script.
Additionally it would look a little odd to have the bootstrap script
read in by one set of file handling functions and then use a different
set for the file handling abstractions used by ordinary code. Of
course we could mix and match, but that would probably be even worse.
The primitives and the foreign functions would need to be consistent.

I have another, perhaps more pragmatic reason for not wanting to go
down this route. I actually don't mind if there is a little inertia
involved in porting to a new platform. A certain amount of diversity
is good, but when we have as few people actively involved in the
project as we do it is very easy to stretch resources too thin.

>
> Porting the VM to Darwin was pretty trivial thanks to your help and -
> mstackrealign -- the heavy lifting has been done in the port to
> Linux.  The os_darwin.cpp I've made is a lightly modified copy of the
> os_linux.cpp.  To make porting to new platforms a bit easier, I'd
> suggest is instead of having to reimplement os for each new platform,
> we provide an implementation for posix systems that Linux, Darwin,
> etc. can specialize as necessary.  The appropriate `os' instance would
> be set in main().
>
> Brian.

It depends how you do it. One approach would be to create a posixOS
base class, in a posixOS.cpp module. The code in this file would be
bracketed with #ifdef _POSIX ... #endif, or something similar. In
separate files named as now - ie. os_linux.cpp, os_darwin.cpp, etc. -
we would put code for a derived class named os that would contain the
platform-specific differences from the POSIX base class. The advantage
of this approach is that we don't need to determine which platform we
are running on anywhere outside of the os_* modules, since we can just
reference the os class in all cases.

I don't see much point in defining the os:: functions as virtual.
There will only be one version appropriate to a given binary.

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
-~----------~----~----~----~------~----~------~--~---