Squeak-dev February 2003

squeak-dev@lists.squeakfoundation.org

195 participants
766 discussions

Re: A declarative model of Smalltalk (was Re: [DOCS] SUnit tests)
by Richard A. O'Keefe 03 Mar '03

03 Mar '03

"Jeff Read" <bitwize(a)snet.net> wrote: Smalltalk appears to borrow a lot from LISP in this regard, at least in terms of philosophy if not implementation. In Scheme, for instance, the keyword define means "Add this symbol to your currently running global environment, and bind it to the following value..." Actually, it doesn't. Any Scheme block (Algol sense) may contain "defines", and they add to the LOCAL scope, not the GLOBAL scope. The Scheme standards (both ISO Scheme and RnRS Scheme) explain how (<stuff> (define x1 e1) ... (define xn en) <more stuff>) is equivalent to (<stuff> (letrec ((x1 e1) ... (xn en)) <more stuff>)) For example, (define (sort Xs) (define (merge Xs Ys) ...) ... ) does NOT introduce a global definition for merge. The Scheme standards define entire Scheme programs in which ALL functions are explicitly present when compilation starts (of course Scheme has closures constructed at run time, but the lambda-expressions they are constructed from are explicitly present at compile time). The difference, if I surmise correctly, is that every Scheme knows what define means; the base semantics for the keyword are standardized -- whereas each Smalltalk has a different protocol for creation of classes and adding methods to them. ANSI Smalltalk defines a "declarative" representation for classes and global variables. It is intended as an interchange format between different Smalltalk implementations.

8 10

re: release prioritization
by Hannes Hirzel 03 Mar '03

03 Mar '03

Hello Craig Craig Latta <craig.latta(a)netjam.org> wrote: > > Hi Hannes-- > > > > > Not having a proper test culture in Squeak leads us to have this > > > > kind of funny discussions. > > > > > > Perhaps you could elaborate as to what you consider a proper > > > test culture. > > > > An example of an emerging test culture > > > > > "Brent Vukmer" <bvukmer(a)blackboard.com> wrote: > > > I installed the MetaClassBuilderFix SAR in a 3.4gamma image, > > > installed the ClassBuilder test suite, > > > and then ran the ClassBuilder test suite > > > -- 3 out of 3 tests passed. > > Indeed, Great! You got the message about tests ;-) Let's move on to the next topic >but to what extent should particular tests delay a particular > release? I think that's the main issue here. > > > thanks, > > -C > Excellent question! IMHO the main issue is that if I look at http://swiki.squeakfoundation.org/squeakfoundation/70 I see the names of the guides: * Doug Way * Daniel Vainsencher * Ned Konz * Craig Latta * Göran Hultgren * Tim Rowledge Then I click on the link 'Release Plan' (http://swiki.squeakfoundation.org/squeakfoundation/79) Then I read 3.4 -- The main purpose of this release is to create an up to date, viable version, that's a good starting point to making Squeak more modular and it's development more decentralized. Changes: - Includes non-modules related updates from 3.3a, including the dynamic filelist services refactoring. - An option to load the SqueakMap package catalog and the base Package Loader from the net. - A dynamic open menu so packages can now register there and become first class applications. - Refactorings making various parts of the image easily removable. See Modularizing the Squeak image for the plan and status. - Various other fixes have been included. Release is tentatively set to end of 2002. ------ Now a question everybody who is looking at your work would come up with: Are these goals met and if yes by which criteria is this evaluated. You have put five points on this list. What do you have to say about them at the end of February? Postponing an issue is fully a viable option if there are important new reasons coming up. This has to be discussed and communicated. And: A list of open issues and major known bugs is surely a useful tool for guiding a development process. I do not see any links on the above mentioned pages. In the SqC area for various reasons Dan Ingalls used to be the "development process" (chief programmer approach). Because of his long experience he just took care of a lot of things. In the post SqC area the process should be made more explicit. We have all these nice tools and communication aids (mailing lists, Swikis / even world wide phone calls are accessible for many) - why not use them? I'm hoping that this stimulates you to not soley focus on schedule issues. I really recommend you to (re)read the excellent write-up by Daniel Vainsencher about the nature of releases http://aspn.activestate.com/ASPN/Mail/Message/squeak/1555651 (Email from today). Regards and happy Squeaking! Hannes P.S. My emphasis for having a proper (not perfect!) 3.4 release is motivated by my fears it might be the base for further development for a rather long time. This is fed by the fact that on the release plan (http://swiki.squeakfoundation.org/squeakfoundation/79) there is no single sentence about 3.5 not to speak of 3.6 and 3.7.

2 1

RE: Outstanding 3.4 bugs?
by Brent Vukmer 03 Mar '03

03 Mar '03

Andreas -- How did you debug this? I remember you saying to Ned that his stack trace didn't go down far enough to get to the problem.. -----Original Message----- From: Andreas Raab [mailto:andreas.raab@gmx.de] Sent: Thursday, February 27, 2003 4:04 PM To: 'Discussing the Squeak Foundation' Cc: squeak-dev(a)lists.squeakfoundation.org Subject: RE: Outstanding 3.4 bugs? Hi Ned, > These bugs (and more, like the much-discussed bug with adding an > instVar to ClassDescription) still exist in 3.4g. Here's an update on this problem. I could trace it down to a very obscure breakage of the superclass/subclass invariant which can only happen when you recompile any of the essential behaviors (Behavior, ClassDescription, Class).

11 14

Re: [Squeakfoundation]re: release prioritization (was "ClassBuilder problem")
by Hannes Hirzel 03 Mar '03

03 Mar '03

Roel Wuyts <roel.wuyts(a)iam.unibe.ch> wrote: > Somebody needs to decide what is a release and what's get in there, and > it was decided that these were the Guides. I trust them to do an > excellent job at this, that is why they are responsible. I can imagine > that there is some 'bigger plan' for which they want to have this > release. The question for me is: 'what is this bigger plan'. If it is > only that it was promised to have a new release by a certain time, then > I agree with you that we can wait. But I guess the plan for 3.4 was to > have SM up and running, and that is also important to get out so that > everybody can enjoy it. Yes, adding SM and not breaking existing things. >From http://swiki.squeakfoundation.org/squeakfoundation/79 <citation> 3.4 -- The main purpose of this release is to create an up to date, viable version, that's a good starting point to making Squeak more modular and it's development more decentralized. Changes: - Includes non-modules related updates from 3.3a, including the dynamic filelist services refactoring. - An option to load the SqueakMap package catalog and the base Package Loader from the net. - A dynamic open menu so packages can now register there and become first class applications. - Refactorings making various parts of the image easily removable. See Modularizing the Squeak image for the plan and status. - Various other fixes have been included. Release is tentatively set to end of 2002. </citation> Regarding "Refactoring making various packages easily removable": There is just Balloon3DRemoval and GamesRemoval. I do not consider this goal is met. And breaking an important thing and not including the fix is surely not good stewardship as well. Again: Where does this time pressure at the expense of quality come from? Cheers Hannes

3 2

[Q][Morphic] Acessing ImageImports by direct manipulation
by Hannes Hirzel 03 Mar '03

03 Mar '03

Hi There is a global dictionary called ImageImports which holds the images you import in the FileList with the command 'read grahic into ImageImports'. I remember that there was once a menu entry or a halo which allowed to create ImageMorphs based on a selection of an entry in this ImageImports dictionary. There even was a function to browse through the entries of this image dictionary. I would appreciate any hint! Regards Hannes

3 2

[OT][To Cees] Squeak-ja archive
by Yoshiki.Ohshima＠acm.org 03 Mar '03

03 Mar '03

Cees, # I'm sending this to the squeak-dev list because I still have a # little doubt that the direct mails from me to you are blocked at # somewhere. Sorry for doing this, everyone. Thanks again for hosting Squeak-ja list. Now we have about one hundred subscribers. A problem we've found is that the archive doesn't archive all email. The mbox file from the "download the full raw archive" link does have all emails, but the other HTML files contain very limited number of emails. I couldn't figure out why some are listed and others are not. Do you have any idea why this is happening? And would you try to recreate the HTMLs from the mbox (with mailman/bin/arch command parhaps?) Thank you, -- Yoshiki

2 2

RE: [ENH][DOC] MorphClassComment-efc
by Brent Vukmer 03 Mar '03

03 Mar '03

Looks great. What about putting a hyperlink to the Swiki page for this class comment( assuming that page is up-to-date ), within the class comment? -----Original Message----- From: Eddie Cottongim [mailto:cottonsqueak@earthlink.net] Sent: Thursday, February 27, 2003 11:36 AM To: squeak-dev(a)lists.squeakfoundation.org Subject: [ENH][DOC] MorphClassComment-efc Eddie from preamble: "Change Set: MorphClassComment-efc Date: 26 February 2003 Author: Eddie Cottongim Extended Class Comment for Morph. Thanks to everyone who helped review the draft version!!"!

6 5

SPrevayler
by Avi Bryant 02 Mar '03

02 Mar '03

I've been watching the work on SPrevayler with a cocked eyebrow, because I have to admit that I find it an extremely clunky approach, at least in its Java incarnation. Stephen's suggestion to combine it with REPLServer is interesting, but I think goes in the wrong direction - we don't want to be logging doIts (isn't that what the .changes file does anyway?), and we don't really want to be logging commands, we want to be logging message sends. There are a couple of steps that I think could be taken to make the Prevayler approach more "smalltalky" and more manageable. The first is to get rid of Command objects and replace them with Message objects. That is, wrap a proxy around the PrevaylerSystem that implements DNU to capture and log any messages sent to the system before forwarding them on (if you like, you can wrap these in a Command object before serializing them, but you'll only need that one class of Command). This gets rid of the ridiculous duplication of having to implement a Command class with executeOn: aSystem aSystem someMessage: ... for every message on System. The second step is to maintain a weak dictionary mapping unique ids to any object that passes through this proxy as a parameter, so that these ids can be written into the log instead of the objects themselves - you only need to fully serialize the object into the log when the id is first assigned (and, of course, you should replace any objects that already have ids during this serialization, with an id marker). At that point you'd have something halfway between Prevayler and an OODB - no transactions, still a single bottleneck for mutation, but much more flexibility in what your commands can look like and much less overhead in implementing them. Marco, Stephen, thoughts?

4 12

Re: [FIX] #union: broken for sets
by Richard A. O'Keefe 02 Mar '03

02 Mar '03

Daniel Vainsencher <danielv(a)netvision.net.il> wrote: I wonder if #union: of Bags should use Set semantics or Bag semantics. This has been discussed before. In fact, I recall raising the issue myself quite some time ago. Currently, and with your suggestion - #(1 2 1) asBag union: #(1 2) asBag -> a Set(1 2) which is precisely what it is documented as doing. I would personally _prefer_ it to return a Bag, but I can't call it a bug when a method delivers the result its documentation says it delivers, without any nasty side effects. It would be more meaningful, and one can always convert to Sets first to get the usual functionality. Well, you can always write (aCollection copy asBag) addAll: anotherCollection; yourself if you want bag union. Or even (aCollection asArray , anotherCollection asArray) asBag More importantly, if #union: were changed in this way, #intersection: and #difference: should also be changed. To be really honest, I think #union:, #intersection:, and #difference: belong in Set (and its subclasses), not Collection. How often do you want to compute the union of a Dictionary and a SortedCollection? But what Bag>>union: does and whether #union: should be in Collection at all are design issues that deserve wider debate and probably can't be changed without breaking someone's code. We don't have to settle such matters before fixing an obvious bug.

2 1

[Traits] questions/comments
by German Morales 01 Mar '03

01 Mar '03

Hi everybody, specially traits people at Bern, I'm reading the very interesting Traits papers, and although I haven't finished reading, I can't resist to ask some questions and give some comments: -I see how the conflict resolution is applied for provided methods, but not for required methods. The same aliases mechanism is applied? -I don't completely like the Substraction mechanism (TDrawing - {#hash}). It seems to me that it leads to the same problem described in "Fragile hierarchies". For example, in the example of Circle composed with TCircle and TDrawing - {#hash, #= and #~=}, if later TEquality adds a new method #?=, Circle will have a conflict. Perhaps instead of: Circle = TCircle + (TDrawing - {#hash, #= and #~=}) I would prefer: Circle = TCircle + (TDrawing - TEquality) ??? -a final small comment: I like what I'm reading. That's all for the time being. I'll try to finish reading the papers. I mean, if you want to answer "that is explained later in the other paper!!!", feel free to do it ;-) Regards, German Morales

3 4

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

Jump to page: