Squeak-dev December 1998

squeak-dev@lists.squeakfoundation.org

125 participants
236 discussions

Re: primaryHand
by johnm＠wdi.disney.com 23 Dec '98

23 Dec '98

"Leandro Caniglia" <caniglia(a)dm.uba.ar> wrote: > The multi-hand support of Squeak gets compromised by improper use of the > #primaryHand message. You're right! The "primaryHand" mechanism was a shortcut that was supposed to have been replaced by "self world activeHand" as you describe. The fix you propose is reasonable. -- John

1 0

Re: Porting troubles from 0x80000000 bit
by johnm＠wdi.disney.com 23 Dec '98

23 Dec '98

Georg Gollmann <gollmann(a)edvz.tuwien.ac.at> wrote: > Just for completeness: pre 2.3beta images have bugs that limit them to > about 512MB image size and 256MB object size. We've now integrated *all* of Georg's fixes, so the final version of 2.3 will fix these bugs. -- John

1 0

Re: T Spaces, Jini and musings on the new world order (Was: parallel processing smalltalk)
by Steve Dekorte 23 Dec '98

23 Dec '98

wirth(a)almaden.ibm.com wrote: > I'm not so sure that a "static" language like Java will make it. Once you > create a Java object and let it loose into the world, you've nailed down > it's class definition forever. There's no way to evolve structure. Seems > to me that you either need object "death" (biology's answer to the need for > evolution), or more dynamism in the structure of objects (e.g., > reparenting, or cloning and adapting prototypes). I agree. Of course Smalltalk shares some of Java's difficulty in dealing with change due to their shared class-based object model. > To put it in my favorite (macabre) analogy: Static languages are like going > to the doctor and telling him you have a hangnail, whereupon he agrees, > pulls out a pistol, shoots you and sends a message to your mother to have > another child. :-) That's about right. Unfortunately people tend to be too short sighted to see that effectively dealing with change is our most important problem. Most refuse to accept that change is even something that should happen. When it does, it's frowned upon as a sign of an initial poor design(as if any design could not be improved). The thing that distinguishes software from all other forms of engineering is that change can be much less expensive. Even so, much of computer science has been focused on decreasing change - provability, analysis, etc resulting in static, typed languages, a myriad of methodologies and a high rate of project failure. The pursuit of systems that are "good" from the start has been done without considering whether it could be cheaper to make systems in which it's easier to make mistakes but have a higher rate of improvement because the lower cost of change. Steve

2 1

Re: T Spaces, Jini and musings on the new world order (Was: parallel processing smalltalk)
by Richard L. Peskin 23 Dec '98

23 Dec '98

At 1:22 PM -0800 12/22/98, wirth(a)almaden.ibm.com wrote: >Someone asked: >>>the loose-coupling ideas of Linda (and think they >>>are a good start to thinking about a real network "object ecology"). >There >>>is a way to think of what Linda does in OOP terms. >> >>any refs, pointers ? A student of mine several years ago did a Smalltalk version of Linda. If there is enough interest, I can attempt to locate this and make it available. --dick peskin ================================= R. L. Peskin, Rutgers Univ. ; <peskin(a)caip.rutgers.edu>; <http://www.caip.rutgers.edu/~peskin> VT Phone (802) 824-4558 NJ Phone (732) 445-4208 "The corporate culture is concerned less with Occam's razor than his aftershave lotion."

2 2

[Q] Integrate my C-Code("Large One") with Squeak
by Chun, Sungjin 23 Dec '98

23 Dec '98

I want to use my optimization code in Sqeak but the problem is that it is written in C Language. It is big code almost 20000 lines and I cannot convert them into Smalltalk. Is there any way or resource on this kind of integration ? I really want to do this in Sqeak. Thanks in advance.

1 0

Re: primaryHand
by Les Tyrrell 23 Dec '98

23 Dec '98

The big problem is that the consumers of the events generated by the hands are not getting information about which hand generated the event. So, the primaryHand appears to be a hack to get around this for awhile until the whole thing gets patched up. This would probably only happen in a fairly major cleanup of Morphic, which I think would be a good project for someone. les ( NOT volunteering for this... I need to get the object interfaces and modules working that I've been talking about, not to mention the parameterized formatting that I signed up for ).

1 0

Re: Protocol dilution?
by Marcel Weiher 22 Dec '98

22 Dec '98

> Sorry for a belated response, but this composite wrapper scheme seems > cooler each time I look at it. Thank you! I am glad somebody out there likes it! > (By the way, I'm not really that familiar with what the term "composite" > means in a computer science/math sense... is it fair to say that a > "composite" is something that represents either one object or a > collection > of objects?) The 'composite' part actually refers to the composite pattern that Peter Smet was working on and has nothing to do with my scheme, which doesn't really have a name yet. [ Example: 2 collect raisedTo:#(1 to: 10) ] > I was wondering exactly how this would be implemented... I guess "2 > collect" would return a special Composite object? This Composite object > would then automatically forward any methods sent to it (e.g. raisedTo: ) > to its component object or collection, iterating if it's a collection. No > problem, I think. That's pretty much it. The implementation actually uses various types of streams in order to have a scheme that is very compositional. These 'filter'-streams, modelled after UNIX filters, take another stream as input. The ultimate source can be a stream over a collection, a single object (sometimes turned into an infinite repeater), or some sort of generator. Maybe an object returning lines from a text file? > But it sounds like it would take a look at the arguments passed along with > the methods (e.g. (1 to: 20)) and determine if any of those are > collections, and then iterate appropriately. This part is trickier > now... > what if a method normally has a collection as one of its arguments? How > would it know when to iterate, and when to simply pass the collection > along as a single argument? For example: > > 2 collect addAll: (3 to: 10). > > I suppose you could just lay down the rule that all messages sent to > composites will have their collection arguments iterated through, so > you'd > never want to send something like addAll: to a composite. (Or, it might > be safer to get rid of the collection-argument iterating altogether.) Yes, it probably is safer to do just that, and that's one of the variants I have examined. This requires 'streaming' arguments to be explicitly converted: 2 collect raisedTo:(2 to: 10) collect or maybe 2 collect raisedTo:(2 to: 10) each Which variant is better is one of the questions that should be resolved, though I somewhat favor the explicit approach, even if it is a little more typing, because it is much more orthogonal and probably adheres better to the principle of least astonishment. > Anyway, what I like about this scheme is that (in addition to handling > messages to single objects and collections) it can get rid of the need to > always use blocks for simple iterations, simplifying a lot of code. As > your example shows: > > arg1 do fire > > is a lot more concise (and probably more readable to a novice) than > > arg1 do: [:each | each fire] > > I guess this only works where "each" is the first item after the vertical > bar, but that's often the case for most iterations. Not necessarily: arg1 do: [ :each | someOtherObject fire:each ] turns into someOtherObject do fire: arg1 each As you noted for the other examples, I think this is also somewhat more natural, because it preserves the original message: someOtherObject fire: arg1 and just adds a little embellishment that says 'send this message not just to a single object but to several'. It's really a sort of multicast for Smalltalk messages, and it gets you thinking what other funky things could be done with messages/operations ... > I wonder what the performace implications of this scheme would be... I > suppose creating a Composite object for every iteration might be a bad > thing, but maybe optimizable... Currently, it is significantly slower than block-style iteration. I haven't narrowed it down yet, but I think the major overhead is probably sending Message objects via 'sentTo:' instead of direct byte-coded messages. There are several ways of making it fast again, the coolest probably using some sort of meta-level constructs. Again, thanks for the feedback. I am off on vacation now, so a happy holiday season to everyone and let's talk more in January. Cheers, Marcel

1 0

RE: Another mainstream article about Squeak at PCWeek Online
by Jarvis, Robert P. 22 Dec '98

22 Dec '98

> -----Original Message----- > From: Peter William Lount [SMTP:paradigm@unixg.ubc.ca] > Sent: Tuesday, December 22, 1998 2:51 PM > To: squeak(a)cs.uiuc.edu > Subject: Re: Another mainstream article about Squeak at PCWeek Online > <snip!> As a side note: It's interesting that Sun choose the name of a highly > stimulating and addictive drug as the name for it's product, Java. Maybe > the successes, to date, of Java are actually a result of a coffee induced > drug state instead of any real technicial merrit? You get to drink you > Java > as well as play with it on your computer! Maybe this would work for > Smalltalk as well? Anyone got any stimulating drug (legal) names that are > known by the masses that Smalltalk could take over? > Well, if the object is to contrast Smalltalk with Java, how about "Tea"? I can easily picture the following ad scenarios: Japanese samurai dressed in armor; tea ceremony is performed as traditional Japanese music plays in the background; warrior rises, bows, dons helmet, steps outside, draws sword and, screaming defiance, charges the enemy (who may or may not be dressed in pinstripe suits and ties). Fade out to message, "Tea - The Choice Of Code Warriors Everywhere". Pictures of Japanese tea ceremony; tea being served at Chinese imperial court; tea being served at stuffy English club. Fade to message, "Tea - The Civilized Choice For Developers Everywhere". Picture of traveler on horseback struggling though deep snow/frigid cold/etc.. In distance lights gleam in humble yurt. Traveler enters and is offered a steaming mug of tea by smiling residents. He smiles gratefully as he drinks. Fade to message, "Tea - The Tool That Goes Everywhere". But I still prefer the name Smalltalk... Bob Jarvis The Timken Company

1 0

Re: Another mainstream article about Squeak at PCWeek Online
by Peter William Lount 22 Dec '98

22 Dec '98

Hi, I thought that the article was well written and from what I can tell, factual and without distortions. It contained an short overview of the development history and open source nature of Squeak. For more details it referred you to a squeak website. It was a positive article with overview fluff. This kind of article is good for advertising and promoting a project/product like squeak. A gentle way to introduce people to squeak. A very important task in increasing the distribution and use of Squeak is getting press attention and press mindshare. It would be good to get any success stories of people using Squeak in commercial products or in commercial use published. Anyone know of any? The comparisons with Java are almost required since, presumably, a large part of the audience for the article knows about Java. It's not hard to be better than Java so it's actually a compliment! As a side note: It's interesting that Sun choose the name of a highly stimulating and addictive drug as the name for it's product, Java. Maybe the successes, to date, of Java are actually a result of a coffee induced drug state instead of any real technicial merrit? You get to drink you Java as well as play with it on your computer! Maybe this would work for Smalltalk as well? Anyone got any stimulating drug (legal) names that are known by the masses that Smalltalk could take over? Peter

1 0

Re: Protocol dilution?
by Marcel Weiher 22 Dec '98

22 Dec '98

> I think we are actually talking different things. Your approach sounds > very > much like 'map' in functional programming, where a particular function is > applied > (mapped) to all the elements in a collection. Is that right? It does have connections with map in that it is a higher order construct, but there are crucial differences. > I was thinking more of passing an argument to a method. If the argument is > a single object, you would simply send it arg1 #fire, on the other hand, if > the argument is a collection arg1 #fire will fail. On the other hand, if > single > objects understand do: then arg1 do: [each: each #fire] will work. I dont > see how collect solves this problem? does 5 collect 4 work in your > example?? Yes, single arguments/receivers are wrapped so that they repeat in the presence of collection arguments/receivers. So: 2 collect raisedTo: (1 to: 20) repeats the receiver '2' while stepping through the argument collection, sending the messages 2 raisedTo: 1, 2 raisedTo: 2, 2 raisedTo: 3 etc., whereas: (1 to: 20) collect raisedTo:2 will repeat the argument while stepping through the receiver, sending the messages 1 raisedTo: 2, 2 raisedTo: 2, 3 raisedTo: 2, etc. Finally (1 to:20) collect raisedTo:(1 to:20) will step through both the argument and receiver. Hmm, maybe there should be #cross, (1 to: 20) cross collect raisedTo:(1 to: 20)? In your case, you one would probably use #do instead of #collect, making the example read arg1 do fire which works for either collections or single objects. > The other issue regarding tradeoffs is that writing the forwarding > messages only > needs to be done once, while "collect +" must be written on each invocation. > I think it may be cleaner syntactically to use '+', but as you point out, > there may then be ambiguity... For messages that are sent to collections frequently, adding the forwarders directly could be beneficial. However, the disadvantage is that these special cases also have to be learned individually ( I can send a,b,c to collections, but not x,y,z), whereas the syntax just has to be learned once. Btw, don't nail me down on specifics of the syntax, I am just experimenting in this direction and especially the syntactic aspects seem to have bewildering trade-offs. Marcel

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
24
Older →

Jump to page: