Pragma keyword / selector / methodSelector
Hi, the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector now we have: - #methodSelector to access to method selector - #selector to access to pragma selector That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it. [1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-failing-due-to- MockSettings-class-Object-doesNotUnderstand-mocksystemsettings- SettingTreeBuilder-mocksystemse Cheers -- Pavel
Le 11/11/2016 à 10:55, Pavel Krivanek a écrit :
Hi,
the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector
now we have: - #methodSelector to access to method selector - #selector to access to pragma selector
That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it.
[1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-failing-due-to-MockSet...
Cheers -- Pavel
Hi! Thank you for the report. This broke the latest Metacello. I opened an issue: https://github.com/dalehenrich/metacello-work/issues/424 -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
On 11/11/16 10:55, Pavel Krivanek wrote:
Hi,
the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector
now we have: - #methodSelector to access to method selector - #selector to access to pragma selector
Revert and first do a deprecation phase Stephan
On 11/11/2016 15:58, Stephan Eggermont wrote:
Revert and first do a deprecation phase
Stephan
+1 It would be cool to go by a deprecation phase indeed. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
On 11/11/16 10:55, Pavel Krivanek wrote:
That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it.
As long as we do not systematically collect selectors sent from our sources we cannot know that most users are rewritten. That might be a valuable addition to our development process. For some experiments, take a look at DeprecationFinder Stephan
2016-11-11 10:55 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector
now we have: - #methodSelector to access to method selector - #selector to access to pragma selector
That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it.
[1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-failing-due-to- MockSettings-class-Object-doesNotUnderstand-mocksystemsettings-SettingTre eBuilder-mocksystemse
And it broke finder. 19336 <https://pharo.fogbugz.com/f/cases/19336/Finder-broken-Can-not-search-for-pra...> Finder broken: Can not search for pragmas
Cheers -- Pavel
2016-11-13 10:06 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-11 10:55 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector
now we have: - #methodSelector to access to method selector - #selector to access to pragma selector
That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it.
[1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-failing-due-to- MockSettings-class-Object-doesNotUnderstand-mocksystemsettings- SettingTreeBuilder-mocksystemse
And it broke finder. 19336 <https://pharo.fogbugz.com/f/cases/19336/Finder-broken-Can-not-search-for-pra...> Finder broken: Can not search for pragmas
And FileList can not show .cs files anymore. I think both has something to do with a lock (?) during the transform of the autodeprecation.
Cheers -- Pavel
Well, we will revert the change -- Pavel 2016-11-13 17:33 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-13 10:06 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-11 10:55 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector
now we have: - #methodSelector to access to method selector - #selector to access to pragma selector
That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it.
[1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-fa iling-due-to-MockSettings-class-Object-doesNotUnderstand-moc ksystemsettings-SettingTreeBuilder-mocksystemse
And it broke finder. 19336 <https://pharo.fogbugz.com/f/cases/19336/Finder-broken-Can-not-search-for-pra...> Finder broken: Can not search for pragmas
And FileList can not show .cs files anymore. I think both has something to do with a lock (?) during the transform of the autodeprecation.
Cheers -- Pavel
2016-11-14 9:42 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
Well, we will revert the change
revert the autodeprecation or the new api ? I made a fix for case 19336 Finder and FileList can now work with the new api.
-- Pavel
2016-11-13 17:33 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-13 10:06 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-11 10:55 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector
now we have: - #methodSelector to access to method selector - #selector to access to pragma selector
That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it.
[1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-fa iling-due-to-MockSettings-class-Object-doesNotUnderstand-moc ksystemsettings-SettingTreeBuilder-mocksystemse
And it broke finder. 19336 <https://pharo.fogbugz.com/f/cases/19336/Finder-broken-Can-not-search-for-pra...> Finder broken: Can not search for pragmas
And FileList can not show .cs files anymore. I think both has something to do with a lock (?) during the transform of the autodeprecation.
Cheers -- Pavel
Revert the new API. It was mistake to integrate it in the code freeze phase. -- Pavel 2016-11-14 9:53 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-14 9:42 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
Well, we will revert the change
revert the autodeprecation or the new api ? I made a fix for case 19336 Finder and FileList can now work with the new api.
-- Pavel
2016-11-13 17:33 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-13 10:06 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-11 10:55 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector
now we have: - #methodSelector to access to method selector - #selector to access to pragma selector
That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it.
[1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-fa iling-due-to-MockSettings-class-Object-doesNotUnderstand-moc ksystemsettings-SettingTreeBuilder-mocksystemse
And it broke finder. 19336 <https://pharo.fogbugz.com/f/cases/19336/Finder-broken-Can-not-search-for-pra...> Finder broken: Can not search for pragmas
And FileList can not show .cs files anymore. I think both has something to do with a lock (?) during the transform of the autodeprecation.
Cheers -- Pavel
On 14 Nov 2016, at 10:00, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Revert the new API. It was mistake to integrate it in the code freeze phase.
yep, thatâs accurate :) Esteban
-- Pavel
2016-11-14 9:53 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:
2016-11-14 9:42 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>>: Well, we will revert the change
revert the autodeprecation or the new api ? I made a fix for case 19336 Finder and FileList can now work with the new api.
-- Pavel
2016-11-13 17:33 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:
2016-11-13 10:06 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:
2016-11-11 10:55 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>>: Hi,
the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector
now we have: - #methodSelector to access to method selector - #selector to access to pragma selector
That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it.
[1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-failing-due-to-MockSet...
And it broke finder. 19336 <https://pharo.fogbugz.com/f/cases/19336/Finder-broken-Can-not-search-for-pra...> Finder broken: Can not search for pragmas
And FileList can not show .cs files anymore. I think both has something to do with a lock (?) during the transform of the autodeprecation.
Cheers -- Pavel
Great. Le 14 nov. 2016 11:23, "Esteban Lorenzano" <estebanlm@gmail.com> a écrit :
On 14 Nov 2016, at 10:00, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Revert the new API. It was mistake to integrate it in the code freeze phase.
yep, thatâs accurate :)
Esteban
-- Pavel
2016-11-14 9:53 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-14 9:42 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
Well, we will revert the change
revert the autodeprecation or the new api ? I made a fix for case 19336 Finder and FileList can now work with the new api.
-- Pavel
2016-11-13 17:33 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-13 10:06 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-11 10:55 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,
the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector
now we have: - #methodSelector to access to method selector - #selector to access to pragma selector
That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it.
[1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-fa iling-due-to-MockSettings-class-Object-doesNotUnderstand-moc ksystemsettings-SettingTreeBuilder-mocksystemse
And it broke finder. 19336 <https://pharo.fogbugz.com/f/cases/19336/Finder-broken-Can-not-search-for-pra...> Finder broken: Can not search for pragmas
And FileList can not show .cs files anymore. I think both has something to do with a lock (?) during the transform of the autodeprecation.
Cheers -- Pavel
Hi, Please do not revert the API. Just comment out the deprecation. The code in Moose was already updated to the new API and I presume other projects might be in the same situation. Cheers, Doru
On Nov 14, 2016, at 10:00 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Revert the new API. It was mistake to integrate it in the code freeze phase.
-- Pavel
2016-11-14 9:53 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-14 9:42 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>: Well, we will revert the change
revert the autodeprecation or the new api ? I made a fix for case 19336 Finder and FileList can now work with the new api.
-- Pavel
2016-11-13 17:33 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-13 10:06 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-11-11 10:55 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>: Hi,
the API of Pragma was changed in quite dangerous way. In past we had: - #selector to access to method selector - #keyword to access to pragma selector
now we have: - #methodSelector to access to method selector - #selector to access to pragma selector
That means that the meaning of the message #selector was changed and it can cause some problems (like some currently failing tests [1]). The #selector message was deprecated in the middle of the transition process so most of usages should be already rewritten to #methodSelector but we need to be aware of it.
[1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-failing-due-to-MockSet...
And it broke finder. 19336 Finder broken: Can not search for pragmas
And FileList can not show .cs files anymore. I think both has something to do with a lock (?) during the transform of the autodeprecation.
Cheers -- Pavel
-- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."
On 14/11/2016 13:44, Tudor Girba wrote:
Hi,
Please do not revert the API. Just comment out the deprecation. The code in Moose was already updated to the new API and I presume other projects might be in the same situation.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
Changing the API without a deprecation phase is bad. This kind of breaking change without warning is something companies can fear. This is even more important when there is such a dangerous change. #selector is still here but do something different⦠This is bad to just change it in one go. Maybe some projects updated but most companies do not follow the development version of Pharo. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Hi, Indeed, I forgot that #selector is doing something else. This is a bit of a mess. Either we revert it today, or we leave it. Otherwise, more projects will adopt the new API only to break again afterwards. Doru
On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
On 14/11/2016 13:44, Tudor Girba wrote:
Hi,
Please do not revert the API. Just comment out the deprecation. The code in Moose was already updated to the new API and I presume other projects might be in the same situation.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
Changing the API without a deprecation phase is bad. This kind of breaking change without warning is something companies can fear. This is even more important when there is such a dangerous change. #selector is still here but do something different⦠This is bad to just change it in one go.
Maybe some projects updated but most companies do not follow the development version of Pharo.
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
-- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."
we need to revert. this is a huge mess in a very inappropriate moment :) Esteban
On 14 Nov 2016, at 13:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Indeed, I forgot that #selector is doing something else. This is a bit of a mess. Either we revert it today, or we leave it. Otherwise, more projects will adopt the new API only to break again afterwards.
Doru
On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
On 14/11/2016 13:44, Tudor Girba wrote:
Hi,
Please do not revert the API. Just comment out the deprecation. The code in Moose was already updated to the new API and I presume other projects might be in the same situation.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
Changing the API without a deprecation phase is bad. This kind of breaking change without warning is something companies can fear. This is even more important when there is such a dangerous change. #selector is still here but do something different⦠This is bad to just change it in one go.
Maybe some projects updated but most companies do not follow the development version of Pharo.
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
-- www.tudorgirba.com www.feenk.com
"It's not how it is, it is how we see it."
Agreed. So who is doing it? Doru
On Nov 14, 2016, at 2:16 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
we need to revert. this is a huge mess in a very inappropriate moment :)
Esteban
On 14 Nov 2016, at 13:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Indeed, I forgot that #selector is doing something else. This is a bit of a mess. Either we revert it today, or we leave it. Otherwise, more projects will adopt the new API only to break again afterwards.
Doru
On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
On 14/11/2016 13:44, Tudor Girba wrote:
Hi,
Please do not revert the API. Just comment out the deprecation. The code in Moose was already updated to the new API and I presume other projects might be in the same situation.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
Changing the API without a deprecation phase is bad. This kind of breaking change without warning is something companies can fear. This is even more important when there is such a dangerous change. #selector is still here but do something different⦠This is bad to just change it in one go.
Maybe some projects updated but most companies do not follow the development version of Pharo.
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
-- www.tudorgirba.com www.feenk.com
"It's not how it is, it is how we see it."
-- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."
We should not revert whole update so I created an issue: https://pharo.fogbugz.com/f/cases/19338/Revert-18233-improving-Pragma-API -- Pavel 2016-11-14 14:30 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Agreed. So who is doing it?
Doru
On Nov 14, 2016, at 2:16 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
we need to revert. this is a huge mess in a very inappropriate moment :)
Esteban
On 14 Nov 2016, at 13:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Indeed, I forgot that #selector is doing something else. This is a bit of a mess. Either we revert it today, or we leave it. Otherwise, more projects will adopt the new API only to break again afterwards.
Doru
On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D. < cyril.ferlicot@gmail.com> wrote:
On 14/11/2016 13:44, Tudor Girba wrote:
Hi,
Please do not revert the API. Just comment out the deprecation. The code in Moose was already updated to the new API and I presume other projects might be in the same situation.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
Changing the API without a deprecation phase is bad. This kind of breaking change without warning is something companies can fear. This is even more important when there is such a dangerous change. #selector is still here but do something different⦠This is bad to just change it in one go.
Maybe some projects updated but most companies do not follow the development version of Pharo.
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
-- www.tudorgirba.com www.feenk.com
"It's not how it is, it is how we see it."
-- www.tudorgirba.com www.feenk.com
"Don't give to get. Just give."
Breaking Metacello in Pharo 6: Not good. Revert: +1 On Mon, Nov 14, 2016 at 2:16 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
we need to revert. this is a huge mess in a very inappropriate moment :)
Esteban
On 14 Nov 2016, at 13:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Indeed, I forgot that #selector is doing something else. This is a bit of a mess. Either we revert it today, or we leave it. Otherwise, more projects will adopt the new API only to break again afterwards.
Doru
On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D. < cyril.ferlicot@gmail.com> wrote:
On 14/11/2016 13:44, Tudor Girba wrote:
Hi,
Please do not revert the API. Just comment out the deprecation. The code in Moose was already updated to the new API and I presume other projects might be in the same situation.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
Changing the API without a deprecation phase is bad. This kind of breaking change without warning is something companies can fear. This is even more important when there is such a dangerous change. #selector is still here but do something different⦠This is bad to just change it in one go.
Maybe some projects updated but most companies do not follow the development version of Pharo.
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
-- www.tudorgirba.com www.feenk.com
"It's not how it is, it is how we see it."
2016-11-14 11:27 GMT-03:00 phil@highoctane.be <phil@highoctane.be>:
Breaking Metacello in Pharo 6: Not good. Revert: +1
Breaking Metacello in any version = Not good. Metacello is very backward compatible but breaking pragma semantics would require a rewrite of many configurations that work okay today and would require a new version of Metacello that contemplates the new selectors based on some criteria. Regards! Esteban A. Maringolo
2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo@gmail.com>:
Breaking Metacello in any version = Not good.
Metacello is very backward compatible but breaking pragma semantics would require a rewrite of many configurations that work okay today
Why? ConfigurationOf~ not collect any pragmas by themselves. They only declare versions by pragmas. And we only need to fix Pharo version of Metacello which is already fork.
2016-11-14 11:50 GMT-03:00 Denis Kudriashov <dionisiydk@gmail.com>:
2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo@gmail.com>:
Breaking Metacello in any version = Not good.
Metacello is very backward compatible but breaking pragma semantics would require a rewrite of many configurations that work okay today
Why? ConfigurationOf~ not collect any pragmas by themselves. They only declare versions by pragmas.
You're right.
And we only need to fix Pharo version of Metacello which is already fork.
Which is not there yet. Quoting myself: "... and would require a new version of Metacello that contemplates the new selectors based on some criteria." Criteria being pharo version, or anything else that identifies the new pragma semantics. Regards!
On 14/11/2016 15:50, Denis Kudriashov wrote:
2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo@gmail.com <mailto:emaringolo@gmail.com>>:
Breaking Metacello in any version = Not good.
Metacello is very backward compatible but breaking pragma semantics would require a rewrite of many configurations that work okay today
Why? ConfigurationOf~ not collect any pragmas by themselves. They only declare versions by pragmas. And we only need to fix Pharo version of Metacello which is already fork.
Changes to Metacello should be done on metacello-work repository and not only on Pharo. Else we will not be able to load the latest Metacello anymore and we will not have the latest cool features of Dale. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
On 14 Nov 2016, at 17:18, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
On 14/11/2016 15:50, Denis Kudriashov wrote:
2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo@gmail.com <mailto:emaringolo@gmail.com>>:
Breaking Metacello in any version = Not good.
Metacello is very backward compatible but breaking pragma semantics would require a rewrite of many configurations that work okay today
Why? ConfigurationOf~ not collect any pragmas by themselves. They only declare versions by pragmas. And we only need to fix Pharo version of Metacello which is already fork.
Changes to Metacello should be done on metacello-work repository and not only on Pharo. Else we will not be able to load the latest Metacello anymore and we will not have the latest cool features of Dale.
Yes. The change has to be reverted and then later we need to see what to do in a way that is less disruptive. After we decided to freeze is for sure the wrong time for a change like this. Marcus
On 14 Nov 2016, at 17:18, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
On 14/11/2016 15:50, Denis Kudriashov wrote:
2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo@gmail.com <mailto:emaringolo@gmail.com>>:
Breaking Metacello in any version = Not good.
Metacello is very backward compatible but breaking pragma semantics would require a rewrite of many configurations that work okay today
Why? ConfigurationOf~ not collect any pragmas by themselves. They only declare versions by pragmas. And we only need to fix Pharo version of Metacello which is already fork.
Changes to Metacello should be done on metacello-work repository and not only on Pharo. Else we will not be able to load the latest Metacello anymore and we will not have the latest cool features of Dale.
Metacello should not be a fork. yes, we have problems to keep everything in line, but the fact that we have this problems does not means we should declare the exception a rule :) Esteban
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
2016-11-14 17:18 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot@gmail.com>:
Why? ConfigurationOf~ not collect any pragmas by themselves. They only declare versions by pragmas. And we only need to fix Pharo version of Metacello which is already fork.
Changes to Metacello should be done on metacello-work repository and not only on Pharo. Else we will not be able to load the latest Metacello
But we already has fork of Metacello in image. Many Metacello packages are from integrator. So loading latest version is not possible now. And merge will not be easy task anyway. But maybe I am wrong here.
On 14 Nov 2016, at 18:12, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-11-14 17:18 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot@gmail.com <mailto:cyril.ferlicot@gmail.com>>:
Why? ConfigurationOf~ not collect any pragmas by themselves. They only declare versions by pragmas. And we only need to fix Pharo version of Metacello which is already fork.
Changes to Metacello should be done on metacello-work repository and not only on Pharo. Else we will not be able to load the latest Metacello
But we already has fork of Metacello in image. Many Metacello packages are from integrator. So loading latest version is not possible now. And merge will not be easy task anyway. But maybe I am wrong here.
The idea was to integrate small things first⦠in the past we tried to push small changes to projects first, but it is extremely slow and very hard to get anything done⦠Marcus
Le 14/11/2016 à 18:12, Denis Kudriashov a écrit :
But we already has fork of Metacello in image. Many Metacello packages are from integrator. So loading latest version is not possible now. And merge will not be easy task anyway. But maybe I am wrong here.
For some projects as MaterialDesignLite I need the latest version of Metacello so I load it. Before the change in pragma it was fine. Dale try to keep Metacello running on Pharo with TravisCI I think. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Here is the CI thing for Travis. https://github.com/hpi-swa/smalltalkCI Phil On Mon, Nov 14, 2016 at 7:15 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com
wrote:
Le 14/11/2016 à 18:12, Denis Kudriashov a écrit :
But we already has fork of Metacello in image. Many Metacello packages are from integrator. So loading latest version is not possible now. And merge will not be easy task anyway. But maybe I am wrong here.
For some projects as MaterialDesignLite I need the latest version of Metacello so I load it. Before the change in pragma it was fine.
Dale try to keep Metacello running on Pharo with TravisCI I think.
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Whenever I update the master branch Metacello I run the full test suite against Pharo3.0 through Pharo6.0 (and will add 7.0) ... so the master branch is all that is needed for whatever version of Squeak, GemStone or Pharo you are using and I use Travis-Ci for running the tests ... For GemStone we run the Metacello tests against new versions of GemStone before the release of the next version of GemStone. It would be nice if Pharo did the same thing as a matter of course: run the Metacello tests against the new release of Pharo --- if not before at least close to the new release --- so that things like the change to Pragma could be found before the release ... I t would also be nice if the needed changes for Pharo were integrated into the master branch for Metacello on GitHub ... as Denis mentions, the packages are owned by the integrator so I for one am never sure what kind of changes have been made, but as long as tests are passing .... Dale On 11/14/2016 10:15 AM, Cyril Ferlicot D. wrote:
Le 14/11/2016 à 18:12, Denis Kudriashov a écrit :
But we already has fork of Metacello in image. Many Metacello packages are from integrator. So loading latest version is not possible now. And merge will not be easy task anyway. But maybe I am wrong here. For some projects as MaterialDesignLite I need the latest version of Metacello so I load it. Before the change in pragma it was fine.
Dale try to keep Metacello running on Pharo with TravisCI I think.
Hi All, can I suggest that Pharo and Squeak coordinate on a change. First, #selector is bad because it is ambiguous. As already determined #keyword is awful because it's false (it is a message selector, not just a keyword). So could we - use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword? - after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)? _,,,^..^,,,_ (phone)
On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2016-11-14 11:27 GMT-03:00 phil@highoctane.be <phil@highoctane.be>:
Breaking Metacello in Pharo 6: Not good. Revert: +1
Breaking Metacello in any version = Not good.
Metacello is very backward compatible but breaking pragma semantics would require a rewrite of many configurations that work okay today and would require a new version of Metacello that contemplates the new selectors based on some criteria.
Regards!
Esteban A. Maringolo
I was hit by this today already as it made Catalog slow like hell (which I fixed): https://pharo.fogbugz.com/f/cases/19342/. +1 for the short-term revert +10 for aligning Squeak and Pharo with a more intention revealing name Thx T.
Gesendet: Montag, 14. November 2016 um 19:49 Uhr Von: "Eliot Miranda" <eliot.miranda@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Cc: squeak-dev@lists.squeakfoundation.org Betreff: Re: [Pharo-dev] Pragma keyword / selector / methodSelector
Hi All,
can I suggest that Pharo and Squeak coordinate on a change. First, #selector is bad because it is ambiguous. As already determined #keyword is awful because it's false (it is a message selector, not just a keyword). So could we
- use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword?
- after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)?
_,,,^..^,,,_ (phone)
On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2016-11-14 11:27 GMT-03:00 phil@highoctane.be <phil@highoctane.be>:
Breaking Metacello in Pharo 6: Not good. Revert: +1
Breaking Metacello in any version = Not good.
Metacello is very backward compatible but breaking pragma semantics would require a rewrite of many configurations that work okay today and would require a new version of Metacello that contemplates the new selectors based on some criteria.
Regards!
Esteban A. Maringolo
participants (14)
-
Cyril Ferlicot D. -
Dale Henrichs -
Denis Kudriashov -
Eliot Miranda -
Esteban A. Maringolo -
Esteban Lorenzano -
Marcus Denker -
Nicolai Hess -
Pavel Krivanek -
phil＠highoctane.be -
philippe.back＠highoctane.be -
Stephan Eggermont -
Torsten Bergmann -
Tudor Girba