Squeak-dev August 2002

squeak-dev@lists.squeakfoundation.org

175 participants
535 discussions

RE: The standard does *not* support - a removeAll: a - [was: Re: [BUG] Collection>>removeAll:]
by Jarvis, Robert P. (Contingent) 30 Aug '02

30 Aug '02

> -----Original Message----- > From: Stephan Rudlof [mailto:sr@evolgo.de] > Sent: Friday, August 30, 2002 10:47 AM > To: ML Squeak > Subject: The standard does *not* support - a removeAll: a - [was: Re: > [BUG] Collection>>removeAll:] > > > <snip!> > - The intent of the standard seems to be to *forbid* > a removeAll: a > . > - At least I think this is a reasonable possible interpretation. I disagree. The standard says that after #removeAll: is executed, the receiver of #removeAll: will not retain a reference to the parameter to #removeAll: or, in other words, the receiver will not assign the parameter to a non-temporary variable, or invoke a method which would result in said parameter being assigned to a non-temporary variable. My interpretation is that it does not in any way prohibit a removeAll: a I find it interesting that A) the return value from #removeAll: is unspecified, B) this discussion over relative trivia has gone on for as long and with as much vehemence as it has, and C) I have been fool enough to have become involved in it. :-} Bob "...such was the wreck of the Hesperus in the midnight and the snow..." Jarvis Compuware @ Timken ********************************************************************** This message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communication to others; also please notify the sender by replying to this message, and then delete it from your system. The Timken Company **********************************************************************

1 0

Re: Design Patterns and Collection Classes
by Richard A. O'Keefe 30 Aug '02

30 Aug '02

Torge Husfeldt <Torge.Husfeldt(a)gmx.de> wrote: [You _can_ use soft private initialisers without letting anyone use them to smash existing objects if you make them check that the object hasn't been initialised yet.] Thank you very much for this suggestion. While I don't like "cluttering up" my code with such tests, there isn't any efficiency argument against this because such a test happens only once in the lifetime of an object. (All going well.) I must remember this technique. n this case the invariant "keys are never nil" might do. Ah. Time to come out into the open. There are two things that I am not happy with about Set and Dictionary. (1) In some of my tests, removing a bunch of elements from a Set seems to be rather slow. Make that "extremely slow". (2) The fact that you cannot put nil in a Set or use it as a key in Dictionary smells to me more like a quirk of the implementation (which uses 'nil' in slots to indicate that they are empty) than something motivated by considerations of what people might want to *do* with a Set or Dictionary. For example, you might want to eliminate duplicates from a collection, so you do aCollection := aCollection asSet asArray. But that doesn't work if nil could be in aCollection. And yes, I have wanted to do that. So I've made my own "NewSet" class (so as not to change an existing class) and "NewDictionary" is in the works. As far as I'm concerned, keys MAY be nil. #includes: and #remove:ifAbsent: are pleasantly faster in NewSet than in Set; #add: is about the same (it allocates a new object, which Set>>#add: does not). Otherwise you might have to invent a new instance variable. While an "already initialized?" test happens only once in the lifetime of an object, an extra slot takes up space all the time. I guess if I propose a change to existing things I'll be howled down again, but it _would_ be nice if the compiler accepted (<self | super> <new | new:...>) pvtMessage... in a class.

2 1

Compatibility
by Richard A. O'Keefe 30 Aug '02

30 Aug '02

goran.hultgren(a)bluefish.se wrote: I agree in full with everything you wrote (including the rest) but what is your thought on compatibility? If Squeakers turn to rely on this code working then the code they write will potentially not port to other Smalltalks. We could argue that depending on how other Smalltalks do it is a weak argument that will make any improvement in these areas impossible. I think this is time for a new thread. Goran has raised a general issue of some importance. If I personally didn't care about compatibility, I wouldn't have bothered downloading the standard. (I was going to ask our office to get the electronic copy of the final, having found out how to do so and for how much, but with too many of our office staff sick/on leave, I'm not going to bother the one that's left. When things are back to normal.) I _like_ language standards. I write to them whenever I possibly can. (Except Prolog and APL. I regard the ISO Prolog standard as too little and way too late and too incompatible with prior art. And I can't read the APL2 standard.) There's one fairly basic problem with the ANSI Smalltalk standard. Well, two. If there are any students enrolled in SENG 405 (Formal Methods) next year, I am going to use the #removeAll: debate as a _perfect_ example of why specifications written in plain English can lead to misunderstandings, so that even the attempt at formalisation can help you debug a specification even if you end up never using the formal version for anything. But the other one is that it's very much a minimal standard. There is no SequenceableCollection>>isSorted in ANSI Smalltalk. There is no PluggableSet in ANSI Smalltalk; not even IdentitySet. There is no Object>>storeOn: in ANSI Smalltalk. There is no MappedCollection in ANSI Smalltalk. There is no CharacterSet in ANSI Smalltalk. There is no indexOf:startingAt: in ANSI Smalltalk. There are no operations on directories in ANSI Smalltalk. Heck, there isn't even any Point class in ANSI Smalltalk. There's even a Smalltalk dialect where there is no OrderedCollection, and none needed because Array and String instances can change size. Anyone here seriously proposing to stop using OrderedCollection? But just knowing what the standard says is not enough. You have to know which of those operations are _actually_ portable. (Richard Harmon put a lot of work into his ANSI-Squeak kit. Many thanks to him! Why isn't this stuff already all in Squeak 3.2?) This is just like when I was working in California, it wasn't enough for me to have the POSIX.1 standard and the C standard, I _still_ had to check things on as many different UNIX systems as I could, because they didn't all conform, even when they intended to. (And I also needed to do things that weren't in the standard, and needed to know how portable they were.) What would be a great aid to people trying to write portabile code in Squeak would be a 'portability colouring' browser. (In 3.2, this would be just another source display mode.) We'd start off with a data base of which methods were defined in ANSI Smalltalk. Some heros with access to VW, VA, Dolphin, &c would add notes on what was in their systems and not likely to change. Some Squeak hero would add similar things for Squeak. Add in GNU ... When you were in the browser, the colour would tell you - this is an ANSI method (or classname) - this is an ST-80 method (or classname) not in ANSI but commonly supported - this is in several modern systems but not all - this is probably unique to your system - this is one of yours (known from change sets) This would only be approximate. Just as we currently have 'explain', there'd be a 'portability' menu item. Select a span of text that identifies a method, and 'portability' would give you a List showing which classes the method was available in, according to the various manuals. Select a class name, and 'portability' would give you a List showing which systems/specifications were known to support it. In the absence of such a code view, it is very hard for people to actually know that they are writing portable code. In fact, we never know whether the code we are writing will port to the next version of Squeak, and quite often it doesn't, not without rewriting. By the way, a huge great smiley-faced THANK YOU to all the Camp Smalltalk people who try to make some really useful stuff available in several Smalltalks. That's a huge help to people trying to write portable code.

2 1

Re: [BUG]Collection>>removeAll:
by David Griswold 30 Aug '02

30 Aug '02

goran.hultgren(a)bluefish.se wrote: > [SNIP] > > > I'm sorry, just what is being proposed that would break > > > existing classes? > > > > Changing the meaning of removeAll:. It breaks all existing > classes that > > implement the Collection protocol or reimplement #removeAll:. > > I am sometimes pretty dense (and currently I am swaying > between David's > "assert proposal" and my own "calling removeAll proposal") but are you > saying that making removeAll: returning a correct answer instead of > garbage could break existing classes that rely on the garbage result? No, I think there is a misunderstanding. I'm saying something different: changing #removeAll: so that it is required to work when passed the receiver as an argument breaks all other implementations of removeAll:, because as soon as you make that change, other implementations suddenly no longer do the right thing in that situation, and will have to be changed so that they handle this case, too. > [SNIP] > > > Again, with the possible exception of code that > deliberately causes a > > > DoesNotUnderstand, how would _adding_ a method to Collection > > > "break" any > > > other class? Can you give an actual example? > > > > I just gave the example above: any other class that implements > > Collection without inheriting from it, including your own class you > > mentioned above. > > Now you are talking about breaking code not yet written. That is, code > that will use the message #removeAll (in Collection "version 1.1") and > which would not be able to polymorphically work with old classes that > only implements Collection "version 1.0". No, the code that breaks that I am referring to is not the unwritten uses of the new semantics of #removeAll: that would fail. I am talking about the classes that reimplement the Collection protocol. As soon as Collection is changed in such a way that other classes no longer correctly implement the protocol, those other classes are broken, regardless of whether that brokenness causes a crash now, or in the future. I think we are just using the word "broken" differently- I meant 'out of spec', and you thought I meant "actually crashes". Cheers, Dave

2 2

Re: [BUG]Collection>>removeAll:]
by David Griswold 30 Aug '02

30 Aug '02

Richard A. O'Keefe wrote: > NEW RESULTS! > > There are people in this mailing list who are of the opinion > that the quirk in the implementation of #removeAll: is not a bug > but an obvious precondition that programmers should always have been > aware of, so it doesn't need fixing. > > I am deeply indebted to mwai(a)geico.com for telling me that > > |coll| > coll := OrderedCollection with: 1 with: 2. > coll removeAll: coll > coll inspect --> OrderedCollection() > > _works_ in IBM Smalltalk, despite IBM Smalltalk having the same > implementation of #removeAll:. Finding a single class in another implementation that just happens to work in the case you are interested in proves nothing. You pluck IBM's OrderedCollection out of the air because it happens to meet your needs. We are talking about the general Collection algorithms, not just as they apply to the behaviour of OrderedCollection. Do all the other collection classes in IBM Smalltalk do this? I suspect not. -Dave

1 0

Re: [BUG]Collection>>removeAll:
by David Griswold 30 Aug '02

30 Aug '02

Martin Wirblat <mw.projanynet(a)SoftHome.net> wrote: > Subject: Re: [BUG]Collection>>removeAll: > To: Squeak <squeak-dev(a)lists.squeakfoundation.org> > Date: Thu, 29 Aug 2002 18:09:01 +0100 > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > David Griswold wrote: > > > I made a clear argument that all programs in Smalltalk (or in any > > imperative language for that matter) have a universal, > *implied* constraint > > that you shouldn't change objects that are being used by > something that > > assumes that they remain the same. This language-wide > constraint clearly > > excludes (x removeAll: x), and the specification for > removeAll: doesn't > > override that. > > and > > > Programmers should read this additional constraint into all ANSI > > specifications, so that removeAll: has the implied language > "the argument > > can be any collection that is invariant during the execution of this > > method". > > (x removeAll: x) will NOT change x during its own execution > of the part which > relies on x being invariant, IF IMPLEMENTED PROPERLY. > > => There is NO violation on principle of the mentioned > language-wide constraint > by (x removeAll: x). This differs from the iterator-methods > with blocks where it > can NOT be guaranteed for ALL possible pieces of code in the > block, that this > constraint will not be violated, whereas #removeAll: can be > implemented with the > guaranty to work correctly with ALL possible arguments. Even if the method *can* be implemented to work correctly with all possible arguments (which I don't concede), that still doesn't mean that is what the current spec is. My whole point is that invariance assumptions are so universal in programs, that they have to be the default (i.e. arguments assumed invariant during method execution unless specified otherwise), otherwise any specification would become unreasonably overcomplicated. This effect is one of the main reasons why imperative languages are avoided whenever possible by anyone doing formal reasoning (including mathematics): otherwise their specifications would become wildly overcomplex because they can't assume invariance. I love Smalltalk, but it is imperative, so this is just one of the things you have to live with. Therefore, the spec doesn't require that (x removeAll: x) be supported. Your argument seems to be that because this method might be able to be implemented without one form of the invariance assumption, then the spec must mean that. I don't see how that follows. >Changing #removeAll: in the proposed way would not change semantics of >Collection, it would extend them, so that they stay completely compatible with >existing semantics. There will be no confused programmer and no program becoming >buggy. The programmer can ignore the ability of (a #removeAll: b) to handle >a == b, explicitly test on identity and write the code which could be written >once inside the method many times outside of it. You (along with some other people) are forgetting that specifications are not only for users, but for implementors. Extending semantics or generalizing functionality doesn't break user code, but it does break other implementations. And I would assert that Collection is the single most heavily reimplemented protocol in all of Smalltalk. (Aside: as I have hinted before, Strongtalk's simple, elegant mixin model (which wouldn't be hard to add to Squeak) helps a lot with this problem, since then no one else would ever have to entirely implement the Collection protocol. This would allow new methods, like #removeAll, to be added with much less chance of breaking other implementations, since the new method would automatically propagate to other implementations. But even mixins don't automatically fix the breakage caused by changing the specification of an existing method like #removeAll:. ) > The whole Squeak system is work in progress - many parts of it are improvised > or experimental - preserving the history of some other parts up to the smallest > detail under nearly all circumstances would be funny. It all depends on what you think Squeak's purpose is. If it is just a limited-use multimedia etc. experiment, then you are right- hack away at Collection. If you think Squeak has any chance of someday becoming a widely-used Smalltalk implementation, it is a different matter. Personally, I think that the fact that Squeak is open source, portable, and based quite conservatively, all things considered, on standard Smalltalk semantics, as well as being written by people who know what they are doing, means that it has a chance to become a widely used system in the future. As the past manager of the production Java virtual-machine team, I can assure you that I have seen the real-world consequences of people hacking away freely on core software that they didn't think would be used widely, and it isn't pretty. Sorry if I assumed that the integrity of Squeak's core libraries was important. Cheers, Dave

1 0

Starting the clock...
by Alan Grimes 30 Aug '02

30 Aug '02

om I think that all I need to do now to get morphic working in my AI window is to start the stepping clock... However the most obvious methods for doing this are still in beta, as I discovered. =\ Here is my init method: > initialize > "Try to make an space. > | ex > ex _ 400@300 > super initialize. > self image: (Form extent: ex depth: 8). > super extent: image extent > self isOpaque: true. > > "Try to set up morphic" > AICanvas _ FormCanvas on: image. I am fairly certain it works to this point because sending a message to change the fill color to AICanvas changes the color of the rectangle on the screen. -- AFTER I CLICK ON IT!!! > AIWorldState _ WorldState new > canvas: AICanvas > MorphicWorld _ PasteUpMorph new > initForProject: AIWorldState; > extent: ex; > color: color; > startBackgroundProcess. I don't know what to do after this step or even if I am emotely on the right track at this juncture. I have been comparing the structure of the mini-morphic I am trying to set up to the project structure and have found that they are identical. =\ The only difference I have discovered is that the world morph of the project is getting clock ticks from somewhere by some method while the counters in the mini-morphic are stalled. Again, this is in persuit of my goal of setting up a visable field for the AI to play with. BTW: I realized that my Squeak v3 sources is not the curren Squeak V3 sources... A more useful file-name would be appreciated. =\

1 0

Re: Debugger for Windows VM
by Anthony Hannan 30 Aug '02

30 Aug '02

Anthony Hannan <ajh18(a)cornell.edu> wrote: > Taking strip out of the make allowed cygwin gdb to read the debugging > info; thanks guys. But now gdb runs really, really slow, after it gets > past opening the Squeak window (to slow to use). Any ideas? Do I have > to fix majorShrink and run it on a shrunken image? Would that even > help? Let me correct my report a bit. gdb only slows down once it halts on the seg fault error, before that, even with the Squeak window open and operating, things are fast. But once the seg fault is reached my whole machine slows down terribly to an unusable state, and peculiarly, my disk doesn't thrash at all. I was able to kill gdb and then my machine worked fine again. Perplexed, Anthony

1 0

Re: Design Patterns and Collection Classes
by Richard A. O'Keefe 30 Aug '02

30 Aug '02

Helge.Horch(a)t-online.de (Helge Horch) provided LessPvt.1.cs. Ta muchly. >Anyone read the paper about Smalltalk collections in OOPSLA 92? I googled that you probably meant William R. Cook's "Interfaces and Specifications for the Smalltalk-80 Collection Classes", and CiteSeer was able to come up with a location on the web. A *very* interesting read indeed. That's the one.

1 0

Re: [BUG] WorldWindow not correctly drawn.
by Bob Arning 30 Aug '02

30 Aug '02

Alan, That thing was only a brief experiment and probably doesn't work. The better way to get something like that is to click and hold on a ProjectViewMorph, wait for the menu to pop up and select 'ENTER ACTIVE'. Cheers, Bob On Thu, 29 Aug 2002 18:01:52 -0700 Alan Grimes <alangrimes(a)starpower.net> wrote: >When I do: > >ATest _ WorldWindow new openInWorld. > >I get a really messed up system window. > >The class comment which is there (YAY!!!) says it should have a red bar >which changes color when it is given focus. > >It does the exact same thing with my clean control image. > >Does anyone else have the same problem?

1 0

← Newer
1
2
3
4
5
6
7
...
54
Older →

Jump to page: