This is the list I compiled for the Magma Dependencies in the creation of the Magma Metacello configuration:
WriteBarrier -> none (BytecodeGenerator) Collections-BTree -> none Ma exception handling -> none Ma base additions -> Ma exception handling Ma proxy support -> Ma exception handling Ma Squeak domain -> Ma base additions Ma contextual search -> Ma base additions MaFixedWidthReport -> Ma base additions Ma special collections -> Ma base additions, Collections-BTree Ma traverse object graphs -> Ma proxy suport Ma Statistics -> MaFixedWidthReport Ma object serialization -> Ma Statistics, Ma special collections, Ma traverse object graphs Ma client server -> Ma object serialization Ma Armored Code -> Ma client server, [OSProcess] Magma client -> Ma client server, WriteBarrier Ma object serialization tester -> Ma Squeak domain, Ma contextual search, Ma Armored Code Magma server -> Ma contextual search, Magma client Ma special collections tester -> Ma Armored Code, Magma client Magma tester -> (ProjectHistory), Ma object serialization tester, Magma server
- BytecodeGenerator isn't loaded by default in Squeak or Pharo. Is part of NewCompiler but currently is being rewritten for the closure image. - ProjectHistory only exists in Squeak. In Pharo was removed long ago because of the unloading of the Project code. - OSProcess is used by the tester but isn't loaded by default in Squeak nor Pharo.
I attach the updated .dot file and jpg file of the dependencies graph of Magma 1.0r43 (tester).mcm.
Cheers
El mar, 12-01-2010 a las 16:32 -0600, Miguel Enrique Cobá Martinez escribió:
This is the list I compiled for the Magma Dependencies in the creation of the Magma Metacello configuration:
WriteBarrier -> none (BytecodeGenerator) Collections-BTree -> none Ma exception handling -> none Ma base additions -> Ma exception handling Ma proxy support -> Ma exception handling Ma Squeak domain -> Ma base additions Ma contextual search -> Ma base additions MaFixedWidthReport -> Ma base additions Ma special collections -> Ma base additions, Collections-BTree Ma traverse object graphs -> Ma proxy suport Ma Statistics -> MaFixedWidthReport Ma object serialization -> Ma Statistics, Ma special collections, Ma traverse object graphs Ma client server -> Ma object serialization Ma Armored Code -> Ma client server, [OSProcess] Magma client -> Ma client server, WriteBarrier Ma object serialization tester -> Ma Squeak domain, Ma contextual search, Ma Armored Code Magma server -> Ma contextual search, Magma client Ma special collections tester -> Ma Armored Code, Magma client Magma tester -> (ProjectHistory), Ma object serialization tester, Magma server
- BytecodeGenerator isn't loaded by default in Squeak or Pharo. Is part
of NewCompiler but currently is being rewritten for the closure image.
- ProjectHistory only exists in Squeak. In Pharo was removed long ago
because of the unloading of the Project code.
- OSProcess is used by the tester but isn't loaded by default in Squeak
nor Pharo.
I attach the updated .dot file and jpg file of the dependencies graph of Magma 1.0r43 (tester).mcm.
Cheers
One thing, neither Dependency Browser nor Lukas Dependency Analyzer show a package that depends on Ma special collections tester. In the graph this is shown as none arrow pointing to the node Ma special collections tester.
Is this intentional?
Or should I make Magma tester depend on Ma special collections tester even though no class of this last one is used by Magma tester?
By the moment I will force the dependency of Magma tester on Ma special collections tester in order to load it when loading Magma tester. Later we can change this if neccessary.
Cheers
One thing, neither Dependency Browser nor Lukas Dependency Analyzer show a package that depends on Ma special collections tester. In the graph this is shown as none arrow pointing to the node Ma special collections tester.
Is this intentional?
Yep. As the name suggests, Ma special collections tester tests the special collections employed by Magma; most notably the critical MaHashIndex.
Or should I make Magma tester depend on Ma special collections tester even though no class of this last one is used by Magma tester?
Why create an artificial dependency?
By the moment I will force the dependency of Magma tester on Ma special collections tester in order to load it when loading Magma tester. Later we can change this if neccessary.
Ah, a tool limitation, that's why.. :(
- Chris
El mié, 13-01-2010 a las 09:54 -0600, Chris Muller escribió:
One thing, neither Dependency Browser nor Lukas Dependency Analyzer show a package that depends on Ma special collections tester. In the graph this is shown as none arrow pointing to the node Ma special collections tester.
Is this intentional?
Yep. As the name suggests, Ma special collections tester tests the special collections employed by Magma; most notably the critical MaHashIndex.
But should be loaded when loading Magma tester right?
Or should I make Magma tester depend on Ma special collections tester even though no class of this last one is used by Magma tester?
Why create an artificial dependency?
Yes, maybe dependency isn't the right word, because it doesn't use a specific class of Ma special collections tester. I really mean that when loading Magma Tester, Ma special collections tester is required to be load. That is how is specified in Metacello. In fact Metacello doesn't know if when specifying that package A requires package B that means that a class in package A uses/references/inherits/whatever a class in package B. Is just a way to declare that before loading package A it should load package B.
By the moment I will force the dependency of Magma tester on Ma special collections tester in order to load it when loading Magma tester. Later we can change this if neccessary.
Ah, a tool limitation, that's why.. :(
Not so, more exactly a bad explanation from me!
- Chris
Thanks
But should be loaded when loading Magma tester right?
Yes. Although it's a separate package, not required to be able to run the Magma test cases, it's just a "very related" testing package because it tests some of Magma's core behaviors. It's a pretty small package that isn't worth making the user load separately, IMO..
magma@lists.squeakfoundation.org
-
Chris Muller -
Miguel Enrique Cobá Martinez