Re: Added test script

On Jun 6, 12:41 pm, "David Griswold" <[email protected]> wrote:
> > -----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.
>

I diff'd my r36 source with the SVN source, checked out last night. In
addition to the classes mentioned in your post, Launcher and
SourceHandler and Platform (oops, forgot that one) showed up. When I
tried to fileIn just the classes you mentioned originally, my image
would not start up again once saved (infinite loop of
doesNotUnderstands).

Looking at the details of the diffs, it seems like the command line
access method names changed, but the Launcher changes seem more
extensive (878 lines without detailed analysis). Was this the
recompileWorld change you mentioned elsewhere?

> > 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).
>
My main interest in Strongtalk development at the moment is
reimplementing the external calls to provide Linux support.

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

Certainly, you would need a separate namespace to file into. How about
wrapping the fileIn in a transaction block that replaces the Delta
alias to Smalltalk with an object representing the new namespace.
Since the fileIn method on CharacterInput executes evaluate: on
Smalltalk rather than Delta, it would be unaffected, allowing the code
to compile against the Smalltalk namespace rather than the new
namespace being constructed. An ensure: block would restore Delta as
an alias to Smalltalk.

Changes would probably be required to the DefinitionReader and Mirrors
to ensure that they all references Delta rather than Smalltalk.

I'm sure there are gaps in the above, but something similar should
work.

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

I'm not convinced that would be as simple as you suggest. Since
updates to the changelog would occur irregularly they may well
conflict with local modifications. As an expedient, users may well
fine in code that interferes with the comparison. You could certainly
easily identify the point at which the user's changelog differed from
the repository version and highlight that point to allow them to file
in manually, or present them with a list of chunks so that they can
choose which to file in.

>
> > 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 thebootstrapmethods 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 VMbootstrapcode 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
> >bootstrapimage.
>
> 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
-~----------~----~----~----~------~----~------~--~---