I'm pleased to announce that the ConfigurationOfMagma now includes
support for loading version 1.1r1 of Magma. In a Pharo or PharoCore 1.0 image evaluate: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMagma'; load. To install the Magma Client evaluate: ConfigurationOfMagma project latestVersion load: 'Client' To install the Magma Server evaluate: ConfigurationOfMagma project latestVersion load: 'Server' To install the Magma Tester evaluate: ConfigurationOfMagma project latestVersion load: 'Tester' Then if you want, run the test suite. Evaluate in a workspace: MagmaTestCase allowWriteBarrier: false. MagmaTestCase fullSuite maDebug. Enjoy -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Hi;
Thanks by the useful configuration. I tried today by first time on a Pharo 1.0 image and get a DNU Scanner class(Object)>> doesNotUnderstand:
#allowUnderscoreAsAssignment: I need to install some patch before run the installation? Cheers. Germán. El 3 de junio de 2010 21:46, Miguel Enrique Cobá Martínez <[hidden email]> escribió: I'm pleased to announce that the ConfigurationOfMagma now includes -- ================================================= Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com ================================================= _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
I checked a bit and saw that such method is on Scanner class on PharoCore 1.2, but not on Pharo 1.0.
What I missed? El 9 de julio de 2010 19:46, Germán Arduino <[hidden email]> escribió:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
I saw that exist a preference, but seems not work.
Also a closed issue talking about this topic (1544) but really don't understand how to use this in Pharo 1.0. Any clarification will be appreciated. Cheers. El 9 de julio de 2010 20:12, Germán Arduino <[hidden email]> escribió: I checked a bit and saw that such method is on Scanner class on PharoCore 1.2, but not on Pharo 1.0. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
El sáb, 10-07-2010 a las 12:14 -0300, Germán Arduino escribió:
> I saw that exist a preference, but seems not work. > > Also a closed issue talking about this topic (1544) but really don't > understand how to use this in Pharo 1.0. > > Any clarification will be appreciated. Hola Germán, just have the time to check this issue. I found the problem. This configuration was made and tested for PharoCore 1.0 (and maybe Pharo 1.0 but I always test on Pharo Core images). The version I published with support for 1.1r1 was ConfigurationOfMagma-MiguelCoba.31.mcz from 3 June 2010, 7:40:32 pm. Thas was tested, as I said, in PharoCore 1.0. In pharo core 1.0 the underscores are allowed. Also, in PharoCore 1.0 the setting is changed in a preference Preferences class>>allowUnderScoreAssingment. Remember that currently only PharoCore 1.0 is released and stable. 1.1 is frozen and 1.2 is unstable. Now, the configuration was modified in order to work for 1.1 and 1.2. So the method: ConfigurationOfMagma>>preLoadForPharo "Magma extends EventSensor that was replaced by InputEventSensor in Pharo and Magma still has underscore code" Smalltalk at: #EventSensor put: InputEventSensor. got this line added: Scanner allowUnderscoreAsAssignment: true. But this is correct only for Pharo 1.1 and 1.2. In those versions of pharo, is the Scanner class the responsible of allowing or not the underscore in the code. In Pharo 1.0 that method doesn't exist in Scanner class. So the error you saw. So the configuration of magma now loads in 1.1 and 1.2 but is broken on the stable release. fortunately this can be reverted and everything will be ok. But... two things: - If we modify a stable configuration in order to make it work in a RC or unstable version of pharo things will probably broke, because of the many changes of the new version of pharo respect to the old one. - We must decide about the aproach for handle this. One proposal suggested to copy all the configurations tested in a given pharo version to a new repository for the next release. I proposed to use tags in the version methods that specify what versions of pharo they apply to (but didn't provide any code for this so the copy of configuration has more viability :) No matter what option is elected as long as is elected soon. Why, because people understandably want software to run in the newest version of pharo, but if there isn't a specific configuration for the new version, they will modify and possibly broke the stable one. So people, what should we do? Dale, can you please give your opinion. We need to decide now. P.S. I will revert for now the change in ConfigurationOfMagma so it works for 1.0 and will be broken for 1.1 and 1.2. Thanks > > Cheers. > > > El 9 de julio de 2010 20:12, Germán Arduino <[hidden email]> > escribió: > I checked a bit and saw that such method is on Scanner class > on PharoCore 1.2, but not on Pharo 1.0. > > What I missed? > > > El 9 de julio de 2010 19:46, Germán Arduino > <[hidden email]> escribió: > > > Hi; > > Thanks by the useful configuration. > > I tried today by first time on a Pharo 1.0 image and > get a DNU > > Scanner class(Object)>> > doesNotUnderstand: #allowUnderscoreAsAssignment: > > I need to install some patch before run the > installation? > > Cheers. > Germán. > > > > > El 3 de junio de 2010 21:46, Miguel Enrique Cobá > Martínez <[hidden email]> escribió: > > I'm pleased to announce that the > ConfigurationOfMagma now includes > > > support for loading version 1.1r1 of Magma. > > In a Pharo or PharoCore 1.0 image evaluate: > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfMagma'; > load. > > To install the Magma Client evaluate: > > ConfigurationOfMagma project latestVersion > load: 'Client' > > To install the Magma Server evaluate: > > ConfigurationOfMagma project latestVersion > load: 'Server' > > To install the Magma Tester evaluate: > > ConfigurationOfMagma project latestVersion > load: 'Tester' > > Then if you want, run the test suite. Evaluate > in a workspace: > > MagmaTestCase allowWriteBarrier: false. > MagmaTestCase fullSuite maDebug. > > > Enjoy > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > _______________________________________________ > Magma mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/magma > > > > > -- > ================================================= > Germán S. Arduino <gsa @ arsol.net> Twitter: > garduino > Arduino Software & Web Hosting > http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > > > > > > -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
We should have a MetacelloRepository for Pharo1.0 and Pharo1.1
and probably metacello should support versions too. Stef On Jul 20, 2010, at 5:59 AM, Miguel Enrique Cobá Martínez wrote: > El sáb, 10-07-2010 a las 12:14 -0300, Germán Arduino escribió: > >> I saw that exist a preference, but seems not work. >> >> Also a closed issue talking about this topic (1544) but really don't >> understand how to use this in Pharo 1.0. >> >> Any clarification will be appreciated. > > Hola Germán, > > just have the time to check this issue. I found the problem. > This configuration was made and tested for PharoCore 1.0 (and maybe > Pharo 1.0 but I always test on Pharo Core images). The version I > published with support for 1.1r1 was > > ConfigurationOfMagma-MiguelCoba.31.mcz from 3 June 2010, 7:40:32 pm. > > Thas was tested, as I said, in PharoCore 1.0. In pharo core 1.0 the > underscores are allowed. > Also, in PharoCore 1.0 the setting is changed in a preference > > Preferences class>>allowUnderScoreAssingment. > > Remember that currently only PharoCore 1.0 is released and stable. 1.1 > is frozen and 1.2 is unstable. > > Now, the configuration was modified in order to work for 1.1 and 1.2. > So the method: > > ConfigurationOfMagma>>preLoadForPharo > "Magma extends EventSensor that was replaced by InputEventSensor in > Pharo and Magma still has underscore code" > > Smalltalk at: #EventSensor put: InputEventSensor. > > got this line added: > > Scanner allowUnderscoreAsAssignment: true. > > But this is correct only for Pharo 1.1 and 1.2. In those versions of > pharo, is the Scanner class the responsible of allowing or not the > underscore in the code. In Pharo 1.0 that method doesn't exist in > Scanner class. So the error you saw. > > So the configuration of magma now loads in 1.1 and 1.2 but is broken on > the stable release. > > fortunately this can be reverted and everything will be ok. But... > > two things: > > - If we modify a stable configuration in order to make it work in a RC > or unstable version of pharo things will probably broke, because of the > many changes of the new version of pharo respect to the old one. > - We must decide about the aproach for handle this. > One proposal suggested to copy all the configurations tested in a > given pharo version to a new repository for the next release. > I proposed to use tags in the version methods that specify what > versions of pharo they apply to (but didn't provide any code for this so > the copy of configuration has more viability :) > > No matter what option is elected as long as is elected soon. Why, > because people understandably want software to run in the newest version > of pharo, but if there isn't a specific configuration for the new > version, they will modify and possibly broke the stable one. > > So people, what should we do? > Dale, can you please give your opinion. We need to decide now. > > P.S. I will revert for now the change in ConfigurationOfMagma so it > works for 1.0 and will be broken for 1.1 and 1.2. > > Thanks > > > >> >> Cheers. >> >> >> El 9 de julio de 2010 20:12, Germán Arduino <[hidden email]> >> escribió: >> I checked a bit and saw that such method is on Scanner class >> on PharoCore 1.2, but not on Pharo 1.0. >> >> What I missed? >> >> >> El 9 de julio de 2010 19:46, Germán Arduino >> <[hidden email]> escribió: >> >> >> Hi; >> >> Thanks by the useful configuration. >> >> I tried today by first time on a Pharo 1.0 image and >> get a DNU >> >> Scanner class(Object)>> >> doesNotUnderstand: #allowUnderscoreAsAssignment: >> >> I need to install some patch before run the >> installation? >> >> Cheers. >> Germán. >> >> >> >> >> El 3 de junio de 2010 21:46, Miguel Enrique Cobá >> Martínez <[hidden email]> escribió: >> >> I'm pleased to announce that the >> ConfigurationOfMagma now includes >> >> >> support for loading version 1.1r1 of Magma. >> >> In a Pharo or PharoCore 1.0 image evaluate: >> >> Gofer it >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfMagma'; >> load. >> >> To install the Magma Client evaluate: >> >> ConfigurationOfMagma project latestVersion >> load: 'Client' >> >> To install the Magma Server evaluate: >> >> ConfigurationOfMagma project latestVersion >> load: 'Server' >> >> To install the Magma Tester evaluate: >> >> ConfigurationOfMagma project latestVersion >> load: 'Tester' >> >> Then if you want, run the test suite. Evaluate >> in a workspace: >> >> MagmaTestCase allowWriteBarrier: false. >> MagmaTestCase fullSuite maDebug. >> >> >> Enjoy >> -- >> Miguel Cobá >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Magma mailing list >> [hidden email] >> http://lists.squeakfoundation.org/mailman/listinfo/magma >> >> >> >> >> -- >> ================================================= >> Germán S. Arduino <gsa @ arsol.net> Twitter: >> garduino >> Arduino Software & Web Hosting >> http://www.arduinosoftware.com >> PasswordsPro http://www.passwordspro.com >> ================================================= >> >> >> >> >> >> > > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Administrator
|
In reply to this post by Miguel Cobá
For now, you can use the hack that Dale suggested in http://groups.google.com/group/metacello/browse_thread/thread/a27c95d24974adda/31fdfa02fc18a4e3.
> Take a look a ConfigurationOfGemTools>>project. In that method I created a #'pharo1.0Beta' attribute by looking at the SystemVersion current version...
Cheers,
Sean |
Hi Miguel. I understand your problem, and we are working on that with Dale and Stef. Having repositories for a specific Pharo version and so on. But we are just starting....
By the moment, you can use what Sean told you, or, just update the configuration, but in a new version. I mean....if you had the version 2.3.4 that was released and working in pharo 1.0, then don't touch it, create a new one, say, 2.4 and that works in 1.1. Of course this is not the perfect solution, but for the moment. But one thing for sure: do not update the SAME version that was working for 1.0. Magma should continue working in 1.0 using the same metacello version. cheers mariano On Tue, Jul 20, 2010 at 9:26 AM, Sean P. DeNigris <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
El mar, 20-07-2010 a las 10:17 +0200, Mariano Martinez Peck escribió:
> Hi Miguel. I understand your problem, and we are working on that with > Dale and Stef. Having repositories for a specific Pharo version and so > on. But we are just starting.... > > By the moment, you can use what Sean told you, or, just update the > configuration, but in a new version. I mean....if you had the version > 2.3.4 that was released and working in pharo 1.0, then don't touch it, > create a new one, say, 2.4 and that works in 1.1. Of course this is > not the perfect solution, but for the moment. But one thing for sure: > do not update the SAME version that was working for 1.0. > Magma should continue working in 1.0 using the same metacello version. Exactly. I will do it this night. BTW. What will be the solution, copying directories (debian does this too. They copy the repository contents and then diverge from them. The previous repository only receives bug fixes) but the solution of Dale, as I understand it uses tags to identify what version is running on and then load only the packages for that version. This solution is a third alternative. So by now we have: - Copy repositories of configurations for each new release - Use version attributes for conditionally loading packages in version methods. - Use tags to mark the pharo release a given version method applies. Then metacello searches for the version method with the highest number that is tagged with the release number of the image (got from SystemVersion) Cheers > > cheers > > mariano > > On Tue, Jul 20, 2010 at 9:26 AM, Sean P. DeNigris > <[hidden email]> wrote: > > For now, you can use the hack that Dale suggested in > http://groups.google.com/group/metacello/browse_thread/thread/a27c95d24974adda/31fdfa02fc18a4e3. > > > Take a look a ConfigurationOfGemTools>>project. In that > method I created a > > #'pharo1.0Beta' attribute by looking at the SystemVersion > current > > version... > -- > View this message in context: > http://forum.world.st/ANN-ConfigurationOfMagma-for-Magma-1-1r1-tp2242566p2295046.html > Sent from the Pharo Smalltalk mailing list archive at > Nabble.com. > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Am 20.07.10 16:42, schrieb Miguel Enrique Cobá Martínez:
> El mar, 20-07-2010 a las 10:17 +0200, Mariano Martinez Peck escribió: >> Hi Miguel. I understand your problem, and we are working on that with >> Dale and Stef. Having repositories for a specific Pharo version and so >> on. But we are just starting.... >> >> By the moment, you can use what Sean told you, or, just update the >> configuration, but in a new version. I mean....if you had the version >> 2.3.4 that was released and working in pharo 1.0, then don't touch it, >> create a new one, say, 2.4 and that works in 1.1. Of course this is >> not the perfect solution, but for the moment. But one thing for sure: >> do not update the SAME version that was working for 1.0. >> Magma should continue working in 1.0 using the same metacello version. > > Exactly. I will do it this night. > > BTW. What will be the solution, copying directories (debian does this > too. They copy the repository contents and then diverge from them. The > previous repository only receives bug fixes) but the solution of Dale, > as I understand it uses tags to identify what version is running on and > then load only the packages for that version. This solution is a third > alternative. So by now we have: > > - Copy repositories of configurations for each new release > - Use version attributes for conditionally loading packages in version > methods. > - Use tags to mark the pharo release a given version method applies. > Then metacello searches for the version method with the highest number > that is tagged with the release number of the image (got from > SystemVersion) > > Cheers Wouldn't it be good to also ask the maintainer of the offending packages to change the assignments such that Pharo will be happy without changing the preference? Regards, Andreas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
El mar, 20-07-2010 a las 18:33 +0200, Andreas Wacknitz escribió:
> Am 20.07.10 16:42, schrieb Miguel Enrique Cobá Martínez: > > El mar, 20-07-2010 a las 10:17 +0200, Mariano Martinez Peck escribió: > >> Hi Miguel. I understand your problem, and we are working on that with > >> Dale and Stef. Having repositories for a specific Pharo version and so > >> on. But we are just starting.... > >> > >> By the moment, you can use what Sean told you, or, just update the > >> configuration, but in a new version. I mean....if you had the version > >> 2.3.4 that was released and working in pharo 1.0, then don't touch it, > >> create a new one, say, 2.4 and that works in 1.1. Of course this is > >> not the perfect solution, but for the moment. But one thing for sure: > >> do not update the SAME version that was working for 1.0. > >> Magma should continue working in 1.0 using the same metacello version. > > > > Exactly. I will do it this night. > > > > BTW. What will be the solution, copying directories (debian does this > > too. They copy the repository contents and then diverge from them. The > > previous repository only receives bug fixes) but the solution of Dale, > > as I understand it uses tags to identify what version is running on and > > then load only the packages for that version. This solution is a third > > alternative. So by now we have: > > > > - Copy repositories of configurations for each new release > > - Use version attributes for conditionally loading packages in version > > methods. > > - Use tags to mark the pharo release a given version method applies. > > Then metacello searches for the version method with the highest number > > that is tagged with the release number of the image (got from > > SystemVersion) > > > > Cheers > Hi, > > Wouldn't it be good to also ask the maintainer of the offending packages > to change the assignments such that Pharo will be happy without changing > the preference? Chris Muller announced some time ago that he was changing the underscores to := assignments in them Magma codebase. He had concerns about the scripts for automating this because it changed the author timestamps of each method modified and he didn't want to lost those original timestamps. So until he publishes the new code without underscores, we must use the preference when loading the code. Cheers > > Regards, > Andreas > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Andreas Wacknitz
First, if you are creating configuration for a project and you have
different code that needs to be loaded depending upon the version of Pharo into which it is loaded, then you can add attiributes like #'Pharo1.1' or #'Pharo1.0' to control which packages get loaded into the image. This is a case where the maintainer _is_ involved in updating the application to ensure that it runs on both Pharo1.0 and Pharo1.1 or Pharo1.x. Secondly, not all maintainer can ensure that their project runs on Pharo1.0 and Pharo1.1, etc.. So there is a separate problem of identifying the versions of a project that are _known_ to work in Pharo1.0 or Pharo1.1. When a new Pharo1.x arrives, many projects may not work, but over time, more and more of the projects get ported to Pharo1.x so determining a means to communicate to users which projects are known to work is important. I would say that we haven't completely settled the second issue. As Miguel mentioned, I think it is clear that the following will be part of the process - Copy repositories of configurations (+mcz files) for each new release - Use version attributes for conditionally loading packages in version methods. I think that we're still up in the air (I know that I am) as to the best method for controlling the actual load. Ideally, the solution would not involve editing configurations (tags). Technically, once you copied the configs/mcz files that are known to work to a Pharo1.0 repository, all you need to do is use #repositoryOverrides: to force the load to be done from the Pharo1.0 repository, but we want something that is very simple and doesn't require an extra step and we're still discussing this. Dale Andreas Wacknitz wrote: > Am 20.07.10 16:42, schrieb Miguel Enrique Cobá Martínez: >> El mar, 20-07-2010 a las 10:17 +0200, Mariano Martinez Peck escribió: >>> Hi Miguel. I understand your problem, and we are working on that with >>> Dale and Stef. Having repositories for a specific Pharo version and so >>> on. But we are just starting.... >>> >>> By the moment, you can use what Sean told you, or, just update the >>> configuration, but in a new version. I mean....if you had the version >>> 2.3.4 that was released and working in pharo 1.0, then don't touch it, >>> create a new one, say, 2.4 and that works in 1.1. Of course this is >>> not the perfect solution, but for the moment. But one thing for sure: >>> do not update the SAME version that was working for 1.0. >>> Magma should continue working in 1.0 using the same metacello version. >> Exactly. I will do it this night. >> >> BTW. What will be the solution, copying directories (debian does this >> too. They copy the repository contents and then diverge from them. The >> previous repository only receives bug fixes) but the solution of Dale, >> as I understand it uses tags to identify what version is running on and >> then load only the packages for that version. This solution is a third >> alternative. So by now we have: >> >> - Copy repositories of configurations for each new release >> - Use version attributes for conditionally loading packages in version >> methods. >> - Use tags to mark the pharo release a given version method applies. >> Then metacello searches for the version method with the highest number >> that is tagged with the release number of the image (got from >> SystemVersion) >> >> Cheers > Hi, > > Wouldn't it be good to also ask the maintainer of the offending packages > to change the assignments such that Pharo will be happy without changing > the preference? > > Regards, > Andreas > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |