Squeak-dev June 1999

squeak-dev@lists.squeakfoundation.org

139 participants
408 discussions

Upload swiki feedback
by Peter Smet 25 Jun '99

25 Jun '99

Re attachments to swiki pages. This may be useful to others. Uploading files named : Publish-Subscribe.24Jun119pm.cs Dependents.15Jun332am.cs Caused 'file not found' problems in the links Renaming to: Publish.cs Dependents.cs fixed the problem. I don't yet know if this relates to multiple dots, or just the length of the names. It may be helpful to put a 'managing attachments' link up at the swiki. Peter

1 0

Re: Screenshots
by Peter Smet 25 Jun '99

25 Jun '99

Stephen Pair wrote: >I just noticed that it's my screenshot (I didn't know it had been >linked)... Sorry Stephen, that was me. I am just stunned at how that screenshots page has taken off! But I agree with Bob and others, we need to spread it across more pages and provide thumbnails. Can I also ask if anyone puts up a screen-look that is derived from a change-set, that they also provide a link to the change set? (Which means I'd better do that for my screen :-) Peter

1 0

Re: ORBs
by Peter Smet 25 Jun '99

25 Jun '99

Stefan, First of all, thanks a lot for looking into this in so much detail! >Last weekend, I looked into the fly-by-wire ORB code and franky, I was a >bit disapointed. It's written in a way I wouldn't do such a thing (a >questionable design IMHO) and the whole concept is extremely inefficient. Hopefully you now have the modified connections.cs framework that I posted. This should be a little closer to what we are trying to achieve. I agree that it's still a long way from being an ORB, but we need to start somewhere. At this stage the socket connection works, you can create remote objects and send messages to them via a remoteProxy. The remote object also sends back return values (objects) via the ORB. >The RemoteObject class should be a real proxy thing. Instances of >RemoteObject should behave exactly as the original object they represent. >Therefore, it must not implement #class. It should have no methods that >might shadow original methods, for example #session. Of course, debugging >support could be an exception. The way to go is to subclass RemoteProxy from nil, but not now. Subclass it from Object for debugging purposes. >RemoteObjects know a session (actually an ORBClient instance) and have a >(hopefully unique) name. No proxy can't be without a name. The proxy's >#doesNotUnderstand: method forwards any messages sent to the proxy to the >session which in turn will forward the message send, encoded as BOSS >(VisualWork's binary object storage format), to the ORBServer instance. Speaking of performance bottlenecks, someone on comp.lang.smalltalk gave me an excellent hint. Everytime the Proxy goes through doesNotUnderstand:, it builds the method it does not understand. It will then implement the forwarding code directly the next time the method is called. This should save heaps of method lookup time. (Is there any other language that can dream of doing such things? - only in Smalltalk). >However, I don't undestand why both client and server will communicate in a >pseudo-asynchron manner. All communication happens in new forked processes >using thread-unsafe queues which are then polled. Using lots of forked processes is a sure way to run into bugs early. The current version uses blocking calls for now. >The classes ORBConsole, ORBDialog and ORBWorkspace are just for the GUI >- which is unfortunately tightly bound to the rest of the ORB code. >However, the GUI looks really nice (I tried the code on VisualWorks). >IndexedQueue and StringBOSS are helper classes. ORBRemoteInterface offers >a restricted interface to class ORB which can be accessed remotely. I ran it in VW too, which gave me the inspiration. The UI is nice, but right now I can see everything I need to see just with inpectors on the ORB and the Proxy. As an experiment, I created a remoteProxy that represented the Sensor in another concurrent image. By saying Sensor := remoteProxy I was then able to click in one Image but drag windows around in the other image. (Not terribly useful I know, but I got a kick out of it). >So here is my sketch of an ORB; you could actually call this lightweight RMI >(remote method invocation), as the idea is similar to the Java solution: > >Each image has an ORB which can contact ORBs of other images using a direct >socket connection. An ORB is identified by a host name and port number pair. > >Each ORB keeps track of all objects which are known by other images. These >are the owned objects. It also keeps track of all proxies (or stub or >shadow or remote objects) which exist for other images' objects. (Let's >ignore distributed garbage collection for now.) > >A proxy knows its UID and the image's orb. It is implemented as an object >without a superclass which understands just the bare minimum of messages >and forwards all unknown messages via its orb to the real object. This >should be completely transparent to the user. Agreed - the transparency is essential. >The server will lookup the receiver object using the OID and will then >perform the selector. Argument data are copied by value for "primitive" >data like numbers, strings or symbols. >For the binary encoding we need a simple encoding for all primitive >types and arrays. We also need an encoding for proxies and remote calls. >This encoding is much simpler than any existing BOSS or ReferenceStream >system. (Optionally, complex objects could be copied by value, but that's an >extension.) I have just used ReferenceStream at present. How would you deal with things like Dictionaries being returned from method calls? >In the meantime, I started to implement this idea - first in Squeak but >when I noticed that using Sockets wasn't as simple as I hoped, I finished >it in Java. Go back to Squeak, the connections stuff takes care of all the socket details, including default time outs. PS I have set up a new project page on the Swiki for this stuff. Please put up links to any relevant code there. (The link is broken, but I will fix it soon) Thanks again - this is excellent.

3 2

Re: RE: Screenshots
by Doug Way 25 Jun '99

25 Jun '99

On Thu, 24 Jun 1999, Bob Arning wrote: > On Thu, 24 Jun 1999 17:42:22 -0400 "Stephen Pair" <spair(a)advantive.com> > wrote: > >I was interested in the following things that I saw: > > > >1. Syntax highlighting > > Curiously enough, that is available in squeak. Use the shifted yellow > button menu in a browser text pane, choose pretty print and keep the > left shift down til the code changes. I don't know if that's exactly > what was used in the picture, but it's certainly similar. I think he might be referring to the syntax coloring. On the swiki Goodies page, there's the following link for 2.x syntax coloring: http://home.munich.netsurf.de/Helge.Horch/SqueakSharesSoar.html > >3. Whisker > > That's Doug Way - check > > >http://www.mindspring.com/~dway/smalltalk/incomplete/Whisker-dew.someDateEtc Yeah, it's not really ready for prime time yet, though. You can try it if your curious. Anyway, Whisker is the name of a new Smalltalk browser I'm working on. For more info on what it should eventually be able to do, see: http://www.mindspring.com/~dway/smalltalk/whisker.html - Doug Way dway(a)mat.net

1 0

Some bizarre thoughts on the nature of programming...
by Peter Smet 24 Jun '99

24 Jun '99

Since this list is pretty diverse and the topics are wide ranging, I'd like to throw up some thoughts that have nothing whatsoever to do with Squeak. Programming is fundamentally wrong. It asssumes some kind of central controller organizing a sequence of events to get the correct outcome. OO helps a little in this regard, but not much. OO helps to decentralize some of the behaviour. The reason programming is fundamentally wrong is exemplified in the following scene: <Scene I> Two giraffes conversing on the Serengeti Bob: God, I am so pissed off! Stretch: What is the problem? Bob: It's this new neck architecture - It's just not working out. The deltoid muscles are connected to the diopter structure and the two just keep interfering with each other. At random times my entire neck just flops over, and yesterday Guzzie had to kickstart me... Stretch: Well, what are you going to do? Bob: What any self-respecting Giraffe with a degree in Computer Science would do..Throw myself back into the primordial slime and start over again with a fundamentally better architecture.... We leave Bob and Stretch there, although it must be said that Bob came to regret his decision when he later evolved into a python. My point is that somehow complex organisms never had to abandon their previous building blocks, and managed to evolve layer after layer of complexity. How did they do this? Evolution is the ultimate component reuse. What makes biological things so different from e-things? Can we mimic what evolution does in some sense? I don't have any simple answers, but let me throw up some scenarios. The garbage collector, and a disk defragmenter. These are good examples of central control. Evolution would shun these two designs and throw them into the vat of useless mutations. What would evolution do here? Well, a slightly unstable programmer might say, why not take OO to its logical extreme and make every memory cell (or disk fragment) responsible for it's own behaviour. Each disk fragment constantly looks at the fragments around it (and only those fragments) and has only one (utterly selfish) behaviour. It moves towards fragments that resemble it. In the case of the memory cell, it's behaviour is to move to cells that point to it. Memory cells with no friends simply die. The funny thing is, these utterly simple, stupid and selfish behaviours will bring about exactly those properties we desire. <Scene II>A computer scientist in the tropical Amazon Basin region. Flabber: My God, check out this amazing termites nest! Layered tunnels, different compartment structures, it's even angled right to reflect the sun's heat perfectly. And the discipline of all the different casts and the way they cooperate.... Flabber spends the next 10 years of his life fruitlessly attempting to locate the 'architect ant' that must surely coordinate the nest building. At least he gets funding from the NIH. Slime moulds, schooling fish, mandelbrot sets and bird's nests are all great examples of trickery. They are not complex at all. Even the ultimate jewel, the brain, may very consitute only a facade of complexity. To be continued.... Peter

3 2

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

24 Jun '99

Marcel, I'm tempted to agree with you. I was implementing this for compatibility with another events system. I'm not sure if blocks are evil, but what is evil is the way they are not encapsulated. Hanging onto variables from the home context etc. Why not just have clean blocks with their own variables etc? Then you can treat them as true objects. > >This is probably not what you want to hear: but how about simply >abandoning anObject when: #anEvent do: aBlock? > >I think Squeak is trying to tell you something: Blocks are evil :-) > >Marcel >

3 2

Re: Screenshots nice, but...
by Doug Way 24 Jun '99

24 Jun '99

It looks like the GaTech swiki is down right now. Probably a bunch of people saw your posting and went to go look at the bandwidth-eating screenshots page (including myself), bringing the swiki to its knees. :-) I think either thumbnails, or even just links to individual screenshots are probably needed. If I have time tonight I might go through and convert them to thumbnails, and provide links to the actual screenshots on separate swiki pages. (Or someone else could do this if they're in the mood.) - Doug Way dway(a)mat.net On Thu, 24 Jun 1999, Bob Arning wrote: > To those who have placed the many interesting screenshots on the swiki, > thanks. It would be nice, however, to consider those with limited > bandwidth connections. The current page takes *forever* to load over a > dial-up line. Could we think about: > > - thumbnails pointing to the fullsize beaties? > - fewer per page? > - smaller and/or lower resolution? > > Those with high-speed connections may be very impressed, but others > (myself included) may be reaching for the stop button. > > Cheers, > Bob > >

1 0

[BUG] drawing translucent text
by Bob Arning 24 Jun '99

24 Jun '99

Changing a TextMorph from opaque to translucent changes the position where the text is drawn. This effect can be seen by creating a new TextMorph. Open an inspector on this morph and in the inspector alternately evaluate: self color: (Color black alpha: 0.5) and self color: Color black Wonder of wonders! The text moves when the color changes! After much poking around, I have discovered that CharacterScanner>>scanCharactersFrom:to:in:rightX:stopConditions:displaying: fails the primitive (103) whenever translucent text (combination rule 31) is drawn. What causes the shift in position is that destX is incremented by the width of the first character even though nothing has been drawn. The Smalltalk code after the primitive then begins drawing the entire string from the wrong position. My guess is that the error lies in BitBltSimulation>>copyBits in the fragment below: (combinationRule = 30) | (combinationRule = 31) ifTrue: ["Check and fetch source alpha parameter for alpha blend" interpreterProxy argCount = 1 ifTrue: [sourceAlpha _ interpreterProxy stackIntegerValue: 0. (interpreterProxy failed not and: [(sourceAlpha >= 0) & (sourceAlpha <= 255)]) ifTrue: [interpreterProxy pop: 1] ifFalse: [^ interpreterProxy primitiveFail]] ifFalse: [^ interpreterProxy primitiveFail]]. which is sent from BitBltSimulation>>scanCharacters in the fragment below: scanDisplayFlag ifTrue: [self copyBits]. destX _ nextDestX. interpreterProxy storeInteger: BBDestXIndex ofObject: bitBltOop withValue: destX. No test is made here for the #copyBits failing, so destX gets updated even though there was nothing drawn. Since the above code is in the VM, it's a bit hard to debug. While a patch could be applied at the Smalltalk level (wrapping the primitive 103 in another method which would preserve destX in the event of failure), it would be better if the VM could be fixed. I also do not know if this probelm appears under other circumstances (like non-text drawing). Cheers, Bob

1 0

[BUG] Celeste and Scamper.
by Ian Trudel 24 Jun '99

24 Jun '99

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: ORBs
by Lex Spoon 24 Jun '99

24 Jun '99

I think that RMI in Smalltalk, as you describe, isn't that hard to do in Smalltalk . The harder part is doing it well :). Do you allow any asynchrony? How do you deal with nodes disappearing and returning? How about migrating frequently accessed objects around the network? Well, if you do that, how do you deal with different versions of classes? And how do you deal with security in all this mess? You have problems both in connecting to the right node, and in limitting those nodes in what they can do. Anyway, I did a basic RMI system for Squeak as a class project last quarter. I hadn't mentioned it because, well, it's just a toy. But maybe a toy is at least interesting to some people out there. I've stuck it at: http://www.cc.gatech.edu/~lex/7431/ The writeup is writeup.*, and the code is in the two .cs files. It should appear at 6:00am EDT tomorrow morning. Now, this is not a great system. But it does work. A few aspects of it: 1. The basic mechanism is the one being bantered around: use a RemoteObject proxy, which triggers on doesNotUnderstand: to talk to a "registry" object which in turn sends requests across the ntework. 2. Only primitive data types actually get passed across the wire (smallIntegers, characters, symbols, floats, maybe one or two others). All other objects are passed by reference. 3. The proxying is asynchronous by default, but I put some work in to make a synchronous option on top of it. That is, if you do "x := remObj foo", then the #foo message goes over the wire, but x becomes immediately useable even without waiting for #foo to come back. But you can do "x stabilize" to make x wait for its result to finish computing, and you can do "x synhcronize" to accomplish this recursively. This latter is a good idea when you pass something into code that isn't prepared to deal with asynchronous execution. Some things are missing: 1. There is no provision for hooking up the systems or assigning node id numbers. You have to hook it up by hand. It shouldn't be tough to stick something on top of the basic system, however. 2. Crashes and security aren't even remotely considered. These things probably require fundamental reconsiderations. 3. I never worked out how to do any kind of garbage collection, not even reference-counting. Reference counting I think would not be too hard, if one takes advantage of the finalization support, but general garbage collection would take some serious thought. Anyway, I hope some of you find it interesting. From reading comp.lang.smalltalk, the older Smalltalkers have probably seen and implemented similar systems a million times. For myself, the project convinced me to stick with old fashioned sockets for now--"transparent" message proxying just isn't actually all that transparent unless you have a well developped system. The system here (and most I've heard of) are reminiscent of installing stuff on MS Windows: anyoud get all these cheezy "isn't everything easy" messages right before everything crashes, and you end up having to reverse engineer and work around the "easy" interfaces. Wouldn't it just be nicer to admit it's hard up front, and do the work diretly? I do hope that someone works through all these issues someday, and comes up with something we are all willing to use. It would be sort of like the global Andrew File System, or the world wide web, except that instead of files, you could actually send messages around and think of the things as objects! Lex Stefan Matthias Aust <sma(a)netsurf.de> wrote: > Hi! > > Last weekend, I looked into the fly-by-wire ORB code and franky, I was a > bit disapointed. It's written in a way I wouldn't do such a thing (a > questionable design IMHO) and the whole concept is extremly inefficient. > > Here's a very informal analysis:

1 0

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

Jump to page: