Folks:
I go again to LittleSmalltalk in the quest of having some Smalltak in WebAssembly.
For the forks of LittleSmalltalk which compiles without any complain and works in macOS High Sierra 10.13.5
https://github.com/kyle-github/littlesmalltalk https://github.com/suetanvil/lst3r
Today I remember having some of 2004 which I attach here The project load in 3.10.2 I attach SciptableButton as do not exist in 5.2 But .pr fails to load complaint about endianess . First time I see such in years of use Mac Linux and Windows Maybe the original was saved in a G4, but today opens in 3.10.2. I remade this in 5.2 as could be a valuable thing in 5.2 Now we have Enviroments enhanced, so maybe could made a very tiny thing The Kyle implementation lets have a html view of the system in less of 3500 object and a start image of 93kb. No bad starting point ...
Edgar @morplenauta
On 6/29/18, Edgar J. De Cleene edgardec2005@gmail.com wrote:
Folks:
I go again to LittleSmalltalk in the quest of having some Smalltak in WebAssembly.
For the forks of LittleSmalltalk which compiles without any complain and works in macOS High Sierra 10.13.5
https://github.com/kyle-github/littlesmalltalk https://github.com/suetanvil/lst3r
Today I remember having some of 2004 which I attach here The project load in 3.10.2 I attach SciptableButton as do not exist in 5.2 But .pr fails to load complaint about endianess .
Result of dropping LittleSmalltalk.001.pr onto the desktop of 5.2a: the error message is attached
--Hannes
First time I see such in years of use Mac Linux and Windows Maybe the original was saved in a G4, but today opens in 3.10.2. I remade this in 5.2 as could be a valuable thing in 5.2 Now we have Enviroments enhanced, so maybe could made a very tiny thing The Kyle implementation lets have a html view of the system in less of 3500 object and a start image of 93kb. No bad starting point ...
Edgar @morplenauta
On 6/29/18, H. Hirzel hannes.hirzel@gmail.com wrote:
On 6/29/18, Edgar J. De Cleene edgardec2005@gmail.com wrote:
Folks:
I go again to LittleSmalltalk in the quest of having some Smalltak in WebAssembly.
For the forks of LittleSmalltalk which compiles without any complain and works in macOS High Sierra 10.13.5
https://github.com/kyle-github/littlesmalltalk https://github.com/suetanvil/lst3r
Today I remember having some of 2004 which I attach here The project load in 3.10.2
Yes, result is attached. I click on the button and create new basic classes. Nothing seems to happen. Then how do I proceed?
I attach SciptableButton as do not exist in 5.2 But .pr fails to load complaint about endianess .
Result of dropping LittleSmalltalk.001.pr onto the desktop of 5.2a: the error message is attached
--Hannes
First time I see such in years of use Mac Linux and Windows Maybe the original was saved in a G4, but today opens in 3.10.2. I remade this in 5.2 as could be a valuable thing in 5.2 Now we have Enviroments enhanced, so maybe could made a very tiny thing The Kyle implementation lets have a html view of the system in less of 3500 object and a start image of 93kb. No bad starting point ...
Edgar @morplenauta
i found the project is incomplete as the files used do not exist. But is important to me i found more info about building a LittleSmalltlk .image http://developers-club.com/posts/164153/ http://developers-club.com/posts/164153/ http://developers-club.com/posts/164769/ http://developers-club.com/posts/164769/ http://developers-club.com/posts/191250/ http://developers-club.com/posts/191250/
Seems the original idea of 2003/2004 was have a LittleSmaltalk system inside Squeak. Following what once I made, the missing file could be the basic list of original LS3 clases. Need much work, but good for learn lots
On 29 Jun 2018, at 17:19, H. Hirzel hannes.hirzel@gmail.com wrote:
Yes, result is attached. I click on the button and create new basic classes. Nothing seems to happen. Then how do I proceed?
I attach SciptableButton as do not exist in 5.2 But .pr fails to load complaint about endianess .
Result of dropping LittleSmalltalk.001.pr onto the desktop of 5.2a: the error message is attached
--Hannes
First time I see such in years of use Mac Linux and Windows Maybe the original was saved in a G4, but today opens in 3.10.2. I remade this in 5.2 as could be a valuable thing in 5.2 Now we have Enviroments enhanced, so maybe could made a very tiny thing The Kyle implementation lets have a html view of the system in less of 3500 object and a start image of 93kb. No bad starting point ...
Edgar @morplenauta
Yes, this is the error. Why the endianness could be a problem if this is opened in 3.10.2 ?
On 29 Jun 2018, at 17:04, H. Hirzel hannes.hirzel@gmail.com wrote:
Result of dropping LittleSmalltalk.001.pr onto the desktop of 5.2a: the error message is attached
On Fri, Jun 29, 2018 at 05:28:31PM -0300, Edgar De Cleene wrote:
Yes, this is the error.
On 29 Jun 2018, at 17:04, H. Hirzel hannes.hirzel@gmail.com wrote:
Result of dropping LittleSmalltalk.001.pr onto the desktop of 5.2a: the error message is attached
Why the endianness could be a problem if this is opened in 3.10.2 ?
Squeak images are saved with the native byte ordering of the machine from which they were saved (https://en.wikipedia.org/wiki/Endianness). I believe that this is true of image segments also.
The platforms that we use today (Linux, Windows, OS X) are all little-endian, but the older Mac machines were big-endian. If the project was originally saved from a Mac, then it was probably saved in a big-endian format.
It is possible that Squeak has lost the ability to handle big-endian images, and it may be that projects saved from older Macs cannot be loaded into Squeak today.
If that is the case (and I am only guessing), then a possible workaround would be to load the old projects into an old Squeak image, save the project again to a new file, and then load that new project file into a modern Squeak image.
Dave
Yes, i agree with your analysis. As the original is very old , is probably saved in a G4, so big endian. The 3.10.2 which do not have this problem uses the JMM Squeak 4.2.5beta1U which runs on both G4 and Intel Macs. No idea if how many projects could be valuable to rescue. Is not a problem,
Thanks
On 29 Jun 2018, at 18:44, David T. Lewis lewis@mail.msen.com wrote:
Squeak images are saved with the native byte ordering of the machine from which they were saved (https://en.wikipedia.org/wiki/Endianness https://en.wikipedia.org/wiki/Endianness). I believe that this is true of image segments also.
The platforms that we use today (Linux, Windows, OS X) are all little-endian, but the older Mac machines were big-endian. If the project was originally saved from a Mac, then it was probably saved in a big-endian format.
It is possible that Squeak has lost the ability to handle big-endian images, and it may be that projects saved from older Macs cannot be loaded into Squeak today.
If that is the case (and I am only guessing), then a possible workaround would be to load the old projects into an old Squeak image, save the project again to a new file, and then load that new project file into a modern Squeak image.
Dave
Hello
the discussion about endianness and re-saving the project brought me to the idea of doing the following.
a) Take a Squeak 3.10.2 image such as the http://folk.uio.no/trygver/assets/BabyIDE.zip version from Trygve Reenskaug
use an interpreter VM to open it. (this is the VM you get when you install it from the 'software center' in Ubuntu, i.e. the interpreter VM.
b) start Squeak 3.10.2 with squeak 7179-basic.356publ.image
c) drop LittleSmalltalk.001.pr onto the desktop of the BabyIDE (Squeak 3.10.2) version.
d) save the project locally (I have chosen 'include change sets') In the Squeaklets folder there is now LittleSmalltalk.002.pr
e) drop LittleSmalltalk.002.pr onto the desktop of Squeak 5.2a latest update: #18117
This now does NO LONGER bring up the endianness error message. It brings up message which is well known in the meantime about MethodProperties.
See this thread
http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-June/199340.html
Change of MethodProperties. An issue were Eliot M. commented on it.
My suggestion is to make the project fully work in 3.10.2 BabyIDE, that will allow also to create some nice diagrams.
I understand that just some files are missing in the image directory.
Then the project might be re-done it in 5.2a using the insight gained doing the work in 3.10.2
HTH --Hannes
On 6/29/18, Edgar De Cleene edgardec2005@gmail.com wrote:
Yes, i agree with your analysis. As the original is very old , is probably saved in a G4, so big endian. The 3.10.2 which do not have this problem uses the JMM Squeak 4.2.5beta1U which runs on both G4 and Intel Macs. No idea if how many projects could be valuable to rescue. Is not a problem,
Thanks
On 29 Jun 2018, at 18:44, David T. Lewis lewis@mail.msen.com wrote:
Squeak images are saved with the native byte ordering of the machine from which they were saved (https://en.wikipedia.org/wiki/Endianness https://en.wikipedia.org/wiki/Endianness). I believe that this is true of image segments also.
The platforms that we use today (Linux, Windows, OS X) are all little-endian, but the older Mac machines were big-endian. If the project was originally saved from a Mac, then it was probably saved in a big-endian format.
It is possible that Squeak has lost the ability to handle big-endian images, and it may be that projects saved from older Macs cannot be loaded into Squeak today.
If that is the case (and I am only guessing), then a possible workaround would be to load the old projects into an old Squeak image, save the project again to a new file, and then load that new project file into a modern Squeak image.
Dave
I do exactly this in Mac and still have the error. See today if in Linux have same issue, for completeness. Again is no problem. I made a .cs in 3.10.2 including the the code for ScriptableButton and load this and the morph first.
Edgar @morplenauta
On 29/06/2018, 19:18, "H. Hirzel" hannes.hirzel@gmail.com wrote:
Hello
the discussion about endianness and re-saving the project brought me to the idea of doing the following.
a) Take a Squeak 3.10.2 image such as the http://folk.uio.no/trygver/assets/BabyIDE.zip version from Trygve Reenskaug
use an interpreter VM to open it. (this is the VM you get when you install it from the 'software center' in Ubuntu, i.e. the interpreter VM.
b) start Squeak 3.10.2 with squeak 7179-basic.356publ.image
c) drop LittleSmalltalk.001.pr onto the desktop of the BabyIDE (Squeak 3.10.2) version.
d) save the project locally (I have chosen 'include change sets') In the Squeaklets folder there is now LittleSmalltalk.002.pr
e) drop LittleSmalltalk.002.pr onto the desktop of Squeak 5.2a latest update: #18117
This now does NO LONGER bring up the endianness error message. It brings up message which is well known in the meantime about MethodProperties.
See this thread
On 6/30/18, Edgar J. De Cleene edgardec2005@gmail.com wrote:
I do exactly this in Mac and still have the error.
I did it on Linux.
Sorry I forgot to attach the project file in my previous mail from yesterday. The version attached is the one I loaded into Squeak 3.10.2 (BabyIDE) and then saved it again.
HTH
--Hannes
See today if in Linux have same issue, for completeness. Again is no problem. I made a .cs in 3.10.2 including the the code for ScriptableButton and load this and the morph first.
Edgar @morplenauta
On 29/06/2018, 19:18, "H. Hirzel" hannes.hirzel@gmail.com wrote:
Hello
the discussion about endianness and re-saving the project brought me to the idea of doing the following.
a) Take a Squeak 3.10.2 image such as the http://folk.uio.no/trygver/assets/BabyIDE.zip version from Trygve Reenskaug
use an interpreter VM to open it. (this is the VM you get when you install it from the 'software center' in Ubuntu, i.e. the interpreter VM.
b) start Squeak 3.10.2 with squeak 7179-basic.356publ.image
c) drop LittleSmalltalk.001.pr onto the desktop of the BabyIDE (Squeak 3.10.2) version.
d) save the project locally (I have chosen 'include change sets') In the Squeaklets folder there is now LittleSmalltalk.002.pr
e) drop LittleSmalltalk.002.pr onto the desktop of Squeak 5.2a latest update: #18117
This now does NO LONGER bring up the endianness error message. It brings up message which is well known in the meantime about MethodProperties.
See this thread
I dug into this a little deeper today as it gave me an opportunity to study ImageSegments. I extracted the cs from 001 and used a binary editor to search for version number. I found one sequence 16r64006619 which decodes to a big-endian 6502 ImageSegment. In 002, I found the sequence 16r66190073 which decodes to a little-endian segment.
When I dropped 001 pr into Squeak 5.2alpha (18120/64b/Ubuntu) and examined the resulting error stack I found something strange.
Before the endian check in LegacyImageSegment>>#comeFullyUpOnReload, the instance is already created in DataStream>>#next method assuming little-endian, so segment ivar first word is 16r66190064. Therefore, the endianness check in:
ImageSegment>>endianness ... ^(segment first bitShift: -24) asCharacter == $d ifTrue: [#big] ifFalse: [#little]
ends up checking the wrong byte for endianness. I changed this code to check for both $s and $d and confirmed that endian check is incorrect at this point.
I got stuck here. How should one fix this error?
Regards .. Subbu
Now test case No: 21 on http://wiki.squeak.org/squeak/1183 with details here http://wiki.squeak.org/squeak/1261
Details need to be refined, in particular an interaction diagram (e.g use https://sequencediagram.org/ to draw the diagram) would be helpful and some references to definitions and a summary of the questions.
On 7/1/18, K K Subbu kksubbu.ml@gmail.com wrote:
I dug into this a little deeper today as it gave me an opportunity to study ImageSegments. I extracted the cs from 001 and used a binary editor to search for version number. I found one sequence 16r64006619 which decodes to a big-endian 6502 ImageSegment. In 002, I found the sequence 16r66190073 which decodes to a little-endian segment.
When I dropped 001 pr into Squeak 5.2alpha (18120/64b/Ubuntu) and examined the resulting error stack I found something strange.
Before the endian check in LegacyImageSegment>>#comeFullyUpOnReload, the instance is already created in DataStream>>#next method assuming little-endian, so segment ivar first word is 16r66190064. Therefore, the endianness check in:
ImageSegment>>endianness ... ^(segment first bitShift: -24) asCharacter == $d ifTrue: [#big] ifFalse: [#little]
ends up checking the wrong byte for endianness. I changed this code to check for both $s and $d and confirmed that endian check is incorrect at this point.
I got stuck here. How should one fix this error?
Regards .. Subbu
On 7/1/18, K K Subbu kksubbu.ml@gmail.com wrote:
I dug into this a little deeper today as it gave me an opportunity to study ImageSegments. I extracted the cs from 001 and used a binary editor to search for version number. I found one sequence 16r64006619 which decodes to a big-endian 6502 ImageSegment. In 002, I found the sequence 16r66190073 which decodes to a little-endian segment.
When I dropped 001 pr into Squeak 5.2alpha (18120/64b/Ubuntu) and examined the resulting error stack I found something strange.
Before the endian check in LegacyImageSegment>>#comeFullyUpOnReload,
The method comeFullyUpOnReload
needs more comments and probably some refactoring into smaller easier understandable methods.
Some more notes may go here: http://wiki.squeak.org/squeak/1280
--Hannes
instance is already created in DataStream>>#next method assuming little-endian, so segment ivar first word is 16r66190064. Therefore, the endianness check in:
ImageSegment>>endianness ... ^(segment first bitShift: -24) asCharacter == $d ifTrue: [#big] ifFalse: [#little]
ends up checking the wrong byte for endianness. I changed this code to check for both $s and $d and confirmed that endian check is incorrect at this point.
I got stuck here. How should one fix this error?
Regards .. Subbu
On Saturday 30 June 2018 03:14 AM, David T. Lewis wrote:
Squeak images are saved with the native byte ordering of the machine from which they were saved (https://en.wikipedia.org/wiki/Endianness). I believe that this is true of image segments also.
Projects files use VM-specific encoding, so they can't be used across different types of VM :-(
From http://forum.world.st/4-6-5-0-how-to-help-users-manage-different-formats-td4... ---- An ImageSegment is a WordArray whose contents are a sequence of heap objects in the VM's native object format. A segment is loaded by invoking a primitive that swizzles the pointers in the word array so that they become valid objects, and then shortening the word array, leaving the objects behind in memory. Since the contents of the WordArray are specific to a given VM architecture one cannot use the primitive loading mechanism to load segments from VMs with different object representations. ----
I am confused with the first statement. segment in ImageSegment is byte indexed and ByteArray has support for endian read/writes. Is there any reason why WordArray was used instead of ByteArray?
HTH .. Subbu
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Edgar De Cleene -
Edgar J. De Cleene
-
H. Hirzel -
K K Subbu