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

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.

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.

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.

Regards, talksmall

On May 7, 10:33 pm, "David Griswold" <[email protected]> wrote:
> This raises a niggling problem that I have not had time to address.  The
> strongtalk.bst image file in the repository is only updated right now when I
> do an actual release, since I do not believe we have enough room in the
> repository to keep it up to date at each commit, because it is a large
> binary file that probably diffs very poorly and Google's repository only
> gives us 100MB total, which would run out very rapidly if we check in a 2MB
> binary file every time we make any Smalltalk change.  So if you don't
> incrementally file in all the changes that I have checked in over time since
> the last release, it will not be correct.  For now I have checked in the
> current .bst, but then there is the associated problem that the associated
> Smalltalk source database is not in the repository, so the image will not
> have the right source code associated with it, and almost certainly won't
> recompile (in Smalltalk) correctly.
>
> Of course the real answer to this is to keep only the truly original,
> non-redundant sources in the repository and rebuild the image completely
> whenever code is released, but that requires a fullbootstrapwhich we can't
> do yet.
>
> This is a big pain in the butt, but the only solution at the moment is for
> me to package up all these big files in some kind of release that gives
> everyone the updated image and Smalltalk source DB at the same time.  I'll
> try to do that tomorrow, but I can't do that for every little change,
> though, so we need a better solution, which as far as I can tell will be to
> finish getting the system to re-bootstrap.  Hopefully that is coming Real
> Soon Now, since that is needed as part of a Squeak port anyway.
>
> I'll think about better ways of dealing with this in the interim.
>
> Sorry for the inconvenience,
> Dave
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of SmallSqueak
> > Sent: Tuesday, May 08, 2007 10:02 PM
> > To: [email protected]
> > Subject: RE: Added test script
>
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of David Griswold
> > Sent: Monday, May 07, 2007 7:10 AM
> > To: strongtalk
> > Subject: Added test script
>
> > We need a large deterministic system test that can be run from the command
> > line, in order to progress with VM debugging. I've used the new script
> > facility for that purpose.
>
> > The new system test is run by executing the new batch file
> > "tools\test.bat"
> > from the Strongtalk home directory.  It not only runs all the
> > unit tests for
> > the libraries, but also recompiles all the methods in the system
> > (using the
> > bytecode compiler, which is written in Smalltalk), which takes quite a
> > while.
>
> > Recompiling all methods had not worked up till now; that is now fixed, at
> > least under the UI.  The main problem was that the Strongtalk source
> > database was corrupted because there were both a class named
> > Point and POINT
> > (the name of a Win32 structure), which didn't cause a problem in
> > Strongtalk
> > because it is case sensitive, but corrupted the source database
> > because the
> > indices are stored in folders named by the class and Windows isn't
> > case-sensitive.
>
> > Recompiling all methods from the UI works in interpreted-only mode, but
> > crashes the VM when run from the test script.  This gives us a
> > good place to
> > start debugging.  Also, recompiling all methods failed even under
> > the UI in
> > compiled mode, but let's start with the interpreter.
>
> > To run the new test script, you will need to:
> > · checkout tools\{test.dlt, test.bat, strongtalkrc-forInterpretedTests}
> > · checkout and filein StrongtalkSource\{WinPOINT.dlt,  MINMAXINFO.dlt,
> > Win32Control.dlt, Window.dlt, SystemInitializer.dlt}
> > · checkout vm\runtime\arguments.cpp and recompile.
> > Dave
>
> > Greetings,
>
> > > · checkout vm\runtime\arguments.cpp and recompile.
>
> >    Step 1.
>
> >    Done. New Strongtalk_debug.exe was built with VS8 SP1 under Vista
> > X64.
>
> > > · checkout and filein StrongtalkSource\{WinPOINT.dlt,  MINMAXINFO.dlt,
> > Win32Control.dlt, Window.dlt, SystemInitializer.dlt}
>
> >    Step 2.
>
> >    Is this step necessary if the new strongtalk.bst (checked out) is
> > used ?
>
> >    The Strongtalk launcher seems to hang after complaining:
>
> >            "identifier expected"
>
> >    when WinPOINT.dlt was filed in
> >    (newly checked out strongtalk.bst, newly built
> > strongtalk.exe/strongtalk_debug.exe
> >    under Vista Enterprise x64 and Windows 2003 TSE x86).
>
> >    Could anyone successfully pass step 2?
>
> > > · checkout tools\{test.dlt, test.bat, strongtalkrc-forInterpretedTests}
>
> >    Regards,
>
> >    PhiHo
>
> >    P.S: The whole strongtalk trunk at revision 94 was checked out.
> >            incls folder was stolen from "strongtalk r36-noasm2 VM pack"
> >            with a commented out line from _interpreter.cpp.incl:
>
> >            // # include "generatedPrimitives.hpp"


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