[squeak-dev] Re: [Newbies] I need an idea. I know you have some. Give.

Jeff Gonis jeff.gonis at gmail.com
Fri Mar 8 15:44:57 UTC 2013


On Thu, Mar 7, 2013 at 11:48 PM, Casey Ransberger
<casey.obrien.r at gmail.com> wrote:
> Hello Squeakers!
>
> So here's the $x question: what do you want me to do? I have a Raspberry Pi on order, so bonus points if you can work that in somehow.
>
> The person with the best (realistic) idea will be credited for it.
>
> Casey

Hi Casey,

Since you asked for ideas, I'll throw a few out there.

1) Get modern graphics facilities up and running in the squeakvm,
either rome, athens, or gezira, or something else
Pros: Smalltalk, and by extension Squeak have always been oriented
towards the graphical. Heck it's where much of what we use everyday
comes from! So it's kind of a drag that when I go to draw a path in
Squeak my choices are a heavily aliased path in the standard canvas,
or a weird set of rectangles joined together on the balloon canvas.
Gezira is from VPRI and gets points for compactness.  Plus Bert has
already done a lot of the work implementing it.  Athens is being done
in Pharo and uses NativeBoost I believe so there is that hurdle.  Rome
used Cairo I believe and has some work completed but was somewhat
abandoned.

Cons: Gezira is largely the product of one man and may fall victim to
a low bus factor if this person decides to work on other things.  Also
I don't know how good its performance is.  Athens uses NativeBoost and
possibly a bunch of other Pharoisms.  That may slow your effort.  Rome
hasn't seen any work in a while so I don't know what state it is
currently in.

2) Work to implement some of the RoarVM concepts into the regular SqueakVM

Pros: My computer seems to acquire more cores with each passing year,
but 100000 factorial still only maxes out one of them.  This is a
shame. Allowing squeak to utilize the numerous threads that we all
have access to will be vital in ensuring its relevance in the coming
years.  The RoarVM already allows this in a Squeak image.  Combined
with Eliot's work on JITing Smalltalk code Squeak could rule the
world!

Cons: RoarVM was part of a research project and as I understand it the
straight-line performance is far behind the regular squeak VM.  It
also appears to be a fairly substantial fork of the regular VM, so
there could probably be a lot of work involved on both the image side
and the VM side in getting its facilities integrated.

STRETCH GOAL
3) Read the asm.js spec at http://asmjs.org and then go to
emscripten.org and read up on the compiler.  Then figure out how to
compile a minimal VM to javascript that can run in the browser and
slowly build your way up from there, implementing more and more
plugins and primitives in javascript until a small squeak image can
run.

Pros: Mozilla spent $150 million last year developing their browser,
and likely Google, Microsoft and Apple did the same.  The amount of
money being poured into making browsers faster, quicker to draw,
better at collecting garbage, etc, is pretty insane.  There are likely
more people working on just the Mozilla garbage collector than people
working on Squeak/Pharo fulltime.  Asm.js is designed to allow for the
compilation of C programs to rigidly defined JS which will be executed
by the browser at speeds currently 2-3x slower than the C code.  This
is still really fast and they expect greater speedups in the future.
The emscripten compiler translates draw calls into Canvas calls, sound
calls into Audio API calls, etc, etc.  Basically most of the
primitives needed by Squeak are available as Javascript APIs, so the
vm calls to C code could be converted to Javascript calls.  Overall
this would allow Squeak to utilize the vast resources being poured
into browsers and Javascript, while bringing along the far superior
language and development environment we all enjoy.

Cons: Relying on Canvas draw calls rather than BitBlt, for example,
will reduce the whole "from the metal up" feel that you can currently
get with Squeak. This is also obviously a very ambitious project that
would take a lot of work. It would also chain Squeak to a standard
that can change or die out at some point in the future. It would also
make it hard to run squeak in a very memory or processor constrained
environment.

Anyway, you asked for ideas and those are 3 of them.  Hopefully that
wall of text wasn't too much for you.

Best of luck!
Jeff


More information about the Squeak-dev mailing list