From philipp.otto2 at student.hpi.de Wed Jul 1 19:49:48 2015 From: philipp.otto2 at student.hpi.de (p-otto) Date: Wed Jul 1 20:12:11 2015 Subject: [Newbies] Resize TextMorph to contained text Message-ID: <1435780188430-4835267.post@n4.nabble.com> Hi, I'm looking for a possibility to automatically resize a TextMorph to the contained text. Is this functionality already available? If not, how would I go about coding it? Best Regards, Philipp Otto -- View this message in context: http://forum.world.st/Resize-TextMorph-to-contained-text-tp4835267.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. From overcomer.man at gmail.com Sun Jul 5 23:22:29 2015 From: overcomer.man at gmail.com (Kirk Fraser) Date: Sun Jul 5 23:22:31 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St Message-ID: 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? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150705/8b525ea8/attachment.htm From dnorton at mindspring.com Sun Jul 5 23:54:20 2015 From: dnorton at mindspring.com (Dan Norton) Date: Sun Jul 5 23:54:26 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: Message-ID: <5599C3AC.1448.20272F8@dnorton.mindspring.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150705/678e038b/attachment-0001.htm From overcomer.man at gmail.com Mon Jul 6 00:12:13 2015 From: overcomer.man at gmail.com (Kirk Fraser) Date: Mon Jul 6 00:12:16 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: <5599C3AC.1448.20272F8@dnorton.mindspring.com> References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> Message-ID: 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. 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. With real time driving, which I hope my robot will do some day, getting rid of all 100ms delays is vital. On Sun, Jul 5, 2015 at 4:54 PM, Dan Norton 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150705/9f6193ea/attachment.htm From pbpublist at gmail.com Mon Jul 6 01:31:28 2015 From: pbpublist at gmail.com (Phil (list)) Date: Mon Jul 6 01:31:20 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> Message-ID: <1436146288.2678.28.camel@gmail.com> 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 > 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 From overcomer.man at gmail.com Mon Jul 6 02:05:41 2015 From: overcomer.man at gmail.com (Kirk Fraser) Date: Mon Jul 6 02:05:43 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: <1436146288.2678.28.camel@gmail.com> References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: >> Tim says a multi-core VM is coming for the new Pi. > Are you *sure* that's what Tim said? Of course my over hopeful misinterpretation is possible. "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 https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 > 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. 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. On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) wrote: > 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 > > 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 > > > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150705/772bc55d/attachment.htm From johnson at cs.uiuc.edu Mon Jul 6 11:19:16 2015 From: johnson at cs.uiuc.edu (Ralph Johnson) Date: Mon Jul 6 11:19:22 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: Here is another possibility. Take a look at Symbolic Sound, a company that makes a system called Kyma. http://kyma.symbolicsound.com/ This company has been around for over twenty years. Its product has always been the fastest music synthesis system in the world that gives you total control over your sound. And by "total", I mean it gives you the ability to mathematically specify each sound wave. If you want, which is actually too much detail for most people. And it is all written in Smalltalk. Not Squeak, of course, since Squeak wasn't around then. But it could have been done in Squeak. And perhaps they ported it to Squeak. I haven't talked to them for a long time so I don't know what they did, but from the screen shots I think it is still a very old version of VisualWorks. Anyway, how do they make it so fast? How can they make something that can be used for hours without any GC pauses? The trick is that the sound is produced on an attached DSP. The GUI is in Smalltalk on a PC, and it generates code for the DSP. It is non-trivial making the compiler so fast that when you press "play", it can immediately start up the DSP and start producing sound. It does this (rather, it did this, since they might have changed the way it works) by just producing enough code to run the DSP for a few seconds and then starting the DSP while it generates the rest of the code. Kyma literally is writing the program into DSP memory at the same time as the DSP is running the program, producing sound. Anyway, maybe that is the right approach to programming robots. You don't even need to use two computers. Imagine you had two computers, one running Squeak and the other a simple, real-time machine designed for controlling robots, but not very sophisticated. Squeak programs the simple computer, and can change its program dynamically. The simple computer has no gc. Since Squeak is a VM on a computer, the real-time computer can be a VM, too. So, you could be running them both on your PC, or you could run them on two separate computers for better performance. I would be happy to talk more about this. But I'd like to talk about the beginning of Kyma. The owners of Symbolic Sound are Carla Scaletti and Kurt Hebel. Carla has a PhD in music, and Kurt in Electrical Engineering. I met Carla after she had her PhD. She wanted to get a MS in computer science so she could prove her computer music expertise, and she ended up getting it with me. She took my course on OOP&D that used Smalltalk. For her class project (back in 1987, I think) she wrote a Smalltalk program that ran on the Mac and that produced about ten seconds of sound, but it took several minutes to do it. Hardly real time. However, she was used to using a supercomputer (a Cray?) to generate sounds that still weren't real time, so she was very pleased that she could do it on the Mac at all, and though Smalltalk was slower than Fortran, in her opinion the ease of use was so great that she didn't mind the speed difference. As she put it, the speed difference between a Mac and a Cray was bigger than between Smalltalk and Fortran. She ended up turning this into the first version of Kyma and that became the subject of her MS thesis. I can remember when she showed it in class. She was the only woman in the class, and the other students knew she was a musician, i.e. not *really* a programmer. She was quiet during class, so they had not had a chance to have their prejudices remedied. Her demo at the end of the semester blew them away. Kurt had built a DSP that their lab used. (The lab was part of the Plato project, I believe, one of the huge number of creative results of this very significant project at Illinois.) It was called the Capybara. This was before the time when you could just buy a good DSP on a chip, but that time came very soon and then they used the commercial chips. For her MS, she converted her system to use the Capybara, and this was when she figured out how to make it start making music within a fraction of a second of pressing the "play" button. Kurt also used Smalltalk with the Capybara. His PhD was about automatically designing digital filters, and his software also generated code for the Capybara, though it was actually quite different from Kyma. The two of them worked on several different projects over the next few years, but kept improving Kyma. Along the way Kurt started building boards that had several commercial DSPs on them. Eventually they decided to go commercial and started Symbolic Sound. -Ralph Johnson On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser wrote: > >> Tim says a multi-core VM is coming for the new Pi. > > > Are you *sure* that's what Tim said? > > Of course my over hopeful misinterpretation is possible. > > "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 > > https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 > > > > 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. > > 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. > > > On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) wrote: > >> 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 >> > 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 >> >> >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150706/9b546ebb/attachment-0001.htm From overcomer.man at gmail.com Mon Jul 6 19:39:13 2015 From: overcomer.man at gmail.com (Kirk Fraser) Date: Mon Jul 6 19:39:16 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: Ralph Johnson, That's an excellent suggestion and an excellent story, thank you very much! Letting the human interface in Smalltalk program the robot controller instead of being the robot controller sounds good. My robot uses a network of Parallax microcontroller chips to drive hydraulic valves, which can be programmed via USB for simple tasks like moving one joint from point A to B but since each controller has 8 cores more complex tasks like grasping or walking can be done on the MCU's or on a small Raspberry Pi or other hardware in a non-GC or controllable GC language. A harder part to wrap my head around is handling the webcam vision system and artificial intelligence while remaining time sensitive enough to do time critical tasks like cartwheels and other acrobatic choreography. I know in effect my human mind shuts down most of its intellectual pursuits when engaged in heavy physical activity - maybe the robot must do the same - think more creatively when idling and pay closer attention while working. That takes care of the Ai timing. The heavy load of vision processing appears to need a mini-cloud of cores to reduce time to identify and measure objects from contours and other information. To guarantee performance they would also need to run a non-GC language that could be programmed from Squeak interactively as new objects are being learned. I haven't worked with a laser range finder but I suspect they use it to narrow the focus onto moving objects to process video in more detail in those areas. The current buzzword "co-robots" meaning robots that work beside or cooperatively with people working in symbiotic relationships with human partners suggests everyone will need a robot friend, which will require an artificial intelligence capable of intelligent thought. As most Americans are Christian it would make sense for a human compatible AI to be based on the Bible. That is what I would love to work on. But that level of thought needs a creative CG environment like Squeak at present. I've been thinking that using a Smalltalk GUI to issue command rules to set an agenda for automatic text analysis and editing might be fun, letting the computer do the editing instead of me. That way it could update the AI knowledge like when a preferred synonym is discovered, without taking human time to do much of it beyond the setup. Your wikipedia entry shows a webpage and blog that apparently are dead links. Would you be interested in being a team member on my SBIR/STTR grant application(s) for AI and Robots responding to: http://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf15505 I've enlisted help in writing the application from Oregon's Small Business Development Center and will meet with an SBIR road trip in August I'm told. (I was also told I need a Ph.D. on my team since I don't have one.) Kirk Fraser On Mon, Jul 6, 2015 at 4:19 AM, Ralph Johnson wrote: > Here is another possibility. > > Take a look at Symbolic Sound, a company that makes a system called Kyma. > http://kyma.symbolicsound.com/ > > This company has been around for over twenty years. Its product has > always been the fastest music synthesis system in the world that gives you > total control over your sound. And by "total", I mean it gives you the > ability to mathematically specify each sound wave. If you want, which is > actually too much detail for most people. And it is all written in > Smalltalk. Not Squeak, of course, since Squeak wasn't around then. But > it could have been done in Squeak. And perhaps they ported it to Squeak. > I haven't talked to them for a long time so I don't know what they did, > but from the screen shots I think it is still a very old version of > VisualWorks. > > Anyway, how do they make it so fast? How can they make something that can > be used for hours without any GC pauses? > > The trick is that the sound is produced on an attached DSP. The GUI is > in Smalltalk on a PC, and it generates code for the DSP. It is > non-trivial making the compiler so fast that when you press "play", it can > immediately start up the DSP and start producing sound. It does this > (rather, it did this, since they might have changed the way it works) by > just producing enough code to run the DSP for a few seconds and then > starting the DSP while it generates the rest of the code. Kyma literally > is writing the program into DSP memory at the same time as the DSP is > running the program, producing sound. > > Anyway, maybe that is the right approach to programming robots. You > don't even need to use two computers. Imagine you had two computers, one > running Squeak and the other a simple, real-time machine designed for > controlling robots, but not very sophisticated. Squeak programs the simple > computer, and can change its program dynamically. The simple computer has > no gc. Since Squeak is a VM on a computer, the real-time computer can be > a VM, too. So, you could be running them both on your PC, or you could run > them on two separate computers for better performance. > > I would be happy to talk more about this. But I'd like to talk about the > beginning of Kyma. The owners of Symbolic Sound are Carla Scaletti and > Kurt Hebel. Carla has a PhD in music, and Kurt in Electrical Engineering. > I met Carla after she had her PhD. She wanted to get a MS in computer > science so she could prove her computer music expertise, and she ended up > getting it with me. She took my course on OOP&D that used Smalltalk. For > her class project (back in 1987, I think) she wrote a Smalltalk program > that ran on the Mac and that produced about ten seconds of sound, but it > took several minutes to do it. Hardly real time. However, she was used > to using a supercomputer (a Cray?) to generate sounds that still weren't > real time, so she was very pleased that she could do it on the Mac at all, > and though Smalltalk was slower than Fortran, in her opinion the ease of > use was so great that she didn't mind the speed difference. As she put > it, the speed difference between a Mac and a Cray was bigger than between > Smalltalk and Fortran. She ended up turning this into the first version of > Kyma and that became the subject of her MS thesis. I can remember when > she showed it in class. She was the only woman in the class, and the other > students knew she was a musician, i.e. not *really* a programmer. She was > quiet during class, so they had not had a chance to have their prejudices > remedied. Her demo at the end of the semester blew them away. > > Kurt had built a DSP that their lab used. (The lab was part of the Plato > project, I believe, one of the huge number of creative results of this very > significant project at Illinois.) It was called the Capybara. This was > before the time when you could just buy a good DSP on a chip, but that time > came very soon and then they used the commercial chips. For her MS, she > converted her system to use the Capybara, and this was when she figured out > how to make it start making music within a fraction of a second of pressing > the "play" button. Kurt also used Smalltalk with the Capybara. His PhD > was about automatically designing digital filters, and his software also > generated code for the Capybara, though it was actually quite different > from Kyma. > > The two of them worked on several different projects over the next few > years, but kept improving Kyma. Along the way Kurt started building > boards that had several commercial DSPs on them. Eventually they decided > to go commercial and started Symbolic Sound. > > -Ralph Johnson > > On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser > wrote: > >> >> Tim says a multi-core VM is coming for the new Pi. >> >> > Are you *sure* that's what Tim said? >> >> Of course my over hopeful misinterpretation is possible. >> >> "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 >> >> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 >> >> >> > 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. >> >> 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. >> >> >> On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) wrote: >> >>> 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 >>> > 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 >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150706/20260e90/attachment-0001.htm From casey.obrien.r at gmail.com Tue Jul 14 00:58:34 2015 From: casey.obrien.r at gmail.com (Casey Ransberger) Date: Tue Jul 14 00:58:40 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: Hey Kirk, I like Ralph's suggestion of doing the time/timing specific stuff on a dedicated microcontroller. I'd recommend going one better: use more than one microcontroller. Robots need to do a lot in parallel; if the robot has to stop driving in order to think, that's a problem (although the converse would be decidedly human!) Anyway, it sounds like real-time is not negotiable in your view, so green threads won't cut it either. Mine has... six controllers in total. That's not counting the ARM9 which is more like a full computer (e.g., Linux.) I think six anyway. Could be more hiding in there. Two drive sensors, three drive motors, one is wired up close to the ARM board to coordinate the other controllers on behalf of what the Linux system wants them doing. I'm curious, have you figured out what the average, best, and worst case latencies are on human reflexes? In my view, matching or beating that benchmark is where the money probably is. --C > On Jul 6, 2015, at 12:39 PM, Kirk Fraser wrote: > > Ralph Johnson, > > That's an excellent suggestion and an excellent story, thank you very much! Letting the human interface in Smalltalk program the robot controller instead of being the robot controller sounds good. > > My robot uses a network of Parallax microcontroller chips to drive hydraulic valves, which can be programmed via USB for simple tasks like moving one joint from point A to B but since each controller has 8 cores more complex tasks like grasping or walking can be done on the MCU's or on a small Raspberry Pi or other hardware in a non-GC or controllable GC language. > > A harder part to wrap my head around is handling the webcam vision system and artificial intelligence while remaining time sensitive enough to do time critical tasks like cartwheels and other acrobatic choreography. > > I know in effect my human mind shuts down most of its intellectual pursuits when engaged in heavy physical activity - maybe the robot must do the same - think more creatively when idling and pay closer attention while working. That takes care of the Ai timing. > > The heavy load of vision processing appears to need a mini-cloud of cores to reduce time to identify and measure objects from contours and other information. To guarantee performance they would also need to run a non-GC language that could be programmed from Squeak interactively as new objects are being learned. I haven't worked with a laser range finder but I suspect they use it to narrow the focus onto moving objects to process video in more detail in those areas. > > The current buzzword "co-robots" meaning robots that work beside or cooperatively with people working in symbiotic relationships with human partners suggests everyone will need a robot friend, which will require an artificial intelligence capable of intelligent thought. As most Americans are Christian it would make sense for a human compatible AI to be based on the Bible. That is what I would love to work on. But that level of thought needs a creative CG environment like Squeak at present. > > I've been thinking that using a Smalltalk GUI to issue command rules to set an agenda for automatic text analysis and editing might be fun, letting the computer do the editing instead of me. That way it could update the AI knowledge like when a preferred synonym is discovered, without taking human time to do much of it beyond the setup. > > Your wikipedia entry shows a webpage and blog that apparently are dead links. Would you be interested in being a team member on my SBIR/STTR grant application(s) for AI and Robots responding to: > http://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf15505 I've enlisted help in writing the application from Oregon's Small Business Development Center and will meet with an SBIR road trip in August I'm told. (I was also told I need a Ph.D. on my team since I don't have one.) > > Kirk Fraser > > >> On Mon, Jul 6, 2015 at 4:19 AM, Ralph Johnson wrote: >> Here is another possibility. >> >> Take a look at Symbolic Sound, a company that makes a system called Kyma. http://kyma.symbolicsound.com/ >> >> This company has been around for over twenty years. Its product has always been the fastest music synthesis system in the world that gives you total control over your sound. And by "total", I mean it gives you the ability to mathematically specify each sound wave. If you want, which is actually too much detail for most people. And it is all written in Smalltalk. Not Squeak, of course, since Squeak wasn't around then. But it could have been done in Squeak. And perhaps they ported it to Squeak. I haven't talked to them for a long time so I don't know what they did, but from the screen shots I think it is still a very old version of VisualWorks. >> >> Anyway, how do they make it so fast? How can they make something that can be used for hours without any GC pauses? >> >> The trick is that the sound is produced on an attached DSP. The GUI is in Smalltalk on a PC, and it generates code for the DSP. It is non-trivial making the compiler so fast that when you press "play", it can immediately start up the DSP and start producing sound. It does this (rather, it did this, since they might have changed the way it works) by just producing enough code to run the DSP for a few seconds and then starting the DSP while it generates the rest of the code. Kyma literally is writing the program into DSP memory at the same time as the DSP is running the program, producing sound. >> >> Anyway, maybe that is the right approach to programming robots. You don't even need to use two computers. Imagine you had two computers, one running Squeak and the other a simple, real-time machine designed for controlling robots, but not very sophisticated. Squeak programs the simple computer, and can change its program dynamically. The simple computer has no gc. Since Squeak is a VM on a computer, the real-time computer can be a VM, too. So, you could be running them both on your PC, or you could run them on two separate computers for better performance. >> >> I would be happy to talk more about this. But I'd like to talk about the beginning of Kyma. The owners of Symbolic Sound are Carla Scaletti and Kurt Hebel. Carla has a PhD in music, and Kurt in Electrical Engineering. I met Carla after she had her PhD. She wanted to get a MS in computer science so she could prove her computer music expertise, and she ended up getting it with me. She took my course on OOP&D that used Smalltalk. For her class project (back in 1987, I think) she wrote a Smalltalk program that ran on the Mac and that produced about ten seconds of sound, but it took several minutes to do it. Hardly real time. However, she was used to using a supercomputer (a Cray?) to generate sounds that still weren't real time, so she was very pleased that she could do it on the Mac at all, and though Smalltalk was slower than Fortran, in her opinion the ease of use was so great that she didn't mind the speed difference. As she put it, the speed difference between a Mac and a Cray was bigger than between Smalltalk and Fortran. She ended up turning this into the first version of Kyma and that became the subject of her MS thesis. I can remember when she showed it in class. She was the only woman in the class, and the other students knew she was a musician, i.e. not *really* a programmer. She was quiet during class, so they had not had a chance to have their prejudices remedied. Her demo at the end of the semester blew them away. >> >> Kurt had built a DSP that their lab used. (The lab was part of the Plato project, I believe, one of the huge number of creative results of this very significant project at Illinois.) It was called the Capybara. This was before the time when you could just buy a good DSP on a chip, but that time came very soon and then they used the commercial chips. For her MS, she converted her system to use the Capybara, and this was when she figured out how to make it start making music within a fraction of a second of pressing the "play" button. Kurt also used Smalltalk with the Capybara. His PhD was about automatically designing digital filters, and his software also generated code for the Capybara, though it was actually quite different from Kyma. >> >> The two of them worked on several different projects over the next few years, but kept improving Kyma. Along the way Kurt started building boards that had several commercial DSPs on them. Eventually they decided to go commercial and started Symbolic Sound. >> >> -Ralph Johnson >> >>> On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser wrote: >>> >> Tim says a multi-core VM is coming for the new Pi. >>> >>> > Are you *sure* that's what Tim said? >>> >>> Of course my over hopeful misinterpretation is possible. >>> >>> "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 >>> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 >>> >>> > 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. >>> >>> 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. >>> >>> >>>> On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) wrote: >>>> 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 >>>> > 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150713/ab8ccf25/attachment-0001.htm From herdenkerry6 at gmail.com Tue Jul 14 02:02:50 2015 From: herdenkerry6 at gmail.com (Kerry Herden) Date: Tue Jul 14 02:02:53 2015 Subject: [Newbies] Re: Beginners Digest, Vol 108, Issue 5 In-Reply-To: <55a45ecc.f4528c0a.e50af.ffff8570SMTPIN_ADDED_MISSING@mx.google.com> References: <55a45ecc.f4528c0a.e50af.ffff8570SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: unsubscribe? On Tue, Jul 14, 2015 at 10:58 AM, < beginners-request@lists.squeakfoundation.org> wrote: > Send Beginners mailing list submissions to > beginners@lists.squeakfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.squeakfoundation.org/mailman/listinfo/beginners > or, via email, send a message with subject or body 'help' to > beginners-request@lists.squeakfoundation.org > > You can reach the person managing the list at > beginners-owner@lists.squeakfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Beginners digest..." > > > Today's Topics: > > 1. Re: Raspberry Pi v. Raspberry St (Casey Ransberger) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 13 Jul 2015 17:58:34 -0700 > From: Casey Ransberger > Subject: Re: [Newbies] Raspberry Pi v. Raspberry St > To: "A friendly place to get answers to even the most basic questions > about Squeak." > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hey Kirk, > > I like Ralph's suggestion of doing the time/timing specific stuff on a > dedicated microcontroller. > > I'd recommend going one better: use more than one microcontroller. Robots > need to do a lot in parallel; if the robot has to stop driving in order to > think, that's a problem (although the converse would be decidedly human!) > Anyway, it sounds like real-time is not negotiable in your view, so green > threads won't cut it either. > > Mine has... six controllers in total. That's not counting the ARM9 which > is more like a full computer (e.g., Linux.) > > I think six anyway. Could be more hiding in there. Two drive sensors, > three drive motors, one is wired up close to the ARM board to coordinate > the other controllers on behalf of what the Linux system wants them doing. > > I'm curious, have you figured out what the average, best, and worst case > latencies are on human reflexes? In my view, matching or beating that > benchmark is where the money probably is. > > --C > > > On Jul 6, 2015, at 12:39 PM, Kirk Fraser > wrote: > > > > Ralph Johnson, > > > > That's an excellent suggestion and an excellent story, thank you very > much! Letting the human interface in Smalltalk program the robot > controller instead of being the robot controller sounds good. > > > > My robot uses a network of Parallax microcontroller chips to drive > hydraulic valves, which can be programmed via USB for simple tasks like > moving one joint from point A to B but since each controller has 8 cores > more complex tasks like grasping or walking can be done on the MCU's or on > a small Raspberry Pi or other hardware in a non-GC or controllable GC > language. > > > > A harder part to wrap my head around is handling the webcam vision > system and artificial intelligence while remaining time sensitive enough to > do time critical tasks like cartwheels and other acrobatic choreography. > > > > I know in effect my human mind shuts down most of its intellectual > pursuits when engaged in heavy physical activity - maybe the robot must do > the same - think more creatively when idling and pay closer attention while > working. That takes care of the Ai timing. > > > > The heavy load of vision processing appears to need a mini-cloud of > cores to reduce time to identify and measure objects from contours and > other information. To guarantee performance they would also need to run a > non-GC language that could be programmed from Squeak interactively as new > objects are being learned. I haven't worked with a laser range finder but > I suspect they use it to narrow the focus onto moving objects to process > video in more detail in those areas. > > > > The current buzzword "co-robots" meaning robots that work beside or > cooperatively with people working in symbiotic relationships with human > partners suggests everyone will need a robot friend, which will require an > artificial intelligence capable of intelligent thought. As most Americans > are Christian it would make sense for a human compatible AI to be based on > the Bible. That is what I would love to work on. But that level of > thought needs a creative CG environment like Squeak at present. > > > > I've been thinking that using a Smalltalk GUI to issue command rules to > set an agenda for automatic text analysis and editing might be fun, letting > the computer do the editing instead of me. That way it could update the AI > knowledge like when a preferred synonym is discovered, without taking human > time to do much of it beyond the setup. > > > > Your wikipedia entry shows a webpage and blog that apparently are dead > links. Would you be interested in being a team member on my SBIR/STTR > grant application(s) for AI and Robots responding to: > > http://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf15505 I've > enlisted help in writing the application from Oregon's Small Business > Development Center and will meet with an SBIR road trip in August I'm > told. (I was also told I need a Ph.D. on my team since I don't have one.) > > > > Kirk Fraser > > > > > >> On Mon, Jul 6, 2015 at 4:19 AM, Ralph Johnson > wrote: > >> Here is another possibility. > >> > >> Take a look at Symbolic Sound, a company that makes a system called > Kyma. http://kyma.symbolicsound.com/ > >> > >> This company has been around for over twenty years. Its product has > always been the fastest music synthesis system in the world that gives you > total control over your sound. And by "total", I mean it gives you the > ability to mathematically specify each sound wave. If you want, which is > actually too much detail for most people. And it is all written in > Smalltalk. Not Squeak, of course, since Squeak wasn't around then. But > it could have been done in Squeak. And perhaps they ported it to Squeak. > I haven't talked to them for a long time so I don't know what they did, > but from the screen shots I think it is still a very old version of > VisualWorks. > >> > >> Anyway, how do they make it so fast? How can they make something that > can be used for hours without any GC pauses? > >> > >> The trick is that the sound is produced on an attached DSP. The GUI > is in Smalltalk on a PC, and it generates code for the DSP. It is > non-trivial making the compiler so fast that when you press "play", it can > immediately start up the DSP and start producing sound. It does this > (rather, it did this, since they might have changed the way it works) by > just producing enough code to run the DSP for a few seconds and then > starting the DSP while it generates the rest of the code. Kyma literally > is writing the program into DSP memory at the same time as the DSP is > running the program, producing sound. > >> > >> Anyway, maybe that is the right approach to programming robots. You > don't even need to use two computers. Imagine you had two computers, one > running Squeak and the other a simple, real-time machine designed for > controlling robots, but not very sophisticated. Squeak programs the simple > computer, and can change its program dynamically. The simple computer has > no gc. Since Squeak is a VM on a computer, the real-time computer can be > a VM, too. So, you could be running them both on your PC, or you could run > them on two separate computers for better performance. > >> > >> I would be happy to talk more about this. But I'd like to talk about > the beginning of Kyma. The owners of Symbolic Sound are Carla Scaletti > and Kurt Hebel. Carla has a PhD in music, and Kurt in Electrical > Engineering. I met Carla after she had her PhD. She wanted to get a MS > in computer science so she could prove her computer music expertise, and > she ended up getting it with me. She took my course on OOP&D that used > Smalltalk. For her class project (back in 1987, I think) she wrote a > Smalltalk program that ran on the Mac and that produced about ten seconds > of sound, but it took several minutes to do it. Hardly real time. > However, she was used to using a supercomputer (a Cray?) to generate > sounds that still weren't real time, so she was very pleased that she could > do it on the Mac at all, and though Smalltalk was slower than Fortran, in > her opinion the ease of use was so great that she didn't mind the speed > difference. As she put it, the speed difference between a Mac and a Cray > was bigger than between Smalltalk and Fortran. She ended up turning this > into the first version of Kyma and that became the subject of her MS > thesis. I can remember when she showed it in class. She was the only > woman in the class, and the other students knew she was a musician, i.e. > not *really* a programmer. She was quiet during class, so they had not had > a chance to have their prejudices remedied. Her demo at the end of the > semester blew them away. > >> > >> Kurt had built a DSP that their lab used. (The lab was part of the > Plato project, I believe, one of the huge number of creative results of > this very significant project at Illinois.) It was called the Capybara. > This was before the time when you could just buy a good DSP on a chip, but > that time came very soon and then they used the commercial chips. For her > MS, she converted her system to use the Capybara, and this was when she > figured out how to make it start making music within a fraction of a second > of pressing the "play" button. Kurt also used Smalltalk with the > Capybara. His PhD was about automatically designing digital filters, and > his software also generated code for the Capybara, though it was actually > quite different from Kyma. > >> > >> The two of them worked on several different projects over the next few > years, but kept improving Kyma. Along the way Kurt started building > boards that had several commercial DSPs on them. Eventually they decided > to go commercial and started Symbolic Sound. > >> > >> -Ralph Johnson > >> > >>> On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser > wrote: > >>> >> Tim says a multi-core VM is coming for the new Pi. > >>> > >>> > Are you *sure* that's what Tim said? > >>> > >>> Of course my over hopeful misinterpretation is possible. > >>> > >>> "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 > >>> > https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 > >>> > >>> > 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. > >>> > >>> 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. > >>> > >>> > >>>> On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) > wrote: > >>>> 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 > >>>> > 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 > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150713/ab8ccf25/attachment.htm > > ------------------------------ > > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > > End of Beginners Digest, Vol 108, Issue 5 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150714/0c90c940/attachment-0001.htm From overcomer.man at gmail.com Tue Jul 14 03:55:15 2015 From: overcomer.man at gmail.com (Kirk Fraser) Date: Tue Jul 14 03:55:17 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: Hi Casey, Thanks for the suggestion. I will have multiple connected controller boards and with your suggestion maybe I'll try a Pi for each limb and each webcam or maybe your ARM9 suggestion. To prove it's good as a human in performance I want it to do minor acrobatics like cartwheels and balancing tricks, maybe a Chuck Norris kick or jumping over a fence with one hand on a post. Or like those free-running videos. Stuff I could not do myself. But it all waits on money. Maybe I'll make better progress next year when social security kicks in. As far as human performance goals, one professor wrote it takes 200 cycles per second to hop on one leg. Somewhere I read human touch can sense 1 in 32,000 of an inch. I don't have the other figures yet. I may not be able to drive an arm as fast as a human boxer - 200 mph but as long as it's fast enough to drive a vehicle on a slow road (not I5) that might be enough until faster computers are here. The vision system seems like a major speed bottle neck. Maybe a mini-cloud can take one 64th of the image for each processor analyze it, then assemble larger object detection in time for the next frame. The DARPA Atlas robot used 4 cores for each camera I think. But a mini-cloud set off nearby to process vision and return either the objects with measurements or instructions would be a lot of work. The more I write, the more I see why the head of DARPA's robots said they cost 1-2 million as you have to hire a team of programmers or make a really intricate learning program. Kirk On Mon, Jul 13, 2015 at 5:58 PM, Casey Ransberger wrote: > Hey Kirk, > > I like Ralph's suggestion of doing the time/timing specific stuff on a > dedicated microcontroller. > > I'd recommend going one better: use more than one microcontroller. Robots > need to do a lot in parallel; if the robot has to stop driving in order to > think, that's a problem (although the converse would be decidedly human!) > Anyway, it sounds like real-time is not negotiable in your view, so green > threads won't cut it either. > > Mine has... six controllers in total. That's not counting the ARM9 which > is more like a full computer (e.g., Linux.) > > I think six anyway. Could be more hiding in there. Two drive sensors, > three drive motors, one is wired up close to the ARM board to coordinate > the other controllers on behalf of what the Linux system wants them doing. > > I'm curious, have you figured out what the average, best, and worst case > latencies are on human reflexes? In my view, matching or beating that > benchmark is where the money probably is. > > --C > > On Jul 6, 2015, at 12:39 PM, Kirk Fraser wrote: > > Ralph Johnson, > > That's an excellent suggestion and an excellent story, thank you very > much! Letting the human interface in Smalltalk program the robot > controller instead of being the robot controller sounds good. > > My robot uses a network of Parallax microcontroller chips to drive > hydraulic valves, which can be programmed via USB for simple tasks like > moving one joint from point A to B but since each controller has 8 cores > more complex tasks like grasping or walking can be done on the MCU's or on > a small Raspberry Pi or other hardware in a non-GC or controllable GC > language. > > A harder part to wrap my head around is handling the webcam vision system > and artificial intelligence while remaining time sensitive enough to do > time critical tasks like cartwheels and other acrobatic choreography. > > I know in effect my human mind shuts down most of its intellectual > pursuits when engaged in heavy physical activity - maybe the robot must do > the same - think more creatively when idling and pay closer attention while > working. That takes care of the Ai timing. > > The heavy load of vision processing appears to need a mini-cloud of cores > to reduce time to identify and measure objects from contours and other > information. To guarantee performance they would also need to run a non-GC > language that could be programmed from Squeak interactively as new objects > are being learned. I haven't worked with a laser range finder but I > suspect they use it to narrow the focus onto moving objects to process > video in more detail in those areas. > > The current buzzword "co-robots" meaning robots that work beside or > cooperatively with people working in symbiotic relationships with human > partners suggests everyone will need a robot friend, which will require an > artificial intelligence capable of intelligent thought. As most Americans > are Christian it would make sense for a human compatible AI to be based on > the Bible. That is what I would love to work on. But that level of > thought needs a creative CG environment like Squeak at present. > > I've been thinking that using a Smalltalk GUI to issue command rules to > set an agenda for automatic text analysis and editing might be fun, letting > the computer do the editing instead of me. That way it could update the AI > knowledge like when a preferred synonym is discovered, without taking human > time to do much of it beyond the setup. > > Your wikipedia entry shows a webpage and blog that apparently are dead > links. Would you be interested in being a team member on my SBIR/STTR > grant application(s) for AI and Robots responding to: > http://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf15505 I've > enlisted help in writing the application from Oregon's Small Business > Development Center and will meet with an SBIR road trip in August I'm told. > (I was also told I need a Ph.D. on my team since I don't have one.) > > Kirk Fraser > > > On Mon, Jul 6, 2015 at 4:19 AM, Ralph Johnson wrote: > >> Here is another possibility. >> >> Take a look at Symbolic Sound, a company that makes a system called Kyma. >> http://kyma.symbolicsound.com/ >> >> This company has been around for over twenty years. Its product has >> always been the fastest music synthesis system in the world that gives you >> total control over your sound. And by "total", I mean it gives you the >> ability to mathematically specify each sound wave. If you want, which is >> actually too much detail for most people. And it is all written in >> Smalltalk. Not Squeak, of course, since Squeak wasn't around then. But >> it could have been done in Squeak. And perhaps they ported it to Squeak. >> I haven't talked to them for a long time so I don't know what they did, >> but from the screen shots I think it is still a very old version of >> VisualWorks. >> >> Anyway, how do they make it so fast? How can they make something that >> can be used for hours without any GC pauses? >> >> The trick is that the sound is produced on an attached DSP. The GUI is >> in Smalltalk on a PC, and it generates code for the DSP. It is >> non-trivial making the compiler so fast that when you press "play", it can >> immediately start up the DSP and start producing sound. It does this >> (rather, it did this, since they might have changed the way it works) by >> just producing enough code to run the DSP for a few seconds and then >> starting the DSP while it generates the rest of the code. Kyma literally >> is writing the program into DSP memory at the same time as the DSP is >> running the program, producing sound. >> >> Anyway, maybe that is the right approach to programming robots. You >> don't even need to use two computers. Imagine you had two computers, one >> running Squeak and the other a simple, real-time machine designed for >> controlling robots, but not very sophisticated. Squeak programs the simple >> computer, and can change its program dynamically. The simple computer has >> no gc. Since Squeak is a VM on a computer, the real-time computer can be >> a VM, too. So, you could be running them both on your PC, or you could run >> them on two separate computers for better performance. >> >> I would be happy to talk more about this. But I'd like to talk about the >> beginning of Kyma. The owners of Symbolic Sound are Carla Scaletti and >> Kurt Hebel. Carla has a PhD in music, and Kurt in Electrical Engineering. >> I met Carla after she had her PhD. She wanted to get a MS in computer >> science so she could prove her computer music expertise, and she ended up >> getting it with me. She took my course on OOP&D that used Smalltalk. For >> her class project (back in 1987, I think) she wrote a Smalltalk program >> that ran on the Mac and that produced about ten seconds of sound, but it >> took several minutes to do it. Hardly real time. However, she was used >> to using a supercomputer (a Cray?) to generate sounds that still weren't >> real time, so she was very pleased that she could do it on the Mac at all, >> and though Smalltalk was slower than Fortran, in her opinion the ease of >> use was so great that she didn't mind the speed difference. As she put >> it, the speed difference between a Mac and a Cray was bigger than between >> Smalltalk and Fortran. She ended up turning this into the first version of >> Kyma and that became the subject of her MS thesis. I can remember when >> she showed it in class. She was the only woman in the class, and the other >> students knew she was a musician, i.e. not *really* a programmer. She was >> quiet during class, so they had not had a chance to have their prejudices >> remedied. Her demo at the end of the semester blew them away. >> >> Kurt had built a DSP that their lab used. (The lab was part of the >> Plato project, I believe, one of the huge number of creative results of >> this very significant project at Illinois.) It was called the Capybara. >> This was before the time when you could just buy a good DSP on a chip, but >> that time came very soon and then they used the commercial chips. For her >> MS, she converted her system to use the Capybara, and this was when she >> figured out how to make it start making music within a fraction of a second >> of pressing the "play" button. Kurt also used Smalltalk with the >> Capybara. His PhD was about automatically designing digital filters, and >> his software also generated code for the Capybara, though it was actually >> quite different from Kyma. >> >> The two of them worked on several different projects over the next few >> years, but kept improving Kyma. Along the way Kurt started building >> boards that had several commercial DSPs on them. Eventually they decided >> to go commercial and started Symbolic Sound. >> >> -Ralph Johnson >> >> On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser >> wrote: >> >>> >> Tim says a multi-core VM is coming for the new Pi. >>> >>> > Are you *sure* that's what Tim said? >>> >>> Of course my over hopeful misinterpretation is possible. >>> >>> "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 >>> >>> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 >>> >>> >>> > 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. >>> >>> 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. >>> >>> >>> On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) wrote: >>> >>>> 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 >>>> > 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150713/31ec9bdb/attachment-0001.htm From btc at openinworld.com Tue Jul 14 11:42:14 2015 From: btc at openinworld.com (Ben Coman) Date: Tue Jul 14 11:42:35 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: Smalltalk FPGA may be of interest... http://www.slideshare.net/esug/luc-fabresse-iwst2014 http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_From%20Smalltalk%20to%20Silicon_Towards%20a%20methodology%20to%20turn%20Smalltalk%20code%20into%20FPGA.pdf cheers -ben On Tue, Jul 14, 2015 at 11:55 AM, Kirk Fraser wrote: > Hi Casey, > > Thanks for the suggestion. I will have multiple connected controller boards > and with your suggestion maybe I'll try a Pi for each limb and each webcam > or maybe your ARM9 suggestion. > > To prove it's good as a human in performance I want it to do minor > acrobatics like cartwheels and balancing tricks, maybe a Chuck Norris kick > or jumping over a fence with one hand on a post. Or like those free-running > videos. Stuff I could not do myself. But it all waits on money. Maybe I'll > make better progress next year when social security kicks in. > > As far as human performance goals, one professor wrote it takes 200 cycles > per second to hop on one leg. Somewhere I read human touch can sense 1 in > 32,000 of an inch. I don't have the other figures yet. I may not be able > to drive an arm as fast as a human boxer - 200 mph but as long as it's fast > enough to drive a vehicle on a slow road (not I5) that might be enough until > faster computers are here. > > The vision system seems like a major speed bottle neck. Maybe a mini-cloud > can take one 64th of the image for each processor analyze it, then assemble > larger object detection in time for the next frame. The DARPA Atlas robot > used 4 cores for each camera I think. But a mini-cloud set off nearby to > process vision and return either the objects with measurements or > instructions would be a lot of work. The more I write, the more I see why > the head of DARPA's robots said they cost 1-2 million as you have to hire a > team of programmers or make a really intricate learning program. > > Kirk > > > On Mon, Jul 13, 2015 at 5:58 PM, Casey Ransberger > wrote: >> >> Hey Kirk, >> >> I like Ralph's suggestion of doing the time/timing specific stuff on a >> dedicated microcontroller. >> >> I'd recommend going one better: use more than one microcontroller. Robots >> need to do a lot in parallel; if the robot has to stop driving in order to >> think, that's a problem (although the converse would be decidedly human!) >> Anyway, it sounds like real-time is not negotiable in your view, so green >> threads won't cut it either. >> >> Mine has... six controllers in total. That's not counting the ARM9 which >> is more like a full computer (e.g., Linux.) >> >> I think six anyway. Could be more hiding in there. Two drive sensors, >> three drive motors, one is wired up close to the ARM board to coordinate the >> other controllers on behalf of what the Linux system wants them doing. >> >> I'm curious, have you figured out what the average, best, and worst case >> latencies are on human reflexes? In my view, matching or beating that >> benchmark is where the money probably is. >> >> --C >> >> On Jul 6, 2015, at 12:39 PM, Kirk Fraser wrote: >> >> Ralph Johnson, >> >> That's an excellent suggestion and an excellent story, thank you very >> much! Letting the human interface in Smalltalk program the robot controller >> instead of being the robot controller sounds good. >> >> My robot uses a network of Parallax microcontroller chips to drive >> hydraulic valves, which can be programmed via USB for simple tasks like >> moving one joint from point A to B but since each controller has 8 cores >> more complex tasks like grasping or walking can be done on the MCU's or on a >> small Raspberry Pi or other hardware in a non-GC or controllable GC >> language. >> >> A harder part to wrap my head around is handling the webcam vision system >> and artificial intelligence while remaining time sensitive enough to do time >> critical tasks like cartwheels and other acrobatic choreography. >> >> I know in effect my human mind shuts down most of its intellectual >> pursuits when engaged in heavy physical activity - maybe the robot must do >> the same - think more creatively when idling and pay closer attention while >> working. That takes care of the Ai timing. >> >> The heavy load of vision processing appears to need a mini-cloud of cores >> to reduce time to identify and measure objects from contours and other >> information. To guarantee performance they would also need to run a non-GC >> language that could be programmed from Squeak interactively as new objects >> are being learned. I haven't worked with a laser range finder but I suspect >> they use it to narrow the focus onto moving objects to process video in more >> detail in those areas. >> >> The current buzzword "co-robots" meaning robots that work beside or >> cooperatively with people working in symbiotic relationships with human >> partners suggests everyone will need a robot friend, which will require an >> artificial intelligence capable of intelligent thought. As most Americans >> are Christian it would make sense for a human compatible AI to be based on >> the Bible. That is what I would love to work on. But that level of thought >> needs a creative CG environment like Squeak at present. >> >> I've been thinking that using a Smalltalk GUI to issue command rules to >> set an agenda for automatic text analysis and editing might be fun, letting >> the computer do the editing instead of me. That way it could update the AI >> knowledge like when a preferred synonym is discovered, without taking human >> time to do much of it beyond the setup. >> >> Your wikipedia entry shows a webpage and blog that apparently are dead >> links. Would you be interested in being a team member on my SBIR/STTR grant >> application(s) for AI and Robots responding to: >> http://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf15505 I've >> enlisted help in writing the application from Oregon's Small Business >> Development Center and will meet with an SBIR road trip in August I'm told. >> (I was also told I need a Ph.D. on my team since I don't have one.) >> >> Kirk Fraser >> >> >> On Mon, Jul 6, 2015 at 4:19 AM, Ralph Johnson wrote: >>> >>> Here is another possibility. >>> >>> Take a look at Symbolic Sound, a company that makes a system called Kyma. >>> http://kyma.symbolicsound.com/ >>> >>> This company has been around for over twenty years. Its product has >>> always been the fastest music synthesis system in the world that gives you >>> total control over your sound. And by "total", I mean it gives you the >>> ability to mathematically specify each sound wave. If you want, which is >>> actually too much detail for most people. And it is all written in >>> Smalltalk. Not Squeak, of course, since Squeak wasn't around then. But it >>> could have been done in Squeak. And perhaps they ported it to Squeak. I >>> haven't talked to them for a long time so I don't know what they did, but >>> from the screen shots I think it is still a very old version of VisualWorks. >>> >>> Anyway, how do they make it so fast? How can they make something that >>> can be used for hours without any GC pauses? >>> >>> The trick is that the sound is produced on an attached DSP. The GUI is >>> in Smalltalk on a PC, and it generates code for the DSP. It is non-trivial >>> making the compiler so fast that when you press "play", it can immediately >>> start up the DSP and start producing sound. It does this (rather, it did >>> this, since they might have changed the way it works) by just producing >>> enough code to run the DSP for a few seconds and then starting the DSP while >>> it generates the rest of the code. Kyma literally is writing the program >>> into DSP memory at the same time as the DSP is running the program, >>> producing sound. >>> >>> Anyway, maybe that is the right approach to programming robots. You >>> don't even need to use two computers. Imagine you had two computers, one >>> running Squeak and the other a simple, real-time machine designed for >>> controlling robots, but not very sophisticated. Squeak programs the simple >>> computer, and can change its program dynamically. The simple computer has >>> no gc. Since Squeak is a VM on a computer, the real-time computer can be a >>> VM, too. So, you could be running them both on your PC, or you could run >>> them on two separate computers for better performance. >>> >>> I would be happy to talk more about this. But I'd like to talk about the >>> beginning of Kyma. The owners of Symbolic Sound are Carla Scaletti and >>> Kurt Hebel. Carla has a PhD in music, and Kurt in Electrical Engineering. >>> I met Carla after she had her PhD. She wanted to get a MS in computer >>> science so she could prove her computer music expertise, and she ended up >>> getting it with me. She took my course on OOP&D that used Smalltalk. For >>> her class project (back in 1987, I think) she wrote a Smalltalk program that >>> ran on the Mac and that produced about ten seconds of sound, but it took >>> several minutes to do it. Hardly real time. However, she was used to >>> using a supercomputer (a Cray?) to generate sounds that still weren't real >>> time, so she was very pleased that she could do it on the Mac at all, and >>> though Smalltalk was slower than Fortran, in her opinion the ease of use was >>> so great that she didn't mind the speed difference. As she put it, the >>> speed difference between a Mac and a Cray was bigger than between Smalltalk >>> and Fortran. She ended up turning this into the first version of Kyma and >>> that became the subject of her MS thesis. I can remember when she showed >>> it in class. She was the only woman in the class, and the other students >>> knew she was a musician, i.e. not *really* a programmer. She was quiet >>> during class, so they had not had a chance to have their prejudices >>> remedied. Her demo at the end of the semester blew them away. >>> >>> Kurt had built a DSP that their lab used. (The lab was part of the >>> Plato project, I believe, one of the huge number of creative results of this >>> very significant project at Illinois.) It was called the Capybara. This >>> was before the time when you could just buy a good DSP on a chip, but that >>> time came very soon and then they used the commercial chips. For her MS, >>> she converted her system to use the Capybara, and this was when she figured >>> out how to make it start making music within a fraction of a second of >>> pressing the "play" button. Kurt also used Smalltalk with the Capybara. >>> His PhD was about automatically designing digital filters, and his software >>> also generated code for the Capybara, though it was actually quite different >>> from Kyma. >>> >>> The two of them worked on several different projects over the next few >>> years, but kept improving Kyma. Along the way Kurt started building boards >>> that had several commercial DSPs on them. Eventually they decided to go >>> commercial and started Symbolic Sound. >>> >>> -Ralph Johnson >>> >>> On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser >>> wrote: >>>> >>>> >> Tim says a multi-core VM is coming for the new Pi. >>>> >>>> > Are you *sure* that's what Tim said? >>>> >>>> Of course my over hopeful misinterpretation is possible. >>>> >>>> "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 >>>> >>>> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 >>>> >>>> > 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. >>>> >>>> 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. >>>> >>>> >>>> On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) wrote: >>>>> >>>>> 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. >>>>> From hannes.hirzel at gmail.com Tue Jul 14 11:43:49 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Tue Jul 14 11:43:51 2015 Subject: [Newbies] [Squeak 4.6] Font Importer Tool instructions? Message-ID: Hello In the yet to be released Squeak 4.6 (http://ftp.squeak.org/4.6/Squeak-4.6-All-in-One.zip is a preview) there is a note about a Font Importer Tool How do I use it? The release notes as well mention "Better support for True-Type fonts, including PostScript based True-Type fonts." What does this cover? Thank you for the answer in advance Hannes Hirzel From hannes.hirzel at gmail.com Tue Jul 14 12:15:15 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Tue Jul 14 12:15:17 2015 Subject: [Newbies] Loading Vivide IDE? Message-ID: Hello I would like to load the Vivide IDE in the yet to be released Squeak 4.6. (Preview here http://ftp.squeak.org/4.6/Squeak-4.6-All-in-One.zip) On the Squeak ML I got the answer that I have to execute Metacello new baseline: 'Vivide'; repository: 'github://hpi-swa/vivide/repository'; load: #(dev). (Smalltalk classNamed: 'ViScriptArchive') mergeAll. in a workspace. However if I do that I get the answer 'Unknown variable - Metacello, please correct or cancel'. How do I bring Squeak 4.6 into a state where MetaCello is known? Kind regards Hannes Hirzel From Marcel.Taeumel at hpi.de Tue Jul 14 12:20:32 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Tue Jul 14 12:20:37 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: References: Message-ID: <1436876432981-4837448.post@n4.nabble.com> Metacello can be loaded into Squeak 4.6 like this: https://github.com/dalehenrich/metacello-work "Get the Metacello configuration (for Squeak users)" Installer gemsource project: 'metacello'; addPackage: 'ConfigurationOfMetacello'; install. "Bootstrap Metacello Preview, using mcz files (#'previewBootstrap' symbolic version" ((Smalltalk at: #ConfigurationOfMetacello) project version: #'previewBootstrap') load. "Load the Preview version of Metacello from GitHub" (Smalltalk at: #Metacello) new configuration: 'MetacelloPreview'; version: #stable; repository: 'github://dalehenrich/metacello-work:configuration'; load. "Now load latest version of Metacello" Metacello new baseline: 'Metacello'; repository: 'github://dalehenrich/metacello-work:master/repository'; get. Metacello new baseline: 'Metacello'; repository: 'github://dalehenrich/metacello-work:master/repository'; onConflict: [:ex | ex allow]; load. Just do-it one code snippet after another in a workspace. Then: Metacello new baseline: 'Vivide'; repository: 'github://hpi-swa/vivide/repository'; load. For more examples, load the package VivideScripts: https://github.com/hpi-swa/vivide/tree/master/repository/VivideScripts.package I think this last step might work via the Monticello Browser tools. Best, Marcel -- View this message in context: http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837448.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. From overcomer.man at gmail.com Tue Jul 14 12:30:58 2015 From: overcomer.man at gmail.com (Kirk Fraser) Date: Tue Jul 14 12:31:01 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: Ben, Thanks for the FPGA idea and links. I've seen Parallax released their microcontroller design to public so their community can make their own microcontroller FPGA's. Getting Smalltalk code into silicon would be great for a second version of my robot after the prototype works. Or it could be a useful step in dealing with computer vision. Kirk On Tue, Jul 14, 2015 at 4:42 AM, Ben Coman wrote: > Smalltalk FPGA may be of interest... > > http://www.slideshare.net/esug/luc-fabresse-iwst2014 > > > http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_From%20Smalltalk%20to%20Silicon_Towards%20a%20methodology%20to%20turn%20Smalltalk%20code%20into%20FPGA.pdf > > cheers -ben > > On Tue, Jul 14, 2015 at 11:55 AM, Kirk Fraser > wrote: > > Hi Casey, > > > > Thanks for the suggestion. I will have multiple connected controller > boards > > and with your suggestion maybe I'll try a Pi for each limb and each > webcam > > or maybe your ARM9 suggestion. > > > > To prove it's good as a human in performance I want it to do minor > > acrobatics like cartwheels and balancing tricks, maybe a Chuck Norris > kick > > or jumping over a fence with one hand on a post. Or like those > free-running > > videos. Stuff I could not do myself. But it all waits on money. Maybe > I'll > > make better progress next year when social security kicks in. > > > > As far as human performance goals, one professor wrote it takes 200 > cycles > > per second to hop on one leg. Somewhere I read human touch can sense 1 > in > > 32,000 of an inch. I don't have the other figures yet. I may not be > able > > to drive an arm as fast as a human boxer - 200 mph but as long as it's > fast > > enough to drive a vehicle on a slow road (not I5) that might be enough > until > > faster computers are here. > > > > The vision system seems like a major speed bottle neck. Maybe a > mini-cloud > > can take one 64th of the image for each processor analyze it, then > assemble > > larger object detection in time for the next frame. The DARPA Atlas > robot > > used 4 cores for each camera I think. But a mini-cloud set off nearby to > > process vision and return either the objects with measurements or > > instructions would be a lot of work. The more I write, the more I see > why > > the head of DARPA's robots said they cost 1-2 million as you have to > hire a > > team of programmers or make a really intricate learning program. > > > > Kirk > > > > > > On Mon, Jul 13, 2015 at 5:58 PM, Casey Ransberger < > casey.obrien.r@gmail.com> > > wrote: > >> > >> Hey Kirk, > >> > >> I like Ralph's suggestion of doing the time/timing specific stuff on a > >> dedicated microcontroller. > >> > >> I'd recommend going one better: use more than one microcontroller. > Robots > >> need to do a lot in parallel; if the robot has to stop driving in order > to > >> think, that's a problem (although the converse would be decidedly > human!) > >> Anyway, it sounds like real-time is not negotiable in your view, so > green > >> threads won't cut it either. > >> > >> Mine has... six controllers in total. That's not counting the ARM9 which > >> is more like a full computer (e.g., Linux.) > >> > >> I think six anyway. Could be more hiding in there. Two drive sensors, > >> three drive motors, one is wired up close to the ARM board to > coordinate the > >> other controllers on behalf of what the Linux system wants them doing. > >> > >> I'm curious, have you figured out what the average, best, and worst case > >> latencies are on human reflexes? In my view, matching or beating that > >> benchmark is where the money probably is. > >> > >> --C > >> > >> On Jul 6, 2015, at 12:39 PM, Kirk Fraser > wrote: > >> > >> Ralph Johnson, > >> > >> That's an excellent suggestion and an excellent story, thank you very > >> much! Letting the human interface in Smalltalk program the robot > controller > >> instead of being the robot controller sounds good. > >> > >> My robot uses a network of Parallax microcontroller chips to drive > >> hydraulic valves, which can be programmed via USB for simple tasks like > >> moving one joint from point A to B but since each controller has 8 cores > >> more complex tasks like grasping or walking can be done on the MCU's or > on a > >> small Raspberry Pi or other hardware in a non-GC or controllable GC > >> language. > >> > >> A harder part to wrap my head around is handling the webcam vision > system > >> and artificial intelligence while remaining time sensitive enough to do > time > >> critical tasks like cartwheels and other acrobatic choreography. > >> > >> I know in effect my human mind shuts down most of its intellectual > >> pursuits when engaged in heavy physical activity - maybe the robot must > do > >> the same - think more creatively when idling and pay closer attention > while > >> working. That takes care of the Ai timing. > >> > >> The heavy load of vision processing appears to need a mini-cloud of > cores > >> to reduce time to identify and measure objects from contours and other > >> information. To guarantee performance they would also need to run a > non-GC > >> language that could be programmed from Squeak interactively as new > objects > >> are being learned. I haven't worked with a laser range finder but I > suspect > >> they use it to narrow the focus onto moving objects to process video in > more > >> detail in those areas. > >> > >> The current buzzword "co-robots" meaning robots that work beside or > >> cooperatively with people working in symbiotic relationships with human > >> partners suggests everyone will need a robot friend, which will require > an > >> artificial intelligence capable of intelligent thought. As most > Americans > >> are Christian it would make sense for a human compatible AI to be based > on > >> the Bible. That is what I would love to work on. But that level of > thought > >> needs a creative CG environment like Squeak at present. > >> > >> I've been thinking that using a Smalltalk GUI to issue command rules to > >> set an agenda for automatic text analysis and editing might be fun, > letting > >> the computer do the editing instead of me. That way it could update > the AI > >> knowledge like when a preferred synonym is discovered, without taking > human > >> time to do much of it beyond the setup. > >> > >> Your wikipedia entry shows a webpage and blog that apparently are dead > >> links. Would you be interested in being a team member on my SBIR/STTR > grant > >> application(s) for AI and Robots responding to: > >> http://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf15505 I've > >> enlisted help in writing the application from Oregon's Small Business > >> Development Center and will meet with an SBIR road trip in August I'm > told. > >> (I was also told I need a Ph.D. on my team since I don't have one.) > >> > >> Kirk Fraser > >> > >> > >> On Mon, Jul 6, 2015 at 4:19 AM, Ralph Johnson > wrote: > >>> > >>> Here is another possibility. > >>> > >>> Take a look at Symbolic Sound, a company that makes a system called > Kyma. > >>> http://kyma.symbolicsound.com/ > >>> > >>> This company has been around for over twenty years. Its product has > >>> always been the fastest music synthesis system in the world that gives > you > >>> total control over your sound. And by "total", I mean it gives you the > >>> ability to mathematically specify each sound wave. If you want, > which is > >>> actually too much detail for most people. And it is all written in > >>> Smalltalk. Not Squeak, of course, since Squeak wasn't around then. > But it > >>> could have been done in Squeak. And perhaps they ported it to > Squeak. I > >>> haven't talked to them for a long time so I don't know what they did, > but > >>> from the screen shots I think it is still a very old version of > VisualWorks. > >>> > >>> Anyway, how do they make it so fast? How can they make something that > >>> can be used for hours without any GC pauses? > >>> > >>> The trick is that the sound is produced on an attached DSP. The GUI > is > >>> in Smalltalk on a PC, and it generates code for the DSP. It is > non-trivial > >>> making the compiler so fast that when you press "play", it can > immediately > >>> start up the DSP and start producing sound. It does this (rather, it > did > >>> this, since they might have changed the way it works) by just producing > >>> enough code to run the DSP for a few seconds and then starting the DSP > while > >>> it generates the rest of the code. Kyma literally is writing the > program > >>> into DSP memory at the same time as the DSP is running the program, > >>> producing sound. > >>> > >>> Anyway, maybe that is the right approach to programming robots. You > >>> don't even need to use two computers. Imagine you had two computers, > one > >>> running Squeak and the other a simple, real-time machine designed for > >>> controlling robots, but not very sophisticated. Squeak programs the > simple > >>> computer, and can change its program dynamically. The simple computer > has > >>> no gc. Since Squeak is a VM on a computer, the real-time computer > can be a > >>> VM, too. So, you could be running them both on your PC, or you could > run > >>> them on two separate computers for better performance. > >>> > >>> I would be happy to talk more about this. But I'd like to talk about > the > >>> beginning of Kyma. The owners of Symbolic Sound are Carla Scaletti > and > >>> Kurt Hebel. Carla has a PhD in music, and Kurt in Electrical > Engineering. > >>> I met Carla after she had her PhD. She wanted to get a MS in computer > >>> science so she could prove her computer music expertise, and she ended > up > >>> getting it with me. She took my course on OOP&D that used > Smalltalk. For > >>> her class project (back in 1987, I think) she wrote a Smalltalk > program that > >>> ran on the Mac and that produced about ten seconds of sound, but it > took > >>> several minutes to do it. Hardly real time. However, she was used > to > >>> using a supercomputer (a Cray?) to generate sounds that still weren't > real > >>> time, so she was very pleased that she could do it on the Mac at all, > and > >>> though Smalltalk was slower than Fortran, in her opinion the ease of > use was > >>> so great that she didn't mind the speed difference. As she put it, > the > >>> speed difference between a Mac and a Cray was bigger than between > Smalltalk > >>> and Fortran. She ended up turning this into the first version of Kyma > and > >>> that became the subject of her MS thesis. I can remember when she > showed > >>> it in class. She was the only woman in the class, and the other > students > >>> knew she was a musician, i.e. not *really* a programmer. She was quiet > >>> during class, so they had not had a chance to have their prejudices > >>> remedied. Her demo at the end of the semester blew them away. > >>> > >>> Kurt had built a DSP that their lab used. (The lab was part of the > >>> Plato project, I believe, one of the huge number of creative results > of this > >>> very significant project at Illinois.) It was called the Capybara. > This > >>> was before the time when you could just buy a good DSP on a chip, but > that > >>> time came very soon and then they used the commercial chips. For her > MS, > >>> she converted her system to use the Capybara, and this was when she > figured > >>> out how to make it start making music within a fraction of a second of > >>> pressing the "play" button. Kurt also used Smalltalk with the > Capybara. > >>> His PhD was about automatically designing digital filters, and his > software > >>> also generated code for the Capybara, though it was actually quite > different > >>> from Kyma. > >>> > >>> The two of them worked on several different projects over the next few > >>> years, but kept improving Kyma. Along the way Kurt started building > boards > >>> that had several commercial DSPs on them. Eventually they decided to > go > >>> commercial and started Symbolic Sound. > >>> > >>> -Ralph Johnson > >>> > >>> On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser > >>> wrote: > >>>> > >>>> >> Tim says a multi-core VM is coming for the new Pi. > >>>> > >>>> > Are you *sure* that's what Tim said? > >>>> > >>>> Of course my over hopeful misinterpretation is possible. > >>>> > >>>> "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 > >>>> > >>>> > https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 > >>>> > >>>> > 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. > >>>> > >>>> 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. > >>>> > >>>> > >>>> On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) > wrote: > >>>>> > >>>>> 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. > >>>>> > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150714/ba2fb497/attachment-0001.htm From hannes.hirzel at gmail.com Tue Jul 14 15:32:29 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Tue Jul 14 15:32:33 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: <1436876432981-4837448.post@n4.nabble.com> References: <1436876432981-4837448.post@n4.nabble.com> Message-ID: Loading went fine. I opened an 'Animated Morphic' project and wanted to add a class as shown in the video https://github.com/hpi-swa/vivide/blob/master/howto/howto-createclass.gif However the result I got was different, see attached screen shot. Is there something missing? On 7/14/15, marcel.taeumel wrote: > Metacello can be loaded into Squeak 4.6 like this: > https://github.com/dalehenrich/metacello-work > > "Get the Metacello configuration (for Squeak users)" > Installer gemsource > project: 'metacello'; > addPackage: 'ConfigurationOfMetacello'; > install. > > "Bootstrap Metacello Preview, using mcz files (#'previewBootstrap' symbolic > version" > ((Smalltalk at: #ConfigurationOfMetacello) project > version: #'previewBootstrap') load. > > "Load the Preview version of Metacello from GitHub" > (Smalltalk at: #Metacello) new > configuration: 'MetacelloPreview'; > version: #stable; > repository: 'github://dalehenrich/metacello-work:configuration'; > load. > "Now load latest version of Metacello" > Metacello new > baseline: 'Metacello'; > repository: 'github://dalehenrich/metacello-work:master/repository'; > get. > Metacello new > baseline: 'Metacello'; > repository: 'github://dalehenrich/metacello-work:master/repository'; > onConflict: [:ex | ex allow]; > load. > > Just do-it one code snippet after another in a workspace. Then: > > Metacello new > baseline: 'Vivide'; > repository: 'github://hpi-swa/vivide/repository'; > load. > > For more examples, load the package VivideScripts: > https://github.com/hpi-swa/vivide/tree/master/repository/VivideScripts.package > > I think this last step might work via the Monticello Browser tools. > > Best, > Marcel > > > > -- > View this message in context: > http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837448.html > Sent from the Squeak - Beginners mailing list archive at Nabble.com. > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > -------------- next part -------------- A non-text attachment was scrubbed... Name: Vivide_IDE_Add_Class_2015-07-14 15:28:55.png Type: image/png Size: 73514 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150714/e3791855/55-0001.png From hannes.hirzel at gmail.com Tue Jul 14 15:34:22 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Tue Jul 14 15:34:23 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: References: <1436876432981-4837448.post@n4.nabble.com> Message-ID: P.S. It would be helpful to have a ready-made Squeak 4.6 all-in-one with Vivide preinstalled. --HH On 7/14/15, H. Hirzel wrote: > Loading went fine. > > I opened an 'Animated Morphic' project and wanted to add a class as > shown in the video > > https://github.com/hpi-swa/vivide/blob/master/howto/howto-createclass.gif > > However the result I got was different, see attached screen shot. > > Is there something missing? > > > > On 7/14/15, marcel.taeumel wrote: >> Metacello can be loaded into Squeak 4.6 like this: >> https://github.com/dalehenrich/metacello-work >> >> "Get the Metacello configuration (for Squeak users)" >> Installer gemsource >> project: 'metacello'; >> addPackage: 'ConfigurationOfMetacello'; >> install. >> >> "Bootstrap Metacello Preview, using mcz files (#'previewBootstrap' >> symbolic >> version" >> ((Smalltalk at: #ConfigurationOfMetacello) project >> version: #'previewBootstrap') load. >> >> "Load the Preview version of Metacello from GitHub" >> (Smalltalk at: #Metacello) new >> configuration: 'MetacelloPreview'; >> version: #stable; >> repository: 'github://dalehenrich/metacello-work:configuration'; >> load. >> "Now load latest version of Metacello" >> Metacello new >> baseline: 'Metacello'; >> repository: 'github://dalehenrich/metacello-work:master/repository'; >> get. >> Metacello new >> baseline: 'Metacello'; >> repository: 'github://dalehenrich/metacello-work:master/repository'; >> onConflict: [:ex | ex allow]; >> load. >> >> Just do-it one code snippet after another in a workspace. Then: >> >> Metacello new >> baseline: 'Vivide'; >> repository: 'github://hpi-swa/vivide/repository'; >> load. >> >> For more examples, load the package VivideScripts: >> https://github.com/hpi-swa/vivide/tree/master/repository/VivideScripts.package >> >> I think this last step might work via the Monticello Browser tools. >> >> Best, >> Marcel >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837448.html >> Sent from the Squeak - Beginners mailing list archive at Nabble.com. >> _______________________________________________ >> Beginners mailing list >> Beginners@lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/beginners >> > From overcomer.man at gmail.com Tue Jul 14 17:28:46 2015 From: overcomer.man at gmail.com (Kirk Fraser) Date: Tue Jul 14 17:28:50 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: Wow! Ben's article and slides shows Ralph Johnson's suggestion several steps closer to real life and on computer vision for robots. I'm still thinking a laser range finder is not necessary since humans don't have them. We get by with eyes that can measure distances with or without stereo enhancement and the stereo image facility helps us see things neither eye can make out alone. On Tue, Jul 14, 2015 at 5:30 AM, Kirk Fraser wrote: > Ben, > > Thanks for the FPGA idea and links. I've seen Parallax released their > microcontroller design to public so their community can make their own > microcontroller FPGA's. Getting Smalltalk code into silicon would be great > for a second version of my robot after the prototype works. Or it could be > a useful step in dealing with computer vision. > > Kirk > > On Tue, Jul 14, 2015 at 4:42 AM, Ben Coman wrote: > >> Smalltalk FPGA may be of interest... >> >> http://www.slideshare.net/esug/luc-fabresse-iwst2014 >> >> >> http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_From%20Smalltalk%20to%20Silicon_Towards%20a%20methodology%20to%20turn%20Smalltalk%20code%20into%20FPGA.pdf >> >> cheers -ben >> >> On Tue, Jul 14, 2015 at 11:55 AM, Kirk Fraser >> wrote: >> > Hi Casey, >> > >> > Thanks for the suggestion. I will have multiple connected controller >> boards >> > and with your suggestion maybe I'll try a Pi for each limb and each >> webcam >> > or maybe your ARM9 suggestion. >> > >> > To prove it's good as a human in performance I want it to do minor >> > acrobatics like cartwheels and balancing tricks, maybe a Chuck Norris >> kick >> > or jumping over a fence with one hand on a post. Or like those >> free-running >> > videos. Stuff I could not do myself. But it all waits on money. Maybe >> I'll >> > make better progress next year when social security kicks in. >> > >> > As far as human performance goals, one professor wrote it takes 200 >> cycles >> > per second to hop on one leg. Somewhere I read human touch can sense 1 >> in >> > 32,000 of an inch. I don't have the other figures yet. I may not be >> able >> > to drive an arm as fast as a human boxer - 200 mph but as long as it's >> fast >> > enough to drive a vehicle on a slow road (not I5) that might be enough >> until >> > faster computers are here. >> > >> > The vision system seems like a major speed bottle neck. Maybe a >> mini-cloud >> > can take one 64th of the image for each processor analyze it, then >> assemble >> > larger object detection in time for the next frame. The DARPA Atlas >> robot >> > used 4 cores for each camera I think. But a mini-cloud set off nearby >> to >> > process vision and return either the objects with measurements or >> > instructions would be a lot of work. The more I write, the more I see >> why >> > the head of DARPA's robots said they cost 1-2 million as you have to >> hire a >> > team of programmers or make a really intricate learning program. >> > >> > Kirk >> > >> > >> > On Mon, Jul 13, 2015 at 5:58 PM, Casey Ransberger < >> casey.obrien.r@gmail.com> >> > wrote: >> >> >> >> Hey Kirk, >> >> >> >> I like Ralph's suggestion of doing the time/timing specific stuff on a >> >> dedicated microcontroller. >> >> >> >> I'd recommend going one better: use more than one microcontroller. >> Robots >> >> need to do a lot in parallel; if the robot has to stop driving in >> order to >> >> think, that's a problem (although the converse would be decidedly >> human!) >> >> Anyway, it sounds like real-time is not negotiable in your view, so >> green >> >> threads won't cut it either. >> >> >> >> Mine has... six controllers in total. That's not counting the ARM9 >> which >> >> is more like a full computer (e.g., Linux.) >> >> >> >> I think six anyway. Could be more hiding in there. Two drive sensors, >> >> three drive motors, one is wired up close to the ARM board to >> coordinate the >> >> other controllers on behalf of what the Linux system wants them doing. >> >> >> >> I'm curious, have you figured out what the average, best, and worst >> case >> >> latencies are on human reflexes? In my view, matching or beating that >> >> benchmark is where the money probably is. >> >> >> >> --C >> >> >> >> On Jul 6, 2015, at 12:39 PM, Kirk Fraser >> wrote: >> >> >> >> Ralph Johnson, >> >> >> >> That's an excellent suggestion and an excellent story, thank you very >> >> much! Letting the human interface in Smalltalk program the robot >> controller >> >> instead of being the robot controller sounds good. >> >> >> >> My robot uses a network of Parallax microcontroller chips to drive >> >> hydraulic valves, which can be programmed via USB for simple tasks like >> >> moving one joint from point A to B but since each controller has 8 >> cores >> >> more complex tasks like grasping or walking can be done on the MCU's >> or on a >> >> small Raspberry Pi or other hardware in a non-GC or controllable GC >> >> language. >> >> >> >> A harder part to wrap my head around is handling the webcam vision >> system >> >> and artificial intelligence while remaining time sensitive enough to >> do time >> >> critical tasks like cartwheels and other acrobatic choreography. >> >> >> >> I know in effect my human mind shuts down most of its intellectual >> >> pursuits when engaged in heavy physical activity - maybe the robot >> must do >> >> the same - think more creatively when idling and pay closer attention >> while >> >> working. That takes care of the Ai timing. >> >> >> >> The heavy load of vision processing appears to need a mini-cloud of >> cores >> >> to reduce time to identify and measure objects from contours and other >> >> information. To guarantee performance they would also need to run a >> non-GC >> >> language that could be programmed from Squeak interactively as new >> objects >> >> are being learned. I haven't worked with a laser range finder but I >> suspect >> >> they use it to narrow the focus onto moving objects to process video >> in more >> >> detail in those areas. >> >> >> >> The current buzzword "co-robots" meaning robots that work beside or >> >> cooperatively with people working in symbiotic relationships with human >> >> partners suggests everyone will need a robot friend, which will >> require an >> >> artificial intelligence capable of intelligent thought. As most >> Americans >> >> are Christian it would make sense for a human compatible AI to be >> based on >> >> the Bible. That is what I would love to work on. But that level of >> thought >> >> needs a creative CG environment like Squeak at present. >> >> >> >> I've been thinking that using a Smalltalk GUI to issue command rules to >> >> set an agenda for automatic text analysis and editing might be fun, >> letting >> >> the computer do the editing instead of me. That way it could update >> the AI >> >> knowledge like when a preferred synonym is discovered, without taking >> human >> >> time to do much of it beyond the setup. >> >> >> >> Your wikipedia entry shows a webpage and blog that apparently are dead >> >> links. Would you be interested in being a team member on my SBIR/STTR >> grant >> >> application(s) for AI and Robots responding to: >> >> http://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf15505 I've >> >> enlisted help in writing the application from Oregon's Small Business >> >> Development Center and will meet with an SBIR road trip in August I'm >> told. >> >> (I was also told I need a Ph.D. on my team since I don't have one.) >> >> >> >> Kirk Fraser >> >> >> >> >> >> On Mon, Jul 6, 2015 at 4:19 AM, Ralph Johnson >> wrote: >> >>> >> >>> Here is another possibility. >> >>> >> >>> Take a look at Symbolic Sound, a company that makes a system called >> Kyma. >> >>> http://kyma.symbolicsound.com/ >> >>> >> >>> This company has been around for over twenty years. Its product has >> >>> always been the fastest music synthesis system in the world that >> gives you >> >>> total control over your sound. And by "total", I mean it gives you >> the >> >>> ability to mathematically specify each sound wave. If you want, >> which is >> >>> actually too much detail for most people. And it is all written in >> >>> Smalltalk. Not Squeak, of course, since Squeak wasn't around then. >> But it >> >>> could have been done in Squeak. And perhaps they ported it to >> Squeak. I >> >>> haven't talked to them for a long time so I don't know what they did, >> but >> >>> from the screen shots I think it is still a very old version of >> VisualWorks. >> >>> >> >>> Anyway, how do they make it so fast? How can they make something that >> >>> can be used for hours without any GC pauses? >> >>> >> >>> The trick is that the sound is produced on an attached DSP. The GUI >> is >> >>> in Smalltalk on a PC, and it generates code for the DSP. It is >> non-trivial >> >>> making the compiler so fast that when you press "play", it can >> immediately >> >>> start up the DSP and start producing sound. It does this (rather, it >> did >> >>> this, since they might have changed the way it works) by just >> producing >> >>> enough code to run the DSP for a few seconds and then starting the >> DSP while >> >>> it generates the rest of the code. Kyma literally is writing the >> program >> >>> into DSP memory at the same time as the DSP is running the program, >> >>> producing sound. >> >>> >> >>> Anyway, maybe that is the right approach to programming robots. You >> >>> don't even need to use two computers. Imagine you had two >> computers, one >> >>> running Squeak and the other a simple, real-time machine designed for >> >>> controlling robots, but not very sophisticated. Squeak programs the >> simple >> >>> computer, and can change its program dynamically. The simple >> computer has >> >>> no gc. Since Squeak is a VM on a computer, the real-time computer >> can be a >> >>> VM, too. So, you could be running them both on your PC, or you could >> run >> >>> them on two separate computers for better performance. >> >>> >> >>> I would be happy to talk more about this. But I'd like to talk about >> the >> >>> beginning of Kyma. The owners of Symbolic Sound are Carla Scaletti >> and >> >>> Kurt Hebel. Carla has a PhD in music, and Kurt in Electrical >> Engineering. >> >>> I met Carla after she had her PhD. She wanted to get a MS in computer >> >>> science so she could prove her computer music expertise, and she >> ended up >> >>> getting it with me. She took my course on OOP&D that used >> Smalltalk. For >> >>> her class project (back in 1987, I think) she wrote a Smalltalk >> program that >> >>> ran on the Mac and that produced about ten seconds of sound, but it >> took >> >>> several minutes to do it. Hardly real time. However, she was used >> to >> >>> using a supercomputer (a Cray?) to generate sounds that still weren't >> real >> >>> time, so she was very pleased that she could do it on the Mac at all, >> and >> >>> though Smalltalk was slower than Fortran, in her opinion the ease of >> use was >> >>> so great that she didn't mind the speed difference. As she put it, >> the >> >>> speed difference between a Mac and a Cray was bigger than between >> Smalltalk >> >>> and Fortran. She ended up turning this into the first version of >> Kyma and >> >>> that became the subject of her MS thesis. I can remember when she >> showed >> >>> it in class. She was the only woman in the class, and the other >> students >> >>> knew she was a musician, i.e. not *really* a programmer. She was >> quiet >> >>> during class, so they had not had a chance to have their prejudices >> >>> remedied. Her demo at the end of the semester blew them away. >> >>> >> >>> Kurt had built a DSP that their lab used. (The lab was part of the >> >>> Plato project, I believe, one of the huge number of creative results >> of this >> >>> very significant project at Illinois.) It was called the Capybara. >> This >> >>> was before the time when you could just buy a good DSP on a chip, but >> that >> >>> time came very soon and then they used the commercial chips. For her >> MS, >> >>> she converted her system to use the Capybara, and this was when she >> figured >> >>> out how to make it start making music within a fraction of a second of >> >>> pressing the "play" button. Kurt also used Smalltalk with the >> Capybara. >> >>> His PhD was about automatically designing digital filters, and his >> software >> >>> also generated code for the Capybara, though it was actually quite >> different >> >>> from Kyma. >> >>> >> >>> The two of them worked on several different projects over the next few >> >>> years, but kept improving Kyma. Along the way Kurt started building >> boards >> >>> that had several commercial DSPs on them. Eventually they decided to >> go >> >>> commercial and started Symbolic Sound. >> >>> >> >>> -Ralph Johnson >> >>> >> >>> On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser >> >>> wrote: >> >>>> >> >>>> >> Tim says a multi-core VM is coming for the new Pi. >> >>>> >> >>>> > Are you *sure* that's what Tim said? >> >>>> >> >>>> Of course my over hopeful misinterpretation is possible. >> >>>> >> >>>> "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 >> >>>> >> >>>> >> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 >> >>>> >> >>>> > 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. >> >>>> >> >>>> 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. >> >>>> >> >>>> >> >>>> On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) >> wrote: >> >>>>> >> >>>>> 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. >> >>>>> >> _______________________________________________ >> Beginners mailing list >> Beginners@lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/beginners >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150714/9a735998/attachment-0001.htm From Marcel.Taeumel at hpi.de Wed Jul 15 05:31:25 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Wed Jul 15 05:31:31 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: References: <1436876432981-4837448.post@n4.nabble.com> Message-ID: <1436938285615-4837525.post@n4.nabble.com> Most of the time, you are dragging objects around. In this case, it is a block that contains the instructions to create that (other) object. If this is the case anywhere, just hit 'e' while dragging the object to evaluate it before dropping it. Another drag-modifier is 's', which lets you script any dropped objects directly. If you drag long enough, there will be a hint about possible drag modifiers in the bottom-right corner. Best, Marcel -- View this message in context: http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837525.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. From hannes.hirzel at gmail.com Wed Jul 15 09:24:43 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Wed Jul 15 09:24:45 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: <1436938285615-4837525.post@n4.nabble.com> References: <1436876432981-4837448.post@n4.nabble.com> <1436938285615-4837525.post@n4.nabble.com> Message-ID: Hello again, Marcel Thank you for the instruction how to get an 'Add class' window. Waiting a few seconds after dragging out the 'Add class' window brought up a hint. After pressing 'e' the window appeared. However while adding the class an emergency evaluator came up. Maybe this is related to Squeak 4.6 because I had the similar thing trying to leave an MVC project I created. The videos on github are fine in terms of content but they play too fast. So it is difficult to see which steps are actually involved defining a class. I suggest to go for a Squeak 4.6 all-in-one with Vivide preloaded so that we have the same artifact we talk about while exploring the Vivide functions. Kind regards Hannes Hirzel On 7/15/15, marcel.taeumel wrote: > Most of the time, you are dragging objects around. In this case, it is a > block that contains the instructions to create that (other) object. If this > is the case anywhere, just hit 'e' while dragging the object to evaluate it > before dropping it. > > Another drag-modifier is 's', which lets you script any dropped objects > directly. > > If you drag long enough, there will be a hint about possible drag modifiers > in the bottom-right corner. > > Best, > Marcel > > > > -- > View this message in context: > http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837525.html > Sent from the Squeak - Beginners mailing list archive at Nabble.com. > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > -------------- next part -------------- A non-text attachment was scrubbed... Name: Vivide_Emergency_debugger_when_adding_class2015-07-15 09:18:49.png Type: image/png Size: 68686 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150715/43f112b4/49-0001.png From btc at openinworld.com Wed Jul 15 13:11:42 2015 From: btc at openinworld.com (Ben Coman) Date: Wed Jul 15 13:12:05 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: On Wed, Jul 15, 2015 at 1:28 AM, Kirk Fraser wrote: > Wow! Ben's article and slides shows Ralph Johnson's suggestion several > steps closer to real life and on computer vision for robots. > > I'm still thinking a laser range finder is not necessary since humans don't > have them. We get by with eyes that can measure distances with or without > stereo enhancement and the stereo image facility helps us see things neither > eye can make out alone. OT: That sounds a bit purist. Just because we haven't evolved laser vision (yet) doesn't mean its not useful. If it needs less computation than stereo vision then I'd say use the tools you've got :) cheers -ben :)-|--< From Marcel.Taeumel at hpi.de Wed Jul 15 15:41:29 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Wed Jul 15 15:41:38 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: References: <1436876432981-4837448.post@n4.nabble.com> <1436938285615-4837525.post@n4.nabble.com> Message-ID: <1436974889529-4837688.post@n4.nabble.com> Hi Hannes, the fact that a debugger should appear might be related to some Squeak 4.6 specifics. That it is an emergency debugger, however, was a bug in Vivide, which I just fixed. :-) Thanks for the bug report! You can update your image or setup a new one. Updating should work, just close Vivide upfront and then follow the update instructions: https://github.com/hpi-swa/vivide/wiki/FAQ If you want to use the traditional Squeak debugger, open the preferences, look for the Vivide category and disable "Use Vivide Debugger". Best, Marcel -- View this message in context: http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837688.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. From Marcel.Taeumel at hpi.de Thu Jul 16 06:10:38 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Thu Jul 16 06:10:52 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: References: <1436876432981-4837448.post@n4.nabble.com> <1436938285615-4837525.post@n4.nabble.com> Message-ID: <1437027038089-4837737.post@n4.nabble.com> Hey Hannes, here is a latest stable build: http://www.lively-kernel.org/babelsberg/vivide Best, Marcel -- View this message in context: http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837737.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. From Marcel.Taeumel at hpi.de Thu Jul 16 06:57:26 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Thu Jul 16 06:57:39 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: References: <1436876432981-4837448.post@n4.nabble.com> <1436938285615-4837525.post@n4.nabble.com> Message-ID: <1437029846031-4837741.post@n4.nabble.com> Hi Hannes, I also updated the FAQ about class creation: https://github.com/hpi-swa/vivide/wiki/FAQ Best, Marcel -- View this message in context: http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837741.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. From hannes.hirzel at gmail.com Thu Jul 16 12:37:43 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Thu Jul 16 12:37:46 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: <1437027038089-4837737.post@n4.nabble.com> References: <1436876432981-4837448.post@n4.nabble.com> <1436938285615-4837525.post@n4.nabble.com> <1437027038089-4837737.post@n4.nabble.com> Message-ID: On 7/16/15, marcel.taeumel wrote: > Hey Hannes, > > here is a latest stable build: > http://www.lively-kernel.org/babelsberg/vivide Thank you, this is more convenient. --HH > Best, > Marcel > > > > -- > View this message in context: > http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837737.html > Sent from the Squeak - Beginners mailing list archive at Nabble.com. > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > From hannes.hirzel at gmail.com Thu Jul 16 12:41:11 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Thu Jul 16 12:41:12 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: <1437029846031-4837741.post@n4.nabble.com> References: <1436876432981-4837448.post@n4.nabble.com> <1436938285615-4837525.post@n4.nabble.com> <1437029846031-4837741.post@n4.nabble.com> Message-ID: On 7/16/15, marcel.taeumel wrote: > Hi Hannes, > > I also updated the FAQ about class creation: > https://github.com/hpi-swa/vivide/wiki/FAQ > > Best, > Marcel Now very clear..... https://github.com/hpi-swa/vivide/wiki/FAQ#how-can-i-create-a-class-in-vivide Very neat to have a video clip right in the FAQ. Thank you. --Hannes > > > -- > View this message in context: > http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837741.html > Sent from the Squeak - Beginners mailing list archive at Nabble.com. > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > From btc at openinworld.com Thu Jul 16 17:10:49 2015 From: btc at openinworld.com (Ben Coman) Date: Thu Jul 16 17:11:14 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: And another option might be using the Programmable Realtime Unit of the Beaglebone Black. For example, tight loop toggling of an LED is 200ns on: * 1Ghz Arm Cortex-A8 = 200ns * 200Mhz PRU = 5ns ELC 2015 - Enhancing Real-Time Capabilities with the PRU - Rob Birkett, Texas Instruments http://events.linuxfoundation.org/sites/events/files/slides/Enhancing%20RT%20Capabilities%20with%20the%20PRU%20final.pdf https://www.youtube.com/watch?v=plCYsbmMbmY cheers -ben On Tue, Jul 14, 2015 at 7:42 PM, Ben Coman wrote: > Smalltalk FPGA may be of interest... > > http://www.slideshare.net/esug/luc-fabresse-iwst2014 > > http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_From%20Smalltalk%20to%20Silicon_Towards%20a%20methodology%20to%20turn%20Smalltalk%20code%20into%20FPGA.pdf > > cheers -ben > > On Tue, Jul 14, 2015 at 11:55 AM, Kirk Fraser wrote: >> Hi Casey, >> >> Thanks for the suggestion. I will have multiple connected controller boards >> and with your suggestion maybe I'll try a Pi for each limb and each webcam >> or maybe your ARM9 suggestion. >> >> To prove it's good as a human in performance I want it to do minor >> acrobatics like cartwheels and balancing tricks, maybe a Chuck Norris kick >> or jumping over a fence with one hand on a post. Or like those free-running >> videos. Stuff I could not do myself. But it all waits on money. Maybe I'll >> make better progress next year when social security kicks in. >> >> As far as human performance goals, one professor wrote it takes 200 cycles >> per second to hop on one leg. Somewhere I read human touch can sense 1 in >> 32,000 of an inch. I don't have the other figures yet. I may not be able >> to drive an arm as fast as a human boxer - 200 mph but as long as it's fast >> enough to drive a vehicle on a slow road (not I5) that might be enough until >> faster computers are here. >> >> The vision system seems like a major speed bottle neck. Maybe a mini-cloud >> can take one 64th of the image for each processor analyze it, then assemble >> larger object detection in time for the next frame. The DARPA Atlas robot >> used 4 cores for each camera I think. But a mini-cloud set off nearby to >> process vision and return either the objects with measurements or >> instructions would be a lot of work. The more I write, the more I see why >> the head of DARPA's robots said they cost 1-2 million as you have to hire a >> team of programmers or make a really intricate learning program. >> >> Kirk >> >> >> On Mon, Jul 13, 2015 at 5:58 PM, Casey Ransberger >> wrote: >>> >>> Hey Kirk, >>> >>> I like Ralph's suggestion of doing the time/timing specific stuff on a >>> dedicated microcontroller. >>> >>> I'd recommend going one better: use more than one microcontroller. Robots >>> need to do a lot in parallel; if the robot has to stop driving in order to >>> think, that's a problem (although the converse would be decidedly human!) >>> Anyway, it sounds like real-time is not negotiable in your view, so green >>> threads won't cut it either. >>> >>> Mine has... six controllers in total. That's not counting the ARM9 which >>> is more like a full computer (e.g., Linux.) >>> >>> I think six anyway. Could be more hiding in there. Two drive sensors, >>> three drive motors, one is wired up close to the ARM board to coordinate the >>> other controllers on behalf of what the Linux system wants them doing. >>> >>> I'm curious, have you figured out what the average, best, and worst case >>> latencies are on human reflexes? In my view, matching or beating that >>> benchmark is where the money probably is. >>> >>> --C >>> >>> On Jul 6, 2015, at 12:39 PM, Kirk Fraser wrote: >>> >>> Ralph Johnson, >>> >>> That's an excellent suggestion and an excellent story, thank you very >>> much! Letting the human interface in Smalltalk program the robot controller >>> instead of being the robot controller sounds good. >>> >>> My robot uses a network of Parallax microcontroller chips to drive >>> hydraulic valves, which can be programmed via USB for simple tasks like >>> moving one joint from point A to B but since each controller has 8 cores >>> more complex tasks like grasping or walking can be done on the MCU's or on a >>> small Raspberry Pi or other hardware in a non-GC or controllable GC >>> language. >>> >>> A harder part to wrap my head around is handling the webcam vision system >>> and artificial intelligence while remaining time sensitive enough to do time >>> critical tasks like cartwheels and other acrobatic choreography. >>> >>> I know in effect my human mind shuts down most of its intellectual >>> pursuits when engaged in heavy physical activity - maybe the robot must do >>> the same - think more creatively when idling and pay closer attention while >>> working. That takes care of the Ai timing. >>> >>> The heavy load of vision processing appears to need a mini-cloud of cores >>> to reduce time to identify and measure objects from contours and other >>> information. To guarantee performance they would also need to run a non-GC >>> language that could be programmed from Squeak interactively as new objects >>> are being learned. I haven't worked with a laser range finder but I suspect >>> they use it to narrow the focus onto moving objects to process video in more >>> detail in those areas. >>> >>> The current buzzword "co-robots" meaning robots that work beside or >>> cooperatively with people working in symbiotic relationships with human >>> partners suggests everyone will need a robot friend, which will require an >>> artificial intelligence capable of intelligent thought. As most Americans >>> are Christian it would make sense for a human compatible AI to be based on >>> the Bible. That is what I would love to work on. But that level of thought >>> needs a creative CG environment like Squeak at present. >>> >>> I've been thinking that using a Smalltalk GUI to issue command rules to >>> set an agenda for automatic text analysis and editing might be fun, letting >>> the computer do the editing instead of me. That way it could update the AI >>> knowledge like when a preferred synonym is discovered, without taking human >>> time to do much of it beyond the setup. >>> >>> Your wikipedia entry shows a webpage and blog that apparently are dead >>> links. Would you be interested in being a team member on my SBIR/STTR grant >>> application(s) for AI and Robots responding to: >>> http://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf15505 I've >>> enlisted help in writing the application from Oregon's Small Business >>> Development Center and will meet with an SBIR road trip in August I'm told. >>> (I was also told I need a Ph.D. on my team since I don't have one.) >>> >>> Kirk Fraser >>> >>> >>> On Mon, Jul 6, 2015 at 4:19 AM, Ralph Johnson wrote: >>>> >>>> Here is another possibility. >>>> >>>> Take a look at Symbolic Sound, a company that makes a system called Kyma. >>>> http://kyma.symbolicsound.com/ >>>> >>>> This company has been around for over twenty years. Its product has >>>> always been the fastest music synthesis system in the world that gives you >>>> total control over your sound. And by "total", I mean it gives you the >>>> ability to mathematically specify each sound wave. If you want, which is >>>> actually too much detail for most people. And it is all written in >>>> Smalltalk. Not Squeak, of course, since Squeak wasn't around then. But it >>>> could have been done in Squeak. And perhaps they ported it to Squeak. I >>>> haven't talked to them for a long time so I don't know what they did, but >>>> from the screen shots I think it is still a very old version of VisualWorks. >>>> >>>> Anyway, how do they make it so fast? How can they make something that >>>> can be used for hours without any GC pauses? >>>> >>>> The trick is that the sound is produced on an attached DSP. The GUI is >>>> in Smalltalk on a PC, and it generates code for the DSP. It is non-trivial >>>> making the compiler so fast that when you press "play", it can immediately >>>> start up the DSP and start producing sound. It does this (rather, it did >>>> this, since they might have changed the way it works) by just producing >>>> enough code to run the DSP for a few seconds and then starting the DSP while >>>> it generates the rest of the code. Kyma literally is writing the program >>>> into DSP memory at the same time as the DSP is running the program, >>>> producing sound. >>>> >>>> Anyway, maybe that is the right approach to programming robots. You >>>> don't even need to use two computers. Imagine you had two computers, one >>>> running Squeak and the other a simple, real-time machine designed for >>>> controlling robots, but not very sophisticated. Squeak programs the simple >>>> computer, and can change its program dynamically. The simple computer has >>>> no gc. Since Squeak is a VM on a computer, the real-time computer can be a >>>> VM, too. So, you could be running them both on your PC, or you could run >>>> them on two separate computers for better performance. >>>> >>>> I would be happy to talk more about this. But I'd like to talk about the >>>> beginning of Kyma. The owners of Symbolic Sound are Carla Scaletti and >>>> Kurt Hebel. Carla has a PhD in music, and Kurt in Electrical Engineering. >>>> I met Carla after she had her PhD. She wanted to get a MS in computer >>>> science so she could prove her computer music expertise, and she ended up >>>> getting it with me. She took my course on OOP&D that used Smalltalk. For >>>> her class project (back in 1987, I think) she wrote a Smalltalk program that >>>> ran on the Mac and that produced about ten seconds of sound, but it took >>>> several minutes to do it. Hardly real time. However, she was used to >>>> using a supercomputer (a Cray?) to generate sounds that still weren't real >>>> time, so she was very pleased that she could do it on the Mac at all, and >>>> though Smalltalk was slower than Fortran, in her opinion the ease of use was >>>> so great that she didn't mind the speed difference. As she put it, the >>>> speed difference between a Mac and a Cray was bigger than between Smalltalk >>>> and Fortran. She ended up turning this into the first version of Kyma and >>>> that became the subject of her MS thesis. I can remember when she showed >>>> it in class. She was the only woman in the class, and the other students >>>> knew she was a musician, i.e. not *really* a programmer. She was quiet >>>> during class, so they had not had a chance to have their prejudices >>>> remedied. Her demo at the end of the semester blew them away. >>>> >>>> Kurt had built a DSP that their lab used. (The lab was part of the >>>> Plato project, I believe, one of the huge number of creative results of this >>>> very significant project at Illinois.) It was called the Capybara. This >>>> was before the time when you could just buy a good DSP on a chip, but that >>>> time came very soon and then they used the commercial chips. For her MS, >>>> she converted her system to use the Capybara, and this was when she figured >>>> out how to make it start making music within a fraction of a second of >>>> pressing the "play" button. Kurt also used Smalltalk with the Capybara. >>>> His PhD was about automatically designing digital filters, and his software >>>> also generated code for the Capybara, though it was actually quite different >>>> from Kyma. >>>> >>>> The two of them worked on several different projects over the next few >>>> years, but kept improving Kyma. Along the way Kurt started building boards >>>> that had several commercial DSPs on them. Eventually they decided to go >>>> commercial and started Symbolic Sound. >>>> >>>> -Ralph Johnson >>>> >>>> On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser >>>> wrote: >>>>> >>>>> >> Tim says a multi-core VM is coming for the new Pi. >>>>> >>>>> > Are you *sure* that's what Tim said? >>>>> >>>>> Of course my over hopeful misinterpretation is possible. >>>>> >>>>> "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 >>>>> >>>>> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 >>>>> >>>>> > 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. >>>>> >>>>> 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. >>>>> >>>>> >>>>> On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) wrote: >>>>>> >>>>>> 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. >>>>>> From Marcel.Taeumel at hpi.de Thu Jul 16 17:32:13 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Thu Jul 16 17:32:30 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: References: <1436876432981-4837448.post@n4.nabble.com> <1436938285615-4837525.post@n4.nabble.com> <1437029846031-4837741.post@n4.nabble.com> Message-ID: <1437067933860-4837866.post@n4.nabble.com> In case you missed it: http://forum.world.st/Vivide-IDE-td4837299.html :) Best, Marcel -- View this message in context: http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837866.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. From hannes.hirzel at gmail.com Thu Jul 16 21:26:45 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Thu Jul 16 21:26:48 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: <1437067933860-4837866.post@n4.nabble.com> References: <1436876432981-4837448.post@n4.nabble.com> <1436938285615-4837525.post@n4.nabble.com> <1437029846031-4837741.post@n4.nabble.com> <1437067933860-4837866.post@n4.nabble.com> Message-ID: Thank you. At the moment I'd like to add a method. The video here https://github.com/hpi-swa/vivide/blob/master/howto/howto-createmethod.gif says I should tap two times. I assume you mean type two times the key. I do not get an area where I can add the method code. --Hannes On 7/16/15, marcel.taeumel wrote: > In case you missed it: http://forum.world.st/Vivide-IDE-td4837299.html :) > > Best, > Marcel > > > > -- > View this message in context: > http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837866.html > Sent from the Squeak - Beginners mailing list archive at Nabble.com. > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > From hannes.hirzel at gmail.com Thu Jul 16 21:32:21 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Thu Jul 16 21:32:24 2015 Subject: [Newbies] Re: Loading Vivide IDE? In-Reply-To: References: <1436876432981-4837448.post@n4.nabble.com> <1436938285615-4837525.post@n4.nabble.com> <1437029846031-4837741.post@n4.nabble.com> <1437067933860-4837866.post@n4.nabble.com> Message-ID: And how do I get the System Organisation list shown here https://github.com/hpi-swa/vivide/blob/master/howto/howto-createscript.gif ? On 7/16/15, H. Hirzel wrote: > Thank you. > > At the moment I'd like to add a method. > > The video here > https://github.com/hpi-swa/vivide/blob/master/howto/howto-createmethod.gif > > says I should tap two times. I assume you mean type two times the > key. > > I do not get an area where I can add the method code. > > --Hannes > > On 7/16/15, marcel.taeumel wrote: >> In case you missed it: http://forum.world.st/Vivide-IDE-td4837299.html :) >> >> Best, >> Marcel >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Loading-Vivide-IDE-tp4837445p4837866.html >> Sent from the Squeak - Beginners mailing list archive at Nabble.com. >> _______________________________________________ >> Beginners mailing list >> Beginners@lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/beginners >> > From overcomer.man at gmail.com Fri Jul 17 05:32:38 2015 From: overcomer.man at gmail.com (Kirk Fraser) Date: Fri Jul 17 05:32:43 2015 Subject: [Newbies] Raspberry Pi v. Raspberry St In-Reply-To: References: <5599C3AC.1448.20272F8@dnorton.mindspring.com> <1436146288.2678.28.camel@gmail.com> Message-ID: Thanks Ben and all. I'll keep these posts. On Thu, Jul 16, 2015 at 10:10 AM, Ben Coman wrote: > And another option might be using the Programmable Realtime Unit of > the Beaglebone Black. > For example, tight loop toggling of an LED is 200ns on: > * 1Ghz Arm Cortex-A8 = 200ns > * 200Mhz PRU = 5ns > > ELC 2015 - Enhancing Real-Time Capabilities with the PRU - Rob > Birkett, Texas Instruments > > http://events.linuxfoundation.org/sites/events/files/slides/Enhancing%20RT%20Capabilities%20with%20the%20PRU%20final.pdf > https://www.youtube.com/watch?v=plCYsbmMbmY > > cheers -ben > > > On Tue, Jul 14, 2015 at 7:42 PM, Ben Coman wrote: > > Smalltalk FPGA may be of interest... > > > > http://www.slideshare.net/esug/luc-fabresse-iwst2014 > > > > > http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_From%20Smalltalk%20to%20Silicon_Towards%20a%20methodology%20to%20turn%20Smalltalk%20code%20into%20FPGA.pdf > > > > cheers -ben > > > > On Tue, Jul 14, 2015 at 11:55 AM, Kirk Fraser > wrote: > >> Hi Casey, > >> > >> Thanks for the suggestion. I will have multiple connected controller > boards > >> and with your suggestion maybe I'll try a Pi for each limb and each > webcam > >> or maybe your ARM9 suggestion. > >> > >> To prove it's good as a human in performance I want it to do minor > >> acrobatics like cartwheels and balancing tricks, maybe a Chuck Norris > kick > >> or jumping over a fence with one hand on a post. Or like those > free-running > >> videos. Stuff I could not do myself. But it all waits on money. Maybe > I'll > >> make better progress next year when social security kicks in. > >> > >> As far as human performance goals, one professor wrote it takes 200 > cycles > >> per second to hop on one leg. Somewhere I read human touch can sense 1 > in > >> 32,000 of an inch. I don't have the other figures yet. I may not be > able > >> to drive an arm as fast as a human boxer - 200 mph but as long as it's > fast > >> enough to drive a vehicle on a slow road (not I5) that might be enough > until > >> faster computers are here. > >> > >> The vision system seems like a major speed bottle neck. Maybe a > mini-cloud > >> can take one 64th of the image for each processor analyze it, then > assemble > >> larger object detection in time for the next frame. The DARPA Atlas > robot > >> used 4 cores for each camera I think. But a mini-cloud set off nearby > to > >> process vision and return either the objects with measurements or > >> instructions would be a lot of work. The more I write, the more I see > why > >> the head of DARPA's robots said they cost 1-2 million as you have to > hire a > >> team of programmers or make a really intricate learning program. > >> > >> Kirk > >> > >> > >> On Mon, Jul 13, 2015 at 5:58 PM, Casey Ransberger < > casey.obrien.r@gmail.com> > >> wrote: > >>> > >>> Hey Kirk, > >>> > >>> I like Ralph's suggestion of doing the time/timing specific stuff on a > >>> dedicated microcontroller. > >>> > >>> I'd recommend going one better: use more than one microcontroller. > Robots > >>> need to do a lot in parallel; if the robot has to stop driving in > order to > >>> think, that's a problem (although the converse would be decidedly > human!) > >>> Anyway, it sounds like real-time is not negotiable in your view, so > green > >>> threads won't cut it either. > >>> > >>> Mine has... six controllers in total. That's not counting the ARM9 > which > >>> is more like a full computer (e.g., Linux.) > >>> > >>> I think six anyway. Could be more hiding in there. Two drive sensors, > >>> three drive motors, one is wired up close to the ARM board to > coordinate the > >>> other controllers on behalf of what the Linux system wants them doing. > >>> > >>> I'm curious, have you figured out what the average, best, and worst > case > >>> latencies are on human reflexes? In my view, matching or beating that > >>> benchmark is where the money probably is. > >>> > >>> --C > >>> > >>> On Jul 6, 2015, at 12:39 PM, Kirk Fraser > wrote: > >>> > >>> Ralph Johnson, > >>> > >>> That's an excellent suggestion and an excellent story, thank you very > >>> much! Letting the human interface in Smalltalk program the robot > controller > >>> instead of being the robot controller sounds good. > >>> > >>> My robot uses a network of Parallax microcontroller chips to drive > >>> hydraulic valves, which can be programmed via USB for simple tasks like > >>> moving one joint from point A to B but since each controller has 8 > cores > >>> more complex tasks like grasping or walking can be done on the MCU's > or on a > >>> small Raspberry Pi or other hardware in a non-GC or controllable GC > >>> language. > >>> > >>> A harder part to wrap my head around is handling the webcam vision > system > >>> and artificial intelligence while remaining time sensitive enough to > do time > >>> critical tasks like cartwheels and other acrobatic choreography. > >>> > >>> I know in effect my human mind shuts down most of its intellectual > >>> pursuits when engaged in heavy physical activity - maybe the robot > must do > >>> the same - think more creatively when idling and pay closer attention > while > >>> working. That takes care of the Ai timing. > >>> > >>> The heavy load of vision processing appears to need a mini-cloud of > cores > >>> to reduce time to identify and measure objects from contours and other > >>> information. To guarantee performance they would also need to run a > non-GC > >>> language that could be programmed from Squeak interactively as new > objects > >>> are being learned. I haven't worked with a laser range finder but I > suspect > >>> they use it to narrow the focus onto moving objects to process video > in more > >>> detail in those areas. > >>> > >>> The current buzzword "co-robots" meaning robots that work beside or > >>> cooperatively with people working in symbiotic relationships with human > >>> partners suggests everyone will need a robot friend, which will > require an > >>> artificial intelligence capable of intelligent thought. As most > Americans > >>> are Christian it would make sense for a human compatible AI to be > based on > >>> the Bible. That is what I would love to work on. But that level of > thought > >>> needs a creative CG environment like Squeak at present. > >>> > >>> I've been thinking that using a Smalltalk GUI to issue command rules to > >>> set an agenda for automatic text analysis and editing might be fun, > letting > >>> the computer do the editing instead of me. That way it could update > the AI > >>> knowledge like when a preferred synonym is discovered, without taking > human > >>> time to do much of it beyond the setup. > >>> > >>> Your wikipedia entry shows a webpage and blog that apparently are dead > >>> links. Would you be interested in being a team member on my SBIR/STTR > grant > >>> application(s) for AI and Robots responding to: > >>> http://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf15505 I've > >>> enlisted help in writing the application from Oregon's Small Business > >>> Development Center and will meet with an SBIR road trip in August I'm > told. > >>> (I was also told I need a Ph.D. on my team since I don't have one.) > >>> > >>> Kirk Fraser > >>> > >>> > >>> On Mon, Jul 6, 2015 at 4:19 AM, Ralph Johnson > wrote: > >>>> > >>>> Here is another possibility. > >>>> > >>>> Take a look at Symbolic Sound, a company that makes a system called > Kyma. > >>>> http://kyma.symbolicsound.com/ > >>>> > >>>> This company has been around for over twenty years. Its product has > >>>> always been the fastest music synthesis system in the world that > gives you > >>>> total control over your sound. And by "total", I mean it gives you > the > >>>> ability to mathematically specify each sound wave. If you want, > which is > >>>> actually too much detail for most people. And it is all written in > >>>> Smalltalk. Not Squeak, of course, since Squeak wasn't around then. > But it > >>>> could have been done in Squeak. And perhaps they ported it to > Squeak. I > >>>> haven't talked to them for a long time so I don't know what they did, > but > >>>> from the screen shots I think it is still a very old version of > VisualWorks. > >>>> > >>>> Anyway, how do they make it so fast? How can they make something that > >>>> can be used for hours without any GC pauses? > >>>> > >>>> The trick is that the sound is produced on an attached DSP. The GUI > is > >>>> in Smalltalk on a PC, and it generates code for the DSP. It is > non-trivial > >>>> making the compiler so fast that when you press "play", it can > immediately > >>>> start up the DSP and start producing sound. It does this (rather, it > did > >>>> this, since they might have changed the way it works) by just > producing > >>>> enough code to run the DSP for a few seconds and then starting the > DSP while > >>>> it generates the rest of the code. Kyma literally is writing the > program > >>>> into DSP memory at the same time as the DSP is running the program, > >>>> producing sound. > >>>> > >>>> Anyway, maybe that is the right approach to programming robots. You > >>>> don't even need to use two computers. Imagine you had two > computers, one > >>>> running Squeak and the other a simple, real-time machine designed for > >>>> controlling robots, but not very sophisticated. Squeak programs the > simple > >>>> computer, and can change its program dynamically. The simple > computer has > >>>> no gc. Since Squeak is a VM on a computer, the real-time computer > can be a > >>>> VM, too. So, you could be running them both on your PC, or you could > run > >>>> them on two separate computers for better performance. > >>>> > >>>> I would be happy to talk more about this. But I'd like to talk about > the > >>>> beginning of Kyma. The owners of Symbolic Sound are Carla Scaletti > and > >>>> Kurt Hebel. Carla has a PhD in music, and Kurt in Electrical > Engineering. > >>>> I met Carla after she had her PhD. She wanted to get a MS in computer > >>>> science so she could prove her computer music expertise, and she > ended up > >>>> getting it with me. She took my course on OOP&D that used > Smalltalk. For > >>>> her class project (back in 1987, I think) she wrote a Smalltalk > program that > >>>> ran on the Mac and that produced about ten seconds of sound, but it > took > >>>> several minutes to do it. Hardly real time. However, she was used > to > >>>> using a supercomputer (a Cray?) to generate sounds that still weren't > real > >>>> time, so she was very pleased that she could do it on the Mac at all, > and > >>>> though Smalltalk was slower than Fortran, in her opinion the ease of > use was > >>>> so great that she didn't mind the speed difference. As she put it, > the > >>>> speed difference between a Mac and a Cray was bigger than between > Smalltalk > >>>> and Fortran. She ended up turning this into the first version of > Kyma and > >>>> that became the subject of her MS thesis. I can remember when she > showed > >>>> it in class. She was the only woman in the class, and the other > students > >>>> knew she was a musician, i.e. not *really* a programmer. She was > quiet > >>>> during class, so they had not had a chance to have their prejudices > >>>> remedied. Her demo at the end of the semester blew them away. > >>>> > >>>> Kurt had built a DSP that their lab used. (The lab was part of the > >>>> Plato project, I believe, one of the huge number of creative results > of this > >>>> very significant project at Illinois.) It was called the Capybara. > This > >>>> was before the time when you could just buy a good DSP on a chip, but > that > >>>> time came very soon and then they used the commercial chips. For her > MS, > >>>> she converted her system to use the Capybara, and this was when she > figured > >>>> out how to make it start making music within a fraction of a second of > >>>> pressing the "play" button. Kurt also used Smalltalk with the > Capybara. > >>>> His PhD was about automatically designing digital filters, and his > software > >>>> also generated code for the Capybara, though it was actually quite > different > >>>> from Kyma. > >>>> > >>>> The two of them worked on several different projects over the next few > >>>> years, but kept improving Kyma. Along the way Kurt started building > boards > >>>> that had several commercial DSPs on them. Eventually they decided to > go > >>>> commercial and started Symbolic Sound. > >>>> > >>>> -Ralph Johnson > >>>> > >>>> On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser > >>>> wrote: > >>>>> > >>>>> >> Tim says a multi-core VM is coming for the new Pi. > >>>>> > >>>>> > Are you *sure* that's what Tim said? > >>>>> > >>>>> Of course my over hopeful misinterpretation is possible. > >>>>> > >>>>> "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 > >>>>> > >>>>> > https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818 > >>>>> > >>>>> > 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. > >>>>> > >>>>> 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. > >>>>> > >>>>> > >>>>> On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) > wrote: > >>>>>> > >>>>>> 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. > >>>>>> > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20150716/c21a1d51/attachment-0001.htm From Das.Linux at gmx.de Mon Jul 20 17:48:15 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Mon Jul 20 17:48:19 2015 Subject: [Newbies] [Squeak 4.6] Font Importer Tool instructions? In-Reply-To: References: Message-ID: <2C245FBE-294A-4B1E-A04F-71981BB3D733@gmx.de> Hi Hannes, Sorry for this very late answer. I put the font importer into the image to make it a bit easier to deal with TrueType fonts. On 14.07.2015, at 13:43, H. Hirzel wrote: > Hello > > In the yet to be released Squeak 4.6 > (http://ftp.squeak.org/4.6/Squeak-4.6-All-in-One.zip is a preview) > there is a note about a > > Font Importer Tool > > How do I use it? When you open it, it presents you with a list of fonts a) relative to your image (/fonts/) and b) some platform specific ones. You then can choose to "import"* them into the image (Ie, their glyph data). It should then be possible to use the fonts like other vector-based ones in the image, such as BitstreamVeraSans. > > The release notes as well mention > > "Better support for True-Type fonts, including PostScript based > True-Type fonts." > > What does this cover? Well, you now can load some more ttc (true type collection) files, some other unicode-coded truetype files. And the TrueType machinery chokes less on files that just pretend to be truetype fonts, but aren't (I'm looking at you, Apple). > > Thank you for the answer in advance Best regards -Tobias *If you right-click on a font name, it also offers you to 'link' the font. This does not load the font data into the image but rather references the font file by name. You have to make sure for yourself that font files used that way are always available, also when moving the image.