Partitioning the image (was Re: Shrinking sucks!)
Alexandre Bergel
bergel at iam.unibe.ch
Mon Feb 14 09:26:01 UTC 2005
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Package.16.cs.gz
Type: application/x-gunzip
Size: 9322 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050214/c3dc8c3b/Package.16.cs.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PackageBootstrap.1.cs.gz
Type: application/x-gunzip
Size: 510 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050214/c3dc8c3b/PackageBootstrap.1.cs.bin
More information about the Squeak-dev
mailing list
|