Image not startable after save

Am 07.06.2020 11:48:27 schrieb Marcel Taeumel <[hidden email]>:

Hi all!

DisplayScreen should be removed from the startup list. It is not necessary anymore. Project will do the job just fine.

Yeah, the trick I suggested with the start-up script will -- unfortunately -- not work. ProjectLauncher is processing those after the first drawing cycle in Morphic.

Those cases with a broken display depth in some images out there still puzzles me. Given that the .sources-file-not-found trick works, there is something else in the StartUpList after 8 (FileDirectory) that actually breaks the Display object, which means that it works up to that point. Note that 8 > 5. ;-) Everything *can* work without having DisplayScreen in the StartUpList.

Your broken images are really valuable here! Please do not overwrite them.

Best,

Marcel

Am 06.06.2020 18:17:35 schrieb Thiede, Christoph <[hidden email]>:

I just got it! It was indeed a question of load order. After moving #DisplayScreen in the StartUpList back to index 5 (instead of appending it at the end), my image starts again without renaming any files.

I suppose that all these renamings tricks were only relevant for deferring the execution of the startup list, which - so I suspect - reset the display screen depth temporarily at some point, I don't know.

So to summarize, to rescue your image, you have to:

• apply the 5 steps from my previous message once
• add DisplayScreen >> #startUp (*)
• Evaluate this:
  (SmalltalkImage classVarNamed: #StartUpList) add: #DisplayScreen afterIndex: 4
• And save your image.

I hope this helps other people to rescue their images, too :-)

* Source:

startUp  "DisplayScreen startUp"

Display setExtent: self actualScreenSize depth: Display nativeDepth.

Display beDisplay

Nevertheless thank you for the kind offer, Fabio!

---

Von: Squeak-dev <[hidden email]> im Auftrag von Fabio Niephaus <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:54:10
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save

 

On Sat, 6 Jun 2020 at 5:43 pm, Thiede, Christoph <[hidden email]> wrote:

Thank you, Jakob.

Well, I have to revoke my previous success message. Restarting my image another time and it crashes again on startup ...

But I have looked up my sources files. They do contain DisplayScreen class >> #startUp. And (Smalltalk class classVarNamed: #StartUpList) includes: #DisplayScreen. What could be the problem?

Wild guess: there's something wrong with the display form and the Windows VM crashes before the beDisplay primitive is called with a fresh one. That could explain why it works on macOS. I could have a look at the raw display object if you provide an image.

Fabio

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:33:16

An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save

 

Am Sa., 6. Juni 2020 um 17:25 Uhr schrieb Thiede, Christoph <[hidden email]>:

How did you hit on that?

 

That I tried the same copy of the VM from another folder at all is because I have the unpacked zips lying around and always copy the current VM that I use to a different folder, where the Windows file association looks for it. So when I switch VMs, I won't have to tell Windows again how to open these .image files...

I compared the folders with a merge tool (after renaming my Squeak64.exe .ini and .manifest back). All the binary files are equal, and Monticello/Metacello cache folders, the default image and changes file, debug logs, and crash dumps aside, the only meaningful difference left was eventually the presence of the sources file.

Am 07.06.2020 12:43:52 schrieb Marcel Taeumel <[hidden email]>:

Hi all!

I found the bug. I think. :-)

1. The Solution:

- Move Project before AutoStart in the StartUpList --- maybe even before PasteUpMorph and ControlManager bc. Project is more general than those two, which should be removed alltogether from the list

- In PasteUpMorph >> #installFlaps, replace "self displayWorld" with "self changed"

- From AutoStart class >> #startUp:, move "Project current startUpActions" to Project class >> #startUp:

Doing either one of those will fix the bug. But all are quite important in the long term. ;-)

2. The Bug:

AutoStart has a weird call to Project class >> #startUpActions. If you happen to have local flap tabs (not just the shared/global ones), those actions will trigger a #displayWorld, which will then try to force display updates. At that point, the VM has no idea about the actual display depth and defaults to 0 --- while the image still has 32 configured for the display object.

We did not notice this because DisplayScreen did set those values way before AutoStart was called.

3. How did I found out?

By looking at the complete stack trace. AutoStart was in there. Then it was easy to see and spot in the actual source code.

          0xa6e4a0 I DisplayScreen>forceToScreen: 0x5d2cb78: a(n) DisplayScreen

          0xa6e4d8 M [] in DisplayScreen>forceDamageToScreen: 0x5d2cb78: a(n) DisplayScreen

          0xa6e518 M OrderedCollection>do: 0x5810168: a(n) OrderedCollection

          0xa6e570 I DisplayScreen>forceDamageToScreen: 0x5d2cb78: a(n) DisplayScreen

          0xa6e5b8 I AnimWorldState(WorldState)>forceDamageToScreen: 0xb33abd0: a(n) AnimWorldState

          0xa6e628 I AnimWorldState(WorldState)>displayWorld:submorphs: 0xb33abd0: a(n) AnimWorldState

          0xa6e678 I PasteUpMorph>privateOuterDisplayWorld 0xb33a7f8: a(n) PasteUpMorph

  !!!     0xa6e6b8 I PasteUpMorph>displayWorld 0xb33a7f8: a(n) PasteUpMorph

  !!!     0xa6e6f8 I [] in PasteUpMorph>installFlaps 0xb33a7f8: a(n) PasteUpMorph

          0xa6e758 I OrderedCollection(SequenceableCollection)>keysAndValuesDo: 0x5687588: a(n) OrderedCollection

          0xa6e7a8 I PasteUpMorph>installFlaps 0xb33a7f8: a(n) PasteUpMorph

          0xa6e7e8 I PasteUpMorph>install 0xb33a7f8: a(n) PasteUpMorph

  !!!     0xa6e828 I AnimMorphicProject(MorphicProject)>startUpActions 0xb33a718: a(n) AnimMorphicProject

          0xa6e878 I AutoStart class>startUp: 0x60a6db0: a(n) AutoStart class

@Christoph: I cannot relate to the stack trace you posted here earlier. It seems way too late for the bug to show itself. Can you post it again?

Best,

Marcel

Am 07.06.2020 11:48:27 schrieb Marcel Taeumel <[hidden email]>:

Hi all!

DisplayScreen should be removed from the startup list. It is not necessary anymore. Project will do the job just fine.

Yeah, the trick I suggested with the start-up script will -- unfortunately -- not work. ProjectLauncher is processing those after the first drawing cycle in Morphic.

Those cases with a broken display depth in some images out there still puzzles me. Given that the .sources-file-not-found trick works, there is something else in the StartUpList after 8 (FileDirectory) that actually breaks the Display object, which means that it works up to that point. Note that 8 > 5. ;-) Everything *can* work without having DisplayScreen in the StartUpList.

Your broken images are really valuable here! Please do not overwrite them.

Best,

Marcel

Am 06.06.2020 18:17:35 schrieb Thiede, Christoph <[hidden email]>:

I just got it! It was indeed a question of load order. After moving #DisplayScreen in the StartUpList back to index 5 (instead of appending it at the end), my image starts again without renaming any files.

I suppose that all these renamings tricks were only relevant for deferring the execution of the startup list, which - so I suspect - reset the display screen depth temporarily at some point, I don't know.

So to summarize, to rescue your image, you have to:

• apply the 5 steps from my previous message once
• add DisplayScreen >> #startUp (*)
• Evaluate this:
  (SmalltalkImage classVarNamed: #StartUpList) add: #DisplayScreen afterIndex: 4
• And save your image.

I hope this helps other people to rescue their images, too :-)

* Source:

startUp  "DisplayScreen startUp"

Display setExtent: self actualScreenSize depth: Display nativeDepth.

Display beDisplay

Nevertheless thank you for the kind offer, Fabio!

---

Von: Squeak-dev <[hidden email]> im Auftrag von Fabio Niephaus <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:54:10
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save

 

On Sat, 6 Jun 2020 at 5:43 pm, Thiede, Christoph <[hidden email]> wrote:

Thank you, Jakob.

Well, I have to revoke my previous success message. Restarting my image another time and it crashes again on startup ...

But I have looked up my sources files. They do contain DisplayScreen class >> #startUp. And (Smalltalk class classVarNamed: #StartUpList) includes: #DisplayScreen. What could be the problem?

Wild guess: there's something wrong with the display form and the Windows VM crashes before the beDisplay primitive is called with a fresh one. That could explain why it works on macOS. I could have a look at the raw display object if you provide an image.

Fabio

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:33:16

An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save

 

Am Sa., 6. Juni 2020 um 17:25 Uhr schrieb Thiede, Christoph <[hidden email]>:

How did you hit on that?

 

That I tried the same copy of the VM from another folder at all is because I have the unpacked zips lying around and always copy the current VM that I use to a different folder, where the Windows file association looks for it. So when I switch VMs, I won't have to tell Windows again how to open these .image files...

I compared the folders with a merge tool (after renaming my Squeak64.exe .ini and .manifest back). All the binary files are equal, and Monticello/Metacello cache folders, the default image and changes file, debug logs, and crash dumps aside, the only meaningful difference left was eventually the presence of the sources file.