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
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 lewis@mail.msen.com: 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
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 lewis@mail.msen.com: 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
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 lewis@mail.msen.com: 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
On 15.02.2018, at 07:46, Marcel Taeumel marcel.taeumel@hpi.de 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 lewis@mail.msen.com:
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
On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
On 15.02.2018, at 07:46, Marcel Taeumel marcel.taeumel@hpi.de 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 lewis@mail.msen.com:
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
Hi David, Hi Casey,
On Feb 15, 2018, at 6:05 AM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
On 15.02.2018, at 07:46, Marcel Taeumel marcel.taeumel@hpi.de 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 lewis@mail.msen.com:
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
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 lewis@mail.msen.com wrote:
On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
On 15.02.2018, at 07:46, Marcel Taeumel marcel.taeumel@hpi.de 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
On 15 February 2018 at 18:50, David T. Lewis lewis@mail.msen.com 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 lewis@mail.msen.com
wrote:
On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
On 15.02.2018, at 07:46, Marcel Taeumel marcel.taeumel@hpi.de
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 -
On Thu, Feb 15, 2018 at 08:07:59PM +0100, Bert Freudenberg wrote:
On 15 February 2018 at 18:50, David T. Lewis lewis@mail.msen.com 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 lewis@mail.msen.com
wrote:
On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
On 15.02.2018, at 07:46, Marcel Taeumel marcel.taeumel@hpi.de
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
On Feb 15, 2018, at 16:31, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 15, 2018 at 08:07:59PM +0100, Bert Freudenberg wrote:
On 15 February 2018 at 18:50, David T. Lewis lewis@mail.msen.com 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/ 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
On 16.02.2018, at 02:02, Ken G. Brown kbrown@mac.com wrote:
On Feb 15, 2018, at 16:31, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 15, 2018 at 08:07:59PM +0100, Bert Freudenberg wrote:
On 15 February 2018 at 18:50, David T. Lewis lewis@mail.msen.com 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
Hi David,
On Thu, Feb 15, 2018 at 9:50 AM, David T. Lewis lewis@mail.msen.com 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 lewis@mail.msen.com
wrote:
On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
On 15.02.2018, at 07:46, Marcel Taeumel marcel.taeumel@hpi.de
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
On Friday 16 February 2018 12:50 AM, Eliot Miranda wrote:
- 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.
- 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
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
David T. Lewis -
Eliot Miranda -
K K Subbu -
Ken G. Brown -
Marcel Taeumel -
Tobias Pape