The message was held until approvement by attachment size.
I have exported png to gif with very bad quality and zip the files.
They are attached now
Cheers
El mar, 12-01-2010 a las 12:08 -0600, Miguel Enrique Cobá Martinez escribió:
Hi Chris,
I'm creating the Metacello configuration for Magma. I have almost all done but I need your feedback for the correct dependencies of the packages that compose Magma.
First, I used a clean PharoCore 10505 image. Using monticello browser I loaded
1.0r43 mcm -> 1.0r43 (tester).mcm
that installed:
Ma exception handling-cmm.32 Ma base additions-cmm.149 Ma proxy support-cmm.40 Ma traverse object graphs-cmm.29 MaFixedWidthReport-cmm.7 Ma Statistics-cmm.21 Ma object serialization-cmm.220 Collections-BTree-lr.68 Ma special collections-cmm.101 Ma client server-cmm.214 WriteBarrier-pmm.26 Magma client-cmm.446 Ma contextual search-cmm.29 Magma server-cmm.382 Ma Armored Code-cmm.144 Ma Squeak domain-cmm.28 Ma special collections tester-cmm.12 Ma object serialization tester-cmm.27 Magma tester-cmm.352
Then, using the instructions from Lukas Renggli:
http://lists.gforge.inria.fr/pipermail/pharo-project/2010-January/019678.htm...
and using the DependencyBrowser from Hernán Morales:
http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php
I created the attached .dot file with the dependencies for all the packages for Magma (tester, server and client). The code to generate it was:
(PDPackageAnalyzer onPackagesNamed: #( 'Magma tester' 'Ma special collections tester' 'Ma Squeak domain' 'Ma Armored Code' 'Magma server' 'Ma contextual search' 'Magma client' 'WriteBarrier' 'Ma client server' 'Ma special collections' 'Collections-BTree' 'Ma object serialization' 'Ma Statistics' 'MaFixedWidthReport' 'Ma traverse object graphs' 'Ma proxy support' 'Ma base additions' 'Ma exception handling' )) save: 'magma.dot'
Then using graphviz from linux (installed in Debian Linux as aptitude install graphviz) I generated the attached png graph of the dependencies with:
$ cat magma.dot | dot -Tpng > magma.png
I have checked dependency browser vs. PDPackageAnalyzer and both of them agree on the dependencies so I am almost sure that is ok. But your review will be very welcome.
Couple of things I found in this process:
- The WriteBarrier depends on class ByteCodeGenerator that isn't
included in Pharo. It appears to be on NewCompiler. Should I add NewCompiler as a dependency for Magma, or is writebarrier useful without NewCompiler.
- The Magma tester project depends on ProjectHistory that doesn't exist
anymore in Pharo. Maybe this should be a conditional in Magma or the test modified to not use this class, at least in Pharo.
- Ma Armored Code depends on OSProcess but the mcm doesn't includes it.
Now, as I said, I am doing the Metacello configuration for loading Magma in Pharo (and maybe also in Squeak) and this will permit to load Tester, Server and Client, WITH ALL the dependencies needed. This means that when loading tester will load OSProcess and when loading WriteBarrier will load also NewCompiler.
Any comment on this?
Thanks
Other question:
Do you mind if I use the WriteBarrier from
squeaksource.com/WriteBarrier
(the same versions of course but from the original project) or do you want to use the versions form the Magma repository?
Same for Collections-BTree that is on:
http://www.squeaksource.com/BTree
Cheers
Do you mind if I use the WriteBarrier from
squeaksource.com/WriteBarrier
The problem, of course, is that someone could post a new version of WriteBarrier / BTree that breaks Magma.
My reasoning has always been that *developers* must take responsibility for building an image with correct components anyway. Identifying a need to upgrade some of these packages is something a developer would need / want to do explicitly, not implicitly.
Perhaps for the "MagmaTester" project, we can reference them from the live locations, but for the "Magma" project, they should be static versions..?
- Chris
(the same versions of course but from the original project) or do you want to use the versions form the Magma repository?
Same for Collections-BTree that is on:
http://www.squeaksource.com/BTree
Cheers
Miguel Cobá http://miguel.leugim.com.mx
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
El mié, 13-01-2010 a las 09:47 -0600, Chris Muller escribió:
Do you mind if I use the WriteBarrier from
squeaksource.com/WriteBarrier
The problem, of course, is that someone could post a new version of WriteBarrier / BTree that breaks Magma.
Yes, I agree, but I will install the very same versions that you're using, not the last version that exists in the repository. That is a feature of Metacello, specify version numbers.
Of course it could happen that the original repository deletes the version used and that breaks the installation and in this scenario, it is wise to use the versions copied to the Magma repository.
So, I can use the same versions from the original repositories or from the Magma repository, you tell me what do you prefer? Personally I prefer to use the original repository as is cleaner. Also I would like to add individual metacello configuration for WriteBarrier (that takes care of its own dependencies, i.e. NewCompiler) and have the Magma configuration use the WriteBarrier configuration. This way Magma doesn't even have to know about the dependencies of WriteBarrier but only about its own dependencies.
My reasoning has always been that *developers* must take responsibility for building an image with correct components anyway. Identifying a need to upgrade some of these packages is something a developer would need / want to do explicitly, not implicitly.
Perhaps for the "MagmaTester" project, we can reference them from the live locations, but for the "Magma" project, they should be static versions..?
- Chris
(the same versions of course but from the original project) or do you want to use the versions form the Magma repository?
Same for Collections-BTree that is on:
http://www.squeaksource.com/BTree
Cheers
Miguel Cobá http://miguel.leugim.com.mx
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
So, I can use the same versions from the original repositories or from the Magma repository, you tell me what do you prefer? Personally I prefer to use the original repository as is cleaner. Also I would like to add individual metacello configuration for WriteBarrier (that takes care of its own dependencies, i.e. NewCompiler) and have the Magma configuration use the WriteBarrier configuration. This way Magma doesn't even have to know about the dependencies of WriteBarrier but only about its own dependencies.
Yes, I concur with your preferences. - Chris
I was missing a dependency: Ma object serialization tester :)
El mar, 12-01-2010 a las 12:19 -0600, Miguel Enrique Cobá Martinez escribió:
The message was held until approvement by attachment size.
I have exported png to gif with very bad quality and zip the files.
They are attached now
Cheers
El mar, 12-01-2010 a las 12:08 -0600, Miguel Enrique Cobá Martinez escribió:
Hi Chris,
I'm creating the Metacello configuration for Magma. I have almost all done but I need your feedback for the correct dependencies of the packages that compose Magma.
First, I used a clean PharoCore 10505 image. Using monticello browser I loaded
1.0r43 mcm -> 1.0r43 (tester).mcm
that installed:
Ma exception handling-cmm.32 Ma base additions-cmm.149 Ma proxy support-cmm.40 Ma traverse object graphs-cmm.29 MaFixedWidthReport-cmm.7 Ma Statistics-cmm.21 Ma object serialization-cmm.220 Collections-BTree-lr.68 Ma special collections-cmm.101 Ma client server-cmm.214 WriteBarrier-pmm.26 Magma client-cmm.446 Ma contextual search-cmm.29 Magma server-cmm.382 Ma Armored Code-cmm.144 Ma Squeak domain-cmm.28 Ma special collections tester-cmm.12 Ma object serialization tester-cmm.27 Magma tester-cmm.352
Then, using the instructions from Lukas Renggli:
http://lists.gforge.inria.fr/pipermail/pharo-project/2010-January/019678.htm...
and using the DependencyBrowser from Hernán Morales:
http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php
I created the attached .dot file with the dependencies for all the packages for Magma (tester, server and client). The code to generate it was:
(PDPackageAnalyzer onPackagesNamed: #( 'Magma tester' 'Ma special collections tester' 'Ma Squeak domain' 'Ma Armored Code' 'Magma server' 'Ma contextual search' 'Magma client' 'WriteBarrier' 'Ma client server' 'Ma special collections' 'Collections-BTree' 'Ma object serialization' 'Ma Statistics' 'MaFixedWidthReport' 'Ma traverse object graphs' 'Ma proxy support' 'Ma base additions' 'Ma exception handling' )) save: 'magma.dot'
This is the correct one:
(PDPackageAnalyzer onPackagesNamed: #( 'Magma tester' 'Ma special collections tester' 'Ma Squeak domain' 'Ma Armored Code' 'Magma server' 'Ma contextual search' 'Magma client' 'WriteBarrier' 'Ma client server' 'Ma special collections' 'Collections-BTree' 'Ma object serialization' 'Ma object serialization tester' 'Ma Statistics' 'MaFixedWidthReport' 'Ma traverse object graphs' 'Ma proxy support' 'Ma base additions' 'Ma exception handling' )) save: 'magma.dot'
Then using graphviz from linux (installed in Debian Linux as aptitude install graphviz) I generated the attached png graph of the dependencies with:
$ cat magma.dot | dot -Tpng > magma.png
I have checked dependency browser vs. PDPackageAnalyzer and both of them agree on the dependencies so I am almost sure that is ok. But your review will be very welcome.
Couple of things I found in this process:
- The WriteBarrier depends on class ByteCodeGenerator that isn't
included in Pharo. It appears to be on NewCompiler. Should I add NewCompiler as a dependency for Magma, or is writebarrier useful without NewCompiler.
- The Magma tester project depends on ProjectHistory that doesn't exist
anymore in Pharo. Maybe this should be a conditional in Magma or the test modified to not use this class, at least in Pharo.
- Ma Armored Code depends on OSProcess but the mcm doesn't includes it.
Now, as I said, I am doing the Metacello configuration for loading Magma in Pharo (and maybe also in Squeak) and this will permit to load Tester, Server and Client, WITH ALL the dependencies needed. This means that when loading tester will load OSProcess and when loading WriteBarrier will load also NewCompiler.
Any comment on this?
Thanks
Cheers
Hi Miguel, thanks for doing this! I, unfortunately, have not had time to look into Metacello; does it *finally* (after all these years) now address the issues of package-dependencies? Great!
- The WriteBarrier depends on class ByteCodeGenerator that isn't
included in Pharo. It appears to be on NewCompiler. Should I add NewCompiler as a dependency for Magma, or is writebarrier useful without NewCompiler.
I believe WriteBarrier needs NewCompiler to generate the overriding methods. However, I wouldn't add it as a dependency because it is an optional feature that some folks may not wish to have. I'm not even sure that NewCompiler / WriteBarrier even work at all in Pharo, so I would not have it as a dependency.
- The Magma tester project depends on ProjectHistory that doesn't exist
anymore in Pharo. Maybe this should be a conditional in Magma or the test modified to not use this class, at least in Pharo.
This reference to ProjectHistory should be converted to a Symbol (e.g., (Smalltalk hasClassNamed: #ProjectHistory) ifTrue: [ (Smalltalk classNamed: #ProjectHistory) ... ].
- Ma Armored Code depends on OSProcess but the mcm doesn't includes it.
The dependency on OSProcess should be removed in a similar manner.
Now, as I said, I am doing the Metacello configuration for loading Magma in Pharo (and maybe also in Squeak) and this will permit to load Tester, Server and Client, WITH ALL the dependencies needed. This means that when loading tester will load OSProcess and when loading WriteBarrier will load also NewCompiler.
I think the OSProcess for MagmaTester sounds pretty good; I just can't imagine testing without it.
I'm almost inclined, however, to want to even remove WriteBarrier from the standard installation, make it optional. The user can then load it separately, if they wish. In that case, NewCompiler a dependency of WriteBarrier, permitting a one-click install of the WriteBarrier option, sounds good. However, I do not have time to support the WriteBarrier package for Pharo.
- Chris
El mié, 13-01-2010 a las 09:39 -0600, Chris Muller escribió:
Hi Miguel, thanks for doing this! I, unfortunately, have not had time to look into Metacello; does it *finally* (after all these years) now address the issues of package-dependencies? Great!
- The WriteBarrier depends on class ByteCodeGenerator that isn't
included in Pharo. It appears to be on NewCompiler. Should I add NewCompiler as a dependency for Magma, or is writebarrier useful without NewCompiler.
I believe WriteBarrier needs NewCompiler to generate the overriding methods. However, I wouldn't add it as a dependency because it is an optional feature that some folks may not wish to have. I'm not even sure that NewCompiler / WriteBarrier even work at all in Pharo, so I would not have it as a dependency.
Ok, by the moment I am leaving the dependency on NewCompiler out of the configuration. So Magma installs WriteBarrier without NewCompiler. Lets see if someone reports a bug with this. Anyway this is how the current .mcm works, only installs WriteBarrier but not NewCompiler.
And indeed, NewCompiler is currently being rewritten so it doesn't work nor in Squeak nor Pharo. When stable I'll revisit this issue.
- The Magma tester project depends on ProjectHistory that doesn't exist
anymore in Pharo. Maybe this should be a conditional in Magma or the test modified to not use this class, at least in Pharo.
This reference to ProjectHistory should be converted to a Symbol (e.g., (Smalltalk hasClassNamed: #ProjectHistory) ifTrue: [ (Smalltalk classNamed: #ProjectHistory) ... ].
Ok, should I make the change and send a patch to you or you're adding it to the Magma code?
- Ma Armored Code depends on OSProcess but the mcm doesn't includes it.
The dependency on OSProcess should be removed in a similar manner.
Yes this dependency is only for when the user install Magma Tester, not Magma Server or Magma Client.
Now, as I said, I am doing the Metacello configuration for loading Magma in Pharo (and maybe also in Squeak) and this will permit to load Tester, Server and Client, WITH ALL the dependencies needed. This means that when loading tester will load OSProcess and when loading WriteBarrier will load also NewCompiler.
I think the OSProcess for MagmaTester sounds pretty good; I just can't imagine testing without it.
Yes, this will be installed automatically when loading Magma Tester only.
I'm almost inclined, however, to want to even remove WriteBarrier from the standard installation, make it optional. The user can then load it separately, if they wish. In that case, NewCompiler a dependency of WriteBarrier, permitting a one-click install of the WriteBarrier option, sounds good. However, I do not have time to support the WriteBarrier package for Pharo.
Ok, I will try to add a ConfigurationOfWriteBarrier that takes care of its own dependencies. Meanwhile, I leave the WriteBarrier without NewCompiler in the Magma installation.
- Chris
On 13 Jan 2010, at 15:39, Chris Muller wrote:
Hi Miguel, thanks for doing this! I, unfortunately, have not had time to look into Metacello; does it *finally* (after all these years) now address the issues of package-dependencies? Great!
"after all these years" !!!!!
Sake/Packages was written almost 2 years ago, explicitly to handle dependencies.
Metacello's even existence is an insult to the effort I put in to Sake/ Packages on behalf of the community.
I have withdrawn from contributions to squeak precisely because of the attitude of the communities to contributions and contributors.
"after all these years" huh
Keith
Hi Keith, did you not also read:
"I, unfortunately, have not had time to look into Metacello".
So I didn't get to Sake and I didn't get to Metacello. I'm sure you realize the challenge faced by Sake to achieve mainstream community adoption; that the nature of a packaging system would require it to be "mainstream" before many would have the cahaughneys to adopt it. A chicken and egg problem; I can certainly understand your frustration with that, it's the same problem Magma has faced its entire life.
Personally, my own lack of adoption of either tool has had nothing to do with "attitude". It's more to do with a combination of time, other demands, legacy systems, alternative solutions, and inertia. I've always had a favorable attitude toward your contributions. I hope you will reconsider your own attitude and rejoin the community.
Regards, Chris
On Wed, Jan 13, 2010 at 12:41 PM, keith keith_hodges@yahoo.co.uk wrote:
On 13 Jan 2010, at 15:39, Chris Muller wrote:
Hi Miguel, thanks for doing this! I, unfortunately, have not had time to look into Metacello; does it *finally* (after all these years) now address the issues of package-dependencies? Great!
"after all these years" !!!!!
Sake/Packages was written almost 2 years ago, explicitly to handle dependencies.
Metacello's even existence is an insult to the effort I put in to Sake/Packages on behalf of the community.
I have withdrawn from contributions to squeak precisely because of the attitude of the communities to contributions and contributors.
"after all these years" huh
Keith _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
On 13 Jan 2010, at 19:14, Chris Muller wrote:
Hi Keith, did you not also read:
"I, unfortunately, have not had time to look into Metacello".
So I didn't get to Sake and I didn't get to Metacello. I'm sure you realize the challenge faced by Sake to achieve mainstream community adoption; that the nature of a packaging system would require it to be "mainstream" before many would have the cahaughneys to adopt it. A chicken and egg problem; I can certainly understand your frustration with that, it's the same problem Magma has faced its entire life.
Personally, my own lack of adoption of either tool has had nothing to do with "attitude". It's more to do with a combination of time, other demands, legacy systems, alternative solutions, and inertia. I've always had a favorable attitude toward your contributions. I hope you will reconsider your own attitude and rejoin the community.
Unfortunately there is no longer a community to rejoin.
We have been taken over by a couple of premadonnas, nothing is being planned, there is no framework for decision making, testing, looking at the requirements of the community members, evaluating proposals, or encouraging and facilitating initiatives that would benefit users.
regards mag Keith
magma@lists.squeakfoundation.org
-
Chris Muller -
keith -
Miguel Enrique Cobá Martinez