Dependencies of Magma 1.0r43

Miguel Enrique Cobá Martinez miguel.coba at gmail.com
Wed Jan 13 02:56:31 UTC 2010


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

-- 
Miguel Cobá
http://miguel.leugim.com.mx



More information about the Magma mailing list