Cyclic dependencies ruin any possibility of being able to build up a system from some small core.

So you have MonticelloConfigurations. It depends on System, which depends on MonticelloConfigurations. In turn, System depends on Kernel, which depends on System, which depends on Collections, which depends on Kernel, which depends on Graphics, which depends on System, which depends on oh I'm sure you get the idea already.

The inter-package dependencies, which enormously simpler than they were, are simply a nearly impenetrable mess. MonticelloConfiguration has exactly zero reason to depend on System (and hence on just about the entire rest of the image), because it simply - or should simply - describe a configuration of Monticello packages.

So yes, there is indeed something wrong with MonticelloConfiguration depending on System.

If you want a modular system, then you want to be able to define a core on which you put some other bits, on which you build some more bits, until eventually you supply a user interface (graphical or otherwise) for a person to use. Every cyclic dependency can only occur within one conceptual layer, and we have _so many_ cyclic dependencies, we effectively have a one-layer system.

frank

On 25 July 2013 16:44, Chris Muller asqueaker@gmail.com wrote:

So, you want to move something "back" to Exceptions and will mean it's the only class in that package, but it will remove one of several dependencies on System -- as if there's something wrong with MonticelloConfigurations depending on System..?

I must admit, I'm really confused about your motivations, Frank.

On Wed, Jul 24, 2013 at 5:35 AM, Frank Shearar frank.shearar@gmail.com wrote:

...

On 23 July 2013 10:46, commits@source.squeak.org wrote:

...

Frank Shearar uploaded a new version of Exceptions to project The Trunk: http://source.squeak.org/trunk/Exceptions-fbs.48.mcz

==================== Summary ====================

Name: Exceptions-fbs.48 Author: fbs Time: 23 July 2013, 10:43:57.584 am UUID: ae58a39c-c2b3-f64f-8e96-f1e5b5d238e4 Ancestors: Exceptions-fbs.47

Move Exceptions close to where they're used, rather than collecting them together just because they're Exceptions.

=============== Diff against Exceptions-fbs.47 ===============

Item was removed:

• Notification subclass: #ProgressNotification

•   instanceVariableNames: 'amount done extra'
  

•   classVariableNames: ''
  

•   poolDictionaries: ''
  

•   category: 'Exceptions-Kernel'!
  

• !ProgressNotification commentStamp: '<historical>' prior: 0!
• Used to signal progress without requiring a specific receiver to notify. Caller/callee convention could be to simply count the number of signals caught or to pass more substantive information with #signal:.!

I'm seriously thinking of moving ProgressNotification back to Exceptions. It would be the only class in that package, but it would mean that MonticelloConfigurations would depend on Exceptions, not System. There are other things causing MonticelloConfigurations -> System, but this would remove one of them at least.

frank

This is my demon: https://www.dropbox.com/sh/3vb4z572qid6lzj/21aNXtvJEf/trunkimage-deps.png

Dependencies from test packages are dotted so we can see the more important stuff more clearly. You can easily spot the cyclic dependencies by looking for pairs of edges. Just above the centre of the tangle you'll see System. Below and to its left lives Kernel, and Collections is up and to the right of System.

Files is a very well behaved package. Because of that, you can see it lurking right at the very bottom of the image, where Kernel _ought_ to be (but can't because of all the cycles it's in).

So my motivation is simply to untangle that ball of yarn into a nicely layered system.

frank

On 25 July 2013 19:07, Frank Shearar frank.shearar@gmail.com wrote:

So the users of ProgressNotification live in these packages: a Set(#'Morphic-ToolBuilder' #'Network-RemoteDirectory' #'Morphic-Support' #MonticelloConfigurations #'Morphic-Windows' #'System-Object Storage' #'System-Support' #'Collections-Abstract').

The lowest common package out of this set is Collections. ProgressNotification _could_ move there. But I hesitate to do that because it just doesn't seem like a very Collection-y thing. Hence why perhaps I should have left ProgressNotification in Exceptions, even if it means that Exceptions has a grand total of one class.

frank

On 25 July 2013 18:50, Frank Shearar frank.shearar@gmail.com wrote:

...

Cyclic dependencies ruin any possibility of being able to build up a system from some small core.

So you have MonticelloConfigurations. It depends on System, which depends on MonticelloConfigurations. In turn, System depends on Kernel, which depends on System, which depends on Collections, which depends on Kernel, which depends on Graphics, which depends on System, which depends on oh I'm sure you get the idea already.

The inter-package dependencies, which enormously simpler than they were, are simply a nearly impenetrable mess. MonticelloConfiguration has exactly zero reason to depend on System (and hence on just about the entire rest of the image), because it simply - or should simply - describe a configuration of Monticello packages.

So yes, there is indeed something wrong with MonticelloConfiguration depending on System.

If you want a modular system, then you want to be able to define a core on which you put some other bits, on which you build some more bits, until eventually you supply a user interface (graphical or otherwise) for a person to use. Every cyclic dependency can only occur within one conceptual layer, and we have _so many_ cyclic dependencies, we effectively have a one-layer system.

frank

On 25 July 2013 16:44, Chris Muller asqueaker@gmail.com wrote:

...

So, you want to move something "back" to Exceptions and will mean it's the only class in that package, but it will remove one of several dependencies on System -- as if there's something wrong with MonticelloConfigurations depending on System..?

I must admit, I'm really confused about your motivations, Frank.

On Wed, Jul 24, 2013 at 5:35 AM, Frank Shearar frank.shearar@gmail.com wrote:

...

On 23 July 2013 10:46, commits@source.squeak.org wrote:

...

Frank Shearar uploaded a new version of Exceptions to project The Trunk: http://source.squeak.org/trunk/Exceptions-fbs.48.mcz

==================== Summary ====================

Name: Exceptions-fbs.48 Author: fbs Time: 23 July 2013, 10:43:57.584 am UUID: ae58a39c-c2b3-f64f-8e96-f1e5b5d238e4 Ancestors: Exceptions-fbs.47

Move Exceptions close to where they're used, rather than collecting them together just because they're Exceptions.

=============== Diff against Exceptions-fbs.47 ===============

Item was removed:

• Notification subclass: #ProgressNotification

•   instanceVariableNames: 'amount done extra'
  

•   classVariableNames: ''
  

•   poolDictionaries: ''
  

•   category: 'Exceptions-Kernel'!
  

• !ProgressNotification commentStamp: '<historical>' prior: 0!
• Used to signal progress without requiring a specific receiver to notify. Caller/callee convention could be to simply count the number of signals caught or to pass more substantive information with #signal:.!

I'm seriously thinking of moving ProgressNotification back to Exceptions. It would be the only class in that package, but it would mean that MonticelloConfigurations would depend on Exceptions, not System. There are other things causing MonticelloConfigurations -> System, but this would remove one of them at least.

frank

On Thu, Jul 25, 2013 at 12:50 PM, Frank Shearar frank.shearar@gmail.com wrote:

Cyclic dependencies ruin any possibility of being able to build up a system from some small core.

Yes, I understand and agree with that.

So you have MonticelloConfigurations. It depends on System, which depends on MonticelloConfigurations. In turn, System depends on Kernel, which depends on System, which depends on Collections, which depends on Kernel, which depends on Graphics, which depends on System, which depends on oh I'm sure you get the idea already.

System should not depend on MonticelloConfigurations.

The inter-package dependencies, which enormously simpler than they were, are simply a nearly impenetrable mess. MonticelloConfiguration has exactly zero reason to depend on System (and hence on just about the entire rest of the image), because it simply - or should simply - describe a configuration of Monticello packages.

Yes but there may be some utility behaviors like.. saving to a MC HTTP server which would require something out of System.

So, to me, it's fine for MonticelloConfigurations to depend on System, but not the other way around.

So yes, there is indeed something wrong with MonticelloConfiguration depending on System.

If you want a modular system, then you want to be able to define a core on which you put some other bits, on which you build some more bits, until eventually you supply a user interface (graphical or otherwise) for a person to use. Every cyclic dependency can only occur within one conceptual layer, and we have _so many_ cyclic dependencies, we effectively have a one-layer system.

I'm all for getting rid of the cycles. Perhaps it would help if we organized our existing list of packages into a hierarchy of dependency, just "on paper" (e.g., in a new e-mail thread) and see if we can identify what we think the overall responsibilities of each package. To have a coherent picture of the capabilities of each "module" and, therefore, its position in the dependency tree.

frank

On 25 July 2013 16:44, Chris Muller asqueaker@gmail.com wrote:

...

So, you want to move something "back" to Exceptions and will mean it's the only class in that package, but it will remove one of several dependencies on System -- as if there's something wrong with MonticelloConfigurations depending on System..?

I must admit, I'm really confused about your motivations, Frank.

On Wed, Jul 24, 2013 at 5:35 AM, Frank Shearar frank.shearar@gmail.com wrote:

...

On 23 July 2013 10:46, commits@source.squeak.org wrote:

...

Frank Shearar uploaded a new version of Exceptions to project The Trunk: http://source.squeak.org/trunk/Exceptions-fbs.48.mcz

==================== Summary ====================

Name: Exceptions-fbs.48 Author: fbs Time: 23 July 2013, 10:43:57.584 am UUID: ae58a39c-c2b3-f64f-8e96-f1e5b5d238e4 Ancestors: Exceptions-fbs.47

Move Exceptions close to where they're used, rather than collecting them together just because they're Exceptions.

=============== Diff against Exceptions-fbs.47 ===============

Item was removed:

• Notification subclass: #ProgressNotification

•   instanceVariableNames: 'amount done extra'
  

•   classVariableNames: ''
  

•   poolDictionaries: ''
  

•   category: 'Exceptions-Kernel'!
  

• !ProgressNotification commentStamp: '<historical>' prior: 0!
• Used to signal progress without requiring a specific receiver to notify. Caller/callee convention could be to simply count the number of signals caught or to pass more substantive information with #signal:.!

I'm seriously thinking of moving ProgressNotification back to Exceptions. It would be the only class in that package, but it would mean that MonticelloConfigurations would depend on Exceptions, not System. There are other things causing MonticelloConfigurations -> System, but this would remove one of them at least.

frank