Squeak on Handhelds (Update)

Hello all,

After a recent stint at a product prototyping company that had a lot  
of work going on for touchscreen interfaces, I came back to Squeak  
and looked at the state of handheld software/development support for  
Squeak, and found it stagnant. So I decided to take matters into my  
own hands.

First, the Squeak on Handhelds wiki page:
http://wiki.squeak.org/squeak/Handhelds

Which links to Dynapad (dead sourceforge project, although the author  
Aaron Reichow is still a handhelds-using Squeaker with custom images)  
and Faure (not dead, just not updated and a bit buggy/incomplete). I  
started with Faure, since it has an actual framework for PalmOS-style  
user interfaces and browsing. It has a Url framework that supports  
addressing of various PIM data as well as browsing and editing source  
code and file system entries. There's also a little support for  
including other applications as "pages" to visit (leaves in a  
browsing tree).

So I contacted Russell Allen, who created Faure:
  http://www.russell-allen.com/squeak/faure/
and he claims he's busy with other things and didn't mind if I  
started working with it. So we now share a SqueakSource project:
  http://www.squeaksource.com/Faure.html
where I've been cleaning up the framework and setting it up to be  
more extensible.

I contacted Aaron and he was nice enough to sell me his Nokia 770  
after he upgraded to the 800, so I've had a platform to test the  
various PDA-oriented images out there.

My overall goal is to have a space where most handhelds/touchscreen-
oriented code can be collected and collaborated on. Specifically, I  
want to gather attention about specific topics:
Personal Information Management (PIM or PDA data):
   - contacts, email, messaging, todos, calendaring
   (See PDA/PDAMorph which I want to replace with a Magritte-based  
solution)
Idea-processing:
   - note-taking, drawing, sculpting, outlining, brainstorming.
   (Faure has some basic stuff, and Dynapad *did*, but Golgi
Touchscreen Input Interfaces:
   - stylus or fingers, gestures or pushbuttons.
   (See Genie, and now the InputMethods package in Faure's SqS  
repository which gathers a ThumbPadMorph and a simple  
QwertyKeyboardMorph from Faure).
   - One thing I need to figure out is how to use a click on a widget  
to make the next mouse click show up as a modifier+click or just 2nd/
3rd moues button click. I'm probably close but it's a key feature to  
making a soft keyboard widget complete.
Simpler screen management:
   - Faure's single-pane browsing, or dual-pane browsing for wider  
screens, a universal navigation system (like Faure but hopefully  
merging with OmniBrowser's framework so less code is needed).
   - Simple sweep / flick gestures a la Apple phone interface for  
navigation.
   - A way to detect screen size on startup and do something  
intelligent about it. 240x320 was almost ubiquitous for a while but  
now there's quite a variety of resolutions.
   - A way to detect what device Squeak is on and map key controls  
appropriately. I discovered that the Squeak VM doesn't distinguish  
function keys from each other and that the Nokia 770 maps some keys  
to these X11 key-codes, and I imagine that other small platforms have  
similar issues.

I'd like to know: What solo projects are hiding in the woodwork that  
would benefit from this kind of collaboration? Who wants to donate  
code for this project to maintain?

I've seen and started poking at Tansel's 4MB previously-commercial  
demo image, all of Aaron Reichow's images, and Pavel's KernelImages  
(which I'd prefer going forward since I can automate builds of them  
that way). Craig says he has a pie-menu-like soft-keyboard tool that  
he uses on touchscreens, which sounds interesting.

I should also state that it's important for an end-user to have  
something they can grab immediately for handhelds and touchscreens  
from squeak.org that is self-explanatory in the sense that it should  
always be obvious what is available to do in the current current  
context, and what modes or quasi-modes are available (especially for  
Genie which turns the whole screen into a different mode without  
telling you or giving a novice an easy escape).

I'd also like to know who's interested in the work and might have  
something to contribute. Oh, and how I should organize the project,  
maybe to rename the SqueakSource project to "Dynapad" or "Handhelds"  
or such, for example?

Comments/criticisms/concerns?

--
-Brian
http://briantrice.com

On Mar 8, 2007, at 12:40 PM, Brian Rice wrote:

> Idea-processing:
>   - note-taking, drawing, sculpting, outlining, brainstorming.
>   (Faure has some basic stuff, and Dynapad *did*, but Golgi

Oops, in the process of writing this non-linearly, I forgot to finish  
the sentence:

>   (Faure has some basic stuff, and Dyanapad *did*, but Golgi looks  
> like the only relevant updated project, and it's stale. DabbleDB  
> doesn't really count ;) )

--
-Brian
http://briantrice.com

> Comments/criticisms/concerns?

     Go Brian!


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Sounds very great.

My 2 PDA(*) are ready for your needs.

Cheers.

(*)
iPaq 4150 (BT, Wifi, 400MHZ, 64RAM, 320x200)
        - Runs WM2003 and can run Linux Familiar.

XDA Himalaya (a.k.a. O2 XDAII, Qtek 2020...)
  http://wiki.xda-developers.com/index.php?pagename=Himalaya
  Now has WM2005 and is phone too.



Brian Rice escribió:
--
Giuseppe Luigi Punzi - Consultor

       :: ZYO Consulting ::
email: [hidden email]
tlfno: +34 675 145 912
web: http://www.zyoconsulting.com

Ah, both are 320x240 PocketPC machines. I've owned earlier iPaq  
models in the past, 36xx series. Faure is set up for that resolution  
by default. When I get comfortable enough with my results to produce  
ready-to-go images, I'll send an announcement.

I should note that I'm developing with the Squeak Developer (squeak-
dev) images and enjoying it, but haven't yet tackled making a good  
script to build from KernelImage to full Faure-capable image, which  
is why I just have MCZ to show for now.

On Mar 8, 2007, at 3:34 PM, Giuseppe Luigi Punzi wrote:
--
-Brian
http://briantrice.com

FWIW, I'm doing some stuff with the N800.

So far, I've been cheating and using Seaside, tho'. :-)

This sounds really cool.  Will the project also make VM's for the different
platforms?  I have a Sony Erikson that I would love to put Squeak on.



><< PGP.sig >>




>

_________________________________________________________________
Mortgage rates as low as 4.625% - Refinance $150,000 loan for $579 a month.
Intro*Terms  
https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h27f6&disc=y&vers=743&s=4056&p=5117

Short answer: no.

Long answer:
I am not personally willing to take on the responsibility of making  
the VM sources suitable for multiple OSes and hardware platforms  
(which if done properly should involve actually patching sources in  
the SVN repository which is more than a purely technical challenge).  
My goal is to make Squeak libraries, frameworks, and images suitable  
for demonstrating and using innovative interface ideas. The goal is  
that I can pull out a Nokia 770 and instantly sell Squeak as a  
platform and my consulting services based on a quick demo. If that  
motivates VM ports, I'll be tickled pink, but I can't afford to do  
that - I don't know where next month's rent is coming from often enough.

If someone wants to volunteer (or donate funds) to coordinate that  
kind of project, it would be vastly helpful, since Squeak handheld  
VMs have not been published in a couple of years (except for the  
Nokia VM's which are totally unmodified SVN sources from 3.7(!) which  
means that they really don't integrate with its Gtk-based user  
interface).

Obligatory compliment: Squeak is pretty easy to get running on  
embedded platforms.
Obligatory rejoinder: There's plenty of room for improvement in  
helping Squeakers create a porting branch of the Squeak VM and in  
maintaining such a branch with the least effort in concert with main-
line Squeak updates. Hosting such projects at an official Squeak site  
like squeakvm.org would also be an improvement.

On Mar 10, 2007, at 8:43 AM, J J wrote:
--
-Brian
http://briantrice.com

Brian Rice wrote:
> Obligatory rejoinder: There's plenty of room for improvement in helping
> Squeakers create a porting branch of the Squeak VM and in maintaining
> such a branch with the least effort in concert with main-line Squeak
> updates. Hosting such projects at an official Squeak site like
> squeakvm.org would also be an improvement.

Which, if you start a new platform branch instead of trying to patch
existing ones, shouldn't be a problem I think.

Cheers,
   - Andreas

On Mar 10, 2007, at 5:51 PM, Andreas Raab wrote:

> Brian Rice wrote:
>> Obligatory rejoinder: There's plenty of room for improvement in  
>> helping Squeakers create a porting branch of the Squeak VM and in  
>> maintaining such a branch with the least effort in concert with  
>> main-line Squeak updates. Hosting such projects at an official  
>> Squeak site like squeakvm.org would also be an improvement.
>
> Which, if you start a new platform branch instead of trying to  
> patch existing ones, shouldn't be a problem I think.

This sounds promising, but most of us with interest in handhelds  
aren't experienced (Squeak) VM hackers, and are not aware of the  
process involved, especially if we are making relatively slight  
tweaks to a mature branch, like the Unix branch for the Zaurus PDA or  
Nokia internet tablets. In a lot of these cases, it's a configuration  
issue, and the way to make a platform branch that is maintainable is  
not clear. Most of the existing ports are currently just tarballs of  
some modified snapshot of the VM sources from a while ago, so it  
seems like people have found it easiest so far to just hack until it  
worked and then archive for posterity.

As a non-handheld, but practical example, there have been (mostly-
working, but now no longer on the 'net) BeOS ports of some versions  
of the VM, but it's never gotten to the point where those ports met  
the main repositories. That's an example of a port whose solution  
might tell the solver what documentation needs to be available to  
complete other such ports. Making one solution tractable would make  
the solution of the handheld problems nearly as tractable.

Another thing occurs to me: one of the factors that makes  
coordinating Squeak VM development for PDAs is that there are many  
toolchains (even if gcc-based) for these different systems, and some  
are proprietary (MSVC), so no one person will likely be able to  
understand or vet all the ports (especially Ian or you, who have many  
things on your plates).

So, here are the questions that occur to me:

- Is there a guide for how to do this?
- If you do find it easy enough to explain in an email, how can we  
put it on an official Squeak site where it is likely to be found?  
(The wiki is great, or a README in the SVN tree, but there should at  
least be a link from squeakvm.org's page or something.)
- What is the recommended process for submitting patches for such a  
branch when the level of interaction isn't high enough to merit  
asking for write access to the SVN server?
- If a permanent account to the SVN server is justified, how does one  
make that request?

This kind of information should be published in an obvious place  
rather than repeated on email.

--
-Brian
http://briantrice.com

Brian Rice wrote:
I agree. But a large part of making such tweaks in a separate platform
branch is to spend a bit of time to learn the (admittedly imperfect)
build structure. I think we all agree that it's imperfect but it's the
best we could come up with so far, so willingness to learn it and live
inside it is a must if you want to take on this task seriously.

> Most of
> the existing ports are currently just tarballs of some modified snapshot
> of the VM sources from a while ago, so it seems like people have found
> it easiest so far to just hack until it worked and then archive for
> posterity.

That may well be. How would you propose to change that? As far as I can
remember over the history of Squeak, this is how all ports started. The
main difference between those at SqueakVM.org and those not is that some
of them were supported over a period of time, and some of them weren't.
If you make a one-shot solution, there is not much value in bringing
into the common build structure at SqueakVM.org. If you spend a longer
time it starts to make a lot more sense.

> As a non-handheld, but practical example, there have been
> (mostly-working, but now no longer on the 'net) BeOS ports of some
> versions of the VM, but it's never gotten to the point where those ports
> met the main repositories. That's an example of a port whose solution
> might tell the solver what documentation needs to be available to
> complete other such ports. Making one solution tractable would make the
> solution of the handheld problems nearly as tractable.

I'm trying to be serious here but do you really expect the port
maintainers to go hunting for unsupported ports, and fold them into the
common build structure? I think that's a bit of an expectation mismatch.
The people who maintain "their" ports do it *precisely* because they
like their platform. If you like BeOS, and want to add it to the common
build structure and maintain it, please go for it! But asking other
people to maintain ports in which they basically have no interest seems
a bit far fetched.

> Another thing occurs to me: one of the factors that makes coordinating
> Squeak VM development for PDAs is that there are many toolchains (even
> if gcc-based) for these different systems, and some are proprietary
> (MSVC), so no one person will likely be able to understand or vet all
> the ports (especially Ian or you, who have many things on your plates).

But this is exactly why we have platform branches to begin with. WinCE
for example - a long time ago we had a separate port for WinCE, which I
folded into the main Win32 port around 1998 or so. Later it turned out
to be unfeasible simply because CE was missing so many features that you
take for granted on Win32 in general and these ports again split. Today,
the "main" win32 port is built with a setup that is specifically
available on SqueakVM.org (only FOSS build tools btw, so *everyone* can
build that VM) and the last versions of WinCE were being built with an
MS proprietary toolset. Fine with me, and worth a separate platform
branch as far as I am concerned. OTOH, I just asked Eliot if he could
make the VC++ makefiles for the main Win32 port available since he's
just been working on this. Both are fine ways to deal with it and I am
open to either one.

> So, here are the questions that occur to me:
>
> - Is there a guide for how to do this?

To do what exactly? Make a "minor port" that leverages a "major" port
and just tweaks it slightly? I would guess that depends on how much
magic you do with your build setup. For example, the current win32 build
looks for files first in the win32 tree, then in the cross tree. For a
"minor" port to leverage this it would be quite doable to have a build
setup that first looks in, say "WinCE", then "Win32", then "Cross" etc.
It is some work, sure, and it may require some communication with the
"main" port but it's definitely doable.

> - If you do find it easy enough to explain in an email, how can we put
> it on an official Squeak site where it is likely to be found? (The wiki
> is great, or a README in the SVN tree, but there should at least be a
> link from squeakvm.org's page or something.)

I don't quite understand what you mean here. PR is not my main task ;-)

> - What is the recommended process for submitting patches for such a
> branch when the level of interaction isn't high enough to merit asking
> for write access to the SVN server?

Maintaining a platform port *is* worth asking for write access. And like
I said before, I wouldn't expect that to be any problem whatsoever. If
you have patches for a port, post them to vm-dev.

> - If a permanent account to the SVN server is justified, how does one
> make that request?

Starting with the work you've already done (e.g., at least some partial
work result to show you are serious about it) sending a nice request to
Ian (he owns the physical box) with CC: to vm-dev would be all that is
needed. If nothing happens in a couple of weeks (sometimes people are
just busy) follow up on vm-dev.

> This kind of information should be published in an obvious place rather
> than repeated on email.

Like I was saying before, I don't own the PR on VM stuff. Knock yourself
out if you like, in fact we could probably use someone who owns these
aspects of vm-dev ;-) If you are willing to write a bit of documentation
about it, I think that would be quite welcome.

Cheers,
   - Andreas

On 10-Mar-07, at 6:47 PM, Brian Rice wrote:

>
> - Is there a guide for how to do this?

You could try:-
http://www.rowledge.org/tim/squeak/OE-Tour.html for some general VM  
stuff relating to Squeak
http://wiki.squeak.org/squeak/2105 et al. for specific VMMaker stuff

In general if you download the svn tree, load up VMMaker *from  
SqueakMap* and follow platform instructions you ought to be able to  
build a working vm. It is, after all, what 'us professionals' do. Add  
a new branch to the platforms tree, next to RiscOS/Mac/Win32/unix and  
maybe add a new subclass to VMMaker if you need to do things  
differently wrt code generation. Once you have it working, feel free  
to submit it to me for inclusion in the main VMMaker package. Until  
that point you can work as publically or as secretly as you wish.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A computer program does what you tell it to do, not what you want it  
to do.

tim Rowledge wrote:
Brian,

It's pretty easy to do and figure out, and there is _some_ documentation
(that is written well) to help you (let me know if you need links). I
suggest you get the svn and build a current VM to get your feet wet.
Once you build and it really does work, you'll pretty much understand
the workflow. Then, you could split off a branch for your own work.


--
brad fuller
www.bradfuller.com
+1 (408) 799-6124

I'd just like to chime in to second Brian's sentiment. Like a lot of  
folks, I do Smalltalk, not C. And I don't do VMs. It's just not my  
thing, I'm not a VM hacker, like Brian says. The VMs I've used on  
WinCE were ones that Yoshiki compiled a long time ago, and haven't  
been updated since 2002 or so, but I've gotten by.  Obviously, that  
isn't sustainable... But the solution, at least for Brian and I, is  
to use a Linux-based tablet, esp one that uses X11 for its GUI,  
because it's very easy to get Squeak running on it. Out of the folks  
working on handheld Squeak, at least the ones I can think of doing  
work today, there really isn't much interest in VM hacking.

Even in the areas of possibly extending the VM for PDA-specific  
features- tapping into Nokia's GTK+ soft-keyboard and input system  
isn't something I'm interested in, as I'd rather do it in Squeak and  
make it available to any platform you were using it.  I just took  
what Gerald compiled, which was more or less out of the box, and am  
running with it. There are some tweaks I need to make to make it more  
usable on the Nokia 770/N800- giving it an icon to launch and switch  
back and forth to for instance- but these things don't require  
altering the VM.

With these embedded platforms, it really is a matter of having  
someone interested in doing it.  We could, with enough ingenuity have  
Squeak running on any embedded platform with enough juice to power  
it, and there have been ports of a lot of them in the past- there  
even was an EPOC32 port that would probably be a good starting point  
for the Sony-Ericson phones.  But that said, unless you've got  
someone who has a personal reason to have Squeak running on that  
specific OS, with knowledge of the VM and the new OSes APIs it isn't  
likely to happen.  It's a lot easier, and cheaper from one angle, for  
me to recommend purchasing some sort of Linux or CE based PDA to  
someone who wants to get into handheld Squeak rather than learning  
the requisite VM hacking and PalmOS/EPOC/Symbian/Whatever knowledge-  
you can get a used Linux or CE PDA off of eBay for $100, but learning  
that stuff would certainly cost more than a few hours of my time.

Just some thoughts...

Regards,
Aaron

On Mar 10, 2007, at 8:47 PM, Brian Rice wrote:

Blake-

I'm curious what kind of work you're doing on the N800 with  
Seaside... Specifically, what kind of impressions you have of using  
an app in that sort of situation.

I suspect I'm a bit of an oddity- I can whip up a simple Morphic app  
in Squeak at a speed that isn't far off of a newbie VB programmer-  
fast, though not lightning.  It's a shame more folks don't grok  
Morphic. Not to dis your work, my point is simply that for me, using  
any web app framework- even Seaside- would take more longer to whip  
up some prototype.  I'm very curious about what kind of apps you're  
creating and what kind of experience you've had so far...

Regards,
Aaron

On Mar 9, 2007, at 1:25 AM, Blake wrote:

> FWIW, I'm doing some stuff with the N800.
>
> So far, I've been cheating and using Seaside, tho'. :-)
>

On Sun, 11 Mar 2007 00:26:44 -0800, Aaron Reichow <[hidden email]>  
wrote:

Forms. Lots and lots of forms.

I don't prefer it, but it gets around a lot of other problems. Seaside is  
actually rather simple, easier than morphic (as it should be, given its  
limitations), and I don't have to worry about building the C/S part, nor  
do I need to be overly concerned if the N800 is not my final device (as I  
suspect it won't be).

My plan, once I've gotten my basic framework down, was to move  
bits-and-pieces to be native on the N800, and (with luck) exploit the  
handwriting recognition in Genie (as you mentioned in January).

I'd actually enjoy doing the Nokia VM (C and I are old enemies, and I've  
had fun with VMs a lot in the past), but I don't know if it's realistic.  
(Otherwise I would've jumped in here sooner.) If I can manage to work it  
in as part of the project I'm doing, it gets more realistic (as I'd be  
getting paid for it :-)).

        ===Blake===

On Mar 11, 2007, at 12:55 AM, Blake wrote:
Web forms? Do you use Magritte, then? (which takes meta-model  
descriptor methods and generates views and controllers (seaside and  
morphic) I've been getting started using it but wondering about  
others' experiences.

> I don't prefer it, but it gets around a lot of other problems.  
> Seaside is actually rather simple, easier than morphic (as it  
> should be, given its limitations), and I don't have to worry about  
> building the C/S part, nor do I need to be overly concerned if the  
> N800 is not my final device (as I suspect it won't be).

An interface that fits into Seaside/webapp form can definitely be  
easier to write than a Morphic app since it has a library-language  
for doing it, whereas Morphic is a bit open-ended and hard to orient  
oneself in.

> My plan, once I've gotten my basic framework down, was to move bits-
> and-pieces to be native on the N800, and (with luck) exploit the  
> handwriting recognition in Genie (as you mentioned in January).
>
> I'd actually enjoy doing the Nokia VM (C and I are old enemies, and  
> I've had fun with VMs a lot in the past), but I don't know if it's  
> realistic. (Otherwise I would've jumped in here sooner.) If I can  
> manage to work it in as part of the project I'm doing, it gets more  
> realistic (as I'd be getting paid for it :-)).

Interesting. I almost got paid for my work... but it didn't quite  
work out.

--
-Brian
http://briantrice.com

On Mar 10, 2007, at 10:39 PM, Andreas Raab wrote:
Mostly through a couple of web pages that guide the newbie VM hacker  
in the right direction. The initial steps are easy, just throwing up  
a web page that explains the state of things (culled from these or  
similar messages) and how to ask to do stuff that is not supported  
yet, and the second part, how to learn from the build structure to  
make a new port, would involve one person actually going through the  
process and being able to channel that feedback into those online pages.
Oh, not at all. Actually the idea is to get one person to try this  
approach with their pet port project, particularly where the person  
isn't part of the core team and doesn't have implicit knowledge about  
all this. The BeOS port authors still have websites and can be  
contacted for their stuff and maybe even asked about their  
experiences with it.
Oh, okay. Cool.
Okay.

>> - If you do find it easy enough to explain in an email, how can we  
>> put it on an official Squeak site where it is likely to be found?  
>> (The wiki is great, or a README in the SVN tree, but there should  
>> at least be a link from squeakvm.org's page or something.)
>
> I don't quite understand what you mean here. PR is not my main  
> task ;-)

Yeah, it wasn't personally directed at you.

>> - What is the recommended process for submitting patches for such  
>> a branch when the level of interaction isn't high enough to merit  
>> asking for write access to the SVN server?
>
> Maintaining a platform port *is* worth asking for write access. And  
> like I said before, I wouldn't expect that to be any problem  
> whatsoever. If you have patches for a port, post them to vm-dev.

Okay.

>> - If a permanent account to the SVN server is justified, how does  
>> one make that request?
>
> Starting with the work you've already done (e.g., at least some  
> partial work result to show you are serious about it) sending a  
> nice request to Ian (he owns the physical box) with CC: to vm-dev  
> would be all that is needed. If nothing happens in a couple of  
> weeks (sometimes people are just busy) follow up on vm-dev.

Okay.

>> This kind of information should be published in an obvious place  
>> rather than repeated on email.
>
> Like I was saying before, I don't own the PR on VM stuff. Knock  
> yourself out if you like, in fact we could probably use someone who  
> owns these aspects of vm-dev ;-) If you are willing to write a bit  
> of documentation about it, I think that would be quite welcome.

Thanks. I'll contact Ian (he owns squeakvm.org) and see about a short-
term project to make/coordinate the described progress. (Not that I'm  
going to give up, but limited-scope is what makes these ideas work.)

--
-Brian
http://briantrice.com

Brian Rice wrote:
> Mostly through a couple of web pages that guide the newbie VM hacker in
> the right direction. The initial steps are easy, just throwing up a web
> page that explains the state of things (culled from these or similar
> messages) and how to ask to do stuff that is not supported yet, and the
> second part, how to learn from the build structure to make a new port,
> would involve one person actually going through the process and being
> able to channel that feedback into those online pages.

The uber-minimalistic front page at SqueakVM.org has a lot of room for
improvement ;-)

> Oh, not at all. Actually the idea is to get one person to try this
> approach with their pet port project, particularly where the person
> isn't part of the core team and doesn't have implicit knowledge about
> all this. The BeOS port authors still have websites and can be contacted
> for their stuff and maybe even asked about their experiences with it.

I see. Yes, this would be a sound approach, in particular for gathering
information about the issues that lurk along the way.

>> Like I was saying before, I don't own the PR on VM stuff. Knock
>> yourself out if you like, in fact we could probably use someone who
>> owns these aspects of vm-dev ;-) If you are willing to write a bit of
>> documentation about it, I think that would be quite welcome.
>
> Thanks. I'll contact Ian (he owns squeakvm.org) and see about a
> short-term project to make/coordinate the described progress. (Not that
> I'm going to give up, but limited-scope is what makes these ideas work.)

Yes, I agree.

Cheers,
   - Andreas

Have people actually read the VMMaker help?

Have people actually read the VMMaker page(s) and linked platform  
specific pages on the swiki? (http://wiki.squeak.org/squeak/2105)

Read them and explain where they fail to elucidate and we can improve  
them. Hell, it's a swiki so you can  improve them yourselves!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BSO: Branch Sort Of