Squeak-dev October 2001

squeak-dev@lists.squeakfoundation.org

191 participants
600 discussions

oopsla report at Smalltalk Chronicles
by Alan Knight 30 Oct '01

30 Oct '01

For those who didn't make it, I've put an OOPSLA report up at http://www.smalltalkchronicles.net/oopsla2/oopsla2001report.html -- Alan Knight [|], Cincom Smalltalk Development knight(a)acm.org aknight(a)cincom.com http://www.cincom.com/scripts/smalltalk.exe/downloads/index.asp

1 0

Re: Lots of concurrency
by Ken Kahn 30 Oct '01

30 Oct '01

David Chase wrote: > > At 10:01 AM 10/25/2001 -0700, Ken Kahn wrote: > >Thinking sequentially about problems that are inherently concurrent is > >suboptimal. > > I disagree. My favorite examples, not necessarily relevant > to Squeak, are: > > 1) network (web) servers. > > The task is inherently parallel; there can be many > connections in progress at one time. However, the > task is greatly simplified by organizing it as a > bunch of sequential threads. > Maybe. We seem to agree that the problem should be broken down into many concurrent activities. So we aren't thinking sequentially at the top level. So then the question that remains is how to think and program at the lower level. I have been arguing for a uniform and simpler computation model that has no support for sequentiality (or sequential threads). But there is still dataflow synchronization - it isn't a chaotic concurrency. So one would need to look closely at examples to see if dataflow is natural or awkward. > 2) finite element models (game of life, cellular automata). > > The problem is *described* from the point-of-view of a single > cell, and the parallelism is then added. The differential > equation itself describes the behavior *of a point*. There > are cases where it is more efficient to think of the aggregate > acting in parallel (for instance, the physical properties of > an I-beam) but often the most interesting problems are those > where we *do not know the aggregate behavior* -- there, we > must work from first principles. (It depends, very much, > one what we are using the computer/program for -- designing > a house, we work with standard aggregate-behavior-understood > materials, but designing a scramjet or a high-performance > propeller, we must work from finite elements.) > You seem to be arguing that this is another example of parallelism or concurrency in the large and sequentiality in the small. But the behavior of a cell in the game of life or a cellular automata is not like a sequential thread. There is no need for a stack of procedure calls. Right? > > The use of (synchronized) time steps also helps avoid the > non-uniform progress problem (which is the one that most > often catches me when I write parallel code). > I'll admit to being sloppy about time. And naive concurrent programs can have a problem of non-uniform progress. As I see it the question to whether the underlying computation model needs to "know about" time or whether when appropriate user code can just communicate and synchronize with clock processes. I prefer to keep the model simple but one needs to look at lots of examples to see how clumsy some programs might become as a result. > > In contrast, working on parallel programs, I have seen/heard of > programmers across a wide range of skill levels (everyone from > the more academic members of the Modula-3 design team, to a > tenured professor at MIT, to Los Alamos rocket scientists, to > just ordinary programmers) get wedged numerous times with > mistaken assumptions about atomicity, progress of computing, > progress of communication, and equivalence of different > concurrent programs. > I believe much of the complexity that causes these problems is that the languages they are using mixes concurrent and sequential programming. I'm proposing eliminating the sequential part. > Even something as simple as producers-and-consumers is easy > to get wrong, if the wrong thread does the updates. > Young children program producers and consumers in ToonTalk and they can't get such a thing wrong. They program a robot to keep giving things to a bird (the producer) and another robot to pick things off a nest and process them (the consumer). Multiple senders or recievers don't make it harder. In the model I'm advocating I can't make sense out of "the wrong thread does the updates". > > >I think her problem is that her model of programming is sequential as a > >result of her year of Logo programming. And the world isn't sequential. > >Think of sports teams. Think of traffic. Think of the internal concurrency > >in walking. In games. Think about bank account transfers. The Incredible > >Machine. Cooking. An orchestra. And so on. > > Think, in general, of how we massage these things to make them > more sequential. Traffic -- we have lanes, we have rules, we > have signals. Places like Massachusetts, this is less true, but > I find the driving in Massachusetts is less efficient and more > stressful than in other places (and to count the dents and dings > on cars I see, more error-inducing). If you look at how an > orchestra is organized, it is designed to present the problem > as a collection of sequential tasks; only the conductor is > responsible for the "big picture", and the most difficult > music is that which lacks familiar timing cues (like a regular > beat -- tiny time steps, again). In addition, the musicians > all generally have their own copies of the music (replication -- a > common trick for reducing interdependence in concurrent problems) > even when playing the same part. Or, consider a marching band -- > with certain exceptions (Stanford, Rice) it's time-step city, > with each actor running on his own program taking queues from > his neighbor (he turns left, two ticks, I turn left). I've > seen buggy marching bands, too :-). > Isn't a programmer more like the composer than the musicians or the conductor? But maybe you are right that this is an example of "programming" lots of sequential threads. Here's how I think of the traffic issue. A concurrent view might give a rule to each car that it can enter the space in front of it if it is empty. There is a dataflow (or traffic flow) synchronization between autonomous activities. A sequential view would be a car that moves forward because it finished its previous step regardless of whether the space is occupied. I.e. more dents. ;-) > > My working definition for "asynchronous" is "at any time" -- in particular, > an "asynchronous interrupt" (or "asynchronous method invocation") could > occur at any time during the execution of any other method. This is > incredibly problematic from the POV of data structure consistency, even > with locks/critical sections. The worst parts of Java can occur > "at any time" -- Thread.stop() delivers an exception (in theory) at > any point in a another thread's execution, and Thread.suspend() can > stop a thread from making progress no matter what it is executing, > no matter what locks it holds, etc. > I don't think one needs the concept of an interrupt if there are no sequential threads. Now one might want an object to give priority to messages arriving on certain channels but that doesn't cause all these problems. I haven't thought much about hardware interrupts but can't that be dealt with by low-level system drivers and the concept of an interrupt needn't go any further. And maybe there are better ways to deal with hardware interrupts. > Asynchrony presents a particular problem if you wish to test a > program for the presence of bugs (never mind proving the damn > thing correct in that sort of a world); in practice, you can > never know that you have tested for every possible asynchronous > interrupt/invocation that might occur. In a (compiled) Java system, > we dealt with this problem (for garbage collection) by defining > compiler-inserted safe points where threads are preempted, > including by another thread's need for GC. By reducing (drastically) > the number of places where the asynchronous event (GC) could occur, > we made it actually possible to test that the correct GC > bookkeeping was maintained for every single place where a GC > could occur. Testing was still tedious and slow, but orders of > magnitude less so than testing at every instruction. > Some would argue that it is better to be able to reason about your program than try to test it exhaustively. And having a simpler cleaner underlying model of computation facilitates reasoning. It is harder to reason about programs that are both concurrent and sequential. >There is a further problem in all of this if you are the least >bit worried about performance. Communication is expensive. >Synchronization is expensive. Adding layers of abstraction can >become incredibly expensive if each layer adds its own separate >layer of locking -- no longer is it a matter of "just dynamically >inline it to make it fast" -- the synchronization itself (on >a multiprocessor) can cost an order of magnitude more than >the procedure call/return that was inlined. It's interesting >to look at how unsynchronized versions of various library >classes were added between Java 1.0 and Java 1.1; even with >the fastest possible implementations, synchronization is too >slow to make it the default. Performance can be high for highly concurrent programs in languages implemented well to support such a thing. See for example www.sics.se/~andreas/papers/JavaVsOz.ps and http://www.klic.org/software/klic/index.en.html Enough for now. Thanks for the thought-provoking comments. Best, -ken kahn ( www.toontalk.com )

3 2

RE: Lots of concurrency
by G.J.Tielemans＠dinkel.utwente.nl 30 Oct '01

30 Oct '01

For a beginner all the activities in a problem space are loose ends. Who does not remember driving a car for the first time, All these things you have to do together. And now you drive a car, talk to your friends in the car, wave to that walking lady.. Most of your loose ends of the beginning are now integrated in patterns, lots of them even subconsious: - Oops are we already here.. - With which hand do you control the direction-lights, yes try to remember that. - If you drive a not automatic car: which foot do you use for the very imprtant break? Having lower things organised in patterns, makes room for higher or other skills. Handy users can even do more in these situations: Mister Bean going to the dentist is my favorite. Visual cues, like a well designed GUI can be an extra help, but a GUI or Morph that interferes with the overall design is burning down that profit: It forces you to think again about the GUI concpet: That's one of the reasons people like Squeak to it in the GUI the can dream. But what is a good design environment for a beginner, can be a burden for a more experienced one: And who decides when you are crossing that border line. (In the past we thought that in the final GUI AI would coordinate this.) > -----Original Message----- > From: Alan Kay [mailto:Alan.Kay@squeakland.org] > Sent: maandag 29 oktober 2001 8:31 > To: squeak-dev(a)lists.squeakfoundation.org > Subject: Re: Lots of concurrency > > > If one is actually playing *music* when playing Bach on the pipe > organ, than one is indeed thinking deeply about all the parts at > once, how they intertwine and what they might "mean", both separately > and in combination. Same when one is improvising in counterpoint. > Same, if one is sight reading and trying to have real music flow out. > I'm afraid that one really does think about these in parallel > combination (as I said, very much like watching a theatrical > production with multiple actors on the stage, but sonically). It's > learnable, and lots of people have learned how. I believe that many > advanced thinking "skills" have quite a bit in common with all this. > You can learn how to have multiple "thinkers" working on different > aspects of ideas, all together. > > Cheers, > > Alan > > ---- > At 11:05 PM +0000 10/28/01, Gary McGovern wrote: > >Hello Alan, > >I have to pull you up on something here. A person playing > keyboard, driving > >a car and so on doesn't always think about what they are > doing. Often it is > >trained into the body or mind or whatever through repetition > and practice > >and maybe in a linear fashion. > >Regards, > >Gary > > > >----- Original Message ----- > >From: "Alan Kay" <Alan.Kay(a)squeakland.org> > >To: <squeak-dev(a)lists.squeakfoundation.org> > >Sent: Friday, October 26, 2001 4:13 AM > >Subject: RE: Lots of concurrency > > > > > >> But Herb didn't play Bach on the pipe organ *or* think > about what he > >> was doing when driving a car, or even just walking and talking and > >> looking and feeling .... his intellect was "amazing" (in a very > >> special sense of that word)... > >> > >> Cheers, > >> > >> Alan > >> > >> ------- > >> > >> At 9:46 PM -0400 10/25/01, Mark Guzdial wrote: > >> >As far as I know, Herb Simon didn't argue about naturalness of > >> >parallelism in programming languages. Herb Simon was one of the > >> >pioneers of cognitive science, and he argued that the mind was > >> >single-threaded. (Simon was also one of the most > amazing intellects > >> >of our time -- a Nobel prize winner in Economics and a > Turing Award > >> >winner in computer science) > >> > > >> >Mark > >> > > >> >>Fascinating and important questions being debated in > this thread; I just > >> >>wanted to ask Mark (or anyone else who knows) what the > Herb Simon > >arguments > >> >>and evidence in opposition to the "naturalness" of > >parallelism/concurrency > >> >>in programming languages he was referring to. Perhaps > a brief textual > >> >>summary of the arguments, and maybe a pointer to the evidence? > >> >> > >> >> - Jerry Balzano > >> >> > >> >>At 10:38 AM -0700 10/25/01, Mark Guzdial wrote: > >> >>>We're getting into some of my favorite literature, so > I wanted to jump > >in > >> >>>here. > >> >>> > >> >>>>And I think it is just an illusion > >> >>>>that this parallelism is only at a low level (e.g. > neurons). Read > >Minsky's > >> >>>>Society Theory of Mind ( > http://www.media.mit.edu/people/minsky/ ) for > >> >>>>example. > >> >>> > >> >>>But also consider Herb Simon's arguments in opposition > -- and Simon > >> >>>has a lot more empirical evidence in his favor. I > don't have an > >> >>>opinion on which is right yet, but I don't think that this is a > >> >>>settled point. > >> >> > >> >> > >> >> > >> >>------------------------- > >> >>Dr. Gerald J. Balzano > >> >>Teacher Education Program > >> >>Dept of Music > >> >>Laboratory for Comparative Human Cognition > >> >>Cognitive Science Program > >> >>UC San Diego > >> >>La Jolla, CA 92093 > >> >>(619) 822-0092 > >> >>gjbalzano(a)ucsd.edu > >> > > >> >-------------------------- > >> >Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA > >30332-0280 > >> >Associate Professor - Learning Sciences & Technologies. > >> >Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/ > >> >(404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu > >> >http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html > >> > >> > >> -- > >> > >> > >> > > > -- > >

2 1

Re: Lots of concurrency
by gf＠zchs.org 29 Oct '01

29 Oct '01

As at least one female philosopher (my wife) has observed, "Men are from Earth, women are from Earth. Deal with it." <G> Gary Fisher Russell Allen <russell.allen(a)firebirdmedia.com> wrote: > Hi, > > I like the way in which the squeak mailing list attempts to merge > concepts from outside the CompSci universe into discussions - recently I > have been intrigued by what other people are saying about how they > perceive music. > > For me, I can listen to music in the way which people are suggesting (as > a parallel series of notes - ie horizontally) or vertically as a > succession of sounds/chords, or I think, in whole number of other ways > less amenable to computing analogies ;). > > This, though, is just my experience. I could, for what it is worth, > tell the list about how I perceive music, and how this changes when, for > example, I am singing a solo. I wouldn't want to tell the list (without > some serious research) what all soloists think/experience when singing. > > I have a strong suspicion that this retisence should be carried over to > other sweeping generalisations: I know both male and female musicians > who can 'multitask' better than I can. Whether there is a fundamental > difference in brain make-up is still undecided; and "Men are from Mars > and Women are from Venus" is hardly a groundbreaking piece of either > sociology or biology. > > I am also faintly amused by the thought that I (a male) am commenting on > Justin (a male), who is quoting a book by John (a male) on the subject > of women's mentalities... > > Are there any women on this list? And if so, why not? What good is > programming for children of all ages if half the children are > uninterested or excluded? > > Russell >

2 2

RE: Lots of concurrency
by Jarvis, Robert P. (Contingent) 29 Oct '01

29 Oct '01

> -----Original Message----- > From: John Hinsley [mailto:jhinsley@telinco.co.uk] > Sent: Monday, October 29, 2001 3:45 PM > To: squeak-dev(a)lists.squeakfoundation.org > Subject: Re: Lots of concurrency > > > Maybe there's another book in this: "Men are from Microsoft, Women are > from Unix"? Ummm...no. "Men are from Unix, Women are from Macintosh. God only knows WHAT is with Microsoft...". :-) Bob Jarvis Compuware @ Timken

1 0

Corrupted sources?!
by Kevin Fisher 29 Oct '01

29 Oct '01

Hi Folks: I've been coding in the 3.1beta image with all the latest updates. I've never run into any troubles like this before...I've been able to browse any method I want without problems. Today, I wanted to look at Dictionary>>includesKey:. When I brought it up in the browser, I got a large message informing me that my SqueakV3.sources "may" be corrupt, along with an explanation about how this may have happened. The problem is, this is the -only- method this happens on (that I've encountered). The other methods in Dictionary don't have this problem. Also, this seems to be a Linux thing, as it doesn't happen on my laptop running Win98. I've been using this sources file through the entire 3.1 series without any problems whatsoever! Can anyone else out there running 3.1beta on Linux give this a try? Just click on Dictionary>>includesKey: in the browser... Thanks!

6 11

RE: How to learn Squeak
by G.J.Tielemans＠dinkel.utwente.nl 29 Oct '01

29 Oct '01

While waiting for Minnow when it was down I was thinking: After several tutorials in Squeak the big day comes: what do do next Learning Squeak on this level has for me (and maybe other newbies) two parts: 1. learning to express myself in OO design, developing a small program-idea 2. implement it in this Smalltalk dialect called Squeak. In the past we thought that you did first the design and then the programming details. Now we realize more and more that we as problm solvers jump between design and details, so if we could squeeze it together in one process, it would make a funny sound: "Squeak" If I try as newbie to structure this: I want to open a workspace for all my future thoughts and work in my first project. Then I realize that I should open a projectspace, not a workspace for that. Then my first choice: should I open a MVC-project or a Morph-project. (I choose Morph because it seems to offer more visual support-cues, am I correct?) Then I open a browser on my project canvas: All the classes and methods should be already there someone said to me... How many classes? how many methods???? where to start.. Back to my own ideas: I want to write down my first design-ideas, so I open inside my projectspace a..? ..a workspace for writing down all my free flow thoughts. How to keep overview, how to organise my thoughts... Is there a better way for organizing this logistic part of the design process? (I was thinking of a kind of book but the book misses several methaphor aspects I would wish: - a TOC which I would use as a first draft to do list, must also be possible to reshuffle it later as overview/design outline, - a summary-page to write down my first short intention, and check it now and then. - for every normal page a form with an intro, a paragraph structure and a bookmark option (for meta-thoughts) - .. and yes, also a free text search, like I have in a swiki.. well, should I use a swiki for this? no, not yet.. Maybe I should implement this designbook as "my first little project" first? (Becomes more complex then I first thought...) - For the big ones under you: a good used project-book could grow into a tutorial later.. Or, are there already design-organizers in Squeak? Lets look in the authoring tools first: not for this moment... must remember to visit this later... Back then to the world menu: Package Browser? looks more topic-oriented organized then the browser, helps me find easier? lets replace the general browser by this one on my project canvas. Method finder: lets open that, must be easier then finding the right class... Playfield options:.. graph paper? Nice, lets setup a grid, always easy during design of user-screens Flaps: lets turn all the flaps on for visual help cues when we get desperate. Projects??: what should be the meaning of project hierarchy? What I would like now fro the first round is an organizer that could help me to keep overview of my notes: - a stack of cards for writing down wished-user-scenario's for my idea - a stack of cards for suggesting objects (as candidates classes) for my design (Looks like I reinvent the Boost tool form Mark, would be nice to have that inside Squeak for a start..) But I want more: - a field on each of these last mentioned cards for possible soution-objects I spot in the squeak library. (I have to try them when i work on the details in that card, and then choose & change.) (Could I play this in a browser? ..on the left all the squeak classes, second column my project with it's candidates? Ok, but then: - how could I keep track of possible alternative classes? (AND the rejected candidates) - where do I leave my scenario-wishes, handling more then one object (or morphic representation of it). - how can I visualise the assemblage of all these projects in a final (program)draft: Seeing the browser inside the swiki gave a cue: I can open a browserview with only the classes I want to inspect (open with: with: with: etc..) and store this browser opening-script. - how can I check completeness - how can I organise distribution from this overall-view Did someone try such a thing already before? What is the URL?

3 2

Re: Squeak3.2a-4441.zip
by Bruce ONeel 29 Oct '01

29 Oct '01

Bruce ONeel <beoneel(a)bluewin.ch> wrote: > Hi, > Thanks to Henrik Gedenryd there is now a Squeak3.2a-4441.zip. > Thanks! Opps, on the FTP site in unstable-testPilot.

1 0

Squeak3.2a-4441.zip
by Bruce ONeel 29 Oct '01

29 Oct '01

Hi, Thanks to Henrik Gedenryd there is now a Squeak3.2a-4441.zip. Thanks! cheers bruce

1 0

Re: Lots of concurrency
by Ken Kahn 29 Oct '01

29 Oct '01

Andrew C. Greenberg wrote: > > I fear this debate seems to be taking an odd twist into irrelevancy. > While it may be true (indeed unsurprising) that human cognition can be > modelled most appropriately using concurrency; indeed of a promiscuous > nature, I do not see how this indicates or counterindicates that a > concurrent model is the best model for human cognition to specify the > execution of system. > I agree (and I started this subthread by writing "As an aside ... Minsky ... Society Theory of Mind ..." and placed that in square brackets). But I can see two ways it might be relevant: 1. One reason to give kids (and others) programming languages is to give them tools to think with. And one important thing to think about is how the mind works. If you read Descarte you see he (and many of his contemporaries) used the metaphor of a clockwork to understand the mind. If you read Freud you see he used a pneumatic model (presure builds up that must be released, etc.). Some recent posts to this discussion used the model of a collection of sequential threads to understand the mind. So if we think that one better understands the mind with a good concurrent computation model then all else being equal we should prefer languages based upon such models. 2. If you want to use a language to make AI programs then it is relevant. And I like the idea of having kids try to make simple AI programs. [clip] > > This is not to say that promiscuous determinacy doesn't also add > complexity -- it most certainly does. An example as trivial as the swap > operation of two values x and y, which is invariably modelled using a > temporary variable > > t := x; x := y; y := t > > introduces complexity unrelated to the problem. Indeed, Edsger Dijkstra > emphasized the problem of overdetermining code, favoring therefor the > language construct of the concurrent assignment, so swap can be > indicated thus: > > x,y := y,x > > leaving the more detailed sequencing to the "system" to sort out. The > problem here is that such nondetermincy is well-constrained and easily > implemented in worst case. The sequencing and protection of shared > resources in concurrent programs is far more subtle and problematic. > > My point is that while it is apparent that overdetermining code > sequentially often introduces levels of detail that precludes more > elegant expression of correct code, and sometimes distracts from best > ways to articulate the code, so, too, does expression of concurrency > introduce subtle unstated bugs and requires stating degrees of > sequencing, which are often harder to express than merely specifying the > sequencing in all its gory detail. > I'll agree with you and Dijkstra about overdetermining code (and I rarely agree with Dijkstra). Let's consider a simple case of what I think you are saying. Suppose you have a language where if you write "A, B" then A and B are run concurrently while if you write "A; B" they run sequentially. (If I remember right this is how Parlog from Imperial College worked.) Now suppose that A and B can't interfere with each other. The principal of expressing only necessary constraints (i.e. avoiding overdetermining code) would say you then write "A, B". But the problem here is that every time you write 2 lines of code you have to think "OK, do they interact?" and then use comma or semi-colon as appropriate. This is a cognitive burden. And the consequences for the two kinds of mistakes are very different. If you think they interact and they don't, then the code will still run - it is just overdetermined (well, actually you might have introduced deadlock). If you think they don't interact and they do, then you might have introduced a subtle hard-to-find bug. The solution to this that I prefer is to eliminate the semi-colon and only support concurrent composition. And then design the language so the consequences of pervasive concurrency are acceptable. I think this works in languages in which all shared state is encapsulated in objects, where threads and objects are one-to-one, and where all messages are asynchronous. Best, -ken kahn ( www.toontalk.com )

2 1

← Newer
1
...
6
7
8
9
10
11
12
...
60
Older →

Jump to page: