Thanks, these are now all packed up in:

ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/3.6alpha/Squeak3.6a-5247.zip

cheers

bruce

Doug Way <dway at riskmetrics.com> wrote:
> 
> These are the 4 items which were [approved] last week, plus one which 
> Daniel approved about a month ago that I somehow missed.  (The subject 
> line for that one was munged a bit, though... I'll use that as an 
> excuse. ;-) )
> 
> - Doug Way
> 
> 
> -------------------------------
> 
> 5241instrPrinter-md -- Marcus Denker -- 8 April 2003
> A refactoring for InstructionPrinter,
> AbstractInstructionPrinter and InstVarRefLocator:
> AbstractInstructionPrinter:
> moved the instVar and a method into InstVarRefLocator, now this class 
> can
> be used as a Abstract Superclass for
> both InstructionPrinter and InstVarRefLocator
> Renamed to InstructionClient (c.f. VisualWorks).
> InstructionPrinter: refactored to be a
> subclass of InstructionClient"
> 
> 5242HashChanges1-SqR -- Andres Valloud, Stephan Rudlof -- 13 August 2002
> Goals:
> Implement an improved hash for large integers.
> Refactor/rename some hash methods to make them more intention revealing.
> Pass 1 - Implement refactoring so it can be bridged later.
> sr: I have changed #byteAt: to #basicAt: to make it Slang compilable 
> (and changed some var names)."
> 
> 5243HashChanges2-SqR -- Andres Valloud -- 13 August 2002
> Pass 2.  Implement LargePositiveInteger>>hash.
> Rehash sets as appropriate."
> 
> 5244HashChanges3-SqR -- Andres Valloud -- 13 August 2002
> Pass 3.  Make String and ByteArray use the
> refactoring instead of the original
> implementation."
> 
> 5245MorphicClsComments-efc -- Eddie Cottongim -- 7 March 2003
> Class Comments for Morph, ImageMorph, SimpleButtonMorph and 
> StringMorph. These were subject
> to review and editing on the swiki, and thus should be fairly 
> comprehensive."
> 
> 5246Sibling-dup-tk -- Ted Kaehler -- 11 March 2003
> Whenever you ask for a sibling instance of a Player in an EToy, the 
> Players of the new object is an instance of the original Player class, 
> instead of having a new class.  When you duplicate a morph the holds a 
> set of siblings, there was bug that made the new objects not be 
> siblings.  This fixes the bug.  Alan wants this fixed for the cells of 
> a Tic-Tac-Toe game.
> 	To test, make a playfield with a blob in it.  Make a sibling of the 
> blob.  Tell the playfield to 'make sibling instance'.  All four blobs 
> will remain siblings.
> 	In addition, the production of a sibling instance is now cleaner.
> 	(Updated to fix a conflict with the 5240 MCP update. -dew)"
> 
> 5247VeryDeepCopyUsing-tk -- Ted Kaehler -- 13 May 2003
> Object>>veryDeepCopyUsing: is a utility method.  When you have a 
> complex data structure, involving several custom classes, veryDeepCopy 
> on a subpart may not do what you want.  When you veryDeepCopy one of 
> your objects, it does not know which instance variable are actually 
> pointers back to a 'global' object, which should not be duplicated.  
> The 'parent' links in a tree are an example.  These can be handled by 
> creating veryDeepInner: and veryDeepFixupWith:.  However, it may be 
> easier to make a custom veryDeepCopy method.  In it, you create a 
> DeepCopier, and store into its references dictionary with (globalObject 
> -> globalObject).  Then you want to start a veryDeepCopy using that 
> DeepCopier, and calling veryDeepCopyUsing: is the way to do that."