MiscPrimitivePlugin, translated primitives and ByteString method(s)

>  
> The aim of this change is to help fixing the
> ByteString>>findSubstring:in:startingAt:matchTable: issue
> by moving the selector names , which should be translated from
> MiscPrimitivePlugin class to the corresponding classes,
>
> so they could choose which selectors to include.
>
> The problem, that Pharo having the fix for
> findSubstring:in:startingAt:matchTable: bug
> but this method can't be used for translation anymore because it is
> moved to another one:
> findSubstringViaPrimitive:in:startingAt:matchTable: , while original
> one dispatching to it, after testing that there is no widestrings.
>
> And so, VMMaker can't work on pharo without error, so either a patch
> should be applied to VMMaker to change selector from
> #findSubstring:in:startingAt:matchTable: to
> #findSubstringViaPrimitive:in:startingAt:matchTable: in
> MiscPrimitivePlugin , which sucks, because then
> VMMaker package become dirty and it is seen in builds and gets into
> every source file..
>
> , or if we apply this changeset to our images, then Pharo could answer
> different selector, without need
> patching anything.
>
> And for future, this pattern could be extended, to seek for all
> #translatedPrimitiveSelectors implementors in system, not just in 3
> classes.
> But that gets us back to discussion about separating
> responsibilities... so.. lets try to fix what we have instead.
>
> http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003364.html
>

>
> On Fri, Feb 04, 2011 at 05:34:27PM +0100, Igor Stasenko wrote:
>>
>> The aim of this change is to help fixing the
>> ByteString>>findSubstring:in:startingAt:matchTable: issue
>> by moving the selector names , which should be translated from
>> MiscPrimitivePlugin class to the corresponding classes,
>>
>> so they could choose which selectors to include.
>>
>> The problem, that Pharo having the fix for
>> findSubstring:in:startingAt:matchTable: bug
>> but this method can't be used for translation anymore because it is
>> moved to another one:
>> findSubstringViaPrimitive:in:startingAt:matchTable: , while original
>> one dispatching to it, after testing that there is no widestrings.
>>
>> And so, VMMaker can't work on pharo without error, so either a patch
>> should be applied to VMMaker to change selector from
>> #findSubstring:in:startingAt:matchTable: to
>> #findSubstringViaPrimitive:in:startingAt:matchTable: in
>> MiscPrimitivePlugin , which sucks, because then
>> VMMaker package become dirty and it is seen in builds and gets into
>> every source file..
>>
>> , or if we apply this changeset to our images, then Pharo could answer
>> different selector, without need
>> patching anything.
>>
>> And for future, this pattern could be extended, to seek for all
>> #translatedPrimitiveSelectors implementors in system, not just in 3
>> classes.
>> But that gets us back to discussion about separating
>> responsibilities... so.. lets try to fix what we have instead.
>>
>> http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003364.html
>>
>
> I am traveling and cannot look at the change set now (so ignore this if
> it is not relevant to your cs), but FYI Andreas already fixed the underlying
> problem in the VM that led to the Pharo refactoring, and Stef already agreed
> (Pharo list email somewhere) that it would be good to revert the Pharo change
> after the VM fix is in general circulation.
>

>
> On 4 February 2011 18:31, David T. Lewis <[hidden email]> wrote:
>>
>> On Fri, Feb 04, 2011 at 05:34:27PM +0100, Igor Stasenko wrote:
>>>
>>> The aim of this change is to help fixing the
>>> ByteString>>findSubstring:in:startingAt:matchTable: issue
>>> by moving the selector names , which should be translated from
>>> MiscPrimitivePlugin class to the corresponding classes,
>>>
>>> so they could choose which selectors to include.
>>>
>>> The problem, that Pharo having the fix for
>>> findSubstring:in:startingAt:matchTable: bug
>>> but this method can't be used for translation anymore because it is
>>> moved to another one:
>>> findSubstringViaPrimitive:in:startingAt:matchTable: , while original
>>> one dispatching to it, after testing that there is no widestrings.
>>>
>>> And so, VMMaker can't work on pharo without error, so either a patch
>>> should be applied to VMMaker to change selector from
>>> #findSubstring:in:startingAt:matchTable: to
>>> #findSubstringViaPrimitive:in:startingAt:matchTable: in
>>> MiscPrimitivePlugin , which sucks, because then
>>> VMMaker package become dirty and it is seen in builds and gets into
>>> every source file..
>>>
>>> , or if we apply this changeset to our images, then Pharo could answer
>>> different selector, without need
>>> patching anything.
>>>
>>> And for future, this pattern could be extended, to seek for all
>>> #translatedPrimitiveSelectors implementors in system, not just in 3
>>> classes.
>>> But that gets us back to discussion about separating
>>> responsibilities... so.. lets try to fix what we have instead.
>>>
>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003364.html
>>>
>>
>> I am traveling and cannot look at the change set now (so ignore this if
>> it is not relevant to your cs), but FYI Andreas already fixed the underlying
>> problem in the VM that led to the Pharo refactoring, and Stef already agreed
>> (Pharo list email somewhere) that it would be good to revert the Pharo change
>> after the VM fix is in general circulation.
>>
>
> But even if that, i think it is generally better let each class
> personally decide, which selectors should be translated
> and which ones not.
>
>> Dave
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> Nicolas
>
> 2011/2/4 Igor Stasenko <[hidden email]>:
>>
>> On 4 February 2011 18:31, David T. Lewis <[hidden email]> wrote:
>>>
>>> On Fri, Feb 04, 2011 at 05:34:27PM +0100, Igor Stasenko wrote:
>>>>
>>>> The aim of this change is to help fixing the
>>>> ByteString>>findSubstring:in:startingAt:matchTable: issue
>>>> by moving the selector names , which should be translated from
>>>> MiscPrimitivePlugin class to the corresponding classes,
>>>>
>>>> so they could choose which selectors to include.
>>>>
>>>> The problem, that Pharo having the fix for
>>>> findSubstring:in:startingAt:matchTable: bug
>>>> but this method can't be used for translation anymore because it is
>>>> moved to another one:
>>>> findSubstringViaPrimitive:in:startingAt:matchTable: , while original
>>>> one dispatching to it, after testing that there is no widestrings.
>>>>
>>>> And so, VMMaker can't work on pharo without error, so either a patch
>>>> should be applied to VMMaker to change selector from
>>>> #findSubstring:in:startingAt:matchTable: to
>>>> #findSubstringViaPrimitive:in:startingAt:matchTable: in
>>>> MiscPrimitivePlugin , which sucks, because then
>>>> VMMaker package become dirty and it is seen in builds and gets into
>>>> every source file..
>>>>
>>>> , or if we apply this changeset to our images, then Pharo could answer
>>>> different selector, without need
>>>> patching anything.
>>>>
>>>> And for future, this pattern could be extended, to seek for all
>>>> #translatedPrimitiveSelectors implementors in system, not just in 3
>>>> classes.
>>>> But that gets us back to discussion about separating
>>>> responsibilities... so.. lets try to fix what we have instead.
>>>>
>>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003364.html
>>>>
>>>
>>> I am traveling and cannot look at the change set now (so ignore this if
>>> it is not relevant to your cs), but FYI Andreas already fixed the underlying
>>> problem in the VM that led to the Pharo refactoring, and Stef already agreed
>>> (Pharo list email somewhere) that it would be good to revert the Pharo change
>>> after the VM fix is in general circulation.
>>>
>>
>> But even if that, i think it is generally better let each class
>> personally decide, which selectors should be translated
>> and which ones not.
>>
>>> Dave
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>