Hi Henrik

thanks to answer I was thinking that I was saying something wrong, and have
the impression to shout in the desert

>> 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.

Ok I will try. Slowly because I'm again flooded by reports ;((((


>> 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.

When morphic is referenced by the compiler or a non ui classe, this
is simply wrong ;)


>> - 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.

This is what I mean: removing unnecessary or stupid dependencies by moving
methods around. restructuring the code. This is my business ;)

> 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...

sure but we should be able to distribute the work


>> -  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.

But the problem is not doing it: the point is having it into the image and
controlling the changes that's why these modules are so important. We will
be able to work on a part of Squeak and controlling its changes.

What is important after the modules are started is to say to all the brave
souls around: "ok if you want to be responsible for something please be and
we can organise a kind of peer reviews"

> 
> 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.

No there is nothing complex in Ginsu, it modifies nothing just classify them
according to some visibility rules. But nobody really looks at it.

I still do not know if the solution you proposed proposes modules has a
scoping mechanism because I never had the time to look at it. Ginsu only
partitions class according to dependency visibility that exist between
modules but does not introduce a scoping mechanism.

And by the way I do not care about Ginsu, I just care about the knowledge
people like joseph have. The design of the package and module interested me
not the code. For me having modules is the way to have a clean squeak
decomposable. this is the key point. Having tools to fight against spaghetti
code is the next ones.

> 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'm not sure about the repository right now. I think that a gross
decomposition of the system is needed (with a chainsaw;)), the decomposition
should identify which module depends on which one. Then we should have
ModSq1.0 and start by letting people working on these big modules and
cleaning them and decomposing them into smaller if necessary. But this is
hard.

> 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.

Focus on something working. I think that once we have an example we will
understand 

> 
>> 
>> - 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.

ok I will try. Do you have a wiki where I can find the latest version?


>> - 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.
>