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