Re: Porting to Darwin

On Jun 30, 5:15 am, Brian de Alwis <[email protected]> wrote:
> Hi Steve.  Thanks for asking.  I've managed to build a new VM under
> VisualStudio.  Unfortunately my Darwin-patched sources leads to a
> failed assertion when filing in code, such as your ANSI exceptions.

Which assertion fails? Is it an assertion in Smalltalk or an assertion
in the VM? Can you send me your patches?

> But a VM built from a fresh set of sources works fine.  So I'm in the
> middle of figuring out what part of my patches causes the issue.  (I
> can't seem to figure out how to get VisualStudio to load the .pdb file
> for debugging symbols though.)

Strange about the symbols. Are you using the solution file under the
build.win32 directory?

>
> Even with fresh sources, however, recompiling the world (File ->
> Recompile world) fails in DeltaCompiler>>#copyParameters: as a method-
> scope's toHeap block is being fired, and the block is raising an
> error.  I'm finding it a bit difficult to navigate the UI to figure
> out what source object is causing the problem though.
>
> Otherwise, I've been figuring out the UI environment, and trying to
> figure out how to move forward.  I've currently created a
> 'DarwinPlatform' class and rewrote DLLMapName: to instead return an
> array of library names (and modify its dependents).  I'm trying to
> figure out what to do with StatBuffer and its indices.

Pardon my ignorance, but I have no knowledge of the Darwin
environment. Is StatBuffer relevant to Darwin? Does Darwin have a libc
equivalent? If so, one option would be to create a DarwinStatBuffer,
which may or not subclass the existing StatBuffer, and just override
the offset and length accessors with appropriate values for Darwin.

>
> I'm also trying to figure out how to manage source code: I'm from an
> ENVY background and am finding the ball'o'wax file-in/file-out model a
> big perplexing.  For example, your ANSI exception source includes
> SUnit test methods -- I don't dispute that they have a purpose being
> on Exception, but they shouldn't be in the file-in.

Oops. That was careless of me. Bit of a chicken and egg situation
though. I wanted to use SUnit tests to express the intent of the
Exception handling, however SUnit depends on Exception handling. I
wrote a little utility to help with managing the fileouts, but it is
inclusive rather than exclusive (by which I mean it is much easier to
include more of something than exclude a part).

Going forward Smalltalk source code management will be an issue. Quite
apart from anything else if you file things in in the wrong order the
later file ins may break. Consider, for example, class Foo which
contains a reference to a global Bar. Bar happens to be another class.
If you file in Bar before Foo, everything is good. If you file in Foo
before Bar, the Foo file in will create a global variable named bar
with value nil. A subsequent attempt to file in Bar will fail as it
attempts to redefine the global Bar.

One option for the longer term might be something like Monticello
which is what Squeak uses. I haven't looked into whether that is
practical, though.

>
> So I'm making progress, slowly but surely.
>
> Brian.
>
> On Jun 29, 10:21 am, talksmall <[email protected]> wrote:
>
> > Hi Brian,
> > Just wondering how you were getting on with creating new Smalltalk
> > platform classes for the OSX port. Did your windows build work OK? If
> > not, I can still generate a binary for you to use. Let me know if you
> > would like me to do this.
>
> > 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
-~----------~----~----~----~------~----~------~--~---