[Pharo-project] Fwd: I will customize phexample to work on both 1.4 and 2.0
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 <smalltalk@stefan-marr.de> 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 <frank.shearar@gmail.com> wrote:
On 10 February 2013 17:28, Stefan Marr <smalltalk@stefan-marr.de> 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
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
participants (4)
-
Frank Shearar -
H. Hirzel -
Stefan Marr -
stephane ducasse