Yes, this seems to describe my confusing scenario exactly. ��Thanks.
The thought is:���� Pharo 3.0.7 knows that it is version 3.0.7.�� Why then is Iceberg fetching by default version 8.0 from the Git repo?�� This destroys your confidence in the versioning system or, in my case, in the Pharo install itself, because I chose non-default folders, and am still wondering whether this is an issue.�� Can the handler of the installer of Pharo Launcher perhaps do an install to non-default folders, and test this idea.���� Can we tweak the installer of Pharo Launcher so that it will allow installation outside the user-account folder, without having first to create a folder under Program Files (x86) and add permissions?��
I���ve managed to crash the VM twice, with both Pharo 8 and Pharo 3.0.7, just by cloning a Git repo via Iceberg, and then by using Iceberg to fetch a version.���� Sometime during those calculations/comparisons, the VM crashed.�� I also used Iceberg to delete the pharo repo at several points, in order to start the exercise over.�� It worked, but Pharo was un-responsive in a tight synchronous thread during this operation, and there was no indication that anything sane was happening, not even a wait cursor.���� I���m wondering why we choose to leave the user wondering for long stretches (many minutes during the Iceberg/Git repo delete and 1 to 2 minutes during the earlier 20-odd-package delete) what is happening inside his Smalltalk image.�� Can someone explain the no-wait-cursor default in Pharo GUIs?
Can someone look at the .dmp file I attached to the e-mail describing the first VM crash, and tell me what he thinks happened?�� I saw mentions of a stack overflow.�� I still have the .dmp file from the second VM crash with Pharo 3.0.7, if anyone wants to see it.
Shaping