Now this is the Stephane I know ;-)

ducasse stephane wrote:

> So now I would really like to see a small of the system decomposed in
> modules and having dependencies and versions between them.

Yes, this is no small task. More below.

> I would like to
> see how we can load/unload a system like Alice or the speech recognition and
> be able to have different versions of Morph and different versions of Alice
> just to see how this would work.

There will be demos for sure, but we will roll things out in increments, and
there will be bumps in the road no doubt.

> Once we have module in place, the next steps are to put in place some
> infrastructure at the code level:
> - we should take the filelist of swt which support registration of the tools
> (this is implementation of henrik I adapted a bit).

If you bring it up to 3.1 I will vote for this to be included right away.

> - we should have the same at the level of the ui for morph and mvc.

Some indirection is desirable but I think "the same" will be hard. Only a
small subset is the same for both.

> would avoid to have morphic referenced from the compiler. Or have all these
> horrible Smalltalk at: #Morph everywhere in the code. This is clearly the
> sign that something is missing.

Having Morphic "carry" these as external methods could solve some of these
problems, but not all.

> - I think that modules without a clean dependency structure will be just
> lazzagna instead of spaghetti code ;)

If we mean that we need to refactor the image, yes definitely. But if you
mean some sort of higher-level architectural scheme I have a proposal for a
model that I developed when digging a little deeper into the current image.
I will post it in a separate thread.

> I think that analysing the dependencies between the modules will be an
> important occasion for squeak to be cleaned (removing gifReader reference
> from Smalltalk, or things like that), In the same way roel told me that he
> could not write a nice visitor on html tree to check web page because there
> was a dialog popping up as error, so we have a dependency between socket and
> UI ;(

This need will always be there; I think we will need to carefully choosing
"which battles to fight", picking the most important and easiest achieved
:-) goals first. So many refactorings, so little time...

> -  Can you tell us how you see the process, because I would like to
> participate?

Steph, excellent! Code improvements that don't need the module system as
such can be done right now. The FileList refactoring is a perfect example of
this. So any such untangling can be begun today. Cleaning up exceptions like
in Roel's example is another.

Beside that, contributing refactorings *within* the new modules system. E.g.
redoing the equivalent of majorShrink to work with it.

Also, "porting" existing packages to the scheme: Whisker, MathMorphs, RB,
Ginsu(!). Although Ginsu may be a little bit harder--I suspect it modifies
some of the same parts as this modules system itself.

An immediate task is for SqF to bring about a central (think "default" not
centralized) repository. We have had a temporary one from Cees but the long
term requires another solution, and there are a lot of non-technical issues
surrounding this as well, rules and principles etc. This could start right
now.

I am hoping that Dan posts his recent thoughts about what goals we would
want to focus on, I liked what he proposed. Having established, clear,
shared goals in mind is crucial and very helpful.

> What I see is that you or a group of volunteers will have to do a
> first pass to fix the original structure of the dependency between
> modules checking why certain conceptually unrelated modules are
> related. Then or fixing them directly or making a list of things to
> be fixed. 

I feel like the proverbial horse between two hay stacks right now: posting
info and documentation, vs. concentrating on bringing the code functionality
forward, at least to the point where others can start to use the system and
make solid contributions. Thoughts on what you all think we should
prioritize are welcome.

> 
> - Is there a analysis support for doing that?
> because in Envy the system tell us (brutally) when a class refers to a
> non-visible class. and this is important to move things around and as
> squeak does not have a culture of explicit tests this may be a long task

There are some things, for example see the Module class, categories "code
analysis" and "system conversion"; class ModuleRefactorer and subclasses.
This works with the code I already sent out.

> - we excluded the people of the modsqueak mailing-list. Look at who
> really used this modsqueak  mailing-list. I think that this would have
> been clearer to say to them:  "you do not want to be in the mailing ok
> we will not interact with you."

This was unintentional, we started that way but then it slipped. It might
have been a task for a moderator to repost to them.

> - I'm personally a bit frustrated because lot of the design points I
> asked have never been answered like if they were or stupid or misplaced.
> originally I was thinking ok I do not care, but I care because I'm
> investing on Squeak. So I hope we will not realize mistakes in 1 year
> from now.

In truth, almost all of them had been discussed here some time before, but I
understand you were working on your habilitation back then.

Henrik