Squeak-dev October 2007

squeak-dev@lists.squeakfoundation.org

151 participants
195 discussions

What is the proper way to get the Refactoring Browser in 3.9
by Hilaire Fernandes 07 Dec '07

07 Dec '07

I have installed RB and AST from SqueakMap for 3.9, but I have many random problem swith features not working as hierarchy browsing, simple editing in the browser, refactoring tools as renaming methods. These problems happen more or less randomly. Hilaire

4 13

Concurrent Futures
by Peter William Lount 15 Nov '07

15 Nov '07

Hi, This link will be of interest to those wanting easy concurrency. Works best for simple cases and can be used as a primitive in building up more complex concurrency controls. However, use with caution, especially when larger amounts of code are being executed that could conflict with other threads is involved. This applies even in the single native thread multiple Smalltalk "light weight green" processes environment of most Smalltalks. http://onsmalltalk.com/programming/smalltalk/smalltalk-concurrency-playing-… Cheers, Peter

29 138

[ANN] Smalltalk Party Berne, 17th of November 2007
by Marcus Denker 10 Nov '07

10 Nov '07

SSUG is organizing a Smalltalk Gathering. We invite all Smalltalkers to join this event to share their enthusiasm and knowledge about Smalltalk. Where Software Composition Group Schuettzenmattstrasse 14 3012 Bern Switzerland When Saturday, 17th of November 2007 10h Start 14h Presentations / Demos Please send an email to denker(a)iam.unibe.ch if you plan to attend and especially when you plan to give a demo/talk. More infos: http://smallwiki.unibe.ch/ssug/smalltalkparty17thofnovember2007/ Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 1

SqueakMap crashes in 3.10 beta.7158
by Trygve Reenskaug 06 Nov '07

06 Nov '07

I suppose I have missed something, the question is what? The VM crashes when I try to install BabySRE-TRee39 package from SqueakMap. The VM also crashes when I try to install Balloon3D 1.0.4 package from SqueakMap. OS: WinXP version 5.1, SP 2 Image: Squeak3.10beta.7158 VM: SqueakVM-3.10.6 What's wrong? Thanks --Trygve -- Trygve Reenskaug mailto: trygver(a)ifi.uio.no Morgedalsvn. 5A http://folk.uio.no/trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway

19 48

Squeak from a newcomer's perspective
by Jon Hylands 05 Nov '07

05 Nov '07

One of the guys on a robotics list I am on was interested in using Squeak for his robot after I showed him what I had done with my RoboMagellan controller: http://www.huv.com/roboMagellan/MissionEditor.jpg He's been playing with Squeak for a week or so, and he posted this reply to someone who was asking him why Squeak (and I'm reposting it here with permission): ========================== "Robert F. Scheer" <RFScheer(a)speakeasy.net> > Hello, > > tell me more about squeak please... First, let me make it clear I am not yet advocating Squeak. I'm into it now for almost a week. I'm finding it very fun and it looks like it has a big chance of being my robot programming environment for the next 20 years. But it's possible that could change, obviously. Squeak is an open source evolution of Smalltalk-80. I think it doesn't help to describe it as 100% object oriented and so forth. What really attracts me is how you can build up applications from your own and others' collections of stuff written for other projects often in unrelated areas. The unique integrated design environment is fun and powerful. Apparently it is common to write code by first specifying verification procedures and then working backward. It is often common to write code in the integrated debugger. The code is compiled as you go and it is always live. When you enter a line or a class, the IDE won't allow grammar errors or references to missing variables and so forth. You spend no time on type declarations although types are quite rigid, but you don't have issues of different modules using common headers and cr.p like that. Garbage collection is totally built in and needs no programmer attention. A squeak program (image) will run under all *nix's, Windows, Mac and on any machine that hosts those so you can write it on your desktop, test various stuff there and then file it out to your robot for ground testing. Large robot control images can be adapted over time to different projects without rewriting huge portions of code. The same image could be extended over many years to control new robot projects while still being backward compatible to older ones. This way if you develop a brand new feature it might be available to an older robot with no further effort. If early bots use simple subsumption architecture, that code can remain available while you add higher level techniques so it's easy to imagine testing a brand new robot first with the most basic subsumption behaviors and then adding the newer ones layer by layer as you test. Oh, the Squeak community on the web is really well organized and there's a huge degree of sharing. Code is much easier than other languages to share. I believe that even though not that many people seem to use it in my immediate circle (read zero), and I doubt a major fraction of the world's programmers use it, they make progress pretty quickly due to the community pool of knowledge. I may be misusing some concepts but I hope you get the idea. I hope I still agree with this description a year from now. The place to start is a fantastic (free) ebook at this site (Squeak by Example): http://www.iam.unibe.ch/%7Escg/SBE/ I found that Ubuntu made it easy/instant to load version 3.9 sources from repository. There are some downsides to Squeak of course. Images tend to be much larger, meaning multi-MB, than programs in other languages and they're not as fast either but that's not something I'm qualified to amplify on atm. Jon Hylands runs Squeak on Gumstix miniature computers so that tells you that a fast ARM processor is probably the minimal hardware environment. You will not be running Squeak on a PIC or AVR or Propeller though. I am not sure but doubt you could write a vision processor in Squeak with reasonable performance for example. It is most likely you need primitives written in a lower level language that do the grunt work. But I wouldn't be surprised to discover that those are easily loaded from the web and require no effort on your part other than understanding what they are in the first place. > what widgets or GUI tools have found for it that correspond to robotics > type work for GUI design... knobs, meters, and such??? > > inquiring minds want more info...pretty please... I honestly haven't looked for widgets yet. I see huge lists of all types of Squeak code for this and that on line ready to pull into your application. Also, I'm still hazy on what the web pages actually are that the robot will serve to the remote monitor screen and control panel. Just not there yet. I did notice that Jon Hylands, who has been a great mentor btw (sorry Jon to let that slip) is thinking that George's point about remote browser based gui's is a good idea so he'll probably head in that direction. In conclusion, after one week of Squeak, I'd say it's a mind-warp. It's not a linear way of thinking. It requires a disciplined journey to a different reality. One of the first programming exercises is to go through the steps to make a little game. Going through the motions makes a lot of sense and you're done in about 15 minutes. You realize to be able to think along the lines of the original designer would require a different you. ========================== Later, Jon -------------------------------------------------------------- Jon Hylands Jon(a)huv.com http://www.huv.com/jon Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog

7 8

[Q] Linux and localAddress
by Edgar J. De Cleene 05 Nov '07

05 Nov '07

Folks: I playing with Linux and wish know why World reportLocalAddress report 127.0.01 and ifconfig on Linux console gives me 192.168.1.4. The Linux is SimplyMepis 6.5, installing from his repositories ( via console synaptic package manager) brings me Squeak 3.8, and I figure out how transfer and run the 3.10 needed files The computer is on small Lan connected to router with Mac and Windows, so I could test Squeak 3.10 on the three systems. Any lead ? Edgar

9 13

squeak on iLiad
by Norbert Hartl 02 Nov '07

02 Nov '07

Hi, anyone tried to put a squeak vm on an iRex iLiad or knows anything about it? http://www.irextechnologies.com/products/iliad It's an xscale based hardware. thanks, Norbert

6 10

ConcurrentSmalltalk
by Torsten Sadowski 01 Nov '07

01 Nov '07

Hello, with all those threads about a concurrent Squeak I'm wondering if someone knows Yasuhiko Yokote. I have "The Design and Implementation of ConcurrentSmalltalk" and would scan it for the free books collection. Cheers, Torsten

3 3

Re: Concurrent Futures
by Joshua Gargus 31 Oct '07

31 Oct '07

Thanks for this interesting list of your relevant work. I look forward to any other thoughts that you could add to this thread, in particular to provide a reality-check where your real-world experience disagrees with my theoretical understanding :-) Best, Josh On Oct 30, 2007, at 4:24 PM, Jecel Assumpcao Jr wrote: > I would like to mention some of my previous work in this area: > > - tinySelf 1 (1996) > http://www.lsi.usp.br/~jecel/tiny.html#rel1 > > This was a Self interepreter written in Self which implemented the one > thread per object model. All messages were future messages but since > sending a message to an unresolved future would block, you would have > deadlock on any recursion (direct or indirect). This problem was > solved > by detecting the cycles and preempting the blocked mesasge with the > one > it depends on. This results in interleaved execution, but since the > semantics are exactly the same as in a sequential execution of the > recursive code any bugs that appear won't be due to concurrency. > > I was able to test simple expressions and was very happy with how much > parallelism I was able to extract from seemingly sequential code, > but I > made the mistake of introducing a significant optimization (tail send > elimination) that made debugging so much harder that I was unable to > finish in the two weeks that I was able to dedicate to this project. > > - 64 node Smalltalk machine (1992) > http://www.lsi.usp.br/~jecel/ms8702.html > > The most interesting result in this project was the notion that most > objects in the system are immutable at any given time and that a > security system might be used to detect this. For example, just > because > you can edit some font today doesn't mean that you will do it. And if > you and everyone currently logged on the local system only have read > permission for that font then it is effectively immutable. Only > when the > font's owner logs in is this assumption invalid. > > The advantage of knowing that an object is immutable is that you can > replicate it and you can allow multiple threads to access it at the > same > time. > > The only paper in English from this project describes how adaptive > compilation could be used to trim away excessive concurrency by > transforming future message passing into sequential message passing > (the > semantics allow this) and then inlining them away. So if a machine has > 64 processors and the application initially starts out with 10 > thousand > threads, the compiler will eventually change this into code with > 200 or > so threads (some are blocked at any given instant, so going down to 64 > threads would not be good).. > http://www.lsi.usp.br/~jecel/jabs1.html > > - operating system in an Objective-C like language (1988) > http://www.lsi.usp.br/~jecel/atos.html (this page has download > links but > the text still hasn't been written) > > This operating system for 286 machine used the virtual memory of that > hardware to isolate groups of objects, with one thread per group. This > would be similar to the vat/island model. All messages were sent in > exactly the same way and if the receiver was a local object then it > was > just a fancy subroutine call but for remote objects you got a "segment > not present" fault and the message was packed up and sent to the other > task (possibly over the network). All messages were synchronous > since I > was not aware of futures at that time. > > -- current model -- > > I moved back to the one thread per object group model since I feel > that > makes it easier for programmers to control things without having to > worry to much about details most of the time. Since my target is > children this is particularly important. An alternative that I > experimented with was having a separation between active and passive > objects. A passive object could be known only to a single active one, > but it is just too hard to program without ever accidentally letting > references to passive objects "leak". With the group/vat/island model > there is just one kind of object and things are simpler for the > programmer (but more complicated for the implementor). I have a > limitation that you can only create new objects in your own group > or in > an entirely new group - I think forcing some other random group to > create an object for you is rude, though of course you can always ask > for an object there to please do it. > > Some of the loaded groups are read/write but many are read-only. The > latter don't actually have their own threads but instead their code > executes in the thread of the calling group. I have hardware > support for > this. > > Speaking of hardware, I would like to stress how fantastically slow > (relatively speaking) main memory is these days. If I have a good > network connecting processor cores in a single chip then I can > probably > send a message from one to another, get a reply, send a second message > and get another reply in the time that it takes to read a byte from > external RAM. So we should start thinking of DDR SDRAM as a really > fast > disk to swap objects to/from and not as a shared memory. We should > start > to take message passing seriously. > > -- Jecel >

2 1

Re: Concurrent Futures
by Igor Stasenko 31 Oct '07

31 Oct '07

On 01/11/2007, Jecel Assumpcao Jr <jecel(a)merlintec.com> wrote: > Joshua Gargus wrote: > > Thanks for this interesting list of your relevant work. I look > > forward to any other thoughts that you could add to this thread, in > > particular to provide a reality-check where your real-world > > experience disagrees with my theoretical understanding :-) > > Sadly, my practical experience is far more limited than it should be, > given all the years I have spent on this, since often a project would be > abandoned after only preliminary results in favor of a "much better" > one. > > One thing that I haven't tried yet is making messages to futures return > new futures instead of blocking (which I understood from this dicussion > to be the E way). I had thought about it but imagined it might lead to > ever growing graphs of pending messages with no actual work being done. > I see now that in practice the overhead might be comparable to what my > deadlock detector had. This would probably also make my "tail send" > optimization mostly useless, which is a good thing. > > In all my projects I took a very conservative path regarding blocks: I > simply defined "." as a kind of barrier where all previous instructions > must finish before any of the following instructions can be started. > Since I was getting a lot of parallelism even with this I didn't worry > too much about it and this allowed code like this to work just fine: > > | a | > a := 1. > 1 to: 20 do: [ :i | a := a + i ]. > a := a - 1. > 1 to: 20 do: [ :x | a := a - x ]. > ^ a > > Having "." as a barrier is unecessary in the code below, but at least > the results will be correct even if at a much reduced performance: > > | a b | > a := (1 to: 20) collect: [ :i | i * i ]. > b := (1 to: 20) collect: [ :x | x + 7 ]. > ^ a + b > > It isn't very hard for the compiler to know which is the case for each > example. > Yes, without barriers the following code simply will not work as desired: | a b | a := (1 to: 20) collect: [ :i | i * i ]. Interval removeSelector: #collect: . b := (1 to: 20) collect: [ :x | x + 7 ]. ^ a + b -- Best regards, Igor Stasenko AKA sig.

1 0

Jump to page: