[squeak-dev] Recent standalone Squeak ports, and recent hardware to run them?

Is anyone using an existing "bare metal" version of Squeak these days,
or working on a new one?  I know Squeak ran that way on the Itsy and maybe
on early Ipaqs, but I haven't heard of anything more recent.  On newer Ipaqs
Squeak runs under Windows CE but that's not I'm interested in.

For a long time I've been hoping someone would maintain a clean hardware
platform not tied to any one OS.  It would be great if the platform also
favored virtualization and OS debugging.  The Linux handhelds movement may
have started along those lines but it seems to have stagnated.  This list
isn't about hardware design but perhaps someone has looked at these questions
from Squeak's perspective.

Thanks,

-- Derek

On 2009-04-05 17:38, Derek Peschel wrote: SqueakNOS runs on the XO platform.

Karl

Er iPhone, iPod Touch?  Well from the recently ported viewpoint.

See http://isqueak.org/PlatformVMAPI
for all the entry points, documentation and cross platform explanations.
This would be helpful for someone building on a new platform

The port because it's based on a unix system used the following three  
existing support files
sqFilePluginBasicPrims.c
sqUnixUUID.c
sqUnixSocket.c

The sqFilePluginBasicPrims provides for basic file io, not directory  
manipulation.
The SqUnixUUID.c is basically three lines of code
The sqUnixSocket.c is nasty stuff Ian and I worked on. I have been  
tempted but not too tempted to
replace it with CFNetwork logic.  Still any ill behavior I get on os-x  
I should get on the iPhone.


On 5-Apr-09, at 8:38 AM, Derek Peschel wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

Karl Ramberg wrote:
> On 2009-04-05 17:38, Derek Peschel wrote:
> > ["bare metal" version of Squeak]
> SqueakNOS runs on the XO platform.

It should run on many kinds of PCs:

http://wiki.squeak.org/squeak/1762

Other options are listed here, but none has seen any development in
years:

http://wiki.squeak.org/squeak/5727

My own focus is a little below the bare metal - to have a processor that
runs Squeak bytecodes natively.

-- Jecel

On Sun, Apr 05, 2009 at 05:15:45PM -0300, Jecel Assumpcao Jr wrote:
> My own focus is a little below the bare metal - to have a processor that
> runs Squeak bytecodes natively.

I started reading about Plurion and the Merlin 6.  On the SqueakNOS list
Merik Voswinkel also mentioned Morphy.  If you have the VM in the hardware,
the tradeoffs change.  So my next questions are:  How good do you find
SqueakNOS as a debugger for the software? (device drivers, SqueakNOS, apps)
What do you do about the issues of initial loading at power-on, allowing
user changes to the system, and preventing users from making the entire
machine unusable?

Thanks,

-- Derek

Derek Peschel wrote on Tue, 7 Apr 2009 21:56:48 -0700
> On Sun, Apr 05, 2009 at 05:15:45PM -0300, Jecel Assumpcao Jr wrote:
> > My own focus is a little below the bare metal - to have a processor that
> > runs Squeak bytecodes natively.
>
> I started reading about Plurion and the Merlin 6.  On the SqueakNOS list
> Merik Voswinkel also mentioned Morphy.

Morphy is the current name of the machine designs which evolved from
Merlin 6. It reflects the hardware modification features of an FPGA
based computer and sounds a bit more child-friendly.

> If you have the VM in the hardware,
> the tradeoffs change.  So my next questions are:  How good do you find
> SqueakNOS as a debugger for the software? (device drivers, SqueakNOS, apps)

It is better than anything out there - only Forth comes even close. The
problem is that SqueakNOS has not yet crossed its most critical
threshold - being able to save images. Without that, any development you
do will be lost. You will have to go back to a "hosted" version of
Squeak, repeat your modifications there, generate a new CD image and
reboot to test if everything went ok. My prediction is that once you can
develop within SqueakNOS itself, it will take off like nothing you have
ever seen before.

> What do you do about the issues of initial loading at power-on,

If you have a BIOS or OpenFirmware then I don't see any problems. For a
pure Squeak system you can get by with just a trivial loader.

> allowing user changes to the system, and preventing users from
> making the entire machine unusable?

My proposal is to use a separate system image and a user image. You
can't allow full access without also allowing accidents, but a little
structure goes a long way towards eliminating the latter. I described
this in a post to the SqueakNOS list:

http://lists.squeakfoundation.org/pipermail/squeaknos/2008-September/000
125.html

-- Jecel

On 4/9/09, Jecel Assumpcao Jr <[hidden email]> wrote:
>> allowing user changes to the system, and preventing users from
>> making the entire machine unusable?
>
> My proposal is to use a separate system image and a user image. You
> can't allow full access without also allowing accidents, but a little
> structure goes a long way towards eliminating the latter. I described
> this in a post to the SqueakNOS list:

...so you'd have one acting as the operating system, and one acting as
the application?

Gulik.

--
http://gulik.pbwiki.com/

Michael van der Gulik wrote on Wednesday, April 08, 2009 9:39 PM
> On 4/9/09, Jecel Assumpcao Jr wrote:
> > My proposal is to use a separate system image and a user image. You
> > can't allow full access without also allowing accidents, but a little
> > structure goes a long way towards eliminating the latter. I described
> > this in a post to the SqueakNOS list:
> 
> ...so you'd have one acting as the operating system, and one acting as
> the application?

Exactly, though I see no reason not to allow many application images at the same time. That would make using both Sophie and Scratch in a machine with no underlying OS more practical, for example.

For the operating system image, I would actually have two: an emergencySystem.image which would boot up initially and then look for a currentSystem.image to which it would transfer execution after setting up a watchdog timer. If the currentSystem.image is not found or it fails to execute well enough to disable the timer (resulting in a reboot) then the emergencySystem.image would execute all by itself and present the user with enough resources to restore the machine to a usable state.

The currentSystem would be a far smaller image (I imagine less than 1MB) and wouldn't have any GUI or stuff like that. It would do all of the low level stuff for the application images and would normally be safe from anything that happens in these images. But it should be possible to mess around the currentSystem.image from inside one of the application images running remote tools (see Spoon). This would require a series of steps on the user's part and would not normally happen by accident. This is a reasonable balance between full freedom and safety, in my opinion.

Note that practically everything I have described above already exists - it is mostly a matter of gathering the parts into a coherent system.

-- Jecel

On 2009-04-10 22:44, [hidden email] wrote:

Michael van der Gulik wrote on Wednesday, April 08, 2009 9:39 PM
> On 4/9/09, Jecel Assumpcao Jr wrote:
> > My proposal is to use a separate system image and a user image. You
> > can't allow full access without also allowing accidents, but a little
> > structure goes a long way towards eliminating the latter. I described
> > this in a post to the SqueakNOS list:
> 
> ...so you'd have one acting as the operating system, and one acting as
> the application?

Exactly, though I see no reason not to allow many application images at the same time. That would make using both Sophie and Scratch in a machine with no underlying OS more practical, for example.

For the operating system image, I would actually have two: an emergencySystem.image which would boot up initially and then look for a currentSystem.image to which it would transfer execution after setting up a watchdog timer. If the currentSystem.image is not found or it fails to execute well enough to disable the timer (resulting in a reboot) then the emergencySystem.image would execute all by itself and present the user with enough resources to restore the machine to a usable state.

The currentSystem would be a far smaller image (I imagine less than 1MB) and wouldn't have any GUI or stuff like that. It would do all of the low level stuff for the application images and would normally be safe from anything that happens in these images. But it should be possible to mess around the currentSystem.image from inside one of the application images running remote tools (see Spoon). This would require a series of steps on the user's part and would not normally happen by accident. This is a reasonable balance between full freedom and safety, in my opinion.

Note that practically everything I have described above already exists - it is mostly a matter of gathering the parts into a coherent system.

What lack is the last 20% of the work which takes 90% of the time and is 5% as interesting as the rest of the system ;-)

The SqueakNOS on XO need work on the TCP stuff to ease communication to the rest of the world.
I think image saving needs work as well, so changes to the system is kept current.
I like the idea of using different images for different apps, but that need work to make it appear seamless.

Karl