Hi Jeff,<div><br></div><div>Actually I've gotten a few suggestions offlist along the lines of graphics stuff for Squeak. This is an area I'm actively exploring. Thanks for the suggestions! Also, thanks for putting me onto asm.js. This is cool.<br>
<br><div class="gmail_quote">On Fri, Mar 8, 2013 at 7:44 AM, Jeff Gonis <span dir="ltr"><<a href="mailto:jeff.gonis@gmail.com" target="_blank">jeff.gonis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Mar 7, 2013 at 11:48 PM, Casey Ransberger<br>
<<a href="mailto:casey.obrien.r@gmail.com">casey.obrien.r@gmail.com</a>> wrote:<br>
> Hello Squeakers!<br>
><br>
<div class="im">> 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.<br>
><br>
> The person with the best (realistic) idea will be credited for it.<br>
><br>
</div>> Casey<br>
<br>
Hi Casey,<br>
<br>
Since you asked for ideas, I'll throw a few out there.<br>
<br>
1) Get modern graphics facilities up and running in the squeakvm,<br>
either rome, athens, or gezira, or something else<br>
Pros: Smalltalk, and by extension Squeak have always been oriented<br>
towards the graphical. Heck it's where much of what we use everyday<br>
comes from! So it's kind of a drag that when I go to draw a path in<br>
Squeak my choices are a heavily aliased path in the standard canvas,<br>
or a weird set of rectangles joined together on the balloon canvas.<br>
Gezira is from VPRI and gets points for compactness. Plus Bert has<br>
already done a lot of the work implementing it. Athens is being done<br>
in Pharo and uses NativeBoost I believe so there is that hurdle. Rome<br>
used Cairo I believe and has some work completed but was somewhat<br>
abandoned.<br>
<br>
Cons: Gezira is largely the product of one man and may fall victim to<br>
a low bus factor if this person decides to work on other things. Also<br>
I don't know how good its performance is. Athens uses NativeBoost and<br>
possibly a bunch of other Pharoisms. That may slow your effort. Rome<br>
hasn't seen any work in a while so I don't know what state it is<br>
currently in.<br>
<br>
2) Work to implement some of the RoarVM concepts into the regular SqueakVM<br>
<br>
Pros: My computer seems to acquire more cores with each passing year,<br>
but 100000 factorial still only maxes out one of them. This is a<br>
shame. Allowing squeak to utilize the numerous threads that we all<br>
have access to will be vital in ensuring its relevance in the coming<br>
years. The RoarVM already allows this in a Squeak image. Combined<br>
with Eliot's work on JITing Smalltalk code Squeak could rule the<br>
world!<br>
<br>
Cons: RoarVM was part of a research project and as I understand it the<br>
straight-line performance is far behind the regular squeak VM. It<br>
also appears to be a fairly substantial fork of the regular VM, so<br>
there could probably be a lot of work involved on both the image side<br>
and the VM side in getting its facilities integrated.<br>
<br>
STRETCH GOAL<br>
3) Read the asm.js spec at <a href="http://asmjs.org" target="_blank">http://asmjs.org</a> and then go to<br>
<a href="http://emscripten.org" target="_blank">emscripten.org</a> and read up on the compiler. Then figure out how to<br>
compile a minimal VM to javascript that can run in the browser and<br>
slowly build your way up from there, implementing more and more<br>
plugins and primitives in javascript until a small squeak image can<br>
run.<br>
<br>
Pros: Mozilla spent $150 million last year developing their browser,<br>
and likely Google, Microsoft and Apple did the same. The amount of<br>
money being poured into making browsers faster, quicker to draw,<br>
better at collecting garbage, etc, is pretty insane. There are likely<br>
more people working on just the Mozilla garbage collector than people<br>
working on Squeak/Pharo fulltime. Asm.js is designed to allow for the<br>
compilation of C programs to rigidly defined JS which will be executed<br>
by the browser at speeds currently 2-3x slower than the C code. This<br>
is still really fast and they expect greater speedups in the future.<br>
The emscripten compiler translates draw calls into Canvas calls, sound<br>
calls into Audio API calls, etc, etc. Basically most of the<br>
primitives needed by Squeak are available as Javascript APIs, so the<br>
vm calls to C code could be converted to Javascript calls. Overall<br>
this would allow Squeak to utilize the vast resources being poured<br>
into browsers and Javascript, while bringing along the far superior<br>
language and development environment we all enjoy.<br>
<br>
Cons: Relying on Canvas draw calls rather than BitBlt, for example,<br>
will reduce the whole "from the metal up" feel that you can currently<br>
get with Squeak. This is also obviously a very ambitious project that<br>
would take a lot of work. It would also chain Squeak to a standard<br>
that can change or die out at some point in the future. It would also<br>
make it hard to run squeak in a very memory or processor constrained<br>
environment.<br>
<br>
Anyway, you asked for ideas and those are 3 of them. Hopefully that<br>
wall of text wasn't too much for you.<br>
<br>
Best of luck!<br>
<span class="HOEnZb"><font color="#888888">Jeff<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Casey Ransberger
</div>