Should I put my unofficial V3 versions of Squeak 5.2 and 5.3 on files.squeak.org?

A couple of years ago, I put a copy of a Squeak 5.2 image in V3 object
memory format on the squeakvm.org server, and I linked to it from the
project page at http://www.squeaksource.com/TrunkUpdateStreamV3. That link
has gone dead, and I think I recall someone noticing it a recently.

I still have the files, should I put them somewhere on files.squeak.org?
I was thinking of putting them under the "various_images" folder:

        files.squeak.org/various_images/squeak_V3_images/

I also have a V3 image that is up to date with the Squeak 5.3 release,
so I could put that on line as well.

These images will run under an up-to-date interpreter VM or a Cog VM. They
may be of interest to people doing VM work, benchmarking, or as a reference
to understand the image-side differences between Spur and V3.

Dave

Hard to think of any reason *not* to have them available.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
How was Thomas J. Watson buried?  9 edge down.

Moving this to box-admins for assistance.

I have a couple of images that I would like to preserve for posterity
on files.squeak.org. They can go in a new folder under "various_images"

   files.squeak.org/various_images/squeak_V3_images/

Can someone on box-admins help me make this happen? I do not have access
to the server but I can put the files out on a google drive if that works.

I zipped up the files and put them here:

  https://drive.google.com/file/d/1wUZa4IHEkaTqzgwR3K1Wcwa9ckb7iVo2/view?usp=sharing

Thanks,
Dave


On Sat, Jul 25, 2020 at 10:35:22AM -0700, tim Rowledge wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


I'm not sure I understand what exactly are "unofficial V3 versions".

By the way, the ckformat.c C program which can be used to identify the
version of an image, could have a useful --help or --list option.

To list all of the image versions it knows about.

I think the Squeak class ImageFormat, which is used to create ckformat.c

via:

ImageFormat createCkFormatProgram

has a method to list all of the  known image formats.

So the ckformat.c program could also have a switch to list those formats;
or ckformat --help could show the known versions.

Regards,
David Stes


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJfHVbOAAoJEAwpOKXMq1Mam6YH/0tlF6iMkQnuUkW8N++KWzJL
lhMJ3I2YnrCijsCJkMfa8D+1JgYh5YB3ITYHuJgY02413rm2nsXxxvzmqp479ua2
o2ZAq/vTyl3mNPOalzHzt4sI6PMmtz5zXjZFKsVZg8hnyPDz+BVBnEFUa+e8tUUh
wLrnHfNzarwcz4vt8B6hU8Gz3H8SYNXJxobKAxLJ+3DvvNHX0SHgVbR71IzDnI0A
x+pbcfV4/dPCbpidvsar1ZdPj/iT+0KTp1StSKdzInahCsQT43rIf5lyujO52GsM
GfKCEHhhEjylYfris1jlKPoySnnwlG3Js504fiThHFUEVkEuPo9tnPHeSyVwlWA=
=ATkr
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Sorry for asking, but from your posting it is not so clear (to me at least),
what V3 format is.

I wonder whether this has anything to do with for example the 68000 format:

bash-4.4$ ckformat sq64-20101106-dtl.image
68000

There was a 68000 format for 64-bit Squeak V4 images, if I understand rightly.

It would be nice if the "ckformat" C program would print the same info as:

ImageFormat versionDescriptions

a Dictionary(6502->'a 32-bit image with no closure support and no native platform float word order requirement (6502)' 6504->'a 32-bit image with closure support and no native platform float word order requirement (6504)' 6505->'a 32-bit image with closure support and float words stored in native platform order (6505)' 6521->'a 32-bit image with closure support and float words stored in native platform order using Spur object format (6521)' 68000->'a 64-bit image with no closure support and no native platform float word order requirement (68000)' 68002->'a 64-bit image with closure support and no native platform float word order requirement (68002)' 68003->'a 64-bit image with closure support and float words stored in native platform order (68003)' 68019->'a 64-bit image with closure support and float words stored in native platform order using Spur object format (68019)' )

First of all in the above there is no mention of "V3 images".

It just states images with or without closure support/float etc.

The terminology "V3 images" is not used in the ImageFormat class.

But next, based on the Dictionary, the ckformat.c program could print

bach-4.4$ ckformat
6502 a 32-bit image with no closure support and no native platform float word order requirement (6502)
6504 a 32-bit image with closure support and no native platform float word order requirement (6504)
6505 a 32-bit image with closure support and float words stored in native platform order (6505)
6521 a 32-bit image with closure support and float words stored in native platform order using Spur object format (6521)
68000 a 64-bit image with no closure support and no native platform float word order requirement (68000)
68002 a 64-bit image with closure support and no native platform float word order requirement (68002)
68003 a 64-bit image with closure support and float words stored in native platform order (68003)
68019 a 64-bit image with closure support and float words stored in native platform order using Spur object format (68019)

and so on (for example if ckformat is used with --list or without argument).

Like this you have on the UNIX command line with ckformat the same info
as 'ImageFormat versionDescriptions' provides.

David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJfHbykAAoJEAwpOKXMq1MaxMcH/A7xFzmfwMCNIpFIrZ9O+DFk
+yQ8/Q6SD6WAm9Wk8IGubRWgsN+4fFunHFf4fkxAfcOQco+7vy3Tkqfr9uFVx1Hs
75xZCM5hah1k0xEpUIqQYNXrLMQ1xROT3fbK5JDC7gw+QVYd8ceOmiAygE+ZLnlT
sYfj+coo9dpGZ3Q1tVNFhuVnkl+5yJZ6HGZ6R7LBnUBW3j4tOtFre9QSEUw+kT56
VLvonx1fUOjZPjee8MxqWTtaFf/Dfheajtc8YvfEdBcew8HM029GbBCTNDC/IkJz
5PLCbCMweYXbBY4X/gSoGhyQatf0kxGrHSJCIGbMce1ztAYhGuRyd57Y1D6Br88=
=8ET1
-----END PGP SIGNATURE-----

Hi David,

On Sun, Jul 26, 2020 at 07:27:23PM +0200, [hidden email] wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> Sorry for asking, but from your posting it is not so clear (to me at least),
> what V3 format is.

Good question, and to be honest I actually don't know where the term "V3"
originates, but within VMMaker it refers to the traditional object memory
format prior to the introduction of Spur.


>
> I wonder whether this has anything to do with for example the 68000 format:
>
> bash-4.4$ ckformat sq64-20101106-dtl.image
> 68000
>
> There was a 68000 format for 64-bit Squeak V4 images, if I understand rightly.
>

There is a very good (brief) description of the object memory format in
class ObjectMemory, written by Dan Ingalls. It describes the original
32-bit object memory, as well as the simple 64-bit extension of that format
that Dan did with Ian Piumarta. This was (I believe) intended as TSTTCPW
to prove out the viability of 64-bit images. Later work by Eliot Miranda
gave us the 64-bit (and 32-bit) Spur object memory that is used for
Squeak images today.

The original object memory (both 32-bit and 64-bit) was designed at a
time when 64-bit computers and cell phones were in the distant future.
Spur is a newer design that takes better advantage of today's 64-bit
machines, and that also eliminates some design limitations going back
to those earlier days. For example, Spur uses a common object header
design for 32- and 64-bit images, and it permits more kinds of objects
(characters, floating point objects) to be efficiently represented
internally as immediate objects.

Note, there is no such thing as a "V4 image", we had some releases of
Squeak in the "version 4.x" range. But it is just an accident of naming
conventions that the last of the "V3" image formats ended with the
Squeak 4.6 release. Squeak 5.x is based on Spur, and Squeak 4.6 and
earlier used the V3 image format.



That is a very good idea. I just updated ImageFormat-dtl.42 with your suggestion.
When called with no argument, the ckformat program now does this:

$ ./ckformat
usage: ckformat imageFileName
answer the image format number for an image file or 0 if not known
known image formats:
6502: a 32-bit V3 image with no closure support and no native platform float word order requirement
6504: a 32-bit V3 image with closure support and no native platform float word order requirement
6505: a 32-bit V3 image with closure support and float words stored in native platform order
6521: a 32-bit Spur image with closure support and float words stored in native platform order using Spur object format
7033: a 32-bit Spur image with closure support and float words stored in native platform order using Spur object format and multiple bytecode sets
68000: a 64-bit V3 image with no closure support and no native platform float word order requirement
68002: a 64-bit V3 image with closure support and no native platform float word order requirement
68003: a 64-bit V3 image with closure support and float words stored in native platform order
68004: a 64-bit V3 image with closure support and no native platform float word order requirement
68019: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format (obsolete)
68021: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format
68533: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format and multiple bytecode sets

I did not attempt to add argument parsing (--list) but I hope that adding
this to the zero-argument message will be good enough. It's certainly a nice
and easy enhancement :-)

Thanks,
Dave

David T. Lewis wrote on Sun, 26 Jul 2020 14:40:03 -0400
> On Sun, Jul 26, 2020 at 07:27:23PM +0200, stes wrote:
> > Sorry for asking, but from your posting it is not so clear (to me at least),
> > what V3 format is.
>
> Good question, and to be honest I actually don't know where the term "V3"
> originates, but within VMMaker it refers to the traditional object memory
> format prior to the introduction of Spur.

The term was created in 2002 to contrast with Anthony Hannon's VI4
Squeak with its new image format and new bytecodes. This did not get
adopted by our community and it became confusing when the official
Squeak 4.0 and later continued using the V3 image format until Spur was
finally adopted.

https://wiki.squeak.org/squeak/2119

-- Jecel

Hi Eliot,

On Sat, Jul 25, 2020 at 08:33:38PM -0700, Eliot Miranda wrote:
Not to worry, there are no changes to trunk. The project page for
http://www.squeaksource.com/TrunkUpdateStreamV3.html explains what
I have been doing.

In general, I have been able to keep MCM file numbers in sync between
trunk and the packages in TrunkUpdateStreamV3. So for example if you
have a Squeak 5.2 image with Compiler-eem.394 then you can look at
Compiler.V3-dtl.393 in the TrunkUpdateStreamV3 repository to see the
differences. Please don't expect this to be perfect, it definitely
is not.

I should note that Juan has been maintaining Cuis for Spur64, Spur32,
and V3 from a common code base. So if someone is interested in how
much complexity is added by supporting this, then Cuis is the best
reference.

Dave

Hello Jecel,

On Sun, Jul 26, 2020 at 03:58:01PM -0300, Jecel Assumpcao Jr wrote:
Thank you! It make perfect sense now.

Dave
 

On Sun, Jul 26, 2020 at 12:12:42PM +0200, [hidden email] wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> I'm not sure I understand what exactly are "unofficial V3 versions".
>

By "unofficial" I mean that it is completely unrelated to any officially
announced versions of Squeak that appear on squeak.org and that are expected
to be of high quality and worthy of long term support.

This is just stuff that I have done on my own and that may be of interest
to a few other people, that's all.

Dave

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Wow, that was fast ...

It didn't take you a lot of time to implement that feature ...

Following the instructions https://wiki.squeak.org/squeak/6177,
(to update/load ImageFormat from the Monticello VMMaker repository)
I recreated the ckformat.c program with : ImageFormat createCkFormatProgram

It seems you now use the term "V3" image and "Spur" image:

bash-4.4$ ./ckformat squeak6.image
68021

bash-4.4$ ./ckformat
6502: a 32-bit V3 image with no closure support and no native platform float word order requirement
...
68533: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format and multiple bytecode sets

Thanks, this is a useful list ...

David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJfHr9RAAoJEAwpOKXMq1Ma1joIAIEwyQV4zNT+vr3AurKhsBwD
YmvV8NDk+Mijgf7GAQBrdk7J6qU0MenwEACvFN3cXTaBD4uaEoVrjpsl80XeeigA
fvOUkSzwLMq9c4tAZ0F8ReNmW1Bq6xKyOmEpz0C2C+Gim3abzgjv+BoPXgX6rO8E
J88WtQHiPVH2BSMiJq1rZyP9QRMaOjp2za3nc7UnT0nLJVlSpYcyvhioSxgTRejM
o/YXHqjRy+CAsYM62CyfuCgFfaG7VHqhjlUtYv4sM2cVB46LXdg23K335kmQytno
65njsthZ3qmLzylu+lrDbD+qw6IeF7L+Ok5QWY4DiskMiZJkxQ9hW8NWbNP9EtA=
=QYe0
-----END PGP SIGNATURE-----

Hi Dave,

On Jul 26, 2020, at 12:37 PM, David T. Lewis wrote:

> By "unofficial" I mean that it is completely unrelated to any  
> officially
> announced versions of Squeak that appear on squeak.org and that are  
> expected
> to be of high quality and worthy of long term support.
>
> This is just stuff that I have done on my own and that may be of  
> interest
> to a few other people, that's all.

It is of interest to me, for whatever that's worth.

Thanks to you for making these images and thanks to whomever helped  
you get them onto files.squeak.org!

Best,
another Tim