Squeak Trunk V3 Update Stream

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Squeak Trunk V3 Update Stream

David T. Lewis
This project provides an update stream that, starting with a Squeak 4.6 release
image, produces an up-to-date trunk level image that can be run with either a
Cog/Stack or classic interpreter VM.

The resulting image uses the traditional V3 object memory format, and therefore
does not support Spur enhancements (immediate characters and floats, enhanced
memory management, etc). It does however run most Squeak functionality exactly
like Squeak trunk on Spur.

I put an update on the swiki here: http://wiki.squeak.org/squeak/6592

The trunk V3 image may be useful for performance comparisons related to
V3/Spur/Cog/Sista variants.

Note, this is a long-term update for a project that I did not intend to keep
alive this long. I had originally intended to maintain the V3 update stream
or one Squeak release cycle, but it has turned out to be useful for keeping
the classic interpreter VM updated with respect to VM primitives, and has
been something of a learning experience for me to keep up with the Context
refactorings, Compiler and Kernel changes, and Sista bytecodes. So for better
or worse, the V3 trunk stream is still alive, and I figured that it is worth
a mention on the squeak-dev list :-)

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Squeak Trunk V3 Update Stream

marcel.taeumel
Thank you, Dave, for supporting the V3 format!

We should also put more effort into a better SystemTracer to be able to convert between image formats (including 64/32 bits) back and forth -- even if there are some limitations. Think about converting between JPG and PNG, which is sometimes quite convenient to have. :-)

Best,
Marcel

Am 14.02.2018 05:36:51 schrieb David T. Lewis <[hidden email]>:

This project provides an update stream that, starting with a Squeak 4.6 release
image, produces an up-to-date trunk level image that can be run with either a
Cog/Stack or classic interpreter VM.

The resulting image uses the traditional V3 object memory format, and therefore
does not support Spur enhancements (immediate characters and floats, enhanced
memory management, etc). It does however run most Squeak functionality exactly
like Squeak trunk on Spur.

I put an update on the swiki here: http://wiki.squeak.org/squeak/6592

The trunk V3 image may be useful for performance comparisons related to
V3/Spur/Cog/Sista variants.

Note, this is a long-term update for a project that I did not intend to keep
alive this long. I had originally intended to maintain the V3 update stream
or one Squeak release cycle, but it has turned out to be useful for keeping
the classic interpreter VM updated with respect to VM primitives, and has
been something of a learning experience for me to keep up with the Context
refactorings, Compiler and Kernel changes, and Sista bytecodes. So for better
or worse, the V3 trunk stream is still alive, and I figured that it is worth
a mention on the squeak-dev list :-)

Dave




Reply | Threaded
Open this post in threaded view
|

Re: Squeak Trunk V3 Update Stream

David T. Lewis
On Wed, Feb 14, 2018 at 07:57:15AM +0100, Marcel Taeumel wrote:
> Thank you, Dave, for supporting the V3 format!

It is a long way from perfect, but with some patience and manual
intervention, the image updates can be done all the way from Squeak 4.6
to the current level of trunk.

Attached is a screen shot to show the result.

>
> We should also put more effort into a better SystemTracer to be able to convert between image formats (including 64/32 bits) back and forth -- even if there are some limitations. Think about converting between JPG and PNG, which is sometimes quite convenient to have. :-)
>


Yes this would be nice to have. Using a VMMaker image to do tracing is
a perfectly reasonable approach, especially now that we have fast machines
and unlimite memory. But it would also be nice to have a lighter-weight
tool, and possibly one that could handle a wider range of conversion
targets. If it were possible to trace back and forth between 32-bit spur
and 64-bit spur, that would be particularly useful.

I have not really looked at it, but I suspect that Eliot's recent work
to handle legacy V3 image segments may be useful here.

Dave



> Best,
> Marcel
> Am 14.02.2018 05:36:51 schrieb David T. Lewis <[hidden email]>:
> This project provides an update stream that, starting with a Squeak 4.6 release
> image, produces an up-to-date trunk level image that can be run with either a
> Cog/Stack or classic interpreter VM.
>
> The resulting image uses the traditional V3 object memory format, and therefore
> does not support Spur enhancements (immediate characters and floats, enhanced
> memory management, etc). It does however run most Squeak functionality exactly
> like Squeak trunk on Spur.
>
> I put an update on the swiki here: http://wiki.squeak.org/squeak/6592
>
> The trunk V3 image may be useful for performance comparisons related to
> V3/Spur/Cog/Sista variants.
>
> Note, this is a long-term update for a project that I did not intend to keep
> alive this long. I had originally intended to maintain the V3 update stream
> or one Squeak release cycle, but it has turned out to be useful for keeping
> the classic interpreter VM updated with respect to VM primitives, and has
> been something of a learning experience for me to keep up with the Context
> refactorings, Compiler and Kernel changes, and Sista bytecodes. So for better
> or worse, the V3 trunk stream is still alive, and I figured that it is worth
> a mention on the squeak-dev list :-)
>
> Dave
>
>

>




world.png (146K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Squeak Trunk V3 Update Stream

marcel.taeumel
For the long term, I would love to have an "Export as..." in the world menu of a regular (trunk) image. :-)

Best,
Marcel

Am 15.02.2018 03:13:39 schrieb David T. Lewis <[hidden email]>:

On Wed, Feb 14, 2018 at 07:57:15AM +0100, Marcel Taeumel wrote:
> Thank you, Dave, for supporting the V3 format!

It is a long way from perfect, but with some patience and manual
intervention, the image updates can be done all the way from Squeak 4.6
to the current level of trunk.

Attached is a screen shot to show the result.

>
> We should also put more effort into a better SystemTracer to be able to convert between image formats (including 64/32 bits) back and forth -- even if there are some limitations. Think about converting between JPG and PNG, which is sometimes quite convenient to have. :-)
>


Yes this would be nice to have. Using a VMMaker image to do tracing is
a perfectly reasonable approach, especially now that we have fast machines
and unlimite memory. But it would also be nice to have a lighter-weight
tool, and possibly one that could handle a wider range of conversion
targets. If it were possible to trace back and forth between 32-bit spur
and 64-bit spur, that would be particularly useful.

I have not really looked at it, but I suspect that Eliot's recent work
to handle legacy V3 image segments may be useful here.

Dave



> Best,
> Marcel
> Am 14.02.2018 05:36:51 schrieb David T. Lewis :
> This project provides an update stream that, starting with a Squeak 4.6 release
> image, produces an up-to-date trunk level image that can be run with either a
> Cog/Stack or classic interpreter VM.
>
> The resulting image uses the traditional V3 object memory format, and therefore
> does not support Spur enhancements (immediate characters and floats, enhanced
> memory management, etc). It does however run most Squeak functionality exactly
> like Squeak trunk on Spur.
>
> I put an update on the swiki here: http://wiki.squeak.org/squeak/6592
>
> The trunk V3 image may be useful for performance comparisons related to
> V3/Spur/Cog/Sista variants.
>
> Note, this is a long-term update for a project that I did not intend to keep
> alive this long. I had originally intended to maintain the V3 update stream
> or one Squeak release cycle, but it has turned out to be useful for keeping
> the classic interpreter VM updated with respect to VM primitives, and has
> been something of a learning experience for me to keep up with the Context
> refactorings, Compiler and Kernel changes, and Sista bytecodes. So for better
> or worse, the V3 trunk stream is still alive, and I figured that it is worth
> a mention on the squeak-dev list :-)
>
> Dave
>
>

>




Reply | Threaded
Open this post in threaded view
|

Re: Squeak Trunk V3 Update Stream

Tobias Pape

> On 15.02.2018, at 07:46, Marcel Taeumel <[hidden email]> wrote:
>
> For the long term, I would love to have an "Export as..." in the world menu of a regular (trunk) image. :-)

Or even better: have the vm detect whether it loads an image matching its bit-ness (is this a word?)
and if not, convert it (maybe with a "please wait" info). I mean, it works for RSqueak and IIRC SqueakJS…

-t

>
> Best,
> Marcel
>> Am 15.02.2018 03:13:39 schrieb David T. Lewis <[hidden email]>:
>>
>> On Wed, Feb 14, 2018 at 07:57:15AM +0100, Marcel Taeumel wrote:
>> > Thank you, Dave, for supporting the V3 format!
>>
>> It is a long way from perfect, but with some patience and manual
>> intervention, the image updates can be done all the way from Squeak 4.6
>> to the current level of trunk.
>>
>> Attached is a screen shot to show the result.
>>
>> >
>> > We should also put more effort into a better SystemTracer to be able to convert between image formats (including 64/32 bits) back and forth -- even if there are some limitations. Think about converting between JPG and PNG, which is sometimes quite convenient to have. :-)
>> >
>>
>>
>> Yes this would be nice to have. Using a VMMaker image to do tracing is
>> a perfectly reasonable approach, especially now that we have fast machines
>> and unlimite memory. But it would also be nice to have a lighter-weight
>> tool, and possibly one that could handle a wider range of conversion
>> targets. If it were possible to trace back and forth between 32-bit spur
>> and 64-bit spur, that would be particularly useful.
>>
>> I have not really looked at it, but I suspect that Eliot's recent work
>> to handle legacy V3 image segments may be useful here.
>>
>> Dave
>>
>>
>>
>> > Best,
>> > Marcel
>> > Am 14.02.2018 05:36:51 schrieb David T. Lewis :
>> > This project provides an update stream that, starting with a Squeak 4.6 release
>> > image, produces an up-to-date trunk level image that can be run with either a
>> > Cog/Stack or classic interpreter VM.
>> >
>> > The resulting image uses the traditional V3 object memory format, and therefore
>> > does not support Spur enhancements (immediate characters and floats, enhanced
>> > memory management, etc). It does however run most Squeak functionality exactly
>> > like Squeak trunk on Spur.
>> >
>> > I put an update on the swiki here: http://wiki.squeak.org/squeak/6592 
>> >
>> > The trunk V3 image may be useful for performance comparisons related to
>> > V3/Spur/Cog/Sista variants.
>> >
>> > Note, this is a long-term update for a project that I did not intend to keep
>> > alive this long. I had originally intended to maintain the V3 update stream
>> > or one Squeak release cycle, but it has turned out to be useful for keeping
>> > the classic interpreter VM updated with respect to VM primitives, and has
>> > been something of a learning experience for me to keep up with the Context
>> > refactorings, Compiler and Kernel changes, and Sista bytecodes. So for better
>> > or worse, the V3 trunk stream is still alive, and I figured that it is worth
>> > a mention on the squeak-dev list :-)
>> >
>> > Dave
>> >
>> >
>>
>> >
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Squeak Trunk V3 Update Stream

David T. Lewis
On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
>
> > On 15.02.2018, at 07:46, Marcel Taeumel <[hidden email]> wrote:
> >
> > For the long term, I would love to have an "Export as..." in the world menu of a regular (trunk) image. :-)
>
> Or even better: have the vm detect whether it loads an image matching its bit-ness (is this a word?)
> and if not, convert it (maybe with a "please wait" info). I mean, it works for RSqueak and IIRC SqueakJS???
>
> -t

These are great ideas!

Does anybody know any smart grad students looking for a challenging project?

;-)

Dave



>
> >
> > Best,
> > Marcel
> >> Am 15.02.2018 03:13:39 schrieb David T. Lewis <[hidden email]>:
> >>
> >> On Wed, Feb 14, 2018 at 07:57:15AM +0100, Marcel Taeumel wrote:
> >> > Thank you, Dave, for supporting the V3 format!
> >>
> >> It is a long way from perfect, but with some patience and manual
> >> intervention, the image updates can be done all the way from Squeak 4.6
> >> to the current level of trunk.
> >>
> >> Attached is a screen shot to show the result.
> >>
> >> >
> >> > We should also put more effort into a better SystemTracer to be able to convert between image formats (including 64/32 bits) back and forth -- even if there are some limitations. Think about converting between JPG and PNG, which is sometimes quite convenient to have. :-)
> >> >
> >>
> >>
> >> Yes this would be nice to have. Using a VMMaker image to do tracing is
> >> a perfectly reasonable approach, especially now that we have fast machines
> >> and unlimite memory. But it would also be nice to have a lighter-weight
> >> tool, and possibly one that could handle a wider range of conversion
> >> targets. If it were possible to trace back and forth between 32-bit spur
> >> and 64-bit spur, that would be particularly useful.
> >>
> >> I have not really looked at it, but I suspect that Eliot's recent work
> >> to handle legacy V3 image segments may be useful here.
> >>
> >> Dave
> >>
> >>
> >>
> >> > Best,
> >> > Marcel
> >> > Am 14.02.2018 05:36:51 schrieb David T. Lewis :
> >> > This project provides an update stream that, starting with a Squeak 4.6 release
> >> > image, produces an up-to-date trunk level image that can be run with either a
> >> > Cog/Stack or classic interpreter VM.
> >> >
> >> > The resulting image uses the traditional V3 object memory format, and therefore
> >> > does not support Spur enhancements (immediate characters and floats, enhanced
> >> > memory management, etc). It does however run most Squeak functionality exactly
> >> > like Squeak trunk on Spur.
> >> >
> >> > I put an update on the swiki here: http://wiki.squeak.org/squeak/6592 
> >> >
> >> > The trunk V3 image may be useful for performance comparisons related to
> >> > V3/Spur/Cog/Sista variants.
> >> >
> >> > Note, this is a long-term update for a project that I did not intend to keep
> >> > alive this long. I had originally intended to maintain the V3 update stream
> >> > or one Squeak release cycle, but it has turned out to be useful for keeping
> >> > the classic interpreter VM updated with respect to VM primitives, and has
> >> > been something of a learning experience for me to keep up with the Context
> >> > refactorings, Compiler and Kernel changes, and Sista bytecodes. So for better
> >> > or worse, the V3 trunk stream is still alive, and I figured that it is worth
> >> > a mention on the squeak-dev list :-)
> >> >
> >> > Dave
> >> >
> >> >
> >>
> >> >
> >>
> >>
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Image conversions (was Re: Squeak Trunk V3 Update Stream)

Eliot Miranda-2
Hi David, Hi Casey,

> On Feb 15, 2018, at 6:05 AM, David T. Lewis <[hidden email]> wrote:
>
>> On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
>>
>>> On 15.02.2018, at 07:46, Marcel Taeumel <[hidden email]> wrote:
>>>
>>> For the long term, I would love to have an "Export as..." in the world menu of a regular (trunk) image. :-)
>>
>> Or even better: have the vm detect whether it loads an image matching its bit-ness (is this a word?)
>> and if not, convert it (maybe with a "please wait" info). I mean, it works for RSqueak and IIRC SqueakJS???
>>
>> -t
>
> These are great ideas!
>
> Does anybody know any smart grad students looking for a challenging project?


My dream conversion would be taking the Smalltalk-80 image I have from the original Xerox tape and replacing its compiler and other relevant methods so that it used closures and Spur, and a conventional file/directory interface, but otherwise remained the simple bitblt based system with some 2000 methods and 200 classes.

Such a system is great for learning because it is small enough for one person to learn all of it.  Of course it would be a bit bigger; the closure compiler is more complicated, but not by much.  But projects like replacing repainting windows by windows with a backing store, are afternoon projects in this context.

> ;-)
>
> Dave

_,,,^..^,,,_ (phone)

>>> Best,
>>> Marcel
>>>> Am 15.02.2018 03:13:39 schrieb David T. Lewis <[hidden email]>:
>>>>
>>>> On Wed, Feb 14, 2018 at 07:57:15AM +0100, Marcel Taeumel wrote:
>>>>> Thank you, Dave, for supporting the V3 format!
>>>>
>>>> It is a long way from perfect, but with some patience and manual
>>>> intervention, the image updates can be done all the way from Squeak 4.6
>>>> to the current level of trunk.
>>>>
>>>> Attached is a screen shot to show the result.
>>>>
>>>>>
>>>>> We should also put more effort into a better SystemTracer to be able to convert between image formats (including 64/32 bits) back and forth -- even if there are some limitations. Think about converting between JPG and PNG, which is sometimes quite convenient to have. :-)
>>>>>
>>>>
>>>>
>>>> Yes this would be nice to have. Using a VMMaker image to do tracing is
>>>> a perfectly reasonable approach, especially now that we have fast machines
>>>> and unlimite memory. But it would also be nice to have a lighter-weight
>>>> tool, and possibly one that could handle a wider range of conversion
>>>> targets. If it were possible to trace back and forth between 32-bit spur
>>>> and 64-bit spur, that would be particularly useful.
>>>>
>>>> I have not really looked at it, but I suspect that Eliot's recent work
>>>> to handle legacy V3 image segments may be useful here.
>>>>
>>>> Dave
>>>>
>>>>
>>>>
>>>>> Best,
>>>>> Marcel
>>>>> Am 14.02.2018 05:36:51 schrieb David T. Lewis :
>>>>> This project provides an update stream that, starting with a Squeak 4.6 release
>>>>> image, produces an up-to-date trunk level image that can be run with either a
>>>>> Cog/Stack or classic interpreter VM.
>>>>>
>>>>> The resulting image uses the traditional V3 object memory format, and therefore
>>>>> does not support Spur enhancements (immediate characters and floats, enhanced
>>>>> memory management, etc). It does however run most Squeak functionality exactly
>>>>> like Squeak trunk on Spur.
>>>>>
>>>>> I put an update on the swiki here: http://wiki.squeak.org/squeak/6592 
>>>>>
>>>>> The trunk V3 image may be useful for performance comparisons related to
>>>>> V3/Spur/Cog/Sista variants.
>>>>>
>>>>> Note, this is a long-term update for a project that I did not intend to keep
>>>>> alive this long. I had originally intended to maintain the V3 update stream
>>>>> or one Squeak release cycle, but it has turned out to be useful for keeping
>>>>> the classic interpreter VM updated with respect to VM primitives, and has
>>>>> been something of a learning experience for me to keep up with the Context
>>>>> refactorings, Compiler and Kernel changes, and Sista bytecodes. So for better
>>>>> or worse, the V3 trunk stream is still alive, and I figured that it is worth
>>>>> a mention on the squeak-dev list :-)
>>>>>
>>>>> Dave
>>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Image conversions (was Re: Squeak Trunk V3 Update Stream)

David T. Lewis
On Thu, Feb 15, 2018 at 07:05:26AM -0800, Eliot Miranda wrote:

> Hi David, Hi Casey,
>
> > On Feb 15, 2018, at 6:05 AM, David T. Lewis <[hidden email]> wrote:
> >
> >> On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
> >>
> >>> On 15.02.2018, at 07:46, Marcel Taeumel <[hidden email]> wrote:
> >>>
> >>> For the long term, I would love to have an "Export as..." in the world menu of a regular (trunk) image. :-)
> >>
> >> Or even better: have the vm detect whether it loads an image matching its bit-ness (is this a word?)
> >> and if not, convert it (maybe with a "please wait" info). I mean, it works for RSqueak and IIRC SqueakJS???
> >>
> >> -t
> >
> > These are great ideas!
> >
> > Does anybody know any smart grad students looking for a challenging project?
>
>
> My dream conversion would be taking the Smalltalk-80 image I have from the original Xerox tape and replacing its compiler and other relevant methods so that it used closures and Spur, and a conventional file/directory interface, but otherwise remained the simple bitblt based system with some 2000 methods and 200 classes.
>
> Such a system is great for learning because it is small enough for one person to learn all of it.  Of course it would be a bit bigger; the closure compiler is more complicated, but not by much.  But projects like replacing repainting windows by windows with a backing store, are afternoon projects in this context.

That idea is crazy enough that it just might work :-)

So just to explore the idea: If someone wanted to actually do this, how
might they proceed?

My guess would be that the fastest path might be to start with a modern
oscog VMMaker image, and write enough new simulator support to handle the
object memory and interpreter of the original Xerox system.

If the old Xerox image could be hosted in a modern simulator, then it
should be possible to translate the object image into a format that could
be executed directly on a Spur VM.

But that is only a piece of the problem, because such an image would be
useless without the updated compiler and file system interface, and I can't
quite picture how those bootstrapping steps might be done.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Image conversions (was Re: Squeak Trunk V3 Update Stream)

Bert Freudenberg
On 15 February 2018 at 18:50, David T. Lewis <[hidden email]> wrote:
On Thu, Feb 15, 2018 at 07:05:26AM -0800, Eliot Miranda wrote:
> Hi David, Hi Casey,
>
> > On Feb 15, 2018, at 6:05 AM, David T. Lewis <[hidden email]> wrote:
> >
> >> On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
> >>
> >>> On 15.02.2018, at 07:46, Marcel Taeumel <[hidden email]> wrote:
> >>>
> >>> For the long term, I would love to have an "Export as..." in the world menu of a regular (trunk) image. :-)
> >>
> >> Or even better: have the vm detect whether it loads an image matching its bit-ness (is this a word?)
> >> and if not, convert it (maybe with a "please wait" info). I mean, it works for RSqueak and IIRC SqueakJS???
> >>
> >> -t
> >
> > These are great ideas!
> >
> > Does anybody know any smart grad students looking for a challenging project?
>
>
> My dream conversion would be taking the Smalltalk-80 image I have from the original Xerox tape and replacing its compiler and other relevant methods so that it used closures and Spur, and a conventional file/directory interface, but otherwise remained the simple bitblt based system with some 2000 methods and 200 classes.
>
> Such a system is great for learning because it is small enough for one person to learn all of it.  Of course it would be a bit bigger; the closure compiler is more complicated, but not by much.  But projects like replacing repainting windows by windows with a backing store, are afternoon projects in this context.

That idea is crazy enough that it just might work :-)

So just to explore the idea: If someone wanted to actually do this, how
might they proceed?

My guess would be that the fastest path might be to start with a modern
oscog VMMaker image, and write enough new simulator support to handle the
object memory and interpreter of the original Xerox system.

If the old Xerox image could be hosted in a modern simulator, then it
should be possible to translate the object image into a format that could
be executed directly on a Spur VM.

But that is only a piece of the problem, because such an image would be
useless without the updated compiler and file system interface, and I can't
quite picture how those bootstrapping steps might be done.

Dave

The Squeak 2.2. Mini image is just 200 classes and 4500 methods.

- Bert -
 


Reply | Threaded
Open this post in threaded view
|

Re: Image conversions (was Re: Squeak Trunk V3 Update Stream)

Eliot Miranda-2
In reply to this post by David T. Lewis
Hi David,

On Thu, Feb 15, 2018 at 9:50 AM, David T. Lewis <[hidden email]> wrote:
On Thu, Feb 15, 2018 at 07:05:26AM -0800, Eliot Miranda wrote:
> Hi David, Hi Casey,
>
> > On Feb 15, 2018, at 6:05 AM, David T. Lewis <[hidden email]> wrote:
> >
> >> On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
> >>
> >>> On 15.02.2018, at 07:46, Marcel Taeumel <[hidden email]> wrote:
> >>>
> >>> For the long term, I would love to have an "Export as..." in the world menu of a regular (trunk) image. :-)
> >>
> >> Or even better: have the vm detect whether it loads an image matching its bit-ness (is this a word?)
> >> and if not, convert it (maybe with a "please wait" info). I mean, it works for RSqueak and IIRC SqueakJS???
> >>
> >> -t
> >
> > These are great ideas!
> >
> > Does anybody know any smart grad students looking for a challenging project?
>
>
> My dream conversion would be taking the Smalltalk-80 image I have from the original Xerox tape and replacing its compiler and other relevant methods so that it used closures and Spur, and a conventional file/directory interface, but otherwise remained the simple bitblt based system with some 2000 methods and 200 classes.
>
> Such a system is great for learning because it is small enough for one person to learn all of it.  Of course it would be a bit bigger; the closure compiler is more complicated, but not by much.  But projects like replacing repainting windows by windows with a backing store, are afternoon projects in this context.

That idea is crazy enough that it just might work :-)

So just to explore the idea: If someone wanted to actually do this, how
might they proceed?

My guess would be that the fastest path might be to start with a modern
oscog VMMaker image, and write enough new simulator support to handle the
object memory and interpreter of the original Xerox system.

I would definitely go the other way.  The Spur bootstrap used the Simulator to allow using the host to compile methods and inject them into the image.  So I would proceed as follows:

1. write a loader for the 16-bit Smalltalk-80 v2 image that brought in the objects in their native format. This would involve writing a simple memory manager sufficient for the very simple 16-bit object representation

2. write a converter that took this loaded image and constructed a Spur format 32- or 64- bit image

3. using the host compiler, recompile all the methods in the Spur-format image to use the current bytecode set, installing them in the image

4. excising specific classes (specifically the compiler classes) and replacing them with a clone of the host compiler

Another way might be to take the Smnalltalk-80 source file, p[roduce an edit that contained the system compiler, and then write a bootstrap (which could use Pavel Krivanek's work for Pharo) from source.

 
If the old Xerox image could be hosted in a modern simulator, then it
should be possible to translate the object image into a format that could
be executed directly on a Spur VM.

Right.
 

But that is only a piece of the problem, because such an image would be
useless without the updated compiler and file system interface, and I can't
quite picture how those bootstrapping steps might be done.

Once one has an image in the simulator arbitrary manipulations are possible.  So creating a clone of the compiler within the simulator and switching over to it is quite possible.
 

Dave





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Image conversions (was Re: Squeak Trunk V3 Update Stream)

David T. Lewis
In reply to this post by Bert Freudenberg
On Thu, Feb 15, 2018 at 08:07:59PM +0100, Bert Freudenberg wrote:

> On 15 February 2018 at 18:50, David T. Lewis <[hidden email]> wrote:
>
> > On Thu, Feb 15, 2018 at 07:05:26AM -0800, Eliot Miranda wrote:
> > > Hi David, Hi Casey,
> > >
> > > > On Feb 15, 2018, at 6:05 AM, David T. Lewis <[hidden email]>
> > wrote:
> > > >
> > > >> On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
> > > >>
> > > >>> On 15.02.2018, at 07:46, Marcel Taeumel <[hidden email]>
> > wrote:
> > > >>>
> > > >>> For the long term, I would love to have an "Export as..." in the
> > world menu of a regular (trunk) image. :-)
> > > >>
> > > >> Or even better: have the vm detect whether it loads an image matching
> > its bit-ness (is this a word?)
> > > >> and if not, convert it (maybe with a "please wait" info). I mean, it
> > works for RSqueak and IIRC SqueakJS???
> > > >>
> > > >> -t
> > > >
> > > > These are great ideas!
> > > >
> > > > Does anybody know any smart grad students looking for a challenging
> > project?
> > >
> > >
> > > My dream conversion would be taking the Smalltalk-80 image I have from
> > the original Xerox tape and replacing its compiler and other relevant
> > methods so that it used closures and Spur, and a conventional
> > file/directory interface, but otherwise remained the simple bitblt based
> > system with some 2000 methods and 200 classes.
> > >
> > > Such a system is great for learning because it is small enough for one
> > person to learn all of it.  Of course it would be a bit bigger; the closure
> > compiler is more complicated, but not by much.  But projects like replacing
> > repainting windows by windows with a backing store, are afternoon projects
> > in this context.
> >
> > That idea is crazy enough that it just might work :-)
> >
> > So just to explore the idea: If someone wanted to actually do this, how
> > might they proceed?
> >
> > My guess would be that the fastest path might be to start with a modern
> > oscog VMMaker image, and write enough new simulator support to handle the
> > object memory and interpreter of the original Xerox system.
> >
> > If the old Xerox image could be hosted in a modern simulator, then it
> > should be possible to translate the object image into a format that could
> > be executed directly on a Spur VM.
> >
> > But that is only a piece of the problem, because such an image would be
> > useless without the updated compiler and file system interface, and I can't
> > quite picture how those bootstrapping steps might be done.
> >
> > Dave
> >
>
> The Squeak 2.2. Mini image is just 200 classes and 4500 methods.
>
> - Bert -

And of course Mini Squeak 2.2 is the first image that is loaded when connecting
wto http://try.squeak.org. It is small, fast, and has a satisfyingly retro
aesthetic :-)

But speaking of the Mini image, I think that it is supposed to be housed
in the files.squeak.org site in the 2.2 directory. But I am getting XML parser
errors with some sort of dire warning about font copyrights. Is there a problem
with our ftp server?

Of course there is a copy in the GitHub SqueakJS repository too, but we should
be able to find it on files.squeak.org too.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Image conversions (was Re: Squeak Trunk V3 Update Stream)

Ken G. Brown


On Feb 15, 2018, at 16:31, David T. Lewis <[hidden email]> wrote:

On Thu, Feb 15, 2018 at 08:07:59PM +0100, Bert Freudenberg wrote:
On 15 February 2018 at 18:50, David T. Lewis <[hidden email]> wrote:

On Thu, Feb 15, 2018 at 07:05:26AM -0800, Eliot Miranda wrote:
Hi David, Hi Casey,

<snip>


The Squeak 2.2. Mini image is just 200 classes and 4500 methods.

- Bert -

And of course Mini Squeak 2.2 is the first image that is loaded when connecting
wto http://try.squeak.org. It is small, fast, and has a satisfyingly retro
aesthetic :-)

But speaking of the Mini image, I think that it is supposed to be housed
in the files.squeak.org site in the 2.2 directory. But I am getting XML parser
errors with some sort of dire warning about font copyrights. Is there a problem
with our ftp server?

Of course there is a copy in the GitHub SqueakJS repository too, but we should
be able to find it on files.squeak.org too.

Dave


If you view source on http://files.squeak.org/2.2/, you get something like this:
-------------

Index of /2.2/

NOTE -- TO SEE THE ENTIRETY OF THIS FILE...
Move the mouse into the rightmost part of the scrollbar, until the cursor changes to a menu-like icon.  Then click and hold down until you have selected the item, 'get entire file'.  If you then release the mouse button, you should see the entire contents of the ReadMe file.
--------------------


About Squeak in General
--------------------------------
             Squeak 2.2
    (c) 1996 Apple Computer, Inc.
     (c) 1997, 1998 Walt Disney
       ALL RIGHTS RESERVED.
Squeak is a work in progress based on Smalltalk-80, with which it is still reasonably compatible.  Please see the various introductory windows for more information about this particular release.

The Interpreter
Squeak includes a complete simulation of its ObjectMemory, Interpreter, and BitBlt, each of which began with the "Blue Book" spec.  The object memory is a completely new direct-pointer object model with compact headers and an incremental compacting garbage collector.  The interpreter has been worked over for efficiency, and improved handling of 32-bit LargeIntegers allows it to simulate itself at reasonable speed.  See the various class comments in the Squeak Interpreter category.  The Squeak system also includes a translator to C.  Together these can generate complete C source code for the interpreter.  If you take advantage of this capability to port the system to other platforms, we would like to hear about it.

Color graphics
Squeak's BitBlt has been retrofitted with support for variable-depth color and many performance enhancements.  It has several added functions including a paint mode that supports transparency, and an alpha-blend mode for 32-bit color.  It also has a "warp-drive" variant that will scale, rotate, and otherwise deform bitmaps in a single pass.  Interested users will want to try
	Display restoreAfter: [WarpBlt test1], and
	Display restoreAfter: [WarpBlt test3].
The warp drive is also capable of limited anti-aliasing.  You can compare the results by executing
	Display restoreAfter: [WarpBlt test12].
Two other demos of possible interest (see comments) are
	Display restoreAfter: [BitBlt alphaBlendDemo], and
	Display restoreAfter: [BitBlt antiAliasDemo].

Sound
Squeak includes base classes and some simple primitives that support real-time background generation of sound and music.  Interested users will want to try
	AbstractSound stereoBachFugue play.
Squeak also includes a MIDI file reader.  If you are connected to a network, you should try one of...
	MIDIFileReader playURLNamed:
	   'http://squeak.cs.uiuc.edu/Squeak2.0/midi/wtellovr.mid'.
	MIDIFileReader playURLNamed:
	   'http://squeak.cs.uiuc.edu/Squeak2.0/midi/toccFugueDmin.mid'.
If you're short on horsepower, you'll do better with...
	MIDIFileReader playURLNamed: 
	   'http://squeak.cs.uiuc.edu/Squeak2.0/midi/tlmnflut.mid'.

Morphic
Morphic is a completely new graphics framework for Squeak.  Examples can be explored in the 'Play With Me' windows, or by following the accompanying Morphic scripting tutorial.  We have loaded lots of things into Morphic.  It's a little cluttered and a bit slow, but it's an architecture we like, and we'll be cleaning it up and tuning it over the next year.

Networking
This version of Squeak supports sockets.  If you are on a web-connected network, you might want to try...
	HTTPSocket httpShowGif:
		'http://squeak.cs.uiuc.edu/Squeak2.0/midi/Squeakers.GIF'.
There are many more examples in the Socket class.

Also included with this release is a complete WikiWiki server.  See the accompanying information on WikiWiki.

Squeak's FileList has also been extended with network access.  This feature is newly added, and will probably require a little shaking down and tuning.

Speaking of network access, we hope soon to eschew all these informational windows in favor of a simple link to a Squeak Wiki full of useful and up-to-date information about the latest release.


About Squeak 2.2
----------------------
Here is a summary of major improvements in the 2.2 release:
Continued improvements to the Morphic window system and scripting.
Three all-new network applications written entirely in Squeak
	Celeste (a mail reader by John Malone)
	Scamper (a web browser by Lex Spoon)
	IRC chat (also by Lex Spoon)
Support for looped sampled music timbres for high quality orchestral synthesis.
Piano roll display for the MIDI player, and external MIDI output.
Rejuvenated support for shrinking the Squeak system (see Image Size).
A couple of new features in the VM, including
	Better handling of delays (more accurate messageTallies)
	Support for opaque as well as transparent cursors.
	Support (on the Mac at least) for high-speed asynchronous disk I/O.
Hundreds of other bug fixes and features.

NOTE: The Comic Sans font included in this release is copyright: 
—————

Maybe the html got overwritten by the file by accident.

Ken G. Brown




Reply | Threaded
Open this post in threaded view
|

Re: Image conversions (was Re: Squeak Trunk V3 Update Stream)

K K Subbu
In reply to this post by Eliot Miranda-2
On Friday 16 February 2018 12:50 AM, Eliot Miranda wrote:
> 1. write a loader for the 16-bit Smalltalk-80 v2 image that brought in
> the objects in their native format. This would involve writing a simple
> memory manager sufficient for the very simple 16-bit object representation

Another simplification - no garbage collection. This is short-lived
program dealing with 16-bit images and unlikely to exhaust available
heap on a modern machines.

> 2. write a converter that took this loaded image and constructed a Spur
> format 32- or 64- bit image

How about moving this proposal to the wiki where it can be augmented
with hints and references? It can serve as a starting assignment for a
budding researcher.

Regards .. Subbu


Reply | Threaded
Open this post in threaded view
|

Re: Image conversions (was Re: Squeak Trunk V3 Update Stream)

Tobias Pape
In reply to this post by Ken G. Brown

> On 16.02.2018, at 02:02, Ken G. Brown <[hidden email]> wrote:
>
>
>
>> On Feb 15, 2018, at 16:31, David T. Lewis <[hidden email]> wrote:
>>
>> On Thu, Feb 15, 2018 at 08:07:59PM +0100, Bert Freudenberg wrote:
>>> On 15 February 2018 at 18:50, David T. Lewis <[hidden email]> wrote:
>>>
>>>> On Thu, Feb 15, 2018 at 07:05:26AM -0800, Eliot Miranda wrote:
>>>>> Hi David, Hi Casey,
>>>>>
>>>>>> <snip>
>>>>
>>>
>>> The Squeak 2.2. Mini image is just 200 classes and 4500 methods.
>>>
>>> - Bert -
>>
>> And of course Mini Squeak 2.2 is the first image that is loaded when connecting
>> wto http://try.squeak.org. It is small, fast, and has a satisfyingly retro
>> aesthetic :-)
>>
>> But speaking of the Mini image, I think that it is supposed to be housed
>> in the files.squeak.org site in the 2.2 directory. But I am getting XML parser
>> errors with some sort of dire warning about font copyrights. Is there a problem
>> with our ftp server?
>>
>> Of course there is a copy in the GitHub SqueakJS repository too, but we should
>> be able to find it on files.squeak.org too.
>>
>> Dave
>>
>
> If you view source on http://files.squeak.org/2.2/, you get something like this:
> -------------
> Index of /2.2/
>
> NOTE -- TO SEE THE ENTIRETY OF THIS FILE...
> Move the mouse into the rightmost part of the scrollbar, until the cursor changes to a menu-like icon.  Then click and hold down until you have selected the item, 'get entire file'.  If you then release the mouse button, you should see the entire contents of the ReadMe file.
> --------------------
>
>
> About Squeak in General
> --------------------------------
>              Squeak 2.2
>     (c) 1996 Apple Computer, Inc.
>      (c) 1997, 1998 Walt Disney
>        ALL RIGHTS RESERVED.
> Squeak is a work in progress based on Smalltalk-80, with which it is still reasonably compatible.  Please see the various introductory windows for more information about this particular release.
>
> The Interpreter
> Squeak includes a complete simulation of its ObjectMemory, Interpreter, and BitBlt, each of which began with the "Blue Book" spec.  The object memory is a completely new direct-pointer object model with compact headers and an incremental compacting garbage collector.  The interpreter has been worked over for efficiency, and improved handling of 32-bit LargeIntegers allows it to simulate itself at reasonable speed.  See the various class comments in the Squeak Interpreter category.  The Squeak system also includes a translator to C.  Together these can generate complete C source code for the interpreter.  If you take advantage of this capability to port the system to other platforms, we would like to hear about it.
>
> Color graphics
> Squeak's BitBlt has been retrofitted with support for variable-depth color and many performance enhancements.  It has several added functions including a paint mode that supports transparency, and an alpha-blend mode for 32-bit color.  It also has a "warp-drive" variant that will scale, rotate, and otherwise deform bitmaps in a single pass.  Interested users will want to try
> Display restoreAfter: [WarpBlt test1], and
> Display restoreAfter: [WarpBlt test3].
> The warp drive is also capable of limited anti-aliasing.  You can compare the results by executing
> Display restoreAfter: [WarpBlt test12].
> Two other demos of possible interest (see comments) are
> Display restoreAfter: [BitBlt alphaBlendDemo], and
> Display restoreAfter: [BitBlt antiAliasDemo].
>
> Sound
> Squeak includes base classes and some simple primitives that support real-time background generation of sound and music.  Interested users will want to try
> AbstractSound stereoBachFugue play.
> Squeak also includes a MIDI file reader.  If you are connected to a network, you should try one of...
> MIDIFileReader playURLNamed:
>   '
> http://squeak.cs.uiuc.edu/Squeak2.0/midi/wtellovr.mid
> '.
> MIDIFileReader playURLNamed:
>   '
> http://squeak.cs.uiuc.edu/Squeak2.0/midi/toccFugueDmin.mid
> '.
> If you're short on horsepower, you'll do better with...
> MIDIFileReader playURLNamed:
>   '
> http://squeak.cs.uiuc.edu/Squeak2.0/midi/tlmnflut.mid
> '.
>
> Morphic
> Morphic is a completely new graphics framework for Squeak.  Examples can be explored in the 'Play With Me' windows, or by following the accompanying Morphic scripting tutorial.  We have loaded lots of things into Morphic.  It's a little cluttered and a bit slow, but it's an architecture we like, and we'll be cleaning it up and tuning it over the next year.
>
> Networking
> This version of Squeak supports sockets.  If you are on a web-connected network, you might want to try...
> HTTPSocket httpShowGif:
> '
> http://squeak.cs.uiuc.edu/Squeak2.0/midi/Squeakers.GIF
> '.
> There are many more examples in the Socket class.
>
> Also included with this release is a complete WikiWiki server.  See the accompanying information on WikiWiki.
>
> Squeak's FileList has also been extended with network access.  This feature is newly added, and will probably require a little shaking down and tuning.
>
> Speaking of network access, we hope soon to eschew all these informational windows in favor of a simple link to a Squeak Wiki full of useful and up-to-date information about the latest release.
>
>
> About Squeak 2.2
> ----------------------
> Here is a summary of major improvements in the 2.2 release:
> Continued improvements to the Morphic window system and scripting.
> Three all-new network applications written entirely in Squeak
> Celeste (a mail reader by John Malone)
> Scamper (a web browser by Lex Spoon)
> IRC chat (also by Lex Spoon)
> Support for looped sampled music timbres for high quality orchestral synthesis.
> Piano roll display for the MIDI player, and external MIDI output.
> Rejuvenated support for shrinking the Squeak system (see Image Size).
> A couple of new features in the VM, including
> Better handling of delays (more accurate messageTallies)
> Support for opaque as well as transparent cursors.
> Support (on the Mac at least) for high-speed asynchronous disk I/O.
> Hundreds of other bug fixes and features.
>
> NOTE: The Comic Sans font included in this release is copyright:
>
> —————
>
> Maybe the html got overwritten by the file by accident.


Yea so the webserver tries something intelligent and includes the Readme in the generated index of files. However, that is XML and thus gets upset if funny things turn up in the readme.

-t
>
> Ken G. Brown
>
>
>