Smalltalk › Squeak › Squeak - Dev

LittleSmalltalk and loading od 2004 .pr

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Edgar De Cleene

LittleSmalltalk and loading od 2004 .pr

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

LittleSmalltalk.001.pr (48K) Download Attachment

ScriptableButton.st (10K) Download Attachment

my ScriptableButton.morph (4K) Download Attachment

Hannes Hirzel

Re: LittleSmalltalk and loading od 2004 .pr

On 6/29/18, Edgar J. De Cleene <[hidden email]> 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
>
>
>
>
>
>
>

Error_Cannot_read_this_segment_endianness.png (120K) Download Attachment

Hannes Hirzel

Re: LittleSmalltalk and loading od 2004 .pr

On 6/29/18, H. Hirzel <[hidden email]> wrote:

> On 6/29/18, Edgar J. De Cleene <[hidden email]> 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
>>
>>
>>
>>
>>
>>
>>
>

LittleSmalltalk.001.pr_loaded_into_Squeak3.10.2_BabyIDE_Screenshot_2018-06-29.png (32K) Download Attachment

Edgar De Cleene

Re: LittleSmalltalk and loading od 2004 .pr

In reply to this post by Hannes Hirzel

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 <[hidden email]> wrote:

Result of dropping LittleSmalltalk.001.pr onto the desktop of 5.2a:
the error message is attached

Edgar De Cleene

Re: LittleSmalltalk and loading od 2004 .pr

In reply to this post by Hannes Hirzel

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/164769/

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 <[hidden email]> 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

David T. Lewis

Re: LittleSmalltalk and loading od 2004 .pr

In reply to this post by Edgar De Cleene

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 <[hidden email]> 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

Edgar De Cleene

Re: LittleSmalltalk and loading od 2004 .pr

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 <[hidden email]> 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.

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

Hannes Hirzel

Re: LittleSmalltalk and loading od 2004 .pr

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 <[hidden email]> 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 <[hidden email]> 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
>
>

Loading_LittleSmalltalk.002.pr_saved_in_3.10.2_BabyIDE_Screenshot_2018-06-30.png (112K) Download Attachment

Edgar De Cleene

Re: LittleSmalltalk and loading od 2004 .pr

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" <[hidden email]> 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

Hannes Hirzel

Re: LittleSmalltalk and loading od 2004 .pr

On 6/30/18, Edgar J. De Cleene <[hidden email]> 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" <[hidden email]> 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
>
>
>
>

LittleSmalltalk.002.pr (131K) Download Attachment

K K Subbu

Re: LittleSmalltalk and loading od 2004 .pr

In reply to this post by David T. Lewis

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-td4811303.html#a4811856
----
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

K K Subbu

Re: LittleSmalltalk and loading od 2004 .pr

In reply to this post by Hannes Hirzel

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

Hannes Hirzel

Re: LittleSmalltalk and loading od 2004 .pr

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 <[hidden email]> 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
>
>

Hannes Hirzel

Re: LittleSmalltalk and loading od 2004 .pr

In reply to this post by K K Subbu

On 7/1/18, K K Subbu <[hidden email]> wrote:

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
>
>