Squeak-dev July 1999

squeak-dev@lists.squeakfoundation.org

139 participants
367 discussions

Working Together - an Initial Project List
by Dan Ingalls 01 Aug '99

01 Aug '99

Folks - The test-pilot version is nearing what I would call 2.5 beta status, following Craig Latta's terminology. We just have a few more outside contributions to funnel in and a bit more work to do on a World-within-a -world window for Morphic. I will announce when I think we're at that point, we'll see what bugs surface for a few days, and then we'll wrap up images and VMs for the release of 2.5. In order to expedite the completion of 2.5, we decided to sidestep a number of larger projects that are of great importance to many of us. With this message, I would like to return to those larger projects, and move forward with my proposal of 7/13... >My proposal is that we identify a list of such projects (we have a start already) >and then, for each one, identify a group of 3 to 5 competent people to carry it >through to completion. I'm going to suggest that one of these people be from >Squeak Central, even if they don't actually do any coding. This will ensure that >any concerns we have will get addressed, that we can track the progress, and >that whoever is doing the hard work will know there is buy-in at Squeak Central >from the start. As used above, "to completion" means that it's ready to be >issued as an update to the test pilots. At the end of this message is a preliminary list of these major areas. I would appreciate it if people would respond DIRECTLY TO ME if they wish to help with specifing goals, implementation, Q/A on any specific projects. I will do my best to coordinate formation of appropriate working groups and to keep everyone informed as things take shape. I've never been one to tell others what they can and cannot do, but it will surely reduce traffic on this list (and thus save us all time) if those with a casual interest in the topics below would refrain from broadcasting their many useful suggestions at this point. As each of the various project teams congealeds, they will presumably send out a summary of their intentions and that would be the appropriate time for criticism and suggestions. I have probably omitted one or two project areas that should be included as formal Squeak Projects at this level. If so, let me know. Here's the list... ------------------- Exceptions This could be one of the first projects to make it into the base image. There are two reasonably complete implementations one of which is already ANSI compliant. Block closures Several people have made stabs at this. There are several levels to deal with: accepting the syntax, compiling the code, implementing one or two new bytecodes, and integration with JITTER. Tim's new compiled method format While Tim seems to have done most of the work already, this involves a major image format change, so we might want to bundle in the other cleanups we have been saving for such a time. Therefore this naturally belongs with a move to 3.0. Real events from the OS The real goals are: don't miss events, have access to useful other events (like window reframe), and still be fairly simple to port to bare chips. Several stabs have been taken at this. Having caucused with the rest of Squeak Central, we would like to be the inplementors on this, but we welcome suggestions and especially tips on specific platforms. We beg your indulgence until we finish the major competing project. Proper sockets The major problem is that until now there hasn't been a BSD accept()-like call (which made it possible to miss connections). Update 1328 allows for such a call *optionally* in ConnectionQueue so if you have it then everything is fine and if you don't you just go the way it has been before. There is a much larger issue of a complete rewrite (along the lines of Craig Latta's Correspondents), and also of a general File System rewrite. We probably need to discuss each of these more fully with regards to pros and cons and urgency. As Craig has pointed out, we will have to move the Mac to OpenTransport when support for MacTCP goes away anyway. Postscript Support Marcel Weiher has had several working versions of PostscriptCanvases, and we owe him (and all of us) the chance to address any design requests, and finally get it into the base image. NameSpaces and Packages I had planned to do this, but others in Squeakville have more experience than I. My goal here is to do the simplest thing that provides the major benefits, and tie it somehow into both the image segment loading facility and the new isolated projects capability. Double-Clickable Squeak Applications, Self-installing Squeak Release I have put these together because the skill set required is pretty similar, and because the second will probably be an example of the first. Documentation While one might not think of this as a project, it really has all the same surrounding issues of deciding how we want to do it, and coordinating it amongst many contributors, and getting it reall Tutorials Same comment as documentation Web Site Same comment as documentation

3 2

[bug?] #addAll: for SortedCollection
by ChrisRath＠aol.com 01 Aug '99

01 Aug '99

Came across a quirk in the behavior of the #addAll: for SortedCollections. If you run the following snippet, you should get a different kind of result for the return value of the message than you do for any of the other standard collections. | x y | x := #(1 2 3) asOrderedCollection. y := x addAll: #(7 8 9). "returns #(7 8 9)" Transcript show: y printString; cr. x := #(1 2 3) asSortedCollection. y := x addAll: #(7 8 9). "returns Sorted Collection (1 2 3 7 8 9)" Transcript show: y printString; cr. I ran the code under VW, and in both instances it returns the array that is being added, not the overall collection. Looking at the implementation of #addAll: method for SortedCollection, it appears that no value is explicitly returned. Not an earth shattering quirk, but perhaps it should be looked at.

1 0

re: Please use accessors!
by Alan Lovejoy 31 Jul '99

31 Jul '99

> ** Original Sender: Bijan Parsia <bparsia(a)email.unc.edu> >[snip] > At 5:15 AM -0400 7/31/99, Alan Lovejoy wrote: > > [snip] > >1. Finding all references to an instance variable in a class hierarchy is > >even easier than finding all senders of some message, because there > > *Really*? What's the key command. In Squeak it's command-N. If there is a keyboard shortcut key, the menu offers no hint for it. It's on the middle button menu for the class pane of the browser, though. It's called "inst var refs..."--smack dab in the middle of the menu. > > > >2. All classes in Smalltalk can be changed by any programmer. If an > >instance variable offends thee, thou mayest rename or remove it. Same > >goes for methods. > > True, but isn't a lot of this a matter of convenience? Absent the requisite > tool, I'd much rather tweak an accessor than plod through all the methods > in search of assignments. > > The best requisite tool, in this case, is, I suspect, "someone else" :) But no! The best requisite tool is the "inst var refs..." pick on the class pane menu! > > Similarly, any programmer can add methods to a > >class to access otherwise encapsulated instance varibles--and can > >also use #instVarAt: and #instVarAt:put: to defeat any message-based > >encapsulation of an instance variable. However, this does not mean > >that one should give up on the attempt to use method-mediated > >encapsulation of state in order to enforce invariants and/or constraints. > >If object encapsulation had no value, then OOP would be pointless. > > <sigh/> I just want to say that I think "encapsulation" is a really, really > messy concept. And that most varients are *not* essential properties of OO > systems (Kent Pitman has a very nice article on this.) The usual mantra is that an object encapsulates state and behavior. I agree that this formula concentrates too much attention on the information hiding, and not enough on the unification of state and behavior into a single entity. Don't get me wrong, I think information hiding is critical to preventing improper interdependencies. But the last thing about OO I would give up would be behavior-state unification. Information hiding would be next to last. You can have OO without information hiding, but not the other way around. > >7. Whether Andres was wrong or right about direct > >instance variable access, it was not cool to come down > >on him like a ton of bricks. Andres, on the other hand, > >should have simply questioned why the instance variables > >were not being accessed directly, instead of boldly asserting > >they should be. > > My main problems was the notion that we *shouldn't* use accessors in order > to save message sends. *That's* dangerous advice. It's akin to "use big > methods to avoid message sends", or "be aware of the messages which, in > certain classes, are compiles to bytecodes, lik #> on Integer" (note how > the advice has to be framed!). In Python, where the cost of a message send > nee method invokation nee function call is exorbinant, big > functions/methods (or binding the function to a local) *is* standard--and > often good--advice. > > But Smalltalk isn't Python. Agreed. > >We need to treat each other with respect and diplomacy. > >We are ambassadors for Smalltalk, and should act accordingly > > I'm not! I wanted to be ambassador to France but couldn't pony up the > donation. In any case, I have been Smalltalkingly long enough to be more > than a "permanant resident" with a slighly wierd visa. Maybe I'll get > naturalized soon! Chuckle :-). I think it is in the best interests of those of us who love Smalltalk to avoid public relations faux pas when dealing with other participants in public Smalltalk fora, such as c.l.s or the SquealList. A little civility never hurt anyone--and may help Smalltalk. > >when communicating in an open forum, one of whose purposes > >is spreading the Smalltalk gospel. > > Eh, I think you're confusing this list with the "EvangeSqueak" list :) <Grin>. Well, there's more than one type of evangelism. I tend to dislike the "It's hellfire and damnation for you if you access instance variables directly!" kind. > >8. Given the above, I would avoid being dogmatic on this > >issue. I think the fact that so many good Smalltalk programmers > >still access instance variables directly, and that code that commits > >this "sin" has lasted unchanged for so long, should cause one to > >at least question whether or not it's all that sinful. > > But do you agree that doing so for the sake of performance without > determining whether it *is* a performance issue in general, or even for the > particular method, is wrongheaded? Absolutely agreed. Read Kent Beck on this issue. I had long battled with extremists on both sides. When I read Kent's excellent comments, my reaction was "Yeah, what he said!" Thank you for your diplomatic reply. -Alan

1 0

re: [bug] my first squeak bugfix - Interval>>includes:
by Alan Lovejoy 31 Jul '99

31 Jul '99

> ** Original Sender: Alan Lovejoy <sourcery(a)pacbell.net> > > ** Original Sender: merlyn(a)stonehenge.com (Randal L. Schwartz) > > > > Interval>>includes: fails if the increment is not 1. Here's code that works: > > > > includes: aNumber > > ^self increment = 1 > > ifTrue: [aNumber between: self first and: self last] > > ifFalse: [super includes: aNumber] "fall back to enumerate items" > > > > Oh dear. The ParcPlace code for Interval>includes: has worked since I first > started using it, way back in 1986. So I was shocked to see the following code > in my Squeak image: > > Interval>includes: aNumber > ^ aNumber between: self first and: self last > > I guess this reinforces for me yet again that I should not assume that > things that have always been working correctly in the ParcPlace > image line are also good in Squeak (in spite of the fact that they both > ultimately come from Xerox PARC stock). > > As for the fix above, it will work, but I would like to offer an alternative: > > Interval>includes: aNumber > ^ (aNumber between: self first and: self last) > and: [self increment = 1 > ifTrue: [true] > ifFalse: [aNumber - self first \\ self increment = 0]] > > Kudos to Randy for finding this! > Ahem. Well, after considering the flurry of replies to this, it has dawned on me that the fix above is not correct. It fails in the case where the increment is 1. Why? Because it assumes that <aNumber> is an integer and that <start> is an integer (note the small i). So it will incorrectly report that <(1 to: 10 by: 1) includes: 5.5s> is true! Therefore, the new, improved fix is as follows: Interval>includes: aNumber "Answer whether the receiver, considered as the set of values S, where S = {x | x >= start, x <= stop, (x - start) mod step = 0}, includes <aNumber>. If <aNumber> is a floating point value, results are not defined." (aNumber between: self first and: self last) ifFalse: [^false]. (aNumber isInteger and: [self increment = 1 and: [self first isInteger]]) ifTrue: [^true]. ^aNumber - self first \\ self increment = 0 --Alan

1 0

Re: Smalltalk implementation of Linda?
by Dwight Hughes 31 Jul '99

31 Jul '99

Here is a Linda Tutorial for those interested or curious: http://www.sca.com/ltutorial.html -- Dwight Dan Ingalls wrote: > > Hello - > > I'm looking for a non-proprietary Smalltalk impementation of the Linda tuple-space kernel for parallel programming. We are considering this facility for Squeak and it would be nice to save a little work. > > If you don't know about Linda and are curious, check out CACM Vol 32 no. 4, April 1989. > > Thanks in advance > > - Dan

1 0

Re: Please use accessors!
by Helge Horch 31 Jul '99

31 Jul '99

At 18:55 30.07.99 -0400, Chris Norton wrote: >I will admit to having used i-vars directly in the past. At the time, it >seemed like a good way to ensure privacy, but upon reflection I decided that >this was silly. Any developer can just add his/her own accessor. So now my >practice is to create accessors, but label them as "private" and put them >into "private" method categories. Since Smalltalk does not enforce privacy, >we have to assume that our fellows will adhere to our "code of conduct". ></Soapbox> <Déjà vu> I like the way Kent Beck reasons about it. In [SBPP] he lists *both* "Direct Variable Access" (p.89) and "Indirect Variable Access" (p.91) as valid coding patterns, alluding to the obvious schizophrenia, and mentioning encapsulation and dogmatism. ([SWS] is leaning towards indirect-only, IIRC.) In his recent [GTBS], featuring a reprint of his 1993 SmalltalkReport column "To Accessor or Not to Accessor", I found his leading remarks from today's view most interesting: "[...] It wasn't until I rewrote the while thing as patterns for the book [SBPP] that I realized the key issue here is communication." (The column itself stresses the importance of consistency in one's ways.) His conclusive remark: "Anyway, if this one bugs you, ignore it, all except the part about making accessors private by default." These all make for good reading IMHO: [SBPP] Beck, Kent: Smalltalk best practice patterns; Prentice-Hall 1997; ISBN 0-13-476904-X [GTBS] Beck, Kent: Guide to Better Smalltalk; SIGS/Cambridge Univ. Press 1999; ISBN 0-521-64437-2 [SWS] Skublics, Suzanne; Klimas, Edward J.; Thomas, David A.: Smalltalk with Style; Prentice-Hall 1996; ISBN 0-13-165549-3 Back in a couple of days, Helge

1 0

Re: Please use accessors! Was: [RE: [Interval Problem] 2 cents]
by Andres Valloud 31 Jul '99

31 Jul '99

Hola. > [Sorry Andres; I can't help but climb up on the soap box. ;-) ] La venganza sera terrible! Andres.

1 0

Re: [Interval Problem] 2 cents
by Andres Valloud 31 Jul '99

31 Jul '99

Hi. > > do: aBlock > > > > | aValue | > > aValue _ start. > > step < 0 > > ifTrue: [[stop <= aValue] > > whileTrue: > > [aBlock value: aValue. > > aValue _ aValue + step]] > > ifFalse: [[stop >= aValue] > > whileTrue: > > [aBlock value: aValue. > > aValue _ aValue + step]] > > > > I do not see any accessor there. > But you should ;-) I did not code the Interval class!!! And furthermore, I don't think I would like accessors in Interval. But ok, next time I'll save my 2 cents. > A really objectified version would go even further like > > do: aBlock > [self atEnd] whileFalse: [ > aBlock value: self currentValue. > self step] > > This would even increase performance because you could optimize > different atEnd and step methods for e.g. ints and floats or points etc. No way!... #atEnd forces a message send, #< is not a message send with regular ints and floats because it's done by the VM as a bytecode. Your argument does not apply to all (most common) cases. And would you make subclasses of Interval for different types of start and end, or would you optimize #< instead? Andres.

1 0

Interval class
by Andres Valloud 31 Jul '99

31 Jul '99

Hi. I did not code the Interval class! Andres.

1 0

[Interval Problem] No $ anymore
by Andres Valloud 31 Jul '99

31 Jul '99

Hi. 1st: read the subject. It is understood from now on that all the following is about the Interval class. 2nd: following the spirit of the code already present in the Interval class, I suggested to remove the accessors from the fixes to Interval>>includes:. Andres.

1 0

Jump to page: