Partitioning the image (was Re: Shrinking sucks!)

Alexandre Bergel bergel at iam.unibe.ch
Mon Feb 14 10:12:54 UTC 2005


Currently, I am working on extending the system change notifier to trigger package related event.

Alexandre

On Mon, Feb 14, 2005 at 10:26:01AM +0100, Alexandre Bergel wrote:
> Hello,
> 
> I have attached the code to this email. 
> How to install it:
>   - Take an image where MC and Omnibrowser are installed.
>   - Load Package.cs
>   - Load PackageBootstrap.cs
>   - To convert all the packages from packageinfo to package instance, execute 'Package bootstrap'.
> 
> The 12 tests contained in PackageTest should be green.
> 
> In the World/open menu, there is a new entry, 'package browser', open one. On the lest pane list, non indented name are packages, indented one are category contained in this package. I do not like this design, I thing we should get rid of categories, but we still would like to read old fashion packages...
> 
> Click on a package, for instance Omnibrowser. Click on the menu, you can add a new repository for this project, create a new package, save the system, ...
> 
> If you display a method menu, the first choice is 'Move To Another Package'.
> 
> It is far from behing finished... Any comment appreciated.
> 
> Alexandre
> 
> 
> On Sun, Feb 13, 2005 at 09:21:10AM +0100, stéphane ducasse wrote:
> > >I agree to a large extent.  At least the simple stuff that PackageInfo 
> > >knows how to do on its own -- show the code it contains, show its 
> > >name, show its comment, be able to unload itself -- ought to be doable 
> > >in a Package Browser tool completely separate from SqueakMap.  (A 
> > >Package Browser would list the PackageInfos comprising all of the code 
> > >in the image.)
> > 
> > By the way alex will certainly release some code to support for a real 
> > package class and this will be a good start to have a better support 
> > for MC. Mike was doing the same so we are trying to merge effort.
> > The idea is that we can then avoid to have category but first class 
> > objects instead.
> > Alex can we have initialization with your approach? I guess yes but not 
> > as method of a subclass so may be this would be a nice idea to have a 
> > package been a subclass of Package.
> > 
> > The last time I wanted to use Yaxo but I could not know whether the XML 
> > parser was part of it or another package. So what I ended up doing was 
> > to load the package Yaxo and check whether classes changed. So this is 
> > to avoid this situation that we should have meta-information.
> > 
> > >I kind of think of SqueakMap as the interface to the outside world of 
> > >packages.  Some of the meta-data associated with packages is mostly 
> > >"outside world" related, such as the URL, whether it's "published", 
> > >which SM version it is... these are probably not as essential for a 
> > >simple in-image PackageInfo, so they could stay in SMPackage.  
> > >"Author" is kind of a borderline case... method timestamps in the 
> > >image have author initials, although classes in the image don't keep 
> > >track of their authors.  I guess I'm okay with most metadata being in 
> > >SMPackage for now.
> > >
> > >>(snip)
> > >>
> > >>So, my proposal is:
> > >>
> > >>	1. Move ahead with PackageInfo.
> > >
> > >Yes.
> > >
> > >>	2. Add some minor descriptive info to PackageInfo, like 
> > >>"description",
> > >>and maybe a url for more info.  It would be great for these to be 
> > >>there.
> > >> The description should be a Text, ideally, just like class comments.
> > >
> > >I think adding a single comment/description instvar is a good idea.  
> > >Mmm, a url seems like something relating to the outside world which 
> > >could be handled by the corresponding SMPackage instance.
> > >
> > >>	3. Add some sort of variable, which optionally refers to a SqueakMap
> > >>package corresponding to that PackageInfo.  I defer to Goran for what
> > >>kind of info should go there, but the idea is, so long as the tools 
> > >>know
> > >>which PackageInfo goes with which SqueakMap package, the tools can do
> > >>all the same smart things they could do if PackageInfo were the *same*
> > >>as a SqueakMap package.
> > >
> > >I think the SMPackage actually points to the PackageInfo instance 
> > >right now (if it's a PI-based SMPackage).  So, mm, I think every 
> > >PackageInfo should be able to look up its corresponding SMPackage.  
> > >Goran can confirm.  Maybe that needs  a bit of thought as to how they 
> > >will be looked up.
> > >
> > >Just so it's clear, I think the situation would be this:
> > >
> > >The partitioned image would have a global list of PackageInfo 
> > >instances.  These PI instances (with names like 'Morphic', 'Graphics', 
> > >etc) would define ALL of the source code in the image.  Also, every 
> > >method in the Basic image would belong to ONE package.  (I don't think 
> > >there'd be any reason to use PI method overrides within the Basic 
> > >image, at least.)
> > 
> > It depends because may be you will face cases where a method has in 
> > fact two behavior and one part depends on the presence of another 
> > package.
> > 
> > >(Mm, the browsers will probably still let you create a new class 
> > >category without a new PI instance, so you'd have code outside of any 
> > >package... that would need to be tightened up.)
> > 
> > This should not. Else this will be the mess.
> > 
> > >If you had SqueakMap installed (which you would in a Basic image), 
> > >that would have its list of SMPackage instances, which would contain 
> > >the SMPackages pointing to the above PackageInfo instances, plus 
> > >possibly a mishmash of other SMPackages (changesets, projects, etc) 
> > >which happened to be loaded but which are not PI-related packages.
> > 
> > I do not understand why you need SM to have a list of packages inside 
> > the image. You should have all the categories as packages and they may 
> > or not be saved as SM packages.
> > 
> > I think that if you want to partition the image and you start to want 
> > to support sar, changeset, ... as packages you will die. Why not take 
> > the simple idea that a category is a package as in MC?
> > 
> > >Is there a situation where you'd have the global list of PI instances 
> > >in a more minimal image, but not have SqueakMap installed?  Could be, 
> > >but that might be uncommon.  I was thinking that the Minimal image 
> > >would still have the PI instances, which means PackageInfo would need 
> > >to be part of the Kernel, but I don't know if that's necessary.  As 
> > >long as it can add code to itself.  (That is when we take a serious 
> > >look at Spoon. :) )
> > >
> > >>Everyone seems to agree with #1.  #2 is contentious, so consider this
> > >>email to be my 2 cents on the issue.  #3 is a possible compromise for
> > >>everyone who cares about #2.
> > >
> > >I think #2 is not that contentious, if we just add a "comment" or 
> > >"description" instvar.  If we do that, should we call it "comment"?
> > 
> > Why not going for a real class.
> > Alex can you publish your code?
> > 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.iam.unibe.ch/~bergel
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> 


-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



More information about the Squeak-dev mailing list