Problems with very old Squeak releases

On Fri, Dec 15, 2017 at 03:38:59PM -0500, Phil B wrote:
> I was doing some spelunking on historical images and ran into a couple
> issues...
>
> The page at files.squeak.org/2.8 has problems rendering (tag mismatch on
> cpu-vendor-os in both Firefox and Chromium) so I can't get a download link.
> (The 2.7 and 3.0 pages are fine so it appears specific to this version)
>
> Also on a somewhat related note, I am not able to run 1.x images using the
> classic VM... should this be expected to work or is there another Linux VM
> around that will work?

The answer is "yes, but..."

Yes, the classic VM runs images from Squeak 1.2 through 4.6.

But, the official releases on http://squeakvm.org are out of date, so you
have to compile it yourself. If you are using Linux, this is easy to do,
see http://wiki.squeak.org/squeak/6354 for the instructions.

For earlier images such as Squeak 1.1, try using SqueakJS (http://try.squeak.org).

Dave

> On 15.12.2017, at 23:18, Phil B <[hidden email]> wrote:
>
> Thanks Tobias!  Probably no cookie for me but I'd guess the page generation choked on something in the readme or a file name? (i.e. didn't properly escape a character or sequence of chars)
>

Yea, the readme used  <...> somewhere and the brower thought it had to interpret that as xml…

Best regards
        -Tobias

> On Dec 15, 2017 4:06 PM, "Tobias Pape" <[hidden email]> wrote:
>
> > On 15.12.2017, at 21:38, Phil B <[hidden email]> wrote:
> >
> > I was doing some spelunking on historical images and ran into a couple issues...
> >
> > The page at files.squeak.org/2.8 has problems rendering (tag mismatch on cpu-vendor-os in both Firefox and Chromium) so I can't get a download link. (The 2.7 and 3.0 pages are fine so it appears specific to this version)
> >
>
> Thats what one gets for trying cheap fancy directory indexes :)
> (that means: sorry, my fault)
>
> Fixed now.
>
> Best regards
>         -Tobias
> PS: you get a cookie if you guess what happened
>
> > Also on a somewhat related note, I am not able to run 1.x images using the classic VM... should this be expected to work or is there another Linux VM around that will work?
> >
> > Thanks,
> > Phil
> >
>
>
>
>

On Mon, Dec 18, 2017 at 04:50:29PM -0500, Phil B wrote:
> Dave,
>
> I have been trying using a built classic VM (which works fine with 3.x
> images but hangs on startup on every 1.x or 2.x image I've tried).  I last
> built it from sources a year ago or more so I'll try downloading the latest
> sources and try again.

Yes please try it again. The enhancements to support older images with the
classic VM were done in January 2017.

>
> It would be great to have this as an option for old images as the shipped
> VMs from that time period seem have an annoying transparent window issue on
> recent Linux distros so unless I put a black window behind the Squeak
> window, it's very difficult to see what's going on (screenshot attached to
> illustrate.).  Should anyone recalling the specifics of the VM builds back
> then be reading: is this because true color depths weren't common back then
> or is something else going on?
>

The change history is in http://source.squeak.org/VMMaker in package 'VMMaker',
so you can browse the history with a Monticello browser.

The recent updates that pertain to older image support are:

===

Name: VMMaker-dtl.392
Author: dtl
Time: 12 January 2017, 8:34:22.25 pm
UUID: 7c31d31d-9de0-4f45-89e2-6caa1886f12f
Ancestors: VMMaker-dtl.391

VMMaker 4.16.3

Support very early images in which method context copy fails due to stack
pointer not yet adjusted to position. For these images, disable stack limit
bounds check. Based on SqueakJS implementation as described below.

From: Bert Freudenberg <[hidden email]>
Date: Wed, 11 Jan 2017 17:10:24 +0100
To: The general-purpose Squeak developers list <[hidden email]>
Subject: Re: [squeak-dev] Backward image and VM compatibility

Some early images fill the context stack before advancing its stack pointer.
I have a flag to allow that, it's pretty certainly used in primitive 61.
Normally the VM does not allow access beyond the SP because there is garbage
there (stack pops do not nil out the context slot):

https://github.com/bertfreudenberg/SqueakJS/search?q=allowAccessBeyondSP

But since the regular VM does not allow it, no image (except the really old
ones) ever does it, so I just leave the flag enabled whenever "oldPrims" is
in effect ;) Would be better if we could come up with a better way to identify
these images.

===

Name: VMMaker-dtl.391
Author: dtl
Time: 5 January 2017, 7:35:14.1 pm
UUID: eb3fd060-b323-4a7d-9b06-b4b23f599fc8
Ancestors: VMMaker-dtl.390

VMMaker 4.16.2

Old image support: Rescue five sound primitive assignments for updatePrimitiveTable
for primitives that should be loaded from SouondGenerationPlugin, not from SoundPlugin.

The following ancient primitives are still not loadable into the primitiive
table for old image support:

  #primWaveTableSoundmixSampleCountintostartingAtpan
  #primFMSoundmixSampleCountintostartingAtpan
  #primPluckedSoundmixSampleCountintostartingAtpan
  #primSampledSoundmixSampleCountintostartingAtpan
  #oldprimSampledSoundmixSampleCountintostartingAtleftVolrightVol

In addition #primitiveReadJoystick does not load from JoystickTabletPlugin
when running on Linux, but this is confirmed to be an artifact of the function
loader, which abandons the attempt to load a module if #initialiseModule
answers false, as is the case in the Unix stub code implementation (so it
should work on platforms that do support the joystick plugin).

===

Name: VMMaker-dtl.390
Author: dtl
Time: 2 January 2017, 8:52:00.539 pm
UUID: 1fb628a6-18d2-4d86-b651-dc3b3d0cce69
Ancestors: VMMaker-dtl.389

VMMaker 4.16.1 - Support older Squeak images back to version 1.13 (circa 1996)

This set of updates is based on SqueakJS as a reference implementation that
supports a full range of images from Squeak 1.13 through the latest Spur images.

Numbered primitives are identified in the primitive table, established by the
implementations of #initializePrimitiveTable in the various images. Class
PrimitiveTableHistory has been added to document known versions of the
primitive table.

Background: In general, primitives that originated as numbered primitives in early
Squeak versions have been reimplemented as named primitives in the base
interpreter and in various interpreter plugins. The goal is to reduce or eliminate
use of numbered primitives. Support for old images therefore amounts to reassiging
the old primitive numbers to named primitives where necessary to support
running an older image.

Strategy: Check if the current image #hasClosures based on the image format
number, then provide an older set of numbered primitives suitable for a range of
pre-closure images dating back to Squeak 1.13. Do this by starting with the
default primitive table, checking at entry to interpreter() to see if this is a
pre-closure image, then installing old primitives as needed in #updatePrimitiveTable.

Interpreter primitives that require a primitive number for older images are
added to the primitive table with #installPrimitive:at: and primitives that are now
implemented in interpreter plugins are loaded and installed in the primitive
table with #installPrimitive:from:at:.

===

Name: VMMaker-dtl.389
Author: dtl
Time: 21 December 2016, 6:31:30.057 pm
UUID: 3cce2df0-2d06-46f6-bed2-8946fb48c878
Ancestors: VMMaker-dtl.388

VMMaker 4.15.11

Fix the interpreter for running images of the Squeak 3.6 and 3.8 era. Several
obsolete primitives were removed in VMMaker-dtl.387, but these are still
required for older images.

For this update, the primitive table initialiation is unchanged, but a run
time update is done for the ContextInterpreter to restore the old primitive
assignments. It is not clear if this will be a good strategy but for now add
InterpreterPrimitives>>installPrimitive:at: and use it to update the table
on first entry to the interpret() loop.

Possible future updates could support run time fixup to the primitive table
for Squeak 3.2 and earlier images.

===

Dave

On Wed, Dec 27, 2017 at 05:27:52PM -0500, Phil B wrote:
>
> On Dec 27, 2017 5:25 PM, "tim Rowledge" <[hidden email]> wrote:
>
> >
> > > On 27-12-2017, at 2:21 PM, Phil B <[hidden email]> wrote:
> > >
> > > Dave,
> > >
> > > I've been trying to get the latest sources but when I try:
> > > svn co http://squeakvm.org/svn/squeak/trunk/platforms
> > >
> > > I get:
> > > svn: E020014: Can't find a temporary directory: Internal error
> >
> > Hah! I was just about to mention the same problem. Tried fetching those for
> > a RISC OS experiment and boom, fail.
> >
>
> Heh... At least now I know not to keep banging my head thinking it's a
> local issue!
>

Oops. According to google, that means the server is out of disk space ... which in fact it is.

I sent mail to Ian to ask for help, and I deleted some files from /tmp to
get things working again. Ian gave me root access quite some time ago to
help with things like this, so I'll keep an eye on it.

Sorry,
Dave