Squeak-dev June 1999

squeak-dev@lists.squeakfoundation.org

139 participants
408 discussions

Re: [BUG] Celeste and Scamper.
by Lex Spoon 24 Jun '99

24 Jun '99

Looks like the server or the network was being slow. Maybe Outlook is more patient? What if you try it again? If that doesn't help, try opening up a Transcript and getting a little more info on what is happening. POPSocket seems to think, in your example, that you have successfully logged in, so it either made some progress or fooled itself into *thinking* it had made some progress. Lex "Ian Trudel" <ian(a)monk.cgocable.ca> wrote: > Hei, > > I was messing around scamper and celeste today, and I have found that I > cannot access to my email server (currently MailGear on NT meanwhile our > other Linux server is brought back) which is on this computer. I have > succefully accessed to other email servers though. So, since I could not > login to my mail server locally, I have decided to try the web based (such > hotmail) one provided with MailGear. I have then discovered that Scamper > does not provide support for password fields, I see instead [form input of > type: password]. > > Ooops, meanwhile typing this email I have retry to deliver you the debug > log. But Celeste worked fine. Anyway, I have found the first log. (Btw, when > the error occured I could download my mail from Outlook but not Celeste) > > no response from server > 24 June 1999 12:08:12 pm > POPSocket(Object)>>error: > POPSocket(SimpleClientSocket)>>waitForDataQueryingUserEvery: > POPSocket(SimpleClientSocket)>>getResponseShowing: > POPSocket(SimpleClientSocket)>>getResponse > POPSocket>>numMessages > MailDB>>fetchMailFromPOP:userName:password:doFormatting:deleteFromServer: > Celeste>>fetchMail > Celeste>>perform:orSendTo: > [] in MenuMorph>>invokeItem:event: > CursorWithMask(Cursor)>>showWhile: > MenuMorph>>invokeItem:event: > [] in MenuItemMorph>>mouseUp: > UndefinedObject>>ifNil: > MenuItemMorph>>mouseUp: > HandMorph>>handleMouseUp: > HandMorph>>handleEvent: > HandMorph>>processEvents > [] in WorldMorph>>doOneCycleNow > Array(SequenceableCollection)>>do: > WorldMorph>>doOneCycleNow > WorldMorph>>doOneCycle > [] in Project>>spawnNewProcess > [] in BlockContext>>newProcess > > ---------------------------------- > Ian Trudel > Email: ian(a)monk.cgocable.ca > URL: http://monk.cgocable.ca/~ian/ > ----------------------------------

1 0

RE: Thoughts on the nature of programming...Asynchronous Events
by Peter Crowther 24 Jun '99

24 Jun '99

> Selfish individuals have discovered that they can make > money by selling bread to their neighbours. And that is ALL it takes. The > consequence of all these millions of combined selfish actions is that New > York benefits immensely, and is able to coordinate it's bread supply and > demand effortlessly. I would take issue with the ideas that New York 'benefits immensely' and 'effortlessly'. The effort required is distributed among many individuals rather than concentrated among a few, but the overall effort required to supply New York may be greater in the distributed case than in the centralised case. There's also the possibility of local maxima developing; you might be on top of one 'hill' of benefit now, and there might be a very different system that would be much more beneficial to suppliers and consumers alike (a 'mountain'), but the distributed, evolutionary supply system would never be able to get there as there is a period of less benefit (a 'valley') on the way. Central control can move such systems, otherwise you have to 'tilt the playing field' by central intervention such as taxes and subsidies to get the mass of individually evolving bread suppliers to move across something that is no longer a valley to the more optimal system. Interestingly, Dawkins hasn't really considered environmental change in this way in any of his books [that I've found] so far. No doubt he will. > There is no committee (apologies to Squeak central) that > determines what the architecture of Squeak will be. No, but merges into the Disney releases do tilt the playing field. - Peter

1 0

RE: Some bizarre thoughts on the nature of programming...
by Peter Crowther 24 Jun '99

24 Jun '99

> A baseball is an "inert" object > that doesn't know anything about any other objects, and yet it seems to > respond properly with everything else in its environment. On the contrary. Both the 'baseball' and the 'everything else' here are macroscopic generalisations of particular configurations of basic particles [whatever they eentually turn out to be, but let's call them Atoms for now]. Atoms 'know' about electroweak theory, strong nuclear force, gravity, and quantum physics --- the first three of which are ways in which atoms *have* to know about other atoms, potentially some distance away. These systems are certainly not inert. > I think it might interesting to consider an object oriented system that > models the "inert" object approach for all objects. Model at a low enough level and you can do this. But your model rapidly outstrips available computing power. Or you abstract a notion of 'baseball' out as a geeralisation, at which point you also have to abstract out all sorts of notions about how the class of baseballs interact with the class of humans. - Peter

1 0

RE: Thoughts on the nature of programming...Asynchronous Events
by Peter Crowther 24 Jun '99

24 Jun '99

> Well each object would have some proximity factor to all other objects in > the system. What proximity factor, how set, how derived, how calculated? Seems to me the coupling is being arrived at by the back door of object positioning within some multidimensional structure --- in the same way that one's head is coupled by proximity to one's body. If the two are separated in space, the overall system fails catastrophically. What's more, the coupling is present at decreasing strength throughout the entire system. Here, affecting any one object potentially affects all other objects in the system. They're all married together --- for better or worse, richer or poorer, in sickness as well as the undoubted initial health. > If it worked, the browser would suddenly be much more robust. No it wouldn't --- if it were written in this system, potentially moving or otherwise operating on *any* *one* other object in the system would disrupt the event propagation within the browser's own code. The whole system would be robust in the sense that *something* would keep happening, but you now have the distinct possibility that the browser would fail due to editing the 'code' of an 'object' on the other side of the system. Or you accept the very non-Smalltalk idea that the browser is outside the system being studied. - Peter

1 0

Re: ObjectExplorer
by merlyn＠stonehenge.com 24 Jun '99

24 Jun '99

>>>>> "Pablo" == Pablo S Shmerkin <pabloseb(a)ciudad.com.ar> writes: Pablo> Ops... my previous message was intended for Bob Arning, not the list... Pablo> Regards, Reply-to bites again. Who needs more proof that "reply-to" is evil? <sigh> -- Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095 Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying Email: <merlyn(a)stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn(a)teleport.com) Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A> Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

2 1

Re: Thoughts on the nature of programming...Asynchronous Events
by Peter Smet 24 Jun '99

24 Jun '99

Marcel, These are very interesting thoughts. I hadn't really thought through that having mobile neighbours also means that you need to dynamically calculate them. >Multicast to a dynamic group is the next step: > > self neighbours doSomethingInteresting:fascinatingArgument. > >(assuming that neighbours is in fact computed dynamically) A ripple >effect would be: > > self neighbours doSomethingInteresting:fascinatingArgument. > self neighbours neighbours >doSomethingInteresting:fascinatingArgument. > self neighbours neighbours neighbours >doSomethingInteresting:fascinatingArgument. > ... Does the rippling need to work like this? This may be reaching too far, since the object is now telling objects 2 or more layers away about events. I was assuming that the ripple effect would emerge from the neighbours doing something with the event, and then emitting (perhaps different) events onto their neighbours, and so on. This whole thing is starting to look a bit like a neural net of some sort... Since the reaction to events depends on the position and arrangements of objects, objects may need a 'learning period' during which they shuffle around until they reach some sort of equilibrium. I was thinking of the steps as: The event happens at location x,y. The objects immediately around the event are notified. The objects do their thing. Doing their thing may involve moving themselves, or even moving their neighbours. The objects dynamically calculate who their neighbours are, and may or may not pass an Event onto them. The whole thing repeats for the next layer and so on. The stepping is a bit artificial, really everything should be happening simultaneously, but I find that too overwhelming to think about. I havent had time to look at the links yet, but it looks like interesting stuff. Peter

1 0

Garbage Collection catch-22 with blocks
by Peter Smet 24 Jun '99

24 Jun '99

Hi all, Here's my dilemma. I am trying to implement anObject when: #anEvent do: aBlock using weak references. I am using a global collection to hang on to all of these objects and their events. So, I need to hold onto an Object, and I need to hold onto the block that the Object wants evaluated some time later. The most straightforward thing is to put the Object in a WeakKeyDictionary, as the key. If I don't use a strong reference to the block, the block will get garbage-collected. This forces me to keep a strong reference to the block somewhere. And now here is the catch. The block contains a strong reference to the object in my WeakKeyDictionary (since that is its home context). This defeats the WKD, since my object will now never get garbage collected. It will always have at least that block home variable pointing to it. Are there any elegant solutions to this? One is to force the Object to have an instVar pointing to the block, then the block itself can be stored in a WKD, but this is kind of ugly. I have thought about setting the home context to nil, and restoring it when the block needs to be evaluated, but this too seems ungainly. Has anyone solved this circular reference problem before? Are there any better alternatives? Peter

1 0

Re: Thoughts on the nature of programming...Asynchronous Events
by Marcel Weiher 24 Jun '99

24 Jun '99

> From: "Peter Smet" <peter.smet(a)flinders.edu.au> > > Not only is 'locality multicast' more biologically plausible, it is much > more efficient to implement than a global broadcast mechanism. The problem > still is that 'ripple effects' will be substantial. Since the whole thing is > happening asynchronously, it becomes a nightmare to predict the sequence of > events. But perhaps this is exactly the point - let the local interactions > happen, and the global consequences will take care of themselves. The software architecture people have been doing research on implicit invocation: http://www.cs.cmu.edu/afs/cs/project/able/www/paper_abstracts/implinvoc-fse… Another issue with "broadcast" in Smalltalk is that there is no syntax for it. You can only send a message to a single named entity, though that entity can be a proxy for a collection of objects ( collection + trampoline ). This is multicast to a static group. Multicast to a dynamic group is the next step: self neighbours doSomethingInteresting:fascinatingArgument. (assuming that neighbours is in fact computed dynamically) A ripple effect would be: self neighbours doSomethingInteresting:fascinatingArgument. self neighbours neighbours doSomethingInteresting:fascinatingArgument. self neighbours neighbours neighbours doSomethingInteresting:fascinatingArgument. ... Although this looks like it will first compute the neighbours and then send the message, an iterator based implementation could actually send the messages incrementally as the (expanding) list of neighbours is computed. The rippling effect is actually a higher order effect that could again be captured by a message: self probe neighbours doSomethingInteresting:fascinatingArgument. #probe keeps applying the #neighbours message to the results of the previous #neighbours send, and applies the "interesting" message to each result. ( Note: the common, symmetric interpretation of neighbours would in this case lead to non-termination of the example, but that can be fixed by either a more limited view of neighborhood or a sufficiently smart #probe method, or by running the example on suitably rigged slide projector :-)) ). Again, an iterator based implementation does not have to compute large collections of intermediate results but can proceed to send messages one by one (at least in principle). (Just thinking: tree traversal := self probe children doSomethingWithTreeNodes ) Marcel

1 0

Re: QKS SmallTalk Agents
by Bruce ONeel 24 Jun '99

24 Jun '99

Hi, I talked to them at OOPSLA '98 and the sales person didn't seem to want to mention the mac :-( but she was very interested in pushing the windows version. Oh well... cheers bruce "Jeff Szuhay" <jeffs(a)pstnet.com> wrote: > visit <http:/www.qks.com/> > for news of their upcoming release > > beta 3.0 is for Windows only. > Mac version seems stuck at 2.2 :-( > > > --************************************************** > Jeff Szuhay <mailto:jeffs@pstnet.com> > Lead Macintosh Engineer voice: 412/271-5040 x227 > Psychology Software Tools <http://www.pstnet.com/>

1 0

ObjectExplorer
by Bob Arning 24 Jun '99

24 Jun '99

ObjectExplorer offers a hierarchical alternative to #inspect. Nice when you need to dig deep and don't want a lot of windows opened. http://www.charm.net/~arning/ObjectExplorer.21Jun359pm.cs Cheers, Bob

3 2

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

Jump to page: