Squeak-dev September 2002

squeak-dev@lists.squeakfoundation.org

165 participants
288 discussions

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

13 Oct '02

Lex Spoon <lex(a)cc.gatech.edu> wrote: I still think it's likely -- it's the way I code, and it's the way I've heard many people suggest coding. When you do a rewrite by inline expansion of a method, do you always throw away the assertions, error checks, and guard code? Because that's what's needed for this example. It's unreasonable to do full proofs of correctness, and it's unhelpful to point the finger and say it's so and so's responsibility to do such an unreasonable thing. Nobody has suggested proofs of correctness, only (1) reasonable testing and (2) not throwing away guard code. | x | x := self allFooishMembers. self removeNonTrueBelievers. "at this point, is x the same as it was up above? you'd like it to be!!" This is discussed in the Smalltalk Style Guide, which is currently at home or I'd cite the page number. I argued at length (only to be jumped on hard by A----- G-------) that objects shouldn't hand out references to their innards, and if they do, they don't have a usable class invariant any more. In different language, the Smalltalk Style Guide suggests handing out _new_ collections as a good thing to do. While I know that C++ 'strstream' is frowned on, it does count as an example. Once you ask for (and are given) a reference to a ostrstream's buffer, that's practically _all_ you can do with the ostrstream thereafter.

5 7

Laptop suspending and network drives
by Michael Roberts 03 Oct '02

03 Oct '02

Hi, I was playing within Squeak, on a win2k laptop, with an image I had shared over a network. I then suspended the laptop, with Squeak running, and brought the machine back to life some time later. I started to get primitive errors along the lines of write's failing. This was a felt a bit odd for a while as I was only writing to the Transcript. When I tried to save my image, however, I realised that it was probably due to suspending the machine and I was unable to save the image. I tried to find a way of saving to the local drive but wasn't able to figure that out. I didn't have anything particularly serious to lose to I quit the image. I was wondering if this was a known issue, or has cropped up before? It seems a bit of a daft thing to have done, in retrospect, but it would be nice to be able to fix this or have some work around. Any thoughts much appreciated Cheers Mike

5 14

OOPSLA BOF scheduling
by Martin McClure 03 Oct '02

03 Oct '02

As I prepare once again for OOPSLA (if you haven't yet registered, last day for the early-bird discount is the 26th) I've started thinking about the Squeak BOF, always one of the highlights of OOPSLA. Over the past few years it seems like it's gotten harder to find a good time for the Squeak BOF, so I'm hoping to start discussion early enough that we can find a time that most folks can be there without missing something else near and dear to their interests. The "traditional" time for the Squeak BOF is on Tuesday evening, which is on a Wednesday this year. (okay, not quite, but close. Most OOPSLAs of recent years run Sunday through Thursday. This one runs Monday through Friday, so everything is pushed back a day.) The past couple of years there has been some competition for that evening, since Cincom has scheduled a reception and presentation on that evening as well. This year, Cincom and GemStone are hosting an event from 7-9pm Wednesday at the Sheraton. I'm hoping that the Squeak BOF isn't at the same time, because I want to go to both. Looking over the schedule (available at oopsla.acm.org) the only times that don't conflict with *something* are in the middle of the night. There's even an invited talk scheduled Wednesday evening opposite the Cincom/GemStone bash. My opinion at this point is that we might want to have the BOF during the day, conflicting with papers, panels, and such. Others may have different opinions, which is why I'm starting this discussion. My personal preference at this point is for Friday morning, 10:00 to 12:00. -Martin

7 10

Is Squeak usable on Sharp Zaurus SL-5X00
by Andy Stoffel 03 Oct '02

03 Oct '02

I see from browsing the list back in August (Aug 7th-10th) that several people were talking about running Squeak on the Linux version of the Zaurus and I found several references here: http://minnow.cc.gatech.edu/squeak/2437 And (looking for an (additional) excuse to pick up a Zaurus this weekend...) I was wondering if anyone had Squeak running better on it than was reported back in August ... and... (besides 'where can I get it from') which is the best technique to have it running - frame buffer or Qtopia (X) and drawbacks of either. Thanks :-). -Andy-

4 7

[Q] Will somebody pleas review my changesets?
by Torge Husfeldt 02 Oct '02

02 Oct '02

Hi group, I know, you are all probably very busy, but I don't think i'm expecting too much when i wish for one single member of this mailinglist to at least read my mail and comment on my changeset. In the past few weeks i have posted two cs that were explitly requested by list members and i didn't even get an ack. These were: [Enh]shrinkingSelection and WordprocessorStyleCursorMovement (in reply to: Text selection by: Tommy Thorn) http://swiki.gsug.org:8080/sqfixes/2657.html and: Re: is subclassing Project OK? (in reply to a message of the same Subject by Ned Konz) http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-August/017398.h… respectively. There is a new message upcoming subjected: "[Enh]Auto Scroll" that i would like your opinions of, too. Please note that i am not expecting much. A simple note of the form - you are reinventing wheels here look for <searchString> in [Google|Swiki|mail-archive|other] - i tried it in <version-information> and it didn't work/filein due to [<short error description>|<walkback>] - inoticed your work and will probably try later (a bit unsatisfying but i would settle for it) would suffice. Please note also that i have invested some ours of work (ok, it was fun too) in these and am a bit disappointed to see them pass completely unnoticed. Hope to hear from you soon, Torge

3 2

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

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

[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

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

[BUG] PasteUpMorph becomes a Sketch (Etoy)
by Bert Freudenberg 01 Oct '02

01 Oct '02

When a Playfield is told to "look like" another morph it becomes a SketchMorph. I'd expect it to just change its appeareance. That is, it should change its sticky background morph to look like that other Morph. This would be consistent with the fact that I can just paint on it via the halo, which actually paints onto the background morph. I'm not quite sure where to hook into, so no fix yet. -- Bert

2 2

Jump to page: