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
|