Squeakfoundation November 2002

squeakfoundation@lists.squeakfoundation.org

22 participants
41 discussions

Re: [Squeakfoundation]One more update for 3.2.1?
by Daniel Vainsencher 21 Nov '02

21 Nov '02

The SMLoader change is now done an on SM, but I now tend to agree with sentiments expressed that a 3.2.1 with SM is not that important, considering the direction of 3.4a and all. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > Scott, there was some discussion earlier about adding the SqueakMap bootstrap update to 3.2.1, similar to what was added to 3.4alpha. I think we should do this, since easy access to SqueakMap was the main point of the 3.2.1 release, I believe. (Would you be able to just re-use update #5105?) > > However, the one thing we should probably wait for is Daniel's update to the SMLoader package, so that the 3.2-compatible packages will show up in the list. (See below. Almost done with that, Daniel? (nudge) :-) ) Once this is done, perhaps you could go ahead and add the update to 3.2.1. > > - Doug > > > danielv(a)netvision.net.il wrote: > > > > goran.hultgren(a)bluefish.se wrote: > > > :-) Yes, we need to fix the Package Loader to "treat" 3.2.1 as 3.2 when > > > filtering for versions. Or something to the same effect. Perhaps just > > > use "beginsWith:" instead of "="? :-) And some other things. > > > > So basically, we'll have SM categories for image versions like 3.2, 3.3, > > 3.4, and they will match actual image versions like 3.2.1, 3.3a, 3.4a > > and so forth? > > > > Ok, it'll go into the next version. > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

PackageInfo and refactoring the image
by danielv＠netvision.net.il 20 Nov '02

20 Nov '02

I think we should put Avi's newly isolated PackageInfo in the image. Why? It makes the *methodCategory convention for class extensions concrete. This would allow tools such as a PackageBrowser that really views all of a package, and nothing else, Lint over a package, and so forth. One of the ways to refactor the image is to find and declare all class extensions (Object>>asString). The new PI can answer questions of the type - "who references my classes outside myself?", which gives proper feedback to such refactorings. BTW, so far, Ned and Andreas have mentioned at some point that they think PI should be in the image. What do you guys think? Daniel

1 0

Re: SM not in 3.2.1?
by danielv＠netvision.net.il 20 Nov '02

20 Nov '02

[SM in 3.2.1] Yes we need to get this cleaned up somehow - there are probably quite a few newbies encountering 3.2 images out there. Unless if we decide to make 3.4 *really* short, like a month, rather than two. I don't mind either way. goran.hultgren(a)bluefish.se wrote: > :-) Yes, we need to fix the Package Loader to "treat" 3.2.1 as 3.2 when > filtering for versions. Or something to the same effect. Perhaps just > use "beginsWith:" instead of "="? :-) And some other things. So basically, we'll have SM categories for image versions like 3.2, 3.3, 3.4, and they will match actual image versions like 3.2.1, 3.3a, 3.4a and so forth? Ok, it'll go into the next version. We will need to clean up the extranous tags like 3.4alpha, though (I don't think we'll lose much precision by it - anyway the category should be view as an indication, not a promise, since we're not including update number). Daniel

3 2

New update stream (was Re: [Squeakfoundation]Order of business ...)
by danielv＠netvision.net.il 20 Nov '02

20 Nov '02

Hi Scott. We got no answers from you on: danielv(a)netvision.net.il wrote: > Hi Guides (fellow Squeakers in the audience? ;-) > > Three issues we should start moving on, IMO: > 1. Process to take physical ownership of updates. > * Scott/SqC - do you have any remaining agenda for 3.4a/3.2.1, to > settle before handing over the "keys"? > * Scott, are you interested in some role (as vaguely ;-) postulated by > goran, or otherwise) under the guidance (sic) of us Guides? > * If neither of the above, can you explain the current existing tools > in the image for handling this and the required resources, so we can > plan a clean transition? How do you prefer to proceed? And if the last, then on the technical side - > I assume basically we'll need some public readable, Guides writeable > storage space on updates.squeakfoundation.org, and a final update on > both all current servers and versions that changes the urls currently in > the image. Am I missing something? Daniel

5 4

Guide roles! PLEASE!
by goran.hultgren＠bluefish.se 19 Nov '02

19 Nov '02

Hi guys! Ok, I have cleaned up the Guide role page a bit: http://swiki.squeakfoundation.org/squeakfoundation/73 I think that page is very important - if we don't know who is focusing on what then this effort will turn into chaos pretty quick. So, please go over there, add/change/reove the roles and make sure YOU HAVE GOT ONE. Ok? Doug and I are confirmed. Ned, Craig, Tim and Daniel - please take the time to do this, ok? Then you can all go back to hacking away... :-) I repeat: We REALLY need to do this so that our effort doesn't seem just like a bunch of chickens running around posting nice ideas on the lists. Also note that I added a second role table below (we can move it to another page too) that describes the other roles we know that non-Guides have. regards, Göran

3 5

Swiki reorg
by cg＠cdegroot.com 18 Nov '02

18 Nov '02

Per Goran's suggestion, I cleaned up the front page of the Swiki a bit. Because wiki graffiti kiddies have found this one as well, I locked the front page (password 'saycheese'). The general idea is to use 'Squeak Foundation' as a, err, brand name for organizational/meta activities, and one project is instituting the actual legal entity. The next thing I'd like to see is to get separate pages for the Guides' activities. However, I feel that after a short project description, most of the projects should link to the main Squeak swiki for the gory details (hmm - todo: InterWiki links in Swiki ;-)). I've setup something for the PR thingie. Everything not related to 'current' work has been relocated under the 'Other stuff' header. Maybe later on, we should weed out the obsolete stuff. <insert superfluous invitation for comments on this here> Regards, Cees -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Cogito ergo evigilo

2 4

Re: 3.4 Road map and Refactorings (was: [Squeakfoundation]Order of business ...)
by danielv＠netvision.net.il 17 Nov '02

17 Nov '02

Ned said: > Should probably do this as part of the same project as integrating > Michael's/Stephen's sockets/flow code. URL stuff needs considerable > work (haven't seen Michael's stuff yet, though). I've started to look at the mail client (looks good - has POP authentication thrown in, too), but not at the URL stuff. I'm not very familiar with the existing URL stuff, so I don't have an opinion about it (amazing isn't it? ;-). > Simple quality tests would be helpful for removals: Ok, got those.. but - > * No dangling refs to removed classes Snippet? I'm collecting these into a swiki page. Daniel

1 0

Classes as Packages (was: Harvesting infrastructure)
by Anthony Hannan 17 Nov '02

17 Nov '02

> Anthony Hannan <ajh18(a)cornell.edu> wrote: > > What about classes as packages as per my recent email entitled "Class > > Dependencies". I really think we should consider this. Stephane and Goran, Thanks for responding. I was hoping some people would respond so we can discuss this. I know my idea is a little radical and requires significant changes, but I think it is worth considering. The benefits might be well worth the changes. Plus I already have experience and code for make wholesale changes to the image pretty easily in VI4. goran.hultgren(a)bluefish.se wrote: > Well, I need some time to read your post more carefully - but my initial > reaction is that I don't really think it will work in practice. It is > simply too "fine granular". IMHO one of the whole points in talking > about packages is the fact that we indeed try to group things together > in bigger more understandable chunks. > It seems to me that simply saying class == package doesn't solve > anything. I understand your thinking. I was thinking this way as well until I realized that specifying prerequisites is basically the same as specifying what belongs in the package. This lead me to realize that we don't need packages at all if we just specify prerequisites of the elements in the package in the first place (the classes and class extensions). Then I went further and defined class extensions as first-class behaviors using multiple inheritance. I chose multiple inheritance because it solves another problem as well: better behavior sharing. Then I went on to figure how how to find all prerequisites even in the face of polymorphism. That is when I decided to assign selectors to protocols. This also has a side benefit of better structured code. So with these too added features we are able to reliable find all prerequisites of a class automatically. This is basically the process we go through when we defined packages manually. Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > I think that classes are not packages. I think that this really > important > not to have classes as packages. Because packages are groups of > declaration (class def, method def, var def). > We can unify everything and at the end we got a magna. > Some programming languages try to unify classes and modules but > conceptually this is really different and when you teach concepts about > OO > you never have classes as subsystem. > So I would vote really against it. A class can be viewed as a group of declarations as well: vars and methods. Java defines classes as modules. Subsystems should be objects also, that his the whole idea behind object-oriented: everthing is an object. So the class of the subsystem object would be it own package with all other classes that it uses as its prerequisites. Cheers, Anthony

1 0

Re: [Squeakfoundation]Harvesting infrastructure (was Re: Order of business ...)
by goran.hultgren＠bluefish.se 17 Nov '02

17 Nov '02

Anthony Hannan <ajh18(a)cornell.edu> wrote: > Ned Konz <ned(a)bike-nomad.com> wrote: > > Again, we need some kind of modeling of packages. Right now there are > > two that I have in my image: > > * SqueakMap's card > > * PackageInfo (previously a part of DVS, now separate). > > I see these as being complementary; the SqueakMap deals with releases > > and finding them, and the PackageInfo deals with code. > > What about classes as packages as per my recent email entitled "Class > Dependencies". I really think we should consider this. > > Cheers, > Anthony Well, I need some time to read your post more carefully - but my initial reaction is that I don't really think it will work in practice. It is simply too "fine granular". IMHO one of the whole points in talking about packages is the fact that we indeed try to group things together in bigger more understandable chunks. It seems to me that simply saying class == package doesn't solve anything. But again, I need to read it more carefully. regards, Göran

1 0

Re: [Squeakfoundation]Harvesting infrastructure (was Re: Order of business ...)
by Stephane Ducasse 17 Nov '02

17 Nov '02

Hi anthony I think that classes are not packages. I think that this really important not to have classes as packages. Because packages are groups of declaration (class def, method def, var def). We can unify everything and at the end we got a magna. Some programming languages try to unify classes and modules but conceptually this is really different and when you teach concepts about OO you never have classes as subsystem. So I would vote really against it. Stef On dimanche, novembre 17, 2002, at 07:34 pm, Anthony Hannan wrote: > Ned Konz <ned(a)bike-nomad.com> wrote: >> Again, we need some kind of modeling of packages. Right now there are >> two that I have in my image: >> * SqueakMap's card >> * PackageInfo (previously a part of DVS, now separate). >> I see these as being complementary; the SqueakMap deals with releases >> and finding them, and the PackageInfo deals with code. > > What about classes as packages as per my recent email entitled "Class > Dependencies". I really think we should consider this. > > Cheers, > Anthony > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > 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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation November 2002