I should add a couple of remark about what I did.
Application can be saved directly from the new package browser or from monticello using the new Package framework. However, when loaded back, class extensions are not marked as class extention. This means that a package cannot be properly saved.

The package browser is barely usable. Some more work need to be put in before using it...

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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.