on 10/10/01 1:54 am, danielv at netvision.net.il at danielv at netvision.net.il
wrote:

> Hey guys, I'm starting to suspect Henrik wants to drag us back to the age of
> C files and diff files, and Dan is cooperating because that will work
> for distributing cool Media projects.


I was strong but you are a master....

But this is clear that henirck deisgn is far form clear for me...
> We need Ginsu!
> 
> So I played a bit with it. I worked on the 3.1 port Stef did, with my
> own modifications (attached - port improvements and 3x speedup to
> ModuleBuilder). 

I did not have the time because I have to finish one proposal for getting my
salary for the next 4 years...so pretty important plus a &^*&^& project
where I have to finish everything for friday.... ;((((

Could you upload your latest version in the Squeak Foundation site.
> 
> I changed the ModuleBuilder to put everything that hadn't been
> categorized into Unmanaged. Until now if a class hadn't been
> categorized, it wouldn't show up anywhere. This is attached.
> 
> BTW, I think there's a big problem with this - basically the current
> code says "I don't care what system categories exist, I want to have
> modules as defined in these methods" and then it has methods that return
> array constants that show what goes where. This is very fragile and hard
> to work with, because a lot of the work is done already in the
> SystemCategories. I don't understand why not to take the existing
> classification, and then record image refactoring as differences from
> that.

Because categories are not related to a string visibility mechanism. and
changing from time to time. So I imagine that we could easily get rid of
them like in envy and the future versions of VW.
> 
> Especially since at this point, we've classified 10% of Squeak. I think
> it's reasonable to assume that the old categorization is useful, even if
> it doesn't define actual valid modules.

It depends because sometimes it may fit sometimes not. It depends also if
you want to minimize the dependency between them.

> So we could at least put the classes that aren't specifically placed by
> ModuleBuilder in unmanaged, but according to their original place in the
> SystemOrganization. I think I'll work on this next.

The point of unmanaged code is that this is a working place. At the end when
you version everything there should be not class there. The idea behind
unmanaged code was that you should quickly know that a class has a problem
and could not be assigned somewhere. So if you would put it into its old
category you may miss it and every classs should go into a module.

 
> This would mean that people can see their classes in the ModulesBrowser,
> with their usual homes, even if it's not in the core. This might
> encourage people to start moving their stuff around.
> 
> Another problem is that ClassDefinitionWrapper is slow and complicated.
> I removed some code that was never running (it looks like first there
> was lazy init, and then different better init was added that happens at
> creation time) and made it actually lazy. Now it's much faster. This is
> also attached.

I think that the idea is that you can work on a class if it is installed
(running) or desintall. I think that this is really important that you can
modularise soemthing without having it loaded and executable. So my advice
would be that speed is not realy an issue right now

> 
> I think it's important to put a version that loads clean and works
> reasonably, otherwise people can't play. If everyone is busy, I can do
> the integration, and put it somewhere (I'm friendly with SCAN, and I
> can do a one touch install-in-your-image, like I did for the RB), if I
> know of everything that's been changed (I think HMM was doing
> something on this).

This would be great but please document what you are doing. For example I'm
not convinced that the lassy ClassDefinition was a problem. If you could be
sure that the old version still runs this would be easy to switch back if
required.

For the semantic model I had the impression that ClassCommentDefinition was
missing and another stupid one. What would be also fun is to see how we
could use scan to store the computed module.

Stef 

continue

> Daniel
> 
> ====forwarded====
> 
> 
> From: Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se>
> Subject: Re: [ENH][Modules]  Delta Modules [was: Another version]
> In-reply-to: <200110081543.RAA27180 at mailgw1.netvision.net.il>
> Sender: squeak-dev-admin at lists.squeakfoundation.org
> To: squeak-dev at lists.squeakfoundation.org
> 
> danielv at netvision.net.il wrote:
> 
>> Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> wrote:
>>> It did mix the implementation aspect with how DMs would be used, in the
>>> manner of "here are some problems, and this is how DMs can address them".
>>> The implementation difference is not strictly linked to the uses I
>>> mentioned, but in practice there will be such a link: the convenience of the
>>> delta representation means that class extensions probably will be put in DMs
>>> 99% of the time, and so on.
>> Please - lets nail this point down, because the abstractions are all
>> blurred in my head.
>> Do you mean that I'm *can* put extensions in Modules if I wish?
> 
> Sorry, my badly chosen example. The example could have been "the convenience
> of the delta representation means that changes to existing modules probably
> will be put in DMs 99% of the time", but that nothing stops you from
> distributing e.g. a new RB version as a complete module instead. You can't
> put extensions in a Module since they are always complete and not relative
> to a base. 
> 
>> If modules and deltaModules ARE equivalent, except for DMs being defined
>> relatively, this means that modules can conflict, and thus it would be
>> useful to be able to load but not install those, too.
> 
> Yikes! Actually, strictly DMs cannot conflict either, but only if you create
> the new version by activating them "into" the base module instead of into a
> copy of the base module.
> 
> But I really wish people wouldn't dive into technical subexception 31:B:4a
> before having looked at the basic code. That is just the wrong way to go
> about it.
> 
> Henrik
>