[Newbies] Re: Beginners Digest, Vol 108, Issue 5
Kerry Herden
herdenkerry6 at gmail.com
Tue Jul 14 02:02:50 UTC 2015
unsubscribe
On Tue, Jul 14, 2015 at 10:58 AM, <
beginners-request at lists.squeakfoundation.org> wrote:
> Send Beginners mailing list submissions to
> beginners at 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 at lists.squeakfoundation.org
>
> You can reach the person managing the list at
> beginners-owner at 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 <casey.obrien.r at gmail.com>
> Subject: Re: [Newbies] Raspberry Pi v. Raspberry St
> To: "A friendly place to get answers to even the most basic questions
> about Squeak." <beginners at lists.squeakfoundation.org>
> Message-ID: <D0FA7EDA-8261-492F-A974-971786A9614F at gmail.com>
> 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 <overcomer.man at gmail.com>
> 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 <johnson at cs.uiuc.edu>
> 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 <overcomer.man at gmail.com>
> 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) <pbpublist at gmail.com>
> 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 <dnorton at mindspring.com>
> >>>> > wrote:
> >>>> > On 5 Jul 2015 at 16:22, Kirk Fraser wrote:
> >>>> >
> >>>> >
> >>>> > >
> >>>> > > We should ask why do people want to teach Python instead
> of
> >>>> > > Smalltalk? Why do people veer
> >>>> > > away from Smalltalk with add-ons like Etoys, Scratch, and
> >>>> > many other
> >>>> > > paradigms like Patterns
> >>>> > > and CRC cards, which aren't as good for commercial
> >>>> > programming, thus
> >>>> > > really aren't as good to
> >>>> > > teach children? What can be done to remodel Squeak to
> >>>> > provide all
> >>>> > > the features more
> >>>> > > commercially popular languages have?
> >>>> > >
> >>>> > > Earlier a post saying a boss didn't want a GUI that a
> >>>> > combination of
> >>>> > > buttons would bring up all
> >>>> > > sorts of things his employees shouldn't be playing with.
> So
> >>>> > put a
> >>>> > > cleaner commercial GUI on the
> >>>> > > list. Maybe the preferences switch could be in its own
> file
> >>>> > or as
> >>>> > > the first character in Sources to
> >>>> > > reduce file count. The Changes file shouldn't be needed
> in
> >>>> > a
> >>>> > > deployed application. Is there any
> >>>> > > way to cut the deployment image down to one file
> containing
> >>>> > both the
> >>>> > > Sources and VM like an
> >>>> > > .exe in any other language?
> >>>> > >
> >>>> > > I've written on the need to fix Garbage Collection control
> >>>> > so it can
> >>>> > > be turned off like Python allows
> >>>> > > to enable Squeak to be used for real time projects like
> self
> >>>> > driving
> >>>> > > cars, since a 100ms delay can
> >>>> > > veer 8 feet off course, fully into a lane of oncoming
> >>>> > traffic.
> >>>> > >
> >>>> > > Recently I learned from a UC Berkeley website it takes
> 100ms
> >>>> > to
> >>>> > > recognize the objects in a
> >>>> > > picture too. Does that mean the future will have a cloud
> in
> >>>> > every
> >>>> > > car and Squeak needing to
> >>>> > > conduct image analysis in hundreds of cooperating cores to
> >>>> > get safe
> >>>> > > real time performance?
> >>>> > >
> >>>> > > The state of Squeak for all its benefits seems like a
> >>>> > collection of
> >>>> > > law statutes, a big set of text
> >>>> > > contributed by years of legislation that nobody can
> remember
> >>>> > all of
> >>>> > > and some of which makes little
> >>>> > > sense. Maybe a major rewrite starting from zero would
> help?
> >>>> > >
> >>>> >
> >>>> >
> >>>> > " like a collection of law statutes" is a good analogy. Cuis
> >>>> > seems like a major rewrite of Squeak and is simpler, easier
> to
> >>>> > understand. What do you think of Cuis?
> >>>> >
> >>>> >
> >>>> > > The GUI - while it has many nice features, it somehow
> seems
> >>>> > to lack
> >>>> > > the crisp precision, ease,
> >>>> > > and speed of commercial software like Solidworks. I like
> >>>> > how
> >>>> > > Squeak comes up and is ready to
> >>>> > > go far quicker than say Amazon's Audible application but
> >>>> > Squeak
> >>>> > > graphics aren't so fast or easy
> >>>> > > to program as Solidworks.
> >>>> > >
> >>>> > > Recently I saw a couple of short videos on two moderate
> size
> >>>> > robots
> >>>> > > where users extolled their
> >>>> > > ease of programming. Perhaps Smalltalk needs a new top
> >>>> > level rule
> >>>> > > based language to improve
> >>>> > > programmer efficiency. I'm working on this one. And as
> my
> >>>> > > prototype was so easy, it angers me
> >>>> > > to think of all the time I spent being both ignorant and
> >>>> > afraid
> >>>> > > after seeing various compiler books
> >>>> > > like the "Dragon Book" intentionally make compiler
> writing a
> >>>> > > difficult graduate level course instead
> >>>> > > of an easy advanced beginner level assignment.
> >>>> > >
> >>>> > > But one thing I have in common with my Raspberry Pi, when
> my
> >>>> > > utilization is maxed for too long, I
> >>>> > > overheat and shut down. I can write simple stuff like
> this
> >>>> > when
> >>>> > > it's too hot to do real work. But
> >>>> > > even multiple cores get too hot when they are maxed out.
> So
> >>>> > a real
> >>>> > > time computer needs heat
> >>>> > > control or cooling overkill in case a vital complex
> >>>> > situation clogs
> >>>> > > the bandwidth. Well, pray about
> >>>> > > it.
> >>>> >
> >>>> >
> >>>> > - Dan
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > Beginners mailing list
> >>>> > Beginners at lists.squeakfoundation.org
> >>>> >
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
> >>>> >
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > Beginners mailing list
> >>>> > Beginners at lists.squeakfoundation.org
> >>>> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Beginners mailing list
> >>>> Beginners at lists.squeakfoundation.org
> >>>> http://lists.squeakfoundation.org/mailman/listinfo/beginners
> >>>
> >>>
> >>> _______________________________________________
> >>> Beginners mailing list
> >>> Beginners at lists.squeakfoundation.org
> >>> http://lists.squeakfoundation.org/mailman/listinfo/beginners
> >>
> >>
> >> _______________________________________________
> >> Beginners mailing list
> >> Beginners at lists.squeakfoundation.org
> >> http://lists.squeakfoundation.org/mailman/listinfo/beginners
> >
> > _______________________________________________
> > Beginners mailing list
> > Beginners at 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 at 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
More information about the Beginners
mailing list