Fwd: I will customize phexample to work on both 1.4 and 2.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: I will customize phexample to work on both 1.4 and 2.0

Stefan Marr-3
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


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: I will customize phexample to work on both 1.4 and 2.0

Frank Shearar-3
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: I will customize phexample to work on both 1.4 and 2.0

Hannes Hirzel
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
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: I will customize phexample to work on both 1.4 and 2.0

stephane ducasse
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
>
>