RE: Added test script

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of talksmall
> Sent: Wednesday, June 06, 2007 12:53 PM
> To: Strongtalk-general
> Subject: Re: Added test script
>
>
>
> I managed to file the changes in to an r36 based image and save the
> image. I needed a few extras to get the to work. There were also
> changes to Launcher and SourceHandler (compared to the current content
> of the SVN .dlt files) which appeared to be required (ie. the image
> wouldn't restart without them).

What changes to Launcher and SourceHandler are you referring to?  I don't
seem
to see that I made any changes; my versions match the repository.

> Also, the method Bootstrap>>deterministicallyTestSystem does not exist
> in the SVN Bootstrap.dlt file.I realise that the comprehensive test
> suite hasn't been written yet, but I thought there might have been a
> stub.

Yes, here is a method there that apparently didn't get checked in.  I've
checked it in- checkout Bootstrap.dlt and filein.  Sorry I missed that.

> That aside, the scripting changes work for me. The image starts up in
> headless mode until it tries to send deterministicallyTestSystem to
> the newly created instance of Bootstrap at which point it drops into
> the command line evaluator with a does not understand error.
>
> On the topic of bootstrapping the image, do you have a view on how to
> proceed with this? It would appear to be key to proper management of
> the Strongtalk source code in the SVN repository.

Yes, all this points out the woeful state of our smalltalk code management
tools.  However I haven't worried too much about it other than getting
a test framework set up, since focusing on the Squeak port means that not
much
Strongtalk developement will be happening (at least on my part; others are
welcome to dive in).

I have been trying to decide the right bootstrapping approach, although I
haven't done much.  The issue is that it seems to require something like a
separate namespace to file in to, which gets rather ugly when you consider
that the filein chunk headers are code that is executed; they seem to need
to execute in the old namespace, but affect the new
namespace, but they also need to reference the new namespace, which is
rather ugly.  Any ideas?  In couple of weeks I will be starting on the
Squeak port, at which point I will focus on this issue because it is needed
for that also.

As I mentioned in a recent email, I was thinking that a short term
workaround is to move away from holding all the class source code in
separate .dlt files in the repository, and move to just storing the
changelog.  Then, a small tool can compute the added diffs in the repository
change log that are missing in a user's image to bring it up to the state of
the repository.  It would be a quick hack that certainly has drawbacks; I'm
open to other ideas.

> Assuming that we are talking about generating a new image from within
> a running Strongtalk environment, we would need to pick apart the
> existing Dumper code, or at least subclass it, in order to allow us to
> vary the content of what gets filed out. Two issues that spring to
> mind are the contents of the system dictionary and any references to
> elements of the system dictionary that occur in compiled methods.
> Obviously we need to allow existing image saving to continue working,
> whilst providing a mechanism for filing out a subset of the current
> image content.
>
> Of the top of my head, I wonder whether the Visitor pattern might be
> appropriate here. The current code delegates to the objects being
> dumped to the image the twin responsibilitities of deciding which
> related objects to dump and the detailed dump format for the object.
> There is a reflection of this code in the bootstrap methods for the
> well-known object classes in the VM code. Obviously we don't
> necessarily want to change the image format since this would involve
> modifying the VM bootstrap code as well as the Strongtalk code, but we
> could use Visitor to dispatch back to the dumper the responsibility
> for deciding which related objects get written out. A related issue
> would be deciding which methods of each class would be dumped in the
> bootstrap image.

The big problem to me seems to be the namespace differences that occur when
the old image differs significantly from the new image, as I mentioned
above.  It isn't just a matter of which things to dump, but of having two
different versions of them; one that is running, one that is being built.
How would you suggest dealing with that?

-Dave


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