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 <garduino@gmail.com> 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 <garduino@gmail.com> 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 < miguel.coba@gmail.com> 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 Magma@lists.squeakfoundation.org 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 =================================================

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 <garduino@gmail.com> 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 <garduino@gmail.com> 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 <miguel.coba@gmail.com> 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 Magma@lists.squeakfoundation.org 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <sean@clipperadams.com>wrote:

For now, you can use the hack that Dale suggested in

http://groups.google.com/group/metacello/browse_thread/thread/a27c95d24974ad... .

...

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-tp2242566p229... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 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

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project