Squeak-dev October 2002

squeak-dev@lists.squeakfoundation.org

183 participants
406 discussions

Re: [FIX] SortedCollectionFix-sr
by Richard A. O'Keefe 02 Oct '02

02 Oct '02

I noted that SortedCollection>>reversed produces an invalid answer. Stephan Rudlof <sr(a)evolgo.de> replied: There may be a problem: if you apply >>reversed multiple times the opposite comparison sortBlock becomes bigger and bigger, if the implementation just inverts it by constructing a new one with sending #not to the old. As you say, IF. (Although #not is DEFINITELY the wrong thing to do. We want to turn <= into >+, not into > .) There are other implementations possible, though. And indeed there are. One of them is to introduce a new class Object subclass: #BinaryBlockConverse instanceVariables: 'block' .... beConverseOf: aBlock block := aBlock converse ^aBlock value: x value: y ^block value: y value: x class>> of: aBlock ^self new beConverseOf: aBlock and a new method in BlockContext converse self assert: [self numArgs = 2]. ^BinaryBlockConverse of: self I've just sent a change set "converse-raok" that basically does this. (No, it doesn't change SortedCollection reversed.)

2 1

Squeak+Event+Dependencies: The solution
by Stephane Ducasse 02 Oct '02

02 Oct '02

Hi all just to pass the information about how to use event to implement dependency mechanism. I wrote a wiki page 1214 (I fleshed Squeak+Event) Here how to use event to have a changed, update: behavior. This is the way to avoid all these ugly update methods full of case statements. The dark is losing a bit today. MyModel>>lifes: aNumber lifes := aNumber. self trigger: #lifesChanged. MyUI>>initialize super initialize. domain := MyModel new. domain when: #lifesChanged send: #lifesChanged to: self. MyUI>lifesChanged lifeDisplay value: domain lifes Take care the following in for Squeak32 the interface slightly changed in 3.3 Other event pages: *http://minnow.cc.gatech.edu/squeak/2700* *http://minnow.cc.gatech.edu/squeak/2477* Have fun. May be now we should get rid of all the update and changed: methods. :) 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

2 1

RE: [FIX] SortedCollectionFix-sr
by Richard A. O'Keefe 02 Oct '02

02 Oct '02

With an eye to producing a new version of SortedCollection, I spent a couple of hours yesterday going through all of the methods in SortedCollection + all those inherited from OrderedCollection + all those inherited from Collection. Like other core collection classes, SortedCollection turns out to be, um, less than robust and less than consistent. My current "favourite" is this: s := #(1 2 4) asSortedCollection. s collect: [:x | x] ==> an OrderedCollection(1 2 4) s with: s collect: [:x :y | x] ==> a SortedCollection(1 2 4) Surely they should return the same kind of object! This is the underlying reason why s := #(1) asSortedCollection. s + 1 ==> an OrderedCollection(2) s + #(1) ==> a SortedCollection(2) which leads to #(1 2 3) asSortedCollection + #(-2 -4 -6) ==> a SortedCollection(-1 -2 -3) which is in fact NOT sorted (it has a nil sortBlock). The simplest solution would seem to be to make #with:collect: also return an OrderedCollection.

2 1

Re: [FIX] SortedCollectionFix-sr
by Richard A. O'Keefe 02 Oct '02

02 Oct '02

I wrote: > To expand on this a little: why not give programmers a way to build > a sorted collection in linear time when they are able to provide data > in the right order? Stephan Rudlof <sr(a)evolgo.de> wrote: I'm not against this. But please don't use addLast: for this. I don't see any reason why not. It perfectly expresses the intent. It's an existing method. The last thing we need is lots of twisty little methods all slightly different. However, the _best_ approach is to have _no_ such methods but simply to make #add: work efficiently. (This illustrates why jumping into the first patch one thinks of is not such a good idea.) > - we should avoid introducing operations that often don't work Agreed: this is my point regarding >>addLast: introduced for SortedCollections: it always works for OrderedCollections, but only in very special cases, if applied to SortedCollections. I am opposed to *introducing* such operations. > - but when we are stuck with an operation that CAN be allowed to > proceed some of the time we should not be strict bondage and > discipline nannies and stop sensible programmers doing sensible > things. This is a contradiction to the previous point: 'proceed *some* of the time' ('*' by me) violates the goal to 'avoid introducing operations that often don't work'. Not a contradiction at all. I wasn't suggesting *introducing* such an operation, but fixing an operation that *already exists*. > The attitude here is > - I am like God; I know exactly how programmers think and they mustn't. I know what I expect from calling >>addLast:. And I know what I expect. However, I don't know what you expect; you don't know what I expect, and neither of us knows what Jill Neighbour expects. What matters is what's *documented*, not what we think she expects. > Using >>addLast: for a SortedCollection means to try to give an > explicit order to something, which has an automatically 'built > in' one. This mostly is a programmer error. > > I am not sure how to interpret "mostly" here. > If it is an empirical statement about how often it does happen, > then I would be intrigued to know where the evidence came from. It's not an empirical statement. For me it is a convention to expect an OrderedCollection if using >>addLast: (also see below). If it's not an empirical statement, we don't have any grounds for a 'mostly' here. As for "if method is #addLast: then receiver is OrderedCollection", so much the worse for B3DFillList LinkedList POSimplePolygon and RunArray, eh? (I'd agree with you that LinkedList is unlikely, but can we really afford to forget about RunArray?) My point is: if I'd use >>addLast: I'd expect an OrderedCollection, *not* a SortedCollection. Again, RunArray>>addLast:. If I understand you, you are basically saying that whatever Smalltalk thinks to the contrary, SortedCollection isn't _semantically_ a subclass of OrderedCollection. And ANSI supports this kind of view. I am very keen on arguments from the ANSI standard. But I'd really like to see chapter and verse on this one. I still don't have a copy of the final standard, but the 1.9 draft says some funny things about SortedCollection. For example, it says of "x, y" when x is a SortedCollection "Answer a new collection containing all of the receiver's elements in their original order followed by all of the elements of operand, in their original order." but also says "Since the receiver sorts its elements, the result will also be sorted as defined by the receiver's sort block." (Yes, I've read the other bits here.) Now it seems to _me_ that redefining concatenation to be merging is bad practice; an intention revealing name should be used. Note that it isn't a simple matter of concatenating or even of merging two sequences; if the operand is not itself sorted it must be sorted. The ANSI specification of #copyReplaceAll:with: is rather puzzling. Basically, aSortedCollection copyReplaceAll: aSortedSubsequence with: elements does this: if aSortedSubsequence occurs as a subsequence of aSortedCollection, remove those elements, then send addAll: elements to aSortedCollection otherwise make no change. Now this example is very much apropos. It takes a method which is normally thought of as strongly positional, 'abcd' copyReplaceAll: 'bc' with 'xyz' ==> 'abxyzcd' NOT 'abcdxyz' keeps the positional search part, and turns the normally positional replacement part by a sort/merge part. In the same way, aSortedCollection copyReplaceFrom: start to: stop with: elements chops out a positionally determined subset, then does a non-positional add. If we took this as our model, then #addLast: would be allowed and would be identical to #add:. (NOT a change I favour.) What we _do_ want for sorted collections, and are not given by ANSI, is methods that copy or remove a slice based on element contents rather than element positions: aSortedCollection copyAbove: minval below: maxval aSortedCollection removeAbove: minval below: maxval or something like that. > "performant" is, to the best of my knowledge, not an English word. > I certainly haven't been able to find it in any of the paper or > electronic dictionaries I've just checked. Try "faster". I'm wondering, because Leo knows it: http://dict.leo.org/?search=performant&searchLoc=0&relink=on&spellToler=sta… But it may be wrong: you are the native speaker! I note that LEO is provided by a German university. The page I get there when I search for 'performant' does not give any citations or definition. The little 'm' points to the Merriam-Webster dictionary, which is one I checked, and it says quite plainly "The word you've entered isn't in the dictionary." It appears that "Performant" is a German word masquerading as English. I have no idea what it means in German. Perhaps it is a word English needs. But I stay at my assumption to expect an OrderedCollection if using >>addLast:. And if you introduce methods *** with the same name *** in other protocols you break conventions (and ANSI is also a convention). You only break conventions if you do not follow the conventional rules about refinement. The way ANSI refines methods for SortedCollection provides ample precedent for refining the *inherited* (NOT "introduced") method #addLast:. As noted above, some of the ANSI refinements for SortedCollection strike me as bizarre. Order-respecting #addLast: is almost unbelievably tame by comparison.

5 5

Serious Games: Improving Public Policy through Game-Based Learning and Simulation
by Bruce O'Neel 02 Oct '02

02 Oct '02

While reading the PDF file at the following link it seemed that Squeak might be useful here. Plus it seems that there are organizations that might want to fund these sorts of experiments. http://wwics.si.edu/foresight/game/index.htm cheers bruce -- Reality is 80m polygons - Alvy Ray Smith Bruce O'Neel phone: +41 22 950 91 57 INTEGRAL Science Data Centre +41 22 950 91 00 (switchb.) Chemin d'Ecogia 16 fax: +41 22 950 91 35 CH-1290 VERSOIX e-mail: Bruce.Oneel(a)obs.unige.ch Switzerland WWW: http://isdc.unige.ch/

2 2

[ANN] Logic Circus are ready
by Lic. Edgar J. De Cleene 02 Oct '02

02 Oct '02

I complete our delayed Logic Simulator using a bad mix of Smalltalk and stepping methods. The exampe is for a decoder on page 105 of Micro-Processors And Logic Design by Ronald L. Kurtz. Dedicated to all members of this list what kindly help me , Ned , John, Goran , Diego and others . Edgar

3 4

"reply-to" discarded on my previous two messages
by Craig Latta 01 Oct '02

01 Oct '02

Hi-- More FYI... In my previous two messages, I set the "Reply-To" header to the Flow mailing list (flow(a)netjam.org), so as not to clutter squeak-dev, but they seem to have been coerced to squeak-dev by the squeak-dev mailing list server. 'Sorry for any inconvenience, -C -- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

re: #next, #next:
by Bill Schwab 01 Oct '02

01 Oct '02

Craig, Yes, I did mean 'abc' readStream next:5 ~:( It's good to know that Flow considers exhaustion to be an error. Re my problems in stalling Flow, it _appeared_ to load correctly, but then workspace evaluations were broken. There was some problem with obtaining the selection. From what I recall seeing in the debugger (which was able to open), my first guess is that something didn't compile, or at least not correctly. I'll have another run at and let you know what happens. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bills(a)anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

3 2

re: #next, #next:
by Bill Schwab 01 Oct '02

01 Oct '02

Stefan, Thanks for the suggestion. For now though, installing Flow so badly breaks my image (could easily be my fault or simply the result of something that I added) that any DoIt results in a walkback. I need to go though it again carefully and check for logs, output in the transcript, etc. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bills(a)anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

2 1

Reminder: Ottawa Carleton Smalltalk Users Group meeting Oct 3
by David Buck 01 Oct '02

01 Oct '02

Reminder: (Please email david(a)simberon.com if you plan to attend). The Ottawa Carleton Smalltalk Users Group will be holding its first meeting since the summer break on Thursday, Oct 3, 2002. ElastoLab - A Physics Playground for Kids David Buck Simberon Incorporated ElastoLab is a shrink-wrapped VisualWorks application that allows kids to design their own 2D scenes that incorporate physics elements like particles, springs, and gravity and lets them see their scenes animate in real-time. Originally written in C++, it was later completely re-written in Smalltalk. David will be talking about the development history and the design challenges in writing ElastoLab. The talk will explain: * how to interface to the Windows sound facilities from Smalltalk * how to make graphical applications run quickly * how to package a Smalltalk application for release * developing help facilities and guided tours * using the web toolkit to develop a message board on the Internet for ElastoLab. A CD-ROM of the ElastoLab demo version will be available to all attendees. Date and Time Export Development Canada 151 O'Connor Street Ottawa, Ontario Thursday, Oct 3, 2002 7:00 p.m. (please arrive by 6:45) Please RSVP to david(a)simberon.com if you plan to attend.

4 5

Jump to page: