Hi Karl,
On Mon, Apr 30, 2018 at 11:17 AM, karl ramberg karlramberg@gmail.com wrote:
This change set make the project ALMOST load in a 32 bit 6.0 Squeak image. But there are some conversion issues I have not figured out.
Looking at this change:
ObjectScanner>>scanFrom: aByteStream "Sieze control of the fileIn. Put myself in as the context. If any UniClasses (for just one instance) are defined, they will do it through me, and I will look for conflicting class names. If so, install the old name as a class var of me, so the compile will work. Tell my SmartRefStream about renaming the class."
| valWithOddName47 scannerNamed53 chunkNamed117 | pvt3SmartRefStrm := SmartRefStream on: aByteStream. aByteStream ascii. [aByteStream atEnd] whileFalse: [aByteStream skipSeparators. valWithOddName47 := (aByteStream peekFor: $!) ifTrue: [chunkNamed117 := aByteStream nextChunk. "debug" chunkNamed117 = 'ImageSegment new' ifTrue:[ chunkNamed117 := 'NativeImageSegment new']. scannerNamed53 := Compiler evaluate: chunkNamed117 for: self logged: false. scannerNamed53 class == self class ifTrue: ["I already am the scanner for this file"] ifFalse: [scannerNamed53 scanFrom: aByteStream]] ifFalse: [chunkNamed117 := aByteStream nextChunk. chunkNamed117 := self lookAhead: chunkNamed117. Compiler evaluate: chunkNamed117 for: self logged: true]. aByteStream skipStyleChunk]. ^ valWithOddName47
you introduced the lines:
chunkNamed117 = 'ImageSegment new' ifTrue:[ chunkNamed117 := 'NativeImageSegment new'].
I think this is not going to work. The issue being at this point we won't know whether we have a legacy image segment or a native image segment. If you look at the hierarchy, there is ImageSegment NativeImageSegment LegacyImageSegment and intentionally all the list vars are in ImageSegment so that when the scan of the actual binary data, embedded in the .pr file occurs, we can use something like (legacy ifTrue: [LegacyImageSegment] ifFalse: [NativeImageSegment]) adoptInstance: themageSegment to become the right kind of image segment. So the way to proceed is to make ImageSegment intelligent enough to get you as far as the point where the kind of image segment, V3 or Spur, is apparent, and then make the switch.
HTH
NOTE: Image will probably crash. USE WITH CARE
Best, Karl
On Mon, Apr 30, 2018 at 3:37 PM, H. Hirzel hannes.hirzel@gmail.com wrote:
Unfortunately the dynamic essay MorphLayoutArticle.019.pr did not load in a fairly recent Squeak 6.0a trunk image.
an OrderedCollection(ImageSegment(Object)>>doesNotUnderstand: #scanFrom: ObjectScanner>>scanFrom: [] in [] in MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: BlockClosure>>on:do: [] in MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: [] in [] in MorphicUIManager>>displayProgress:at:from:to:during: BlockClosure>>on:do: [] in MorphicUIManager>>displayProgress:at:from:to:during: BlockClosure>>ensure: MorphicUIManager>>displayProgress:at:from:to:during: ProgressInitiationException>>defaultResumeValue ProgressInitiationException(Exception)>>resume ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: ByteString(String)>>displayProgressFrom:to:during: MultiByteBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: MultiByteBinaryOrTextStream(PositionableStream)>>fileIn MultiByteBinaryOrTextStream>>fileInProject MultiByteBinaryOrTextStream>>fileInObjectAndCodeForProject [] in [] in ProjectLoading class>>fileInName:archive:morphOrList: BlockClosure>>on:do: [] in ProjectLoading class>>fileInName:archive:morphOrList: BlockClosure>>ensure: ProjectLoading class>>fileInName:archive:morphOrList: ProjectLoading class>>openName:stream:fromDirectory:withProjectView:clearOriginFlag: ProjectLoading class>>openName:stream:fromDirectory:withProjectView: [] in ProjectLoading class>>openOn: BlockClosure>>on:do: [] in ByteString(String)>>displaySequentialProgress: [] in [] in MorphicUIManager>>displayProgress:at:from:to:during: BlockClosure>>on:do: [] in MorphicUIManager>>displayProgress:at:from:to:during: BlockClosure>>ensure: MorphicUIManager>>displayProgress:at:from:to:during: ProgressInitiationException>>defaultResumeValue ProgressInitiationException(Exception)>>resume ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ProgressInitiationException class>>display:from:to:during: ByteString(String)>>displaySequentialProgress: ProjectLoading class>>openOn: [] in ExternalDropHandler class>>defaultProjectHandler ExternalDropHandler>>handle:in:dropEvent: PasteUpMorph>>handleDroppedItem:event: [] in PasteUpMorph>>dropFiles: BlockClosure>>ensure: PasteUpMorph>>dropFiles: PasteUpMorph(Morph)>>handleDropFiles: DropFilesEvent>>sentTo: PasteUpMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchEvent:withHandler:withMorph: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: PasteUpMorph(Morph)>>processEvent:using: [] in PasteUpMorph>>processEvent:using: BlockClosure>>ensure: PasteUpMorph>>processEvent:using: PasteUpMorph(Morph)>>processEvent: [] in [] in [] in HandMorph>>sendEvent:focus:clear: BlockClosure>>ensure: DropFilesEvent(MorphicEvent)>>becomeActiveDuring: [] in [] in HandMorph>>sendEvent:focus:clear: BlockClosure>>ensure: HandMorph>>becomeActiveDuring: [] in HandMorph>>sendEvent:focus:clear: BlockClosure>>ensure: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendEvent:focus:clear: HandMorph>>sendEvent:focus: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in MorphicProject>>spawnNewProcess [] in BlockClosure>>newProcess)
On 4/30/18, H. Hirzel hannes.hirzel@gmail.com wrote:
Hi Tim
Implementing your suggestion [1] worked to make MorphLayoutArticle.019.pr load into Squeak 3.8.1, see screen shot.
What I aiming at next at is to load it into Squeak 6.0a trunk. I assume this should be possible quite easily because of the enhancements done last year [2][3].
Regards Hannes
[1] Extend #initKnownRenames
SmartRefStream>>initKnownRenames renamed at: #AlansTextPlusMorph put: #TextPlusMorph; at: #FlasherMorph put: #Flasher; yourself
made MorphLayoutArticle.019.pr to load.
[2] 6502 format http://wiki.squeak.org/squeak/6502
ImageFormat of the interpreter Virtual Machine. May be loaded transparently into Squeak 6.0a through the help of LegacyImageSegment.
[3] http://wiki.squeak.org/squeak/6579 LegacyImageSegment A new class introduced in March 2017 in Squeak 6.0a to enable the loading of the older 6502 image segment format type .
More see Smalltalk imageFormatVersion http://wiki.squeak.org/squeak/
873
On 4/30/18, Tm Jhnsn digit@sonic.net wrote:
Hi Hannes,
In 5.1 there is SmartRefStream>>#initKnownRenames which includes:
at: #AlansTextPlusMorph put: #TextPlusMorph;
HTH, Tim
On 4/30/2018 7:33 AM, H. Hirzel wrote:
Hi Bob
It still loads fine in Squeak 3.2. Thank you.
In Squeak 3.8.1 the SmartRefStream needs a new class for
AlansTextPlusMorph
SmartRefStream>> alansTextPlusMorphbosfcebbmsopssrsggshtt0
^ PutNewClassHere
Any suggestions what I should put as a new class?
Regards Hannes
On 4/30/18, Bob Arning arning315@comcast.net wrote:
Here is the latest one I have. It loaded fine in 3.2.
On 4/29/18 10:20 PM, H. Hirzel wrote: > Hello > > Is there a backup-copy/mirror available of the > > MorphLayoutArticle > > project which was on Bob's SuperSwiki? [1] > > Regards > Hannes > > > > ---------------------------------- > [1] > http://wiki.squeak.org/squeak/2141 > > How to lay out submorphs > > Please read the excellent dynamic essay project MorphLayoutArticle > (broken link) on Bob's SuperSwiki. > > Every Morph now has the capability to layout it's submorphs. > (Previously, only the AlignmentMorph could implement layout
policies.
> AlignmentMorph is still available because of compatibility reasons
and
> some utility methods it implements. >