Squeak-dev May 1999

squeak-dev@lists.squeakfoundation.org

126 participants
289 discussions

Re: Squeak controlling a digital camera
by ohshima＠is.titech.ac.jp 22 May '99

22 May '99

Bob, > On Fri, 21 May 1999 23:33:36 +0900 ohshima(a)is.titech.ac.jp wrote: > >P.S. > > I couldn't figure out how to save a 16 bit depth Form in > >convenient way. Would anyone teach me? > > Isn't it just: > > f _ Form extent: 320@240 depth: 16. > f writeOnFileNamed: 'this is a form'. > > restoredF _ (Form collectionFromFileNamed: 'this is a form') first. I wonder what I have been doing... It surely works. And also 'Form class>>fromFileNamed:', which I once thought what didn't work, works fine. Anyway, thank you. OHSHIMA Yoshiki Dept. of Mathematical and Computing Sciences Tokyo Institute of Technology

1 0

Messaging *IS* a Mainstream Terminology
by agree＠carltonfields.com 21 May '99

21 May '99

Enough of this wordplay! Joachim's argument is rooted upon the proposition that Smalltalk programmers should use a mainstream terminology, which he insists prefers terms such as "function," and "method," to terms such as "messages," or "messaging," and since he feels that "message sends are just the same as functions." He provides no substantive reason why the term "function call" is better than the term "message send," apart from his insistance that the latter is disused in favor of the former. I have been unable to confirm his assertion. A review of object-oriented literature in my library suggests that opposite to be true: that "messaging" or "message send" is a mainstream (perhaps the) usage for the concept, and that the awkward phrase "member function call" isn't an overwhelmingly favored usage at all. Let us consider James Gosling's view, which casts a striking contrast to Joachim's: "If an object wants another object to do some work on its behalf, then in the parlance of object-oriented programming, the first object sends a message to the second object." James Gosling & Henry McGilton, The Java Language Environment, A White Paper, http://www.javasoft.com/docs/white/langenv/ (Section 3.2: Methods and Messaging). Q.E.D. Certainly it is true that some formal language specifications do use terms other than "message send," or "message passing" to define particular syntactic constructs in particular languagea, such as C++ which uses the term "member function calls" (and which is expressly distinguished from mere "function calls"). On the other hand, as I passed through a small sample of books at hand in my library talking about actually programming or designing using C++, each reverted to the more traditional messaging terminology. Now, in the sense of full disclosure, I have done far more practicing of law than hacking since I left graduate school and since I sold my software publishing businesses. Accordingly, my libraries haven't been kept entirely up to date. It may be that the more traditional uses have ultimately been usurped and wholly preempted by the term "member function call." However, all indications appear to be to the contrary.

2 1

Re: Messaging vs. subroutines (changed/update problems)
by Joachim Durchholz 21 May '99

21 May '99

Peter Smet wrote: > > I notice that in Java objects lock their state > until all dependents have received their changed notification. Isn't this limited to inter-process calls? (Not sure about what Java really does in this context.) > This seems to reduce, but perhaps not elimate the problem. Hm. It should make the problem obvious (by locking up the program, or throwing a deadlock exception, or whatever Java does in case of such an error), but it won't prevent it in the first place. > Some objects may receive a changed notification and then query the > changed object about what exactly changed. Before they get a chance to > send their query, the sender may change state several times. > > Circular updates can result in loops that never terminate: > > loopy variableA: newValue. > variableA := newValue. > self changed: #variableA > > loopyListener update: symbol > symbol == #variableA ifTrue: [loopy variableA: newValue]. > > Oracle solves this with a rule that an Object (a table in this case) > that has triggered a change notification puts itself into a "mutating" > state, and cannot do any more triggering until the first change > notification is completed, and its state is no longer "mutating". This > mechanism should prevent all endless message loops... At the expense of possibly missing an update in the case of notification circles. I think update circles are a program error, and should be reported as such. > Synchronization is a difficult area, but one that Squeak will need to > address sooner or later. Multithreading and distributed objects are > the direction that things are heading in . Agreed. Regards, Joachim -- Please don't send unsolicited ads.

1 0

Re: Messaging vs. subroutines
by Joachim Durchholz 21 May '99

21 May '99

"Michael S. Klein" wrote: > > > > I would argue that the fundamental point of Smalltalk is that all > > > of computing can be boiled down to entities passing bits of > > > information to each other. > > > > So do subroutines. Or any other information-passing mechanism. By > > the above definition, *everything* is a message send. > > Subroutines have no identifiable entities that exchange information. They have. A subroutine invocation is such an entity. Consider recursive calls. > Lets not degenerate into the old Turing-equivalency points, > clearly everybody in this thread understands this, after all, > its really all just electrons whizzing about. Right. However, I think that saying "computing boils down to entities passing information" is similar to the Turing equivalence thing. I hope I have made my point a bit clearer. Gosh, I'm enjoying this. I've had more new insights forming inside my head in this discussion than otherwise in the past year. I'm having trouble giving each new insight a proper wording on the first attempt; I apologize for any misunderstandings that this causes. I can just hope that I'm providing a sharpening stone for your ideas, so you can find the best argument easier when the next dummy comes along. :) > What are the properties of subprogram invocations that are relavent? > Where are the computational models similar, and where are they > different? It's pretty clear that subroutines, methods, and macros are > *all* examples of subprograms that "exchange" information. > > Of course, if you want to just ramble away, here's a pointless > question: > > Which rings truer: > Messages are just subroutines. > or > Methods are just subroutines. > ? Not pointless. The analogy pairs methods with subroutines and messages with subroutine signatures (I *know* the subroutine things aren't the same as their Smalltalk counterparts, even if there's a fairly large overlap). > Normally, I wouldn't even enter this thread, but I'm on a job > where the only programmers are using BASIC. Don't tell me > that a message send is just GOSUB. Blarch! Urk. Don't name such ugly things. Pleeease... Regards, Joachim -- Please don't send unsolicited ads.

1 0

Re: Messaging vs. subroutines -- This is silly
by Joachim Durchholz 21 May '99

21 May '99

"Andrew C. Greenberg" wrote: > > Joachim writes: > > >A method is a subroutine. > >A message send is a plymorphic selection, followed by a subroutine > >call to the appropriate method. > > We've heard this before. Sorry for repeating myself. I was trying to clarify a point to Randall. > Even taking this as true, it proves the point at least from a logical > as well as a pedagogical point of view. Logically, its sophistry to > assert that anything comprising two distinct substantive parts, can be > "just the same as" only one of its parts? Pedagogically, its > important to understand a composite concept, not only as defined by > its respective parts, but also as the gestalt that is sometimes more > than the sum of its parts. Fully agreed. The thing that I'm storming against is that Smalltalk literature tends to present message sends as an atomic concept, not as a composite one. This hampers understanding for those who already know a component. Besides, those who didn't have exposure to the component concepts will continue to think that message sends are a monolithic concept, and be unable to follow if people from a different background start talking about such a component. They'll just assume that the outsider got it wrong... it's the same sort of mistake as saying that Smalltalk is lacking static typing. That the sum is more than its parts is also true. I don't say that message sending is "nothing more" than the two components that I have listed - conceptually. I think message sends should be explained both ways: As a composite of more primitive operations, and as a new whole with new applications that the primitives alone cannot accomplish. As I wrote elsewhere, I think both views are valuable. The more views of an operation you have, the more you can vary its use. And that's extremely useful if you have a design problem to solve. Regards, Joachim -- Please don't send unsolicited ads.

1 0

Re: Squeak controlling a digital camera
by Bob Arning 21 May '99

21 May '99

On Fri, 21 May 1999 23:33:36 +0900 ohshima(a)is.titech.ac.jp wrote: >P.S. > I couldn't figure out how to save a 16 bit depth Form in >convenient way. Would anyone teach me? Isn't it just: f _ Form extent: 320@240 depth: 16. f writeOnFileNamed: 'this is a form'. restoredF _ (Form collectionFromFileNamed: 'this is a form') first. Cheers, Bob

1 0

Re: Yes! Acorn dynamically loadable plugins!
by John.Maloney＠disney.com 21 May '99

21 May '99

Tim, This is terrific! I know how painful this can be. I had to really struggle to get it working on the Mac. There, the situation was especially annoying because the 68K didn't originally support dynamic linking. It was added to the 68K as an afterthought, but there are all sorts of complications such as not being able to build a "fat" (68K and PPC) DLL. Since the VM it itself a DLL, that means we can no longer have a single "fat" Squeak VM. And, of course, it is hard to discover what you need to know by reading the documentation... Anyhow, I'm glad you drove through your RiscOS difficulties and got it working. Congratulations! -- John >I'm sure it will make most of you yawn, but I have to shout it somewhere - >_finally_, I can do dynamically loadable VM plugins on RiscOS. I still have >to try to unify 'internal' plugins into the mechanism, but it actually >loads the GSM codec plugin, sets up the interpreter and finds/execute the >new state prim. >Why has it taken so long? Well, RiscOS just doesn't normally work that way >- the OS equivalent of plugins/dlls uses runtime binding via names, not >function addresses or anything like that. Many thanks to Ben Summers who >managed to work out the mechanism to allow this. > >You can go back to sleep now... > >-- >Fractured Idiom:- FELIX NAVIDAD - Our cat has a boat >Tim Rowledge: rowledge(a)interval.com (w) +1 (650) 842-6110 (w) > tim(a)sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>

2 1

RE: Messaging vs. subroutines -- This is silly
by Jarvis, Robert P. 21 May '99

21 May '99

I'd say people are uncooperative parallel automata. :-) Bob Jarvis The Timken Company > -----Original Message----- > From: Michael S. Klein [SMTP:mklein@alumni.caltech.edu] > Sent: Friday, May 21, 1999 10:41 AM > To: squeak(a)cs.uiuc.edu > Subject: Re: Messaging vs. subroutines -- This is silly > > > >A message send is a plymorphic selection, followed by a subroutine call > > >to the appropriate method. > > > > Does this mean that you couldn't have a distributed implementation of > > Squeak where objects were people, methods were instructions for them to > > follow, and messages were emails? > > > Are people cooperating sequential processes or what?

1 0

Re: WeakArray and triggering events....
by Peter Smet 21 May '99

21 May '99

Ok, Here is a change set that implements publish-subscribe as described below for Squeak. I would really appreciate it if some people could file it in and take it for a test-drive. It seems to work fine for me at this stage, but I'm sure the code could be greatly improved. Lets put this open source stuff to the test - I would much rather that other people hacked into this code and improved it instead of working on it independently. Most of the code is in the class PostOffice under Publish-Subscribe, but some is in Object under the protocol Publish-Subscribe. Here's an extract from my original post: " I have been trying to implement a publish subscribe mechanism along the lines of Dolphin and VW. With it, any object can trigger events such as Transcript trigger: #bang. an interest in events is registered by the message: Transcript when: #bang send: #run to: self etc. The disadvantage of publish subscribe is that you must explicitly deregister objects from the mechanism for them to be garbage collected. I have tried to get around this by using weakKeyDictionaries to hold both the publishers and the subscribers. If there are no remaining references to either the publisher or the subscriber, these will be garbage collected, and no events will be passed to these deceased objects. " Peter Content-Type: application/octet-stream; name="Publish-Subscribe.21May412pm.cs" Content-Disposition: attachment; filename="Publish-Subscribe.21May412pm.cs" Attachment converted: Anon:Publish-Subscribe.21May412pm.cs (????/----) (0000A767)

2 1

WeakArray and triggering events....
by Peter Smet 21 May '99

21 May '99

Finally, My squeak image is running merrily in the background, doing lots of event triggering and shunting messages everywhere. The event system seems to be working, thanks to the help of Bob Arning and Andreas. I fixed the synchronization as suggested, by subclassing WeakRegistry, and making nearly all access via the protected: block semaphore. Now I can create a stream of publishers and subscribers, run them in a process, and these will be automatically garbage collected, with no apparent synchronization problems. The only time problems occur is when I break out of loops and the FinalizationProcess is broken (could this be fixed by the exception mechanism of Tim?) I will tidy up the code and post a change set soon for anyone interested in VW-style triggers. Thanks again... Peter

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
29
Older →

Jump to page: