Squeak-dev September 2002

squeak-dev@lists.squeakfoundation.org

165 participants
288 discussions

[ENH] ColoredFileContentsBrowser
by Masashi Umezawa 02 Sep '02

02 Sep '02

Hi all, I once sent ColoredChangeSorter ENH on 07/08/2002. This is the part 2. ColoredFileContentsBrowser. You can see code differences very quickly. Enjoy! "Change Set: ColoredFileContentsBrowser Date: 1 September 2002 Author: Masashi Umezawa Adds color listing support to FileContentsBrowser. #identical -> dark green #new -> blue #conflict -> magenta #other -> black Prerequisites: #('ColoredPluggableListMorph')" --- [:masashi | ^umezawa]

1 0

Re: The standard does *not* support - a removeAll: a - [was: Re: [BUG]
by Richard A. O'Keefe 02 Sep '02

02 Sep '02

Jesse Welton wrote: > Richard, would you say that the standard > requires #do: to work properly when the receiver is modified during > the iteration, as well? The text for #do: is 5.7.1.13: For each element of the receiver, operation [the block] is evaluated [invoked] with the element as the parameter. Unless specifically refined, the elements are not traversed in a particular order. Each element is visited exactly once. Conformant protocols may refine this message to specify a particular ordering. If you change what the elements _are_, then this definition runs into trouble. "each element" at what time? Now it's clearly _possible_ to make a 'snapshot' of the collection state and iterate over that. Indeed, that's precisely what Prolog does and what relational databases do. Prolog even does it _without_ making a copy. (Aren't virtual copies wonderful?) However, in this case the iteration process (whether using a copy or otherwise) and the changes _have_ to be interleaved, and it is possible for the block argument to probe intermediate states of the receiver. Those intermediate states are NOT spelled out. So code cannot depend on what they are. (In the case of #removeAll: and #addAll:, whatever intermediate states there might be are _not_ accessible. Even if there is an error, the state at the time of error is completely undefined.) I would say that the most natural way to read this is - you MAY modify the receiver in any way you like as long as you don't change what the elements are. For example, if Smalltalk arrays had lower bounds, shifting the lower bound should be OK. - if you change what the elements are, you are asking for trouble because the specification becomes unclear. - implementors: you don't have to support changes, but you should look for cheap ways of making your code robust just in case there are some. Had I been one of the authors, I would have insisted on putting in an explicit warning that the effect is undefined. Of course, what is in question when *user-written* code *has* to be interleaved with an *explicit* iteration is not in question when implementor-written code is invoked without any explicit iteration being involved and no interleaving is required. Stephan Rudlof <sr(a)evolgo.de> wrote: What should be the semantics then? E.g.: | a num | num _ 1. a := OrderedCollection with: num. a do: [:e | a size < 100 ifTrue: [a add: (num _ num+1)]]. a This is (1) a user-written change (2) interleaved with (3) an explicit iteration. I regard the ANSI specification as sufficiently ambigous in this case to admit both a 'copy semantics' implementation and an 'undefined effect' implementation. So it's not defined. To be honest, once upone a time I would have _expected_ it to invoke the block once, because I _expected_ OrderedCollection>>do: to have been firstIndex to: lastIndex do: [:index | aBlock value: (array at: index)] and I would have expected _that_ to make a copy of the value of lastIndex. But #do: isn't like that, and #to:do: doesn't work that way anyway. (This seems to violate the ANSI specification of #to:do:; no _object_ is being changed but a variable whose value would have been copied had this been a normal message send.)

1 0

RE: [BUG?]Upgrading 3.2 to 3.3alpha
by Richard A. O'Keefe 02 Sep '02

02 Sep '02

"Andreas Raab" <Andreas.Raab(a)gmx.de> wrote: We fixed this problem today. It turned out that there was a slight mismatch in boundary conditions with #to:do: loops - Squeak evaluates the upper bound only once whereas the equivalent C code (using for(;;)) may do this multiple times. Er, I ran into a problem that was caused by Squeak doing the C thing here. I _wrote_ 1 to: n do: [: i | ... ] and got the same effect, in fact the same bytecodes, as for i := 1. [i <= n] whileTrue: [... i := i + 1]. or something like that. I was annoyed, because n was changing, and I had written it as a method call precisely so it _would_ be evaluated once. Here's an example I just tried in Squeak 3.2: n := 1. r := OrderedCollection new. 1 to: n do: [:i | r add: i. n _ n - 1]. r select the lot in a workspace, and PrintIt. ==> an OreredCollection(1 2 3 4 5). This does not look like #to:do: evaluating its upper bound just once...

1 0

Re: The standard does *not* support - a removeAll: a - [was: Re: [BUG] Collection>>removeAll:]
by Richard A. O'Keefe 02 Sep '02

02 Sep '02

Stephan Rudlof <sr(a)evolgo.de> wrote: I've just read parts of the ANSI Smalltalk Standard, <standard> Essential aliasing of parameters is described using a parameter aliasing attribute: *captured* The receiver always retains a reference to the parameter, directly or indirectly, as a result of this message. *uncaptured* The receiver never retains a reference to the parameter, directly or indirectly, as a result of this message. *unspecified* It is unspecified as to whether or not a reference is retained as a result of this message i.e. either case may occur. I quoted the relevant part of this before. Note the key phrase: **AS A RESULT OF THIS MESSAGE**. Since we have an 'uncaptured' parameter, the receiver *has* *to* never retain a reference to the parameter, directly or indirectly, as a result of this message. This does not mean: "As a result of this message, the receiver must not retain a reference to the parameter" but "The receiver must not retain a reference to the parameter AS A RESULT OF THE MESSAGE". Further: The parameter *is* the receiver in the case of a removeAll: a . Has this receiver a direct reference to itself? I don't think so. But the *coupling* between receiver and parameter here is much stronger - identity! - than a mere reference. And the intent of the requirement here - as *I* read the standard - has been to have *no* coupling between parameter and receiver here. No, that's not what it says. It says that any coupling that exists must not be AS A RESULT OF THE MESSAGE. Let's take another case concerning which I hope there is no dispute. a := #(1 2 3 4). b := a asSet. b add: a. With me so far? 'b' is the set {1 2 3 4 #(1 2 3 4)}. b removeAll: a. I hope we are agreed that this clearly and unambiguously leaves 'b' as the set {#(1 2 3 4)}; the elements of 'a' have gone but the reference to 'a' itself has not. According to Squeak the final value of b is 'a Set(#(1 2 3 4))' and 'b anyOne == a' is true. So after this call to #removeAll:, the receiver *does* retain a reference to the argument, but that is OK because that isn't AS A RESULT OF THE MESSAGE. The reference exists because of an _earlier_ message. My conclusions: - I think this supports Allen Wirfs-Brock's view, that this special case has been overlooked. There was never any reason to doubt his word on the matter. - The intent of the standard seems to be to *forbid* a removeAll: a You may be able to justify that conclusion on other grounds, but not on this one. It is quite clear that the "Rudlof reading" of uncaptured is untenable in this case and elsewhere. For another example, consider x = x where x is any object supporting an #= method. After the message, x retains something stronger than a reference to x, x retains identity with x. But section 5.3.1.1 says firmly that the argument is 'uncaptured'. On the Rudlof reading, x would not be allowed to be identical to itself afterward. On the "Richard reading", x knowing itself after x = x is perfectly fine because it doesn't do so AS A RESULT OF the #= message. In the same way, x knowing itself after x removeAll: x is perfectly fine because it doesn't do so AS A RESULT OF the #removeAll: method. Whatever _else_ we can say about x removeAll: x is entirely outside the scope of this message, which is concerned _solely_ with the question "how do we interpret 'uncaptured' when reading the ANSI Smalltalk standard."

1 0

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

Browsing all understandable methods?
by Yoel Jacobsen 01 Sep '02

01 Sep '02

Hello, Is there a way to see, when browsing a class, all the methods the class (and/or the class's instances) understand? [i.e. - including inherited methods] Thanks, Yoel

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

Jump to page: