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 at 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 at 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 at 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 at gmail.com> wrote:
>>>> On 23 July 2013 10:46,  <commits at 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
>>>>
>>>