Squeak-dev September 2002

squeak-dev@lists.squeakfoundation.org

165 participants
288 discussions

Seaside sans Comanche
by Helge.Horch＠t-online.de 05 Sep '02

05 Sep '02

Folks, when playing with Seaside in an image that didn't have Comanche loaded, I experienced a couple of hiccups during image shutdown and startup. I was using Seaside with PWS only, and the code referenced ComancheNetService in a couple of methods. So, if you too intend to try Seaside without loading Comanche, the attached changeset might come in handy. Cheers, Helge

1 0

applescript plugin
by Rob Whitfield 05 Sep '02

05 Sep '02

I'm trying to get the applescript plugin to work but I'm having problems. I followed your directions for installing the applscript plugin that are posted at http://swikimirror.squeakspace.com/852.html It seems that I need a cs or something since there doesn't seem to be anything named "Applescript" in my image. In other words, the command "Applescript initialize" fails with "Unknown variable: Applescript". I'm running 3.2 I tried sending mail to Andrew Greenberg using werdna(a)gate.net but the email was undeliverable. Any suggestions?

4 5

FileList2-enh-asm
by Magistrello Alejandro (SFA) 05 Sep '02

05 Sep '02

This cs adds a method to FileList2: FileList2 modalFolderSelector: 'A more descriptive text to choose a folder' <<FileList2-enh-asm.zip>> Best regards Alejandro

1 0

[FIX] IntegerFromBytesFix-sr
by Stephan Rudlof 05 Sep '02

05 Sep '02

"Change Set: IntegerFromBytesFix-sr Date: 2 September 2002 Author: Stephan Rudlof Fixes a bug creating LargeIntegers, where they should be SmallIntegers. Probably not detected before, since LargeIntegers are normalized frequently. Try: | val | val _ SmallInteger maxVal. {val. val + 1} collect: [:arg | (Integer byte1: (arg digitAt: 1) byte2: (arg digitAt: 2) byte3: (arg digitAt: 3) byte4: (arg digitAt: 4)) class]. before and after filing in." Note: made with 3.2. -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

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

05 Sep '02

Preliminary: This thread is not about #removeAll:, but about how to read standards. "Andrew C. Greenberg" <werdna(a)mucow.com> wrote: But the ANSI standard does not, in fact, admit such a dodge. Indeed, it DEFINES removeAll: as "the equivalent" to an iteration over the elements of the parameter, No, it doesn't. More precisely, as I have already pointed out, it doesn't define it as equivalent to an INTERLEAVED iteration and removals. as a call of #remove for each such element. Specifically, it says that, "[t]he operation is defined to be equivalent to removing each element of oldElements from the receiver." Right. I depend completely on that for my reading. In particular, I claim that removeAll: oldElements |togo| togo := OrderedCollection new. oldElements do: [:each | togo add: each]. togo do: [:each | self remove: each]. ^"some unspecified result" implements precisely the semantics required by the ANSI standard. I also claim that oldElements copy do: [:each | self remove: each] implemenents precisely the semantics required by the ANSI standard. "each element of oldElements" is visited; the text says nothing about sending any enumeration message to oldElements itself. What's more, the ANSI standard very carefully refrains from saying that there is any call to #do: whatsoever. It says "removing each element of oldElements", but for example it says nothing about the order in which they are removed. It doesn't even say that #remove: is called. It says that it is "EQUIVALENT to removing each element ... from the receiver using the #remove: message...", which only requires it to have the same effect as using #remove: would have had. (It is the fact that it doesn't say that #do: is used which means we have no reason to expect a Stream argument to be accepted.) This is the kind of language that other standards use with the intent of allowing radically different implementations that have the same externally observable effect. And for Set, Bag, Dictionary, and OrderedCollection, we know perfectly well that it is possible to get precisely the effect (precisely the sequence of #remove: calls if we choose to take them literally) without ever iterating over the argument as such in the case under consideration. 3) The ANSI standard section 5.7.5.5 explicitly defines "removeAll: oldElements" as an iteration over the elements of oldElements, sending for each such element, say 'each', the message #remove: each. It _does_ mention an iteration over a sequence of elements; it does _not_ mention an iteration over the oldElements object itself. And that's a big difference. The way it seems that such care was taken to avoid calling for a #do: over oldElements itself speaks against Greenberg's reading. And the way such care _seems_ to have been taken never ever to require the iteration and the removals to overlap in time also speaks against that reading. If a simple #remove:-inside-#do: were intended, why didn't they just say "it's exactly as if you had [explicit code]"? When someone goes to such pains to avoid the obvious, you are entitled to assume that they don't intend all the implications of the obvious. (And if they _did_ intend that, it's not the reader's fault.) While one can quibble over the truth of proposition 3, Nobody can reasonably quibble over the truth of proposition 3. But to support your argument, you need the text to say that THE REMOVALS MUST OVERLAP IN TIME AN ACTUAL ITERATION OVER THE ARGUMENT OBJECT (not a copy). And proposition 3 does not involve that at all. one must accept, at least, that it is a fair argument, Fair, yes. Honest, yes. Radically flawed, in that the desired conclusion doesn't even come close to following from it, that too. In particular, the implementation removeAll: oldElements oldElements copy do: [:each | self remove: each] fulfils _every_ requirement of the standard. I'm told that in international law, there is a principle that treaties ought to be interpreted to favour the weaker party. That is certainly how the Treaty of Waitangi (very important in this country) is interpreted. Apply that principle to standards, and you see that vendors are the stronger party (very very much so if the ANSI committee would not have considered requiring vendors to make a one-line fix) and users are the weaker party. If there is a natural reading of a standard that provides more useful guarantees to the users, and a reading that lets vendors get away with quietly returning nonsense answers, the better reading is the one that favours the customers. In particular, if there is a group who have taken on themselves the responsibility for identifying undefined/UNSPECIFIED cases, they have accepted the responsibility for identifying ALL of them, and if some part of the specification can be read naturally as leading to a defined result, WHATEVER the operation in question, whether I personally like the consequences or not (and I've been a language implementor, although not a Smalltalk implementor), then it should be read as defined, not as undefined. The overwhelming context for #removeAll: (and perhaps more importantly, for #addAll:) is a standard where the authors have gone to the extreme of inventing new notations in order to spell out which cases are undefined, and purport to have given full lists of undefined and erroneous cases for these particular operations. We are entitled to _believe_ them about this. I must refer again to Wirfs-Brock, who told us that the committee overlooked these cases, and probably _would_ have listed them as undefined (rather than make implementors introduce one-line fixes). I must also point out again that the authors' intentions or lack of them are not, in fairness, allowed to influence one's reading. What the authors _would_ have done had they thought of it is not what they _did_ do, and when interpreting a standard, you have to deal with what they _did_ do. (I, for one, find it compelling, but reasonable people, apparently, may differ.) Did you know how #removeAll: worked _before_ you read the standard? Are you sure that does not influence your reading? Because I have as yet been unsuccessful in finding _anyone_ who reads the standard as allowing, let alone requiring, a 'hole' in the specification. And believe me, I've tried. By now I've asked about 60 people. Accordingly, it seems to me that the argument that "failure" of "x removeAll: x" is clearly and in black-and-white a bug is, at best, overstated. Well, the claim that it was a bug never did depend on the ANSI specification. It depends on the Smalltalk textbooks and manuals never ever mentioning any exception. It depends on the fact that the present behaviour of removing odd elements and leaving even ones in place is not what anyone expects. Had the ANSI standard said anything which could have been interpreted by anyone not already familiar with implementations as leaving this case unspecified, that would have been that. It would have been a nonsense result, but it would have been _official_ nonsense. The thing would still have _been_ a bug, but a refusal to fix it on the grounds that "ANSI Smalltalk says we don't have to" could have been defended, but even then it would have been necessary to say "It is time the reference manuals and textbooks were amended." Now we have the far more serious question: Is a Smalltalk programmer forced to concede that the ANSI Smalltalk standard must be interpreted in the light of details of how the operations were implemented prior to the standard, hence always in the favour of implementors? I find it fascinating that I have yet to find anyone who sees the apparently obvious, even "compelling", hole-in-the-specification in the ANSI Smalltalk text, _except_ for some people on this list. Even when you point it out to them, people here say something like "well, but that's a bit twisted". There's a sort of groan in it, like someone who has just heard a really stupid pun. This obviously raises the question of what _else_ people read differently about the ANSI Smalltalk standard.

5 7

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

Re: MVC Browswer 'Double Take'
by Bob Arning 05 Sep '02

05 Sep '02

On Wed, 4 Sep 2002 13:15:25 EDT Mark4Flies(a)aol.com wrote: >I just noticed that the System Browser in a MVC project jumps twice (up or >down direction) every time I click above or below the scroll rectangle in the >scroll bar when the up or down cursor is showing. Try it! > >I studied the code. (New part of Squeak for me.) I could not find any obvious >reason for this behavior. This is normal. In MVC, the scroll amount is proportional to the distance between the top of the scroll bar and the mouse click location. The lower down you click, the farther you go. See implementors of #scrollAmount. Cheers, Bob

3 2

Re: String>>hash performance
by Richard A. O'Keefe 05 Sep '02

05 Sep '02

>Squeak 3.2, latest update: #4952, >on a 266 MHz Power Macintosh G3 running MacOS 8.6. >The application folder is "Squeak 3.2.7Beta6.app". >The whole thing was downloaded from st.cs.uiuc.edu. Hmm... just to be sure, you are running Squeak 3.2.7Beta6 and still getting 'MiscPrimitivePlugin 30 May 2001 (i)'? I just fired up the same VM and got 'MiscPrimitivePlugin 9 May 2002 (i)'. Is it possible you have more than one VM and it's the other that's actually running? That's _it_! I am a bear of very little brain. If I'm told "download this, run it by clicking on the .image file", that's what I do, no more, no less. I have Squeak 2.7, Squeak 2.8, and Squeak 3.0.1 all on the same machine. (Mind you, I haven't actually _used_ 2.7 in a while, but I have been flipping beween 2.8, 3.0.1, and 3.2 to make sure things worked in all of them.) I've never had a problem with multiple versions of other programming language environments. (For example, I have two versions of CodeWarrior, three versions of Clean, and who knows how many of other things.) It hasn't been a problem because I start them by clicking on the _application_ icon. In retrospect, MacOS was *telling* me that it was the 3.0 VM, but initially I didn't know that the 3.2 VM was supposed to be different, and by the time I did, I was long past noticing what MacOS was telling me. What should I do so that clicking on a (2.8,3.0,3.2) .image or .changes file will start a (2.8,3.0,3.2) VM? Or should I care? Will the 3.2 VM handle all of them? How then do I make MacOS use the 3.2 VM?

1 0

MVC Browswer 'Double Take'
by Mark4Flies＠aol.com 05 Sep '02

05 Sep '02

I just noticed that the System Browser in a MVC project jumps twice (up or down direction) every time I click above or below the scroll rectangle in the scroll bar when the up or down cursor is showing. Try it! I studied the code. (New part of Squeak for me.) I could not find any obvious reason for this behavior. -Mark

4 3

Questions about #do: (was: Re: [BUG]Collection>>removeAll:)
by Richard A. O'Keefe 05 Sep '02

05 Sep '02

Wim Boot <wim(a)lombok.demon.nl> wrote: If you propose a change here, could you make sure that the following code also works? | c | c := #(1 2 3) asOrderedCollection. c removeAll: c readStream. With the change I have described to #removeIndex:, this could work, except for one thing. The argument of #removeAll: is supposed to be a Collection. Oh, I see, #do: _is_ in ANSI 5.9.2. However, #removeAll: is _not_ defined to actually use #do: (only to work on the elements of a collection in the same order) and its argument must support _all_ the methods of the <collection> protocol, which ReadStream doesn't seem to. But there is still a problem, and it's a general problem with streams. I'm replying to this because it illustrates an important point about streams that is not at all obvious to beginning Smalltalkers. If you accept that "when YOU iterate over a collection, YOU shouldn't change it", which I do, then you also have to accept that "as long as a stream is open on a collection, you should not change that collection" because a stream is precisely an iteration device. (Indeed, C++ calls them 'iterators', and so does Java these days.) So as soon as we have 'c readStream' in our hands, we must refrain from _any_ attempt to modify c by _any_ means until that stream is dead. c := #(1 2 3) asOrderedCollection. s := c readStream. c remove: 1. s next is also banned; it's not removeAll: as such that is the problem. The viewpoint I'm adopting here is that as soon as you invoke #readStream, you have started an _explicit_ iteration, and it is up to you to ensure that the underlying collection isn't changed until you've finished your iteration. This is consistent with my stand on #removeAll:, where I argue that a programmer should not be bound by the constraints of an iteration that s/he has not started, cannot see, and might not even exist. I note that a Java Iterator would notice the change and raise an exception. Basically, Java collections keep a count of the number of changes they've had, and Java iterators remember what that count was. You can make some changes through an iterator, and the remembered count will be updated. Any other changes will be squawked about, loudly. In fact we _could_ make the #readStream case work. It wouldn't even be particularly hard, except that the result would not be an instance of ReadStream. I'm not going to go into detail, because I think the case where there _is_ an explicit iteration in progress is different from the case where there is not. This brings me to some questions about #do: which I've been meaning to ask. When I ask about "general expectations", I am _not_ talking about language standards, and I am not talking about exceptionless rules; what I'm basically after is what assumptions do you make unless you think really hard about them? 1. Is there a general expectation that if you call #do: once, and do not _yourself_ change the object you sent it to, you can do it again and get the same answers, apart from their order? - This is clearly violated by Stream>>do:, but do people find that _surprising_, as I do? 2. Is there a general expectation that if you call #do: once, and do not _yourself_ change the object you sent it to, you will get the same answers _in the same order_ when you send it again, even for a non-sequenceable collection? - This is violated by my NewSet class, thanks to its use of the move-to-front heuristic, and it may be violated by other self-organising containers. 3. Is there a general expectation that if you call #do: the receiver will send messages only to itself, "structural" objects that it owns exclusively, and immutable objects such as numbers? - This is violated by any class you have put debugging print statements in, but that may be harmless. It is certainly violated by MappedCollection. Is that surprising? 4. Is there a general expectation that if you call #do: you may safely send 'query' messages to the receiver, message that do not change its _abstract_ state? - This is violated by NewSet again because of its self-organising nature. You _can_ ask about the element that is currently being scanned, you can even _remove_ that element, but if you _ask_ whether some other element exists that may confuse the iteration. Is that OK or do I have to put a lock around move-to-front while iterations are in progress and use exception handling to make sure the lock is clear when all iterations are over? 5. Is there a general expectation that iterating over N elements using #do: is (amortized) O(N)? - This is violated by the existing Set class in Squeak. The cost is proportional to the _maximum_ number of elements the Set has ever had, not to the number it has right now. Is that surprising? 6. Is there a general expectation that sending query messages to the receiver during an iteration doesn't change the cost of #do:? - Not true in NewSet. Also not true in Eiffel's SET class, even though it isn't self-organising. (It has a cache, and queries can invalidate the cache.)

8 10

← Newer
1
...
22
23
24
25
26
27
28
29
Older →

Jump to page: