<div dir="ltr"><div>>> Tim says a multi-core VM is coming for the new Pi. </div><div><br></div><div>> Are you *sure* that's what Tim said?<br></div><div><br></div>Of course my over hopeful misinterpretation is possible.<div><br></div><div>"Squeak runs quite well on a Pi, especially a pi2 - and we're working on the Cog dynamic translation VM right now, which should with luck triple typical performance." - timrowledge » Thu Feb 19, 2015 <br></div><div><a href="https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818">https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818</a><br></div><div><br></div><div><div>> The trick to getting rid of long delays is more a function of preallocating everything you can than getting rid of GC's (I've done some highly interactive stuff in GC environments and preventing GC's is impractical except over short periods of time, minimizing their frequency and duration is very doable) One of the things I think I</div><div>recently saw that should help you in this regard is FFI memory pinning if you're calling out to external code.</div></div><div><br></div><div>Thanks. Maybe when I find, make, or build a better place to work, I'll be able to tackle some of that. I wouldn't be surprised if a VM is as easy as a compiler once one actually starts working on it.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) <span dir="ltr"><<a href="mailto:pbpublist@gmail.com" target="_blank">pbpublist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, 2015-07-05 at 17:12 -0700, Kirk Fraser wrote:<br>
> I used Cuis at first to display hand written G-Codes in graphic form<br>
> for a printed circuit board. I kept up with Cuis through a few<br>
> versions and found a couple of bugs for Juan. Eventually Casey<br>
> advised going to Squeak so I did. Perhaps my requests were getting<br>
> annoying.<br>
><br>
<br>
</span>Perhaps you misinterpreted what Casey said? Definitely have all options<br>
(Squeak, Pharo, Cuis etc.) as part of your toolkit. Squeak in<br>
particular has a very active mailing lists and you'll find a lot of<br>
existing code to play with. I personally do most of my development in<br>
Cuis, some in Pharo (for things like Seaside that don't yet exist in<br>
Cuis), and a bit still in Squeak. They all have their place depending<br>
on your needs. Given your emphasis on performance, I would think that<br>
Cuis is going to be the place where you can maximize it. (all the above<br>
Smalltalk variants use essentially the same core VM, it's the plugins<br>
and images that really differ)<br>
<span class=""><br>
> I'm mostly interested in using a multi-core Squeak with GC control for<br>
> my robot. Tim says a multi-core VM is coming for the new Pi. He<br>
> hasn't answered on GC control. With muliti-core a user need not see<br>
> GC control but the system should provide 100% GC free service even if<br>
> behind the scenes it momentarily toggles one GC off and lets the other<br>
> complete.<br>
><br>
<br>
</span>Are you *sure* that's what Tim said? I see a thread where he's talking<br>
about *build* performance (i.e. compiling the C code for the VM) on a<br>
quad-core with the caveat 'even if Squeak can't directly take<br>
advantage' (i.e. no multi-core VM)<br>
<span class=""><br>
><br>
> With real time driving, which I hope my robot will do some day,<br>
> getting rid of all 100ms delays is vital.<br>
><br>
<br>
</span>The trick to getting rid of long delays is more a function of<br>
preallocating everything you can than getting rid of GC's (I've done<br>
some highly interactive stuff in GC environments and preventing GC's is<br>
impractical except over short periods of time, minimizing their<br>
frequency and duration is very doable) One of the things I think I<br>
recently saw that should help you in this regard is FFI memory pinning<br>
if you're calling out to external code.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> On Sun, Jul 5, 2015 at 4:54 PM, Dan Norton <<a href="mailto:dnorton@mindspring.com">dnorton@mindspring.com</a>><br>
> wrote:<br>
> On 5 Jul 2015 at 16:22, Kirk Fraser wrote:<br>
><br>
><br>
> ><br>
> > We should ask why do people want to teach Python instead of<br>
> > Smalltalk? Why do people veer<br>
> > away from Smalltalk with add-ons like Etoys, Scratch, and<br>
> many other<br>
> > paradigms like Patterns<br>
> > and CRC cards, which aren't as good for commercial<br>
> programming, thus<br>
> > really aren't as good to<br>
> > teach children? What can be done to remodel Squeak to<br>
> provide all<br>
> > the features more<br>
> > commercially popular languages have?<br>
> ><br>
> > Earlier a post saying a boss didn't want a GUI that a<br>
> combination of<br>
> > buttons would bring up all<br>
> > sorts of things his employees shouldn't be playing with. So<br>
> put a<br>
> > cleaner commercial GUI on the<br>
> > list. Maybe the preferences switch could be in its own file<br>
> or as<br>
> > the first character in Sources to<br>
> > reduce file count. The Changes file shouldn't be needed in<br>
> a<br>
> > deployed application. Is there any<br>
> > way to cut the deployment image down to one file containing<br>
> both the<br>
> > Sources and VM like an<br>
> > .exe in any other language?<br>
> ><br>
> > I've written on the need to fix Garbage Collection control<br>
> so it can<br>
> > be turned off like Python allows<br>
> > to enable Squeak to be used for real time projects like self<br>
> driving<br>
> > cars, since a 100ms delay can<br>
> > veer 8 feet off course, fully into a lane of oncoming<br>
> traffic.<br>
> ><br>
> > Recently I learned from a UC Berkeley website it takes 100ms<br>
> to<br>
> > recognize the objects in a<br>
> > picture too. Does that mean the future will have a cloud in<br>
> every<br>
> > car and Squeak needing to<br>
> > conduct image analysis in hundreds of cooperating cores to<br>
> get safe<br>
> > real time performance?<br>
> ><br>
> > The state of Squeak for all its benefits seems like a<br>
> collection of<br>
> > law statutes, a big set of text<br>
> > contributed by years of legislation that nobody can remember<br>
> all of<br>
> > and some of which makes little<br>
> > sense. Maybe a major rewrite starting from zero would help?<br>
> ><br>
><br>
><br>
> " like a collection of law statutes" is a good analogy. Cuis<br>
> seems like a major rewrite of Squeak and is simpler, easier to<br>
> understand. What do you think of Cuis?<br>
><br>
><br>
> > The GUI - while it has many nice features, it somehow seems<br>
> to lack<br>
> > the crisp precision, ease,<br>
> > and speed of commercial software like Solidworks. I like<br>
> how<br>
> > Squeak comes up and is ready to<br>
> > go far quicker than say Amazon's Audible application but<br>
> Squeak<br>
> > graphics aren't so fast or easy<br>
> > to program as Solidworks.<br>
> ><br>
> > Recently I saw a couple of short videos on two moderate size<br>
> robots<br>
> > where users extolled their<br>
> > ease of programming. Perhaps Smalltalk needs a new top<br>
> level rule<br>
> > based language to improve<br>
> > programmer efficiency. I'm working on this one. And as my<br>
> > prototype was so easy, it angers me<br>
> > to think of all the time I spent being both ignorant and<br>
> afraid<br>
> > after seeing various compiler books<br>
> > like the "Dragon Book" intentionally make compiler writing a<br>
> > difficult graduate level course instead<br>
> > of an easy advanced beginner level assignment.<br>
> ><br>
> > But one thing I have in common with my Raspberry Pi, when my<br>
> > utilization is maxed for too long, I<br>
> > overheat and shut down. I can write simple stuff like this<br>
> when<br>
> > it's too hot to do real work. But<br>
> > even multiple cores get too hot when they are maxed out. So<br>
> a real<br>
> > time computer needs heat<br>
> > control or cooling overkill in case a vital complex<br>
> situation clogs<br>
> > the bandwidth. Well, pray about<br>
> > it.<br>
><br>
><br>
> - Dan<br>
><br>
><br>
> _______________________________________________<br>
> Beginners mailing list<br>
> <a href="mailto:Beginners@lists.squeakfoundation.org">Beginners@lists.squeakfoundation.org</a><br>
> <a href="http://lists.squeakfoundation.org/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/beginners</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Beginners mailing list<br>
> <a href="mailto:Beginners@lists.squeakfoundation.org">Beginners@lists.squeakfoundation.org</a><br>
> <a href="http://lists.squeakfoundation.org/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/beginners</a><br>
<br>
<br>
_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@lists.squeakfoundation.org">Beginners@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/beginners</a><br>
</div></div></blockquote></div><br></div>