SqueakMap in the image (was Re: Incorporating removals & KCP stuff)
[email protected] Wed, 21 May 2003 09:00:41 +0100
| Newsgroups | gmane.comp.lang.smalltalk.squeak.foundation |
|---|---|
| Message-ID | <[email protected]> |
Hi! Doug Way <[email protected]> wrote: > So in other words, I think we should be able to go ahead and add > SqueakMap to the current image? It will certainly be part of the Basic > image, and would probably toward the end of the list of items removed > from the Minimal image (after most development tools, Morphic, MVC, > etc., are already removed). > > We will simply "promise" not to use the main update stream to change > code that resides in packages. The only exception would be SqueakMap > itself, which I guess also happens to be a package. But I don't think > that's a major problem... yes, the update stream may include major > upgrades to SM (such as SM 1.1) which simply overwrites the old package > in the image. Ok, some reasoning here: 1. SM is a package. As it should be. As all things will be. 2. Basic should include SM and a bunch of other "tools" too IMHO. Like DVS. Still as installed packages of course. 3. The current image is transforming itself into Minimal. We said earlier that it is transforming itself into Basic but I don't agree. For example, it doesn't contain SM nor DVS so... :-) By definition it is in some ways actually "smaller" than Basic! 4. I repeat the above just to make sure we agree: The current image is transforming itself towards Minimal. The updatestream is thus attached to Minimal. 5. So what we have today is a large Basic-looking *Minimal* that still includes many wannabe-packages BUT ALSO does not include SM, DVS, SAR etc. 4. When we release 3.6 we should have: a) a sortof Minimal image. A very large one, but still going towards Minimal. b) a loadscript that can bring this image upto Basic. c) another loadscript that can bring Minimal upto Full. It could even be "smart" so that it can be applied to a Basic image too. 5. But on the road towards 4abc - what does the image contain that we are working in? We don't want to work inside Minimal! We want to have Basic. Aha. So the 3.6a image I have sitting on my harddrive with a updatestream connected to - what IS IT? My conclusion: It is the Minimal image with *packages installed* so that it looks like the Basic image that 4b above will produce. Ok, back to the issue at hand: SM. And IMHO DVS, SAR and Package Loader. And perhaps one or two more I am forgetting right now. My reasoning above may sound like I don't want to introduce SM into the image - but in fact I do. :-) But not as "just another changeset". I want them *installed as packages*. What this means in practice is the following: We should issue updates through the update stream that installs these puppies using SM! The SM bootstrap changeset (the one that you get if you do the "Open packag loader") makes it look like SM itself was installed through SM (though of course it wasn't). I know that Scott Wallace earlier argumented to put SM into the image - and I strongly objected. I still object to simply "filing it in" just like *any changeset*. In short - we can issue an update that simply runs the bootstrap. We can keep the bootstrap code in place for a while. > (Then there's Andreas' new stuff which supports update streams on > individual packages, which I haven't looked at closely yet... I'm not > sure if that would make a big difference for this particular case.) I don't think so. I may try it out but I can't see how they have anything to do with us just yet. That package could OTOH be a candidate for Basic of course - just like DVS, SAR etc. Phew - so what do you all say? Does my analysis above sound reasonable? I find it strange that it seems so hard to define what things are - we really are creatures of habit. Hard to let go! :-) > - Doug Way regards, Göran From [email protected] Thu May 22 13:34:37 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 21131 invoked from network); 22 May 2003 13:34:37 -0000 Received: from mxout3.netvision.net.il (194.90.9.24) by mail.theinternetone.net with SMTP; 22 May 2003 13:34:37 -0000 Received: from aSqueakSystem ([80.178.100.180]) by mxout3.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTPA id <[email protected]> for [email protected]; Thu, 22 May 2003 16:34:36 +0300 (IDT) Date: Thu, 22 May 2003 16:25:34 +0200 From: Daniel Vainsencher <[email protected]> Subject: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff) To: Discussing the Squeak Foundation <[email protected]> Message-id: <[email protected]> MIME-version: 1.0 X-Mailer: Celeste 2.0.5174 Content-type: TEXT/PLAIN Content-transfer-encoding: 8BIT 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: Thu, 22 May 2003 13:34:37 -0000 [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. [packages for Basic, like DVS, SAR] IMO Basic should include PackageInfo, because it is a useful unit of filing stuff in and out that (a very lightweight replacement for one function changesets get abused for). DVS and SAR I am less sure about. In particular, DVS seems like it might be temporary, in the sense that the Monticello stuff will replace it as infrastructure. OTOH, maybe I'm just faliing to realize the benefits of how easy it is to issue an update that installs/uninstalls well-packaged stuff. Which, BTW, we need to define and start paying attention to - stuff that doesn't uninstall cleanly is badly packaged, and should not be included in Basic. Daniel [email protected] wrote: > Ok, back to the issue at hand: SM. And IMHO DVS, SAR and Package Loader. > And perhaps one or two more I am forgetting right now. My reasoning > above may sound like I don't want to introduce SM into the image - but > in fact I do. :-) But not as "just another changeset". I want them > *installed as packages*. > > What this means in practice is the following: > > We should issue updates through the update stream that installs these > puppies using SM! The SM bootstrap changeset (the one that you get if > you do the "Open packag loader") makes it look like SM itself was > installed through SM (though of course it wasn't). > > I know that Scott Wallace earlier argumented to put SM into the image - > and I strongly objected. I still object to simply "filing it in" just > like *any changeset*. > > In short - we can issue an update that simply runs the bootstrap. We can > keep the bootstrap code in place for a while. > > > (Then there's Andreas' new stuff which supports update streams on > > individual packages, which I haven't looked at closely yet... I'm not > > sure if that would make a big difference for this particular case.) > > I don't think so. I may try it out but I can't see how they have > anything to do with us just yet. That package could OTOH be a candidate > for Basic of course - just like DVS, SAR etc. > > Phew - so what do you all say? Does my analysis above sound reasonable? > I find it strange that it seems so hard to define what things are - we > really are creatures of habit. Hard to let go! :-) > > > - Doug Way > > regards, Göran > _______________________________________________ > Squeakfoundation mailing list > [email protected] > http://lists.squeakfoundation.org/listinfo/squeakfoundation From [email protected] Thu May 22 16:22:38 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 16725 invoked from network); 22 May 2003 16:22:38 -0000 Received: from shyguy.smb.utfors.se (195.58.112.21) by mail.theinternetone.net with SMTP; 22 May 2003 16:22:38 -0000 Received: from aSqueakSystem (md46911a3.utfors.se [212.105.17.163]) by shyguy.smb.utfors.se (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with SMTP id <[email protected]> for [email protected]; Thu, 22 May 2003 18:22:28 +0200 (MEST) Date: Thu, 22 May 2003 17:27:15 +0100 From: [email protected] Subject: [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://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: Thu, 22 May 2003 16:22:38 -0000 Hi Daniel and all! 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. Whatever - I hope you see my point. > [packages for Basic, like DVS, SAR] > IMO Basic should include PackageInfo, because it is a useful unit of > filing stuff in and out that (a very lightweight replacement for one Definitely. And btw, I have come to realize that PackageInfo and SMCard (future SMPackage) don't necessarily map "one to one". This is important. > function changesets get abused for). DVS and SAR I am less sure about. > In particular, DVS seems like it might be temporary, in the sense that > the Monticello stuff will replace it as infrastructure. OTOH, maybe I'm > just faliing to realize the benefits of how easy it is to issue an > update that installs/uninstalls well-packaged stuff. Which, BTW, we need > to define and start paying attention to - stuff that doesn't uninstall > cleanly is badly packaged, and should not be included in Basic. That I agree with. Even though I personally will not give uninstall much thought for a long time. :-) 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. > Daniel regards, Göran From [email protected] Thu May 22 17:10:48 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 17261 invoked from network); 22 May 2003 17:10:48 -0000 Received: from sccrmhc02.attbi.com (204.127.202.62) by mail.theinternetone.net with SMTP; 22 May 2003 17:10:48 -0000 Received: from goldskin.attbi.com (12-234-54-55.client.attbi.com[12.234.54.55]) by attbi.com (sccrmhc02) with SMTP id <20030522171046002002jjh1e>; Thu, 22 May 2003 17:10:46 +0000 Date: Thu, 22 May 2003 10:06:04 -0700 From: Tim Rowledge <[email protected]> To: [email protected] Subject: Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff) Message-ID: <[email protected]> References: <[email protected]> In-Reply-To: <[email protected]> User-Agent: Messenger-Pro/2.60a (MsgServe/2.00g) (RISC-OS/4.02) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Thu, 22 May 2003 17:10:49 -0000 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. We discussed this matter somewhat at last nights Squeak meeting at Craig's place. (Where were you all? Only seven people turned up and all the rest of you missed pizza, beer, soda, doughnuts and great conversation) Craig's approach to remotely pillaging an image has (much against my original expectations) worked beautifully. The mix of Flow and some very well done proxy design has enabled him to get to a very small image and most importantly to talk to it from a 'sensible' image. Personally I think that the remote part is going to end up far more important than merely shrinking the image. Remote debugging, clusters of images, all sorts of possibilities. Alongside that work we are expecting that some stuff I am deriving from conversations with Alejandro & co. will make it possible to generate a predefined minimal image from scratch, having learned from Craig's pillaging what really needs to be there along with some thought about what Dan referred to as an 'elegant minimal image'. Assuming this all works ok we will have a minimal image that can be expanded by remote manipulation to add any components needed including of course the compiler system so that the subject image can simply filein stuff for itself. At that point we can add more subsystems to produce the basic image and then the mongo-kitchen-sink-dancing-baby version. All completely repeatable via comprehensible scripts from well known archived sources. Golly. All we need is One Million Dollars, to quote Dr. Evil. Unmarked small denomination bills, no consecutive serial numbers, plain brown paper bag. tim -- Tim Rowledge, [email protected], http://sumeru.stanford.edu/tim Useful random insult:- Went to the dentist to have his cranial cavity filled. From [email protected] Fri May 23 00:51:04 2003 Return-Path: <[email protected]> Delivered-To: [email protected] Received: (qmail 31248 invoked from network); 23 May 2003 00:51:04 -0000 Received: from shawidc-mo1.cg.shawcable.net (HELO pd3mo1so.prod.shaw.ca) (24.71.223.10) by mail.theinternetone.net with SMTP; 23 May 2003 00:51:04 -0000 Received: from pd2mr3so.prod.shaw.ca (pd2mr3so-ser.prod.shaw.ca [10.0.141.108])2003)) with ESMTP id <0HFB004A5E64W7@l-daemon> for [email protected]; Thu, 22 May 2003 18:46:52 -0600 (MDT) Received: from pn2ml4so.prod.shaw.ca (pn2ml4so-qfe0.prod.shaw.ca [10.0.121.148]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HFB00M09E64XC@l-daemon> for [email protected]; Thu, 22 May 2003 18:46:52 -0600 (MDT) Received: from h24-77-112-143.vc.shawcable.net (h24-77-112-143.vc.shawcable.net [24.77.112.143]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HFB00A9TE639L@l-daemon> for [email protected]; Thu, 22 May 2003 18:46:52 -0600 (MDT) Date: Thu, 22 May 2003 17:33:02 -0700 (PDT) From: Avi Bryant <[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 Content-type: TEXT/PLAIN; charset=US-ASCII 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 00:51:04 -0000 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? > 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.