Hi Stef:
Begin forwarded message: > because now it only works on 2.0 > So I will use symbolic versions for real. > I think that you are working on 2.0. > On 1.4 I get DNU due to substrings... What's the best way to handle such trivial difference between different versions, or even dialects? So, the problem is basically #includesSubString: vs. #includesSubstring:, used by a single method. Creating a version specific package just for that methods seems to be exaggerated. However, you committed now Phexample-StephaneDucasse.68 that is based on Phexample-StefanMarr.67. I think, in general that will lead to mighty confusion because it is not a general fix, but Pharo 1.4 specific. The latest version now breaks on Pharo 2.0 again (with a deprecation...) Wouldn't it have been better to properly branch off this change and commit it to Phexample.Pharo1.4-StephaneDucasse.68 for instance? Any other good approach to handle such small differences in a scalable way would also be interesting... Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 |
On 10 February 2013 17:28, Stefan Marr <[hidden email]> wrote:
> Hi Stef: > > Begin forwarded message: > >> because now it only works on 2.0 >> So I will use symbolic versions for real. >> I think that you are working on 2.0. >> On 1.4 I get DNU due to substrings... > > > What's the best way to handle such trivial difference between different versions, or even dialects? > > So, the problem is basically #includesSubString: vs. #includesSubstring:, used by a single method. > > Creating a version specific package just for that methods seems to be exaggerated. > > However, you committed now Phexample-StephaneDucasse.68 that is based on Phexample-StefanMarr.67. > I think, in general that will lead to mighty confusion because it is not a general fix, but Pharo 1.4 specific. > The latest version now breaks on Pharo 2.0 again (with a deprecation...) > > Wouldn't it have been better to properly branch off this change and commit it to Phexample.Pharo1.4-StephaneDucasse.68 for instance? > > Any other good approach to handle such small differences in a scalable way would also be interesting... Given that Squeak suffers this particular problem as well (at least for the moment...), perhaps a compatibility shim might be in order? Non-Pharo-2.0 images simply file in a compatibility package that lets them use Phexample. It keeps the problem where it belongs: in those images that still have a horrible mEthodNaMe. frank > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > |
Hello Stefan
Good that you work on customizing phexample to work on both 1.4 and 2.0. On 2/10/13, Frank Shearar <[hidden email]> wrote: > On 10 February 2013 17:28, Stefan Marr <[hidden email]> wrote: >> Hi Stef: >> >> Begin forwarded message: >> >>> because now it only works on 2.0 >>> So I will use symbolic versions for real. >>> I think that you are working on 2.0. >>> On 1.4 I get DNU due to substrings... >> >> >> What's the best way to handle such trivial difference between different >> versions, or even dialects? >> >> So, the problem is basically #includesSubString: vs. #includesSubstring:, >> used by a single method. >> >> Creating a version specific package just for that methods seems to be >> exaggerated. No, if you look at it as a 'Shim' http://en.wikipedia.org/wiki/Shim_%28computing%29 It documents the differences between Pharo 1.4 and Pharo 2.0. If there is only one method in it that this is a helpful piece of information. Maybe there will be more methods later. Frank once had a 'PharoCompatibilityPackage' for Squeak for a particular purpose. I only had one method. This is a solution which communicate well. --Hannes >> However, you committed now Phexample-StephaneDucasse.68 that is based on >> Phexample-StefanMarr.67. >> I think, in general that will lead to mighty confusion because it is not a >> general fix, but Pharo 1.4 specific. >> The latest version now breaks on Pharo 2.0 again (with a deprecation...) >> >> Wouldn't it have been better to properly branch off this change and commit >> it to Phexample.Pharo1.4-StephaneDucasse.68 for instance? >> >> Any other good approach to handle such small differences in a scalable way >> would also be interesting... > > Given that Squeak suffers this particular problem as well (at least > for the moment...), perhaps a compatibility shim might be in order? > Non-Pharo-2.0 images simply file in a compatibility package that lets > them use Phexample. It keeps the problem where it belongs: in those > images that still have a horrible mEthodNaMe. > > frank > >> Thanks >> Stefan >> >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> > > |
In reply to this post by Stefan Marr-3
I have no idea. I'm sorry but I'm rather busy (in fact more than busy).
I will not have the time to produce a version that works for other dialects. Now if this is a problem I will simply fork the project. We have to migrate Moose to 2.0 and this is not an easy task. We want to rewrite all the configurations and I have no time for the rest. As you know my goal is to make sure that people can make money with Smalltalk and we are working hard on that, we are building a company and I want it to succeed. So there is only that and Pharo in my radar. Stef > What's the best way to handle such trivial difference between different versions, or even dialects? > > So, the problem is basically #includesSubString: vs. #includesSubstring:, used by a single method. > > Creating a version specific package just for that methods seems to be exaggerated. > > However, you committed now Phexample-StephaneDucasse.68 that is based on Phexample-StefanMarr.67. > I think, in general that will lead to mighty confusion because it is not a general fix, but Pharo 1.4 specific. > The latest version now breaks on Pharo 2.0 again (with a deprecation...) > > Wouldn't it have been better to properly branch off this change and commit it to Phexample.Pharo1.4-StephaneDucasse.68 for instance? > > Any other good approach to handle such small differences in a scalable way would also be interesting... > > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > |
Free forum by Nabble | Edit this page |