Squeak-dev August 2002

squeak-dev@lists.squeakfoundation.org

175 participants
535 discussions

RE: [BUG]Collection>>removeAll:
by Richard A. O'Keefe 08 Sep '02

08 Sep '02

Valloud Andres <Andres.Valloud(a)oya.state.or.us> wrote: Quantify the usefulness of your expectations. OK: it makes the specification 50% shorter. Please provide real life examples where x removeAll: x is used as an intention revealing feature in a dialect-independent manner. Now *there's* a ploy! When someone says there is a bug, demand that he demonstrate that it already possible to use the method across implementations without running into the bug. Of *course* I can't do that, because there is a bug. The only I could *possibly* provide any real life example of x removeAll: x being used 'in a dialect-independent manner' would be if no Smalltalk had the bug, in which case we wouldn't be having this discussion! With a start like that, I don't think I need to respond to anything else in that message. But I will. The standard also says the argument is to be uncaptured, which is defined as meaning the receiver doesn't acquire direct or indirect references to it. I think the spirit of this was "leave the argument alone". Well, no. If you are going to leave the argument alone, why pass it? If you send even one message to the argument, you are no longer in control of whether the argument will be changed or not. The spirit of "uncaptured" is precisely "The receiver doesn't REMEMBER the argument afterwards." Anything beyond that is ungrounded in the standard and has to be justified on a case-specific basis. Saying "the result is undefined when argument==receiver" also coincides with the "leave the argument alone" attitude. Except that you _can't_ leave the argument alone. You have to send it messages to find out what its elements are. It is possible to construct collections where asking the question changes the answer. (Not very sensible ones, granted. But if other people may imagine hypothetical collection classes that would break things, so may I.) IF the argument is to be left alone, then of course it is to be left alone. But the ANSI standard does NOT say that the argument is to be left alone. This is actually an interesting point, which should be considered in a future revision of the ANSI standard. None of the #removeAll: methods actually say _how_ the elements are to be determined. There is no limit whatsoever placed on which messages may be sent to the argument. It is at least arguable that an implementation which removed the elements from the argument one by one could conform, as long as it put them back afterwards (if that didn't end up changing the receiver). The standard very carefully describes the effect on the receiver _without_ saying anything about how it is to be done. (Even the 'as if ... remove:' stuff doesn't mean you have to send #remove:, because that only applies to specific cases where the effect of #remove: is also specified.) We really cannot conclude from the text of the standard as we have it that no #remove: messages may be sent to the argument. At any rate, the standard does NOT say that #do: may be sent to the argument or that #copy may not be. The implementation aCollection copy do: [:each | self remove: each ifAbsent: [self errorNotFound]] fully conforms to everything the standard says, is at least in the cases I measured, faster than the existing implementation, and does not have the hole in its coverage. The ANSI standard isn't written in stone. No, until it is revised it is rather less mutable than that. I'd rather amend the standard than agreeing with it regardless of the cost. Nobody is suggesting 'regardless of the cost'. I have suggested many ways of getting the effect I want, and Allen Wirfs-Brock, while pointing out that the committee didn't think about the problem, did say that mine was a _possible_ reading of the standard. The outcome is that in this case, conforming to the letter of the standard, including NOT having a hole in the domain, could give us a *FASTER* implementation than what we have now with an interface which is *EASIER* to understand. It is the people who are insisting on not making this correction who are demanding something costly, in my view. By the way, if there _is_ a process for amending the Smalltalk standard, I am very pleased to hear it. Who do I write to? What is the process?

7 12

XML-RPC
by marbusse＠t-online.de 06 Sep '02

06 Sep '02

Hi! http://minnow.cc.gatech.edu/squeak/1399 says that Bolot Kerimbaev had done some work implementing a XML-RPC server for squeak. Looking into the latest comanche-changeset, I can't find classes for that... Does anyone have an implementation on his harddisk? Regards, Markus

2 3

BehaviorInspector
by Stephane Ducasse 05 Sep '02

05 Sep '02

Hi, At ESUG, we got a presentation of F-script (a scripting and Smalltalk language with APL like vector manipulations). Philippe the F-Script father implemented a ***really*** interesting inspector called object inspector. See the attached file The idea is that this behavioral inspector does not show the instance of object, but offers all the methods, when we click on a method it get executed on this object and the result is put on the right. When selecting this new object the method it understand are again displayed on his right. .... The methods are sorted from the class (top) to the superclass (bottom). this way we see always the most specific method first. In addtionI can select by clicking on any visual Mac element and get them into the "object browser" if somebody would implement such an inspector for squeak this would be great to teach oo without violating encapsulation as right now with the inspector. I will try but I'm really full now. Stef Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

4 5

blue ideas
by Jecel Assumpcao Jr 03 Sep '02

03 Sep '02

I wrote a page with five ideas to simplify Self (slightly blue plane stuff): http://www.merlintec.com:8080/software/11 The jargon there is very Self oriented and so might not make much sense to Squeakers. Some of the ideas at least could be applied to Squeak - 1) unified block/method/context objects in Self, methods are supposed to be prototypes from which we obtain contexts by cloning. In practice it doesn't work that way and this is a call to take the idea seriously. Since Squeak is class based we are already used to the idea that an object and the template from which it is created are very different, so the idea doesn't have the same impact. 2) up arrow as binary selector Squeak has little special syntax: <- (or :=), ^, self, super, thisContext, true and false. Self has even less and I would like to take advantage of idea 1 and make ^ be just another binary selector. This doesn't apply to Squeak since it doesn't have the "implied self receiver" syntax. 3) simpler syntax: no literals This idea would work just as well in Squeak and we already have a taste of it in MathMorphs and eToys. If you can embed a graphical representation of any object in source code, you don't need syntax for literals. 4) simpler assignment This is an attempt to make assignment and message argument binding be the same thing. A side effect would be to allow more flexible keyword messages with default arguments. 5) removing inheritance from the base-level parent slots are a neat language design "pun" (a single thing is used for both "has-part" and "inherits-from" relations) but it would be better to have all program structuring stuff live exclusively in the meta-level. Squeak doesn't have parent slots, of course, but does have #class, #isKindOf: and other unmarked portals into the meta-level underworld. === As I was thinking about the pink plane / blue plane stuff, I came to the conclusion that there is a related but separate dimension. A project can seek "synergy" or it can work towards a "separation of concerns". If you add a JIT, for example, it might be an optional plug-in that makes things faster when present, like in Jitter 3. Everything can work either with it or without it. An alternative would be to make it a central aspect of the design (like Self or Jikes) and try to see what can be made simpler because of it. Can name spaces be simpler? Modules? 3D graphics? My personal taste makes me favor synergetic designs but there are problems. It is harder for more than a small group (or even a single person) to work on it. It is harder (impossible?) to understand a part of the project without learning all the rest. New requirements might come along and it might be easier to throw away the system and build a new one than to adapt it. The "separation of concerns" step-by-step development is the way to go in the pink plane. But what is the best style for Squeak on the blue plane? -- Jecel

7 23

Re: [BUG]Collection>>removeAll:
by David Griswold 03 Sep '02

03 Sep '02

To try to move this issue forward, and keep it in the realm of constructive discussion, I'm going to try to clarify what is going on, and put forward a proposal. I suspect that some (Richard at least), are feeling like myself and other nay-sayers are simply being obstructionist about a simple issue. But there is a very good reason for the kind of critical discussion that has been going on, and it is actually a good thing. The closer a change comes to the core of a system, the more it should be challenged, to make sure it is worthy. We are not talking about JoeBlowCornerOfTheSystem, but the *Collection* class and protocol, arguably as close as you can get to the heart of Smalltalk. This class and protocol have withstood an enormous amount of use in the real world, and even a very slight change needs to be really, really thought about. I jumped into the conversation only because it seemed to me that the necessary "due diligence" wasn't being done. I've made my points, but to be constructive and try to move forward, here is how I would reason about this problem and what to do about it. I'm laying it out in painful detail to show the kind of restraint I think is needed when dealing with important code like this. - it is clear that people do try to write (x removeAll: x), and that it doesn't do what they expect. This seems to happen frequently enough that it would be desirable to at least let people know when this happens, so they can write their code a different way. The currently accepted valid ways to empty a collection are to either create a new collection (usually the fastest way) or say (x removeAll: x copy). - If we come up with a way to detect this case and generate an error, then the only remaining rationale for extending removeAll: to support the special case of the receiver as an argument would be if it was required by ANSI, or made the library or its specification simpler and cleaner, or fixed an actual bug. I believe that none of these has been demonstrated to be true. So how would we detect the error? Richard has argued for just putting the check in. I say it belongs in an assertion, even though it is a very fast check, and here is why: every time a programmer thinks of some invariant like this that they want to check, they make a little 'cost' calculation in their head, and if the check is going to have much of a performance cost, they tend to not do the check. Using assertions automatically for all of these kinds of checks eases that difficult cost decision, which encourages people to sprinkle these checks all over their code (a Good Thing). Just because this particular check happens to be very fast does not make it a special case. So I would recommend the following fixes: 1) Get the assertion mechanism working effectively and efficiently in the standard Squeak release. Make sure its cost in development is minimal, and its cost in production, zero. 2) Just add "self assert: [ otherCollection ~~ self ]." to the beginning of removeAll:. Very, very simple. (a Good Thing). It prevents this whole issue from being a problem, with no changing of the basic Collection interface or implementation required, and with no performance impact in production (Good Things). It also gives everyone notice that they can now sprinkle their code with assertions (a *really* Good Thing). Now, to the second, separate matter: is a new #removeAll method needed? I can see only one good reason for a #removeAll message. That is that a large, tenured collection might need it as a hook to implement a more efficient way of being emptied. Another argument that might be made is that people need a generally easy way of removing all of a collection's elements, but I don't buy that because most of the time, they should just create a new empty collection, which is usually faster, so we don't want to particularly encourage doing #removeAll anyway, since it is usually the slowest way to get the job done. However, the large collection argument is a good one, I think. The question then becomes, where does this method belong? One could argue that code dealing with such large collections almost always knows a lot more about the collection than just that it is a collection that supports remove:, so adding efficient removeAll methods to specific collection classes could be done without adding it to the Collection protocol itself. On the other hand, since removeAll is conceptually built using remove:, adding a default implementation to Collection doesn't break any subclass of collection, since it doesn't use any message other than do: and remove:. It would, however, break classes that implement the Collection protocol but which don't inherit from it (ah, for mixins). So basically, I think this argument comes down to weighing whether the "large collection" argument is good enough to overcome the drawback of breaking existing classes that implement Collection without inheriting from it. I'm not drawing a conclusion here, just trying to delineate the crux of the issue. I personally think removeAll would be a nice addition, but it would break some code out there, and it's not used that often (and shouldn't be), so I'm on the fence about it. If such a method was added, in Collection it needs to be something really simple. You can do this safely and generally without copying if you write removeAll [ self isEmpty ] whileFalse: [ self remove: self anElement ] where anElement can be the following private method (it can be made public, and is in Strongtalk, but that's another issue): anElement self do: [ :el | ^el ]. self error: 'Collection empty; no element to return'. Unfortunately, without an inlining compiler, anElement is not very efficient in Squeak right now, although with inlining it could be more efficient than copying. On a 1000 element Set of consecutive integers, the above implementation is a bit slower than (self removeAll: self copy), so maybe the copying version should be used for now instead, if removeAll is to be added (although anElement is a handy method to have around, in its own right). On the other hand, much more efficient implementations of anElement can easily be written for important subclasses, and then removeAll can be done efficiently without copying. So if there is any overall message here, it is: be very careful with code in classes like this, and show great restraint by making changes as minimal as possible. The code in Collection is simple, but not simple-minded. Don't underestimate the subtlety of why these simple-seeming methods are the way they are. Cheers, Dave

5 4

Debugger for Windows VM
by Anthony Hannan 02 Sep '02

02 Sep '02

What debugger should I download and install for debugging the Windows VM? (I have a bug in my VI4 version). I downloaded the latest source and compile tools from squeak.sourceforge.net (Thank you Andreas Raab!). I downloaded and tried Cygwin Insight gdb 5.0 from http://www.objectcentral.com/downloads.htm, but it complains that "this executable has no debugging information" even though my VM compiled successfully with the -g option included (the default in Andreas makefile). I also downloaded the gdb source from http://www.gnu.org/software/gdb but to compile it on Windows the Readme said I needed the DJGPP development environment. I this is what I will have to do? Is there an easier way? Why doesn't Cygwin Insight gdb 5.0 work? Thanks, Anthony P.S. I'm not a Windows programmer.

8 13

Re: Starting the clock...
by Bob Arning 01 Sep '02

01 Sep '02

Alan, What I'm not clear on is the relative importance to your project of - the bitmap-like qualities of an ImageMorph vs. - the world/container qualities of a PasteUpMorph If it is the former, here is an example of how you can have a Form on the screen, make changes to it and see those changes. ============= f _ Form extent: 400@400 depth: 32. f fillColor: Color red. aiworld _ ImageMorph new image: f; openInWorld. World displayWorldSafely. (Delay forSeconds: 1) wait. "so you can see each change happen" f fillColor: Color green. aiworld changed. World displayWorldSafely. (Delay forSeconds: 1) wait. f getCanvas line: 0@0 to: 400@400 width: 6 color: Color yellow. aiworld changed. World displayWorldSafely. (Delay forSeconds: 1) wait. f getCanvas line: 400@0 to: 0@400 width: 6 color: Color blue. aiworld changed. World displayWorldSafely. (Delay forSeconds: 1) wait. ============= If it is the latter, the you might try something like this ============= aiworld _ PasteUpMorph new extent: 400@400; openInWorld. aiworld addMorph: (RectangleMorph new position: 100@100). aiworld addMorph: (EllipseMorph new position: 200@200). aiworld imageForm inspect. "<--your ai could 'read' this form to see wwhat's happening" ============= Cheers, Bob

2 1

Re: [BUG]Collection>>removeAll:
by Richard A. O'Keefe 01 Sep '02

01 Sep '02

"Andrew C. Greenberg" <werdna(a)mucow.com> wrote: *** The iterand of a #do: on a collection, implicitly or otherwise, is undefined whenever the structure and contents of the collection is not invariant through the iteration. That's all very well, but the *CALLER* of #removeAll: is NOT DOING ANY ITERATION. What gets iterated over, when, and how, is the responsibility of the implementation of #removeAll:. I have shown several implementations of #removeAll: where modification of the receiver just plain doesn't happen during whatever iteration takes place. I fully and completely agree that when a programmer writes an iteration, *THAT* programmer is responsible for making sure that the collection is not changed. But when someone calls #addAll:, they are not writing an iteration. It was the author of the #addAll: implementation who wrote the iteration, and it was the author of the #addAll: implementation who had the responsibility for making sure that it either worked or was documented as not working. This is a bedrock principle of the Collection hierarchy's design, and seems to me a sound and reasonable basis for proceeding. I am in complete agreement with you. THAT is why we know #removeAll: is broken. To the extent that I have read what Richard has argued, I would hope that a responsible arguer would have read all of it. I am not convinced that #removeAll: is or should be defined in the case of self. In IBM Smalltalk, I'm told that it _is_. Do you wish to argue that IBM Smalltalk should be changed so that it is not? > And it really is very much an exaggeration to say that > "x removeAll: x copy" is an "accepted way" to empty a collection. > It is a way. It is a good way. But practically nobody knows about it. > It's what people do when they burn their fingers on "x removeAll: x". Just about everybody seems to know about it, IMHO, even late-comers to the language such as myself. You have done a survey of all Smalltalk programmers, have you? If this were true, the thread would never have got started. It _certainly_ isn't mentioned in _any_ of the Smalltalk textbooks I've checked. Surely if it's as well known as all that, _one_ of them would have seen fit to mention it? I have discussed this issue with several of the staff in this department, including the head of department and the person responsible for 2nd year data structures. I have asked "Given an abstract data type T that is some kind of container, with an operation remove_all_elements_of(x: T, y: T) explained as 'remove every element of y from x' what would you expect remove_all_elements_of(x, x) to do?" The unanimous answer was "make x empty". Ralph Johnson wrote a nice little piece I read early on in my Smalltalking life about common Smalltalk bugs, and the "copy trick" was clearly pointed out there. How nice for you. Tell me where to find it and I'll make sure my students see it. > I have also explained repeatedly not only _that_ the change makes the > specification simpler and cleaner, but _how_ it makes the specification > simpler and cleaner. Richard certainly has SAID that he feels it makes the spec simpler and cleaner -- not all of us were satisfied either at the sufficiency or correctness of his "explanation." Merely stating, ipse dixit, that something is so certainly does not evidence that it is so. This makes me very angry. I didn't just SAY that I "feel" it makes the spec simpler, I wrote out in full what the specification _is_ right now and what the specification would be if the bug were fixed. I am not going to do this again because this has already taken too much of my time. No reasonable person could call comparing and contrasting the two versions of the specifications "merely stating that something is so." > Rational/critical debate at least requires a rebuttal of these points, > not a flat denial that no demonstration was ever made. Pot. Kettle. Black. Rational/critical debate at least requires acknowledgment that others have made more than a flat denial when, in fact, they have undertaken to make arguments on the merits. No, once again you have made a FLAT DENIAL that I demonstrated that the specification is simpler when the bug is fixed. I have not found Ralph and David guilty of empty gainsay, though I *DO* find Richard's present "claim of victory by default" (but not his earlier arguments) to be precisely that. I have made no such claim. Indeed, I am fighting desperately for reason and safety in programming precisely because I do *not* feel that I have any kind of victory. It is not fair and not reasonable to attack me for 'empty gainsay' for something I have not said or implied. I am now far too upset to read the rest of the message. To the people who have supported me in this, thank you. Especial thanks to the person who pointed out that x removeAll: x *does* work for OrderedCollections in IBM Smalltalk, so that the nay-sayers are fighting to preserve a bug that at least one commercial- quality Smalltalk does not share. (Perhaps _because_ it is commercial quality?) To the people who have been watching quietly, thank you for your bandwidth. I hope we have all learned something. To the others, well, thank you for provoking me to probe the issue.

8 8

[BUG][FIX] Can't compile interp.c on Acorn and MacOS 10.2
by Andrew C. Greenberg 01 Sep '02

01 Sep '02

As discussed earlier, interp.c as generated contains definitions of variables named "bool," which are treated in some systems, such as Acorn and MacOS 10.2, as a type or reserved word. The attached changeset replaces that code with defintiions of variables instead named "aBool." Before adding this to the release, will someone check to make sure that the updated versions of these methods were created from the most current? I was using a fairly haggard and regularly munged image, so I couldn't be sure. Still, these look like the types of routines that aren't changed too often, so it should be ok. -------- 'From Squeak3.3alpha of 12 January 2002 [latest update: #4934] on 31 August 2002 at 1:10:56 pm'! "Change Set: fixBoolDeclarations Date: 31 August 2002 Author: acg Generated VM interp.c files contained definitions of the form 'int bool;' in various portions of the interpreter. Because some compilers and standard libraries define 'bool' as a class, the generated code is uncompilable without modification. This changeset simply changes those temporary variables named 'bool' to temporary variables named 'aBool,' resulting in versions of interp.c that appear to work correctly for the MacOS X and Acorn ports."! ----------

1 0

Re: Design Patterns and Collection Classes
by David Griswold 31 Aug '02

31 Aug '02

Brian T Rice <water(a)tunes.org> wrote: > > Hi David, > > Would someone be kind enough to produce ascii-text (or at least > non-binary) versions of the Strongtalk sources, since I don't have a > readily-handy new Windows machine, and the Strongtalk system > is totally > unusable on older Windows versions? (I gave up after the > hundredth blue > screen.) > > I'm working on a new language, and want to incorporate the > best ideas that > I can into my collection hierarchy. I've already ported and augmented, > trimmed, and modified Squeak's collection types, but without > real access > to Strongtalk, there are some aspects of this that aren't apparent. > Hi Brian, Let me think about the best way to accomplish this. It would be easy to just file-out the Strongtalk collection classes, but that wouldn't be file-in-able on any other Smalltalk, and isn't that great a read by itself ;-). I've been considering a compatibility-fileout, but there still would be lots of name clashes without namespaces or something, and I would also have to do ugly things like expand mixins etc to make it work, which would destroy some structure. It is a such damn shame that the system has become so unstable on Win95/98. It wasn't always that way- the system was developed on Win95 and NT, and I used to run it all day long on 95 with maybe a crash a day or something (we were doing all our coding in the programming environment at that point, so it obviously *had* to be stabler than it is now). Changes that were made at Sun (not with my approval) just before release to recompile and slightly clean up the VM seem to have resulted in this instability, and I did not have a chance to test it after those changes :-(. I hoped most programmers would have access to XP by now, where it runs much better (altho still not as well as it originally did), but I guess in the Smalltalk community that hasn't happened. I'll get back to you. Cheers, Dave

1 0

Jump to page: