From:  Dean Swan at MITEL on 08/16/99 06:21 PM

Brian,

     I have been working on getting Squeak to a "really usable" state on a Casio
E-105, and you're quite correct.  There are a number of issues with the WinCE
port of the Squeak VM, some more serious than just the issues with the stylus.
I'd certainly be interested in anything that is being done in this area.

     I don't currently own a Palm device, but it presents some interesting
issues that are similar to those faced on the E-105, at least in terms of user
interface and dealing with a fairly small dispaly.

                                   -Dean Swan






Brian Rice <water at tscnet.com> on 08/14/99 05:18:48 PM

Please respond to squeak at cs.uiuc.edu

To:   squeak at cs.uiuc.edu
cc:    (bcc: Dean Swan/Ogd/Mitel)

Subject:  New Squeak Porting Proposals




Hello all.
     It seems that there are some simple problems to be fixed before the WinCE
port of Squeak is going to be really usable.  I'd like to have the source
for that project opened up so that stylus support can be fixed.  Of course
I'd like to help with this, but I'm not familiar with programming a stylus.
 Also, it seems that a Palm Pilot port would be a great benefit,
considering that new versions have plenty of memory for the environment.
I'm collecting info on the hardware, but I'm new to this, and could use
some help.
     If anyone has pointers, please let me know.  Also, I am looking into
making a Squeak based on Self or Omega or another simple prototype-based
language (make our own, perhaps?).  It would allow the system to run faster
(polymorphic message-sends and dynamic recompilation) and use a slightly
smaller memory footprint, to say nothing of making programming and
reflection simpler.  It would also allow Squeak to use the direct
manipulation interface, Seity, or some derivative.  Also, Morphic would
probably run better, as it was designed for that language.
     Hopefully, even the bytecode style VM could be replaced by one that
manipulates syntax trees or something like that (see the Oberon/Juice
language project).  All of this should give a base-level performance boost
and reduce the memory footprint as well, though it may take a while to
implement.

If you are interested in any of these ideas, please contact me.  Thanks.

     Brian