Re: SqueakMap in the image (was Re: Incorporating removals & KCP stuff)
[email protected] Fri, 23 May 2003 09:12:12 +0100
| Newsgroups | gmane.comp.lang.smalltalk.squeak.foundation |
|---|---|
| Message-ID | <[email protected]> |
Tim Rowledge <[email protected]> wrote: > Daniel Vainsencher <[email protected]> wrote: > > > [Add SM into 3.6 using update stream to do package installation] > > Sounds good to me. BTW, you mentioned the current update stream seems to > > be leading to Minimal. I think that at least for 3.6 it should be > > leading us towards Basic. > I'll agree with this; whilst we clearly want to proceed eventually to > having a minimal image I doubt > a) that we're going to do it for 3.6 > b) that it will be done simply by updates. Please read my other post regarding this. I have never thought that the update stream will bring us all the way - not even halway. But the principle is IMHO still a fact - the update stream is *currently* attached to the "image" that is moving *towards* Minimal and not Basic. I agree we are "splitting hairs" or whatever you call it but to me we are doing two things at once and that is muddling the waters: 1. Move towards Minimal. That is what we are doing in 3.6alpa. We are cutting out stuff into packages *including* stuff that will be in Basic (installed as packages). 2. Maintaining the end user experience that the user is sitting in front of Basic. But that means reinstalling packages (ontop of the current not-so-very-but-still-moving-towards-Minimal image) as we go. In my response to Doug I came down to a conclusion and a proposal how we most easily should do this, see that post. [BIG SNIP] Otherwise I agree wholeheartedly about Craig's work and support it 200% and really want it to not turn into a fork. Let me repeat that - it is a "clear and present danger" IMHO. But I know Craig knows this and I hope he manages to keep all his work "somehow repeatable and in synch" with the rest of us. And I also agree that there is no other way we will ever reach a Minimal that has no UI for example. Simply not practical. Go Craig, go. regards, Göran From [email protected] Fri May 23 07:17:53 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 4172 invoked from network); 23 May 2003 07:17:53 -0000 Received: from ns.bluefish.se (HELO leia.bluefish.se) (213.212.22.234) by mail.theinternetone.net with SMTP; 23 May 2003 07:17:53 -0000 Received: from [213.80.63.110] (helo=aSqueakSystem) by leia.bluefish.se with smtp (Exim 3.12 #1 (Debian)) id 19J6oL-0007C5-02 for <[email protected]>; Fri, 23 May 2003 09:17:53 +0200 X-Mailer: Celeste 2.0.4917 Date: Fri, 23 May 2003 09:16:28 +0100 In-reply-to: <[email protected]> Subject: Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff) To: Discussing the Squeak Foundation <[email protected]> References: <[email protected]> From: [email protected] Message-Id: <[email protected]> X-BeenThere: [email protected] X-Mailman-Version: 2.1 Precedence: list Reply-To: Discussing the Squeak Foundation <[email protected]> List-Id: Discussing the Squeak Foundation <squeakfoundation.lists.squeakfoundation.org> List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=subscribe> X-List-Received-Date: Fri, 23 May 2003 07:17:55 -0000 Hi Avi! Avi Bryant <[email protected]> wrote: > On Thu, 22 May 2003 [email protected] wrote: > > > Definitely. And btw, I have come to realize that PackageInfo and SMCard > > (future SMPackage) don't necessarily map "one to one". This is > > important. > > Can you elaborate on this? Yes. SMPackage is tyically a "published" package made for consumption/use of others. A PackageInfo-package may be simply an internal component of such a published package. In short - there may be more PackageInfos than there are SMPackages but there will typically always be one PackageInfo per SMPackage. :-) Looking at CVS again I would say that PackageInfo corresponds a tad with the "modules" you can define in the CVSROOT/Modules file. Partitions of the project suitable for the developers. And SMPackage again - is a "public" package used by others. So my conclusion is that both concepts are valid and disjoint but we should try to NOT introduce any *more* of these "kinda-module-thingies" into the Squeak world. :-) > > Including DVS (which currently uses the same internal code as Monticello > > I think) would be good to make sure people move over to that kind of > > fileout much more suitable for packages. > > Well, all that's actually needed for this is PackageInfo (and maybe some > super-simple UI like right clicking on a category name in the > PackagePaneBrowser and having a "file-out package" option). > > DVS and Monticello don't share any code, by the way; they both depend on > PackageInfo, but that's it. Aha, ok. I remembered wrong. I thought sometime you said that you had moved DVS over to use the same internal code that Monticello does. regards, Göran From [email protected] Fri May 23 07:17:54 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 4180 invoked from network); 23 May 2003 07:17:53 -0000 Received: from ns.bluefish.se (HELO leia.bluefish.se) (213.212.22.234) by mail.theinternetone.net with SMTP; 23 May 2003 07:17:53 -0000 Received: from [213.80.63.110] (helo=aSqueakSystem) by leia.bluefish.se with smtp (Exim 3.12 #1 (Debian)) id 19J6oL-0007C5-03 for <[email protected]>; Fri, 23 May 2003 09:17:53 +0200 X-Mailer: Celeste 2.0.4917 Date: Fri, 23 May 2003 09:04:35 +0100 In-reply-to: <[email protected]> Subject: Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff) To: Discussing the Squeak Foundation <[email protected]> References: <[email protected]> From: [email protected] Message-Id: <[email protected]> X-BeenThere: [email protected] X-Mailman-Version: 2.1 Precedence: list Reply-To: Discussing the Squeak Foundation <[email protected]> List-Id: Discussing the Squeak Foundation <squeakfoundation.lists.squeakfoundation.org> List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=subscribe> X-List-Received-Date: Fri, 23 May 2003 07:17:55 -0000 Hi all! Doug Way <[email protected]> wrote: > I just wanted to mention that the idea of including the SM bootstrap in > the update stream sounds reasonable to me. Ok. Of course we need to get the details straight here before we do anything. > And... > > On Thursday, May 22, 2003, at 12:27 PM, [email protected] wrote: > > > Daniel Vainsencher <[email protected]> wrote: > >> [Add SM into 3.6 using update stream to do package installation] > >> Sounds good to me. BTW, you mentioned the current update stream seems > >> to > >> be leading to Minimal. I think that at least for 3.6 it should be > >> leading us towards Basic. > > > > Well, perhaps I didn't make myself clear. And these things are hard to > > reason about. What I meant is that the update stream feeds updates that > > is producing the Minimal *image*. BUT... with the packages installed > > turning it defacto into Basic. > > > > If we said that the update stream is aiming to produce Basic then... > > What does that mean? Does it mean that we aren't "packageifying" the > > stuff that we intend to have in Basic? Nope. PackageInfo is a package. > > And so is SM. > > > > IMHO this means we are in fact working towards Minimal when we consider > > the *image* (without installed packages) but if we consider *with > > packages* then we surely are aiming for Basic. > > Yeah, I suppose. I guess it depends on whether you consider the > "image" to include these installed packages. Practically speaking, the > packages are in the image file, they just weren't added via the update > stream. :-) But I see your point. Good. This point is IMHO important, see below. > One other side issue... we may or may not want to move straight to the > Basic image and then the Minimal image after that. For example, you > could argue that SUnit should be part of the Basic image. (It is a > pretty fundamental development tool, although it's not one of the > traditional ST80 tools.) In that case, we've already strayed from the > Basic image by removing it. This proves my point even more! As far as "cutting-stuff-out-and-turning-them-into-packages" we *are* moving towards Minimal. BUT - we should install those packages back in (those that belong in Basic that is) so that the end result is a not-yet-but-anyway-Minimal image + the packages considered to belongto Basic. So, no - we aren't straying IMHO. We are doing it exactly right: We cut out packages that are easy to cut out (and it doesn't really matter in which order we do it because *everything* will eventually turn into packages) and we simply install them back in if they belong to Basic. Simple as that. Now - the question is: Should we issue updates that install packages back in or should we simply maintain a Basic-loadscript that is a tad smart and simply makes sure all packages that belong to Basic are installed? I think I vote for the latter. We could of course issue an update that alerts the user of this loadscript and asks if it should be installed. And later - we can issue updates that check if that loadscript is installed and in that case simple "reinstalls" it so that any newly cut out stuff gets installed back in. regards, Göran From [email protected] Fri May 23 11:13:14 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 8301 invoked from network); 23 May 2003 11:13:14 -0000 Received: from mxout2.netvision.net.il (194.90.9.21) by mail.theinternetone.net with SMTP; 23 May 2003 11:13:14 -0000 Received: from aSqueakSystem ([80.178.108.89]) by mxout2.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTPA id <[email protected]> for [email protected]; Fri, 23 May 2003 14:13:11 +0300 (IDT) Date: Fri, 23 May 2003 13:16:05 +0200 From: Daniel Vainsencher <[email protected]> Subject: Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff) To: Discussing the Squeak Foundation <[email protected]> Message-id: <[email protected]> X-Mailer: Celeste 2.0.5174 Content-transfer-encoding: 7BIT X-BeenThere: [email protected] X-Mailman-Version: 2.1 Precedence: list Reply-To: Discussing the Squeak Foundation <[email protected]> List-Id: Discussing the Squeak Foundation <squeakfoundation.lists.squeakfoundation.org> List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=subscribe> X-List-Received-Date: Fri, 23 May 2003 11:13:15 -0000 [email protected] wrote: > And SMPackage again - is a "public" package used by others. > > So my conclusion is that both concepts are valid and disjoint but we > should try to NOT introduce any *more* of these "kinda-module-thingies" > into the Squeak world. :-) On the contrary - it isn't that we have too many "kinda module thingies", it is that we (ab)use the word "module" to describe an imaginary construct that's supposed to solve too many different problems. Here's one way to cut it - * Unit of code reuse (which brings with it issues of understanding changemanagement) * Unit of program deployment (including issues of mixing different versions of modules) * As used by some people, may also include Namespaces, distributed transactions, partitioning of non-code objects... To the extent that we're clear about which design is meant to solve what problems, constructing the overall solution from a few more pieces won't hurt too much, and will give us flexibility (DVS today, Monticello tommorrow). Daniel From [email protected] Fri May 23 12:39:25 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 10030 invoked from network); 23 May 2003 12:39:25 -0000 Received: from ns.bluefish.se (HELO leia.bluefish.se) (213.212.22.234) by mail.theinternetone.net with SMTP; 23 May 2003 12:39:25 -0000 Received: from [213.80.63.110] (helo=aSqueakSystem) by leia.bluefish.se with smtp (Exim 3.12 #1 (Debian)) id 19JBpU-0008Te-00 for <[email protected]>; Fri, 23 May 2003 14:39:24 +0200 X-Mailer: Celeste 2.0.4917 Date: Fri, 23 May 2003 13:50:16 +0100 In-reply-to: <[email protected]> Subject: Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff) To: Discussing the Squeak Foundation <[email protected]> References: <[email protected]> From: [email protected] Message-Id: <[email protected]> X-BeenThere: [email protected] X-Mailman-Version: 2.1 Precedence: list Reply-To: Discussing the Squeak Foundation <[email protected]> List-Id: Discussing the Squeak Foundation <squeakfoundation.lists.squeakfoundation.org> List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://lists.squeakfoundation.org/pipermail/squeakfoundation> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=subscribe> X-List-Received-Date: Fri, 23 May 2003 12:39:25 -0000 Daniel Vainsencher <[email protected]> wrote: > [email protected] wrote: > > And SMPackage again - is a "public" package used by others. > > > > So my conclusion is that both concepts are valid and disjoint but we > > should try to NOT introduce any *more* of these "kinda-module-thingies" > > into the Squeak world. :-) > > On the contrary - it isn't that we have too many "kinda module > thingies", it is that we (ab)use the word "module" to describe an I don't think we have too many either. I just meant that we only need ONE per construct - as you describe below. So in short we are in agreement - I just slipped with the words. > imaginary construct that's supposed to solve too many different > problems. Here's one way to cut it - > * Unit of code reuse (which brings with it issues of understanding > changemanagement) Yes, and here we have typical source management stuff like PackageInfo. > * Unit of program deployment (including issues of mixing different > versions of modules) Right, that is where SMPackage fits. > * As used by some people, may also include Namespaces, distributed > transactions, partitioning of non-code objects... ImageSegments, Magma etc I guess. > To the extent that we're clear about which design is meant to solve what > problems, constructing the overall solution from a few more pieces won't > hurt too much, and will give us flexibility (DVS today, Monticello > tommorrow). I agree fully. I was just trying to note that the seemingly similar PackageInfo and SMPackage (SMCard today) are still different beasts AND that we should be careful with introducing more constructs that try to solve the things *they* already solve. But other abstractions are of course completely ok. :-) Or putting it another way - making a competitor to SM or DVS would be in many ways counterproductive since these tools in some ways work their magic by turning into de facto standards for the community. Much better to cooperate on them. :-) And that is btw one of the reasons I really want opinions on SM. Since a few important issues were reaised on the list recently I am in the process of writing down how SM1.1 will work on: http://anakin.bluefish.se/gohu/15 NOTE that it is a document in progress - I haven't folded in the thoughts from the recent discussion nor have I described my own plans in detail yet. > Daniel regards, Göran From [email protected] Sat May 24 11:57:28 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 31156 invoked from network); 24 May 2003 11:57:28 -0000 Received: from mxout2.netvision.net.il (194.90.9.21) by mail.theinternetone.net with SMTP; 24 May 2003 11:57:28 -0000 Received: from aSqueakSystem ([80.178.108.89]) by mxout2.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTPA id <[email protected]> for [email protected]; Sat, 24 May 2003 14:57:21 +0300 (IDT) Date: Sat, 24 May 2003 14:56:59 +0200 From: Daniel Vainsencher <[email protected]> Subject: Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff) To: Discussing the Squeak Foundation <[email protected]> Message-id: <[email protected]> X-Mailer: Celeste 2.0.5174 Content-transfer-encoding: 7BIT X-BeenThere: [email protected] X-Mailman-Version: 2.1 Precedence: list Reply-To: Discussing the Squeak Foundation <[email protected]> List-Id: Discussing the Squeak Foundation <squeakfoundation.lists.squeakfoundation.org> List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://lists.squeakfoundation.org/pipermail/squeakfoundation> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=subscribe> X-List-Received-Date: Sat, 24 May 2003 11:57:29 -0000 [email protected] wrote: > Or putting it another way - making a competitor to SM or DVS would be in > many ways counterproductive since these tools in some ways work their > magic by turning into de facto standards for the community. Much better > to cooperate on them. :-) I disagree in general - alternative solutions to the problem DVS solves, for example, don't hurt the community, because their functionality is more important than the synergy of sharing the same format. This is because the different formats do not add significant issues, because SM makes hides them by abstracting the install option. So a "better DVS" (just an example) is a good thing. SM specifically, OTOH, derives most of it's benefits from the network effect (everyone is putting his package in one place, and everyone looks for code in one place), and thus two incompatible catalogs would probably be worth less than just one, functionality almost not-withstanding. So SM competitors would be hard pressed to provide real value. > And that is btw one of the reasons I really want opinions on SM. Since a > few important issues were reaised on the list recently I am in the > process of writing down how SM1.1 will work on: It's been a couple of months since the last time I said this, so I consider it borderline-polite-nagging ;-). IMO, nothing matters as much as that you release something as soon as possible that supports package releases. - Details of distribution of the DB is unimportant. - UUIDs vs. names is unimportant. - Caching is unimportant. Why? because releases in SM allow dependencies to be handled in various intelligent ways, which would save people like Stephan from inventing their own schemes that are non-scalable simply because versions are not supported. Such a release would let loose the next "avalanche" of progress in the package handling aspects of Squeak. Also, while 3.6 release is pretty far away, we do need to start seeing how we actually handle releases in and after it, and to do that we need SM 1.1. So please do whatever you can to release asap, we need SM1.1 now! :-) Daniel From [email protected] Sat May 24 21:31:24 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 7728 invoked from network); 24 May 2003 21:31:24 -0000 Received: from snifit.smb.utfors.se (195.58.112.20) by mail.theinternetone.net with SMTP; 24 May 2003 21:31:24 -0000 Received: from aSqueakSystem (md469201f.utfors.se [212.105.32.31]) by snifit.smb.utfors.se (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with SMTP id <[email protected]> for [email protected]; Sat, 24 May 2003 23:31:08 +0200 (MEST) Date: Sat, 24 May 2003 23:29:56 +0100 From: [email protected] Subject: Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff) In-reply-to: <[email protected]> To: Discussing the Squeak Foundation <[email protected]> Message-id: <[email protected]> MIME-version: 1.0 X-Mailer: Celeste 2.0.4917 Content-type: TEXT/PLAIN Content-transfer-encoding: 8BIT References: <[email protected]> X-BeenThere: [email protected] X-Mailman-Version: 2.1 Precedence: list Reply-To: Discussing the Squeak Foundation <[email protected]> List-Id: Discussing the Squeak Foundation <squeakfoundation.lists.squeakfoundation.org> List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://lists.squeakfoundation.org/pipermail/squeakfoundation> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=subscribe> X-List-Received-Date: Sat, 24 May 2003 21:31:25 -0000 Daniel Vainsencher <[email protected]> wrote: > [email protected] wrote: > > Or putting it another way - making a competitor to SM or DVS would be in > > many ways counterproductive since these tools in some ways work their > > magic by turning into de facto standards for the community. Much better > > to cooperate on them. :-) > I disagree in general - alternative solutions to the problem DVS solves, > for example, don't hurt the community, because their functionality is > more important than the synergy of sharing the same format. This is Well, I agree. Nevertheless, the more people that use one format the more incentive to make that a good format. But whatever. > because the different formats do not add significant issues, because SM [SNIP] > > And that is btw one of the reasons I really want opinions on SM. Since a > > few important issues were reaised on the list recently I am in the > > process of writing down how SM1.1 will work on: > It's been a couple of months since the last time I said this, so I > consider it borderline-polite-nagging ;-). It's ok, I know I have talked about SM1.1 for a long time and haven't delivered yet. I can't say anything else than that I am trying but that a small thing called "life" keeps me pretty busy. I do have more time now though than before. > IMO, nothing matters as much as that you release something as soon as > possible that supports package releases. > - Details of distribution of the DB is unimportant. > - UUIDs vs. names is unimportant. > - Caching is unimportant. > > Why? because releases in SM allow dependencies to be handled in various > intelligent ways, which would save people like Stephan from inventing > their own schemes that are non-scalable simply because versions are not > supported. Such a release would let loose the next "avalanche" of > progress in the package handling aspects of Squeak. Also, while 3.6 > release is pretty far away, we do need to start seeing how we actually > handle releases in and after it, and to do that we need SM 1.1. > > So please do whatever you can to release asap, we need SM1.1 now! :-) I know. I am not sure though that I agree with the three bullets above. The first one I agree with. The second one is... I agree, not *important* - but harder to change the longer we go. My current thought is to "prepare" a bit by some very small adjustments and simply keep doing things as they are. So I am keeping UUIDs for SM1.1 but preparing for 1.2. In other words - no effort lost on that issue at this point, don't worry. Caching is not that unimportant because I think it is a key mechanism for the distribution of 3.6. I want people to be able to easily download a minimal/basic image and to be able to build "full" themselves. So I actually think PackageReleases (+ the little simple mechanism to add meta info to packages/releases which I call SMResources) and the cache are the key features of SM1.1. I will most probably only go for those - unless some very easy things pop up along the way that seem good. But in general I agree with you Daniel. :-) regards, Göran From [email protected] Sun May 25 08:27:10 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 18481 invoked from network); 25 May 2003 08:27:10 -0000 Received: from mailhub02-skge0.unibe.ch (HELO mailhub02.unibe.ch) (130.92.9.53) by mail.theinternetone.net with SMTP; 25 May 2003 08:27:10 -0000 Received: from localhost (localhost [127.0.0.1]) by mailhub02.unibe.ch (Postfix) with ESMTP id 0CBD4764B6; Sun, 25 May 2003 10:27:10 +0200 (MEST) Received: from mailhub02.unibe.ch ([127.0.0.1]) by localhost (mailhub02 [127.0.0.1:10024]) (amavisd-new) with LMTP id 15961-01-97; Sun, 25 May 2003 10:27:09 +0200 (MEST) Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4]) by mailhub02.unibe.ch (Postfix) with ESMTP id 8B7EC7640C; Sun, 25 May 2003 10:27:09 +0200 (MEST) Received: from iam.unibe.ch (asterix [130.92.64.4]) by asterix.unibe.ch (8.11.6+Sun/8.11.6) with ESMTP id h4P8R6K28495; Sun, 25 May 2003 10:27:07 +0200 (MET DST) Date: Sun, 25 May 2003 10:27:05 +0200 Subject: Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Discussing the Squeak Foundation <[email protected]> From: Stephane Ducasse <[email protected]> In-Reply-To: <[email protected]> Message-Id: <[email protected]> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Virus-checked: by University of Berne cc: Alexandre Bergel <[email protected]> cc: =?ISO-8859-1?Q?Markus_G=E4lli?= <[email protected]> cc: =?ISO-8859-1?Q?Nathanael_Sch=E4rli?= <[email protected]> cc: Roel Wuyts <[email protected]> X-BeenThere: [email protected] X-Mailman-Version: 2.1 Precedence: list Reply-To: Discussing the Squeak Foundation <[email protected]> List-Id: Discussing the Squeak Foundation <squeakfoundation.lists.squeakfoundation.org> List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://lists.squeakfoundation.org/pipermail/squeakfoundation> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>, <mailto:[email protected]?subject=subscribe> X-List-Received-Date: Sun, 25 May 2003 08:27:10 -0000 Hi all, Just a simple point about packages. I discussed a lot with Avi and I think that while DVS is a simple start the future is to have real package and not only hack around the categories. Avi agrees on that. I discussed recently also with joseph and he said that Ginsu is free (I should send him a license). What would be good is to have a group of people discussing/cooperating to create this asset. May be this is already in place (sorry for not knowing it). So there is still a gap between having definitions in the image (like in Ginsu) and only definitions in the exchange files but having definitions is important. We should have a way to see in the file that we declare a new Class, Pool what ever. We could have then multiple run-times if people want and we could load code without installing it. So imagine what we could do. Having support for real package in the image is not really difficult but the browser is so much a pain that it will hamper any move. Nathanael and alex for the traits and the classboxes had to fix, patch, this gory browser, Markus also for his ideas. What we are planning to do here is to build our own browser where they could plug what they need for their research. I will check what is the plan but it should be still in our current plans. First we want to fix the core (compiler, changes notification, classOrganization). However, this means that we could take into account that other entities such as packages could be used there too. Stef