2009/11/3 David T. Lewis lewis@mail.msen.com:

On Tue, Nov 03, 2009 at 11:46:50AM +0100, arnaud Jean Baptiste wrote:

...

the MiscPrimitivesPlugin loop when generating.

the cause is :

the primitives: #findSubstring:in:startingAt:matchTable: was change to the primitive that name is now: #findSubstringViaPrimitive:in:startingAt: matchTable:

i can simply change the name in #translatedPrimitives (MiscPrimitivePlugin ) method but i am looking for long term solution.

Good question.

Pharo is doing this in ByteString:

findSubstring: key in: body startingAt: start matchTable: matchTable        key isWideString ifTrue: [^super findSubstring: key in: body startingAt: start matchTable: matchTable].        ^self findSubstringViaPrimitive: key in: body startingAt: start matchTable: matchTable

I am not familiar with WideString usage, perhaps someone can comment as to whether the the #findSubstringViaPrimitive:in:startingAt:matchTable: is likely to be adopted in Squeak generally. If yes, then we should probably change MiscPrimitivePlugin class>>translatedPrimitives to look for that selector if present in the image. Or perhaps the check for WideString belongs in the primitive itself?

Dave

http://bugs.squeak.org/view.php?id=6366 has been solved differently in trunk and Pharo. Changes in Pharo are stamped with an anterior date and might come from another project (Sophie ?).

I think the check for WideString belongs to primitive, and super call belongs to fallback code.

Concerning super, I note that Pharo version works if and only if this invariant is true: Character charCode > 255 ==> (Character leadingChar ~~ 0).

un-carefull synthetic String don't respect it and then fail: (WideString with: 300 asCharacter with: 400 asCharacter) findString: (WideString with: 300 asCharacter) startingAt: 1 caseSensitive: false

If we refactor to have unicode leadingChar = 0, then Pharo version will have to be changed.

Nicolas

On Tue, Nov 03, 2009 at 02:06:36PM +0100, Nicolas Cellier wrote:

2009/11/3 David T. Lewis lewis@mail.msen.com:

...

On Tue, Nov 03, 2009 at 11:46:50AM +0100, arnaud Jean Baptiste wrote:

...

the MiscPrimitivesPlugin loop when generating.

the cause is :

the primitives: #findSubstring:in:startingAt:matchTable: was change to the primitive that name is now: #findSubstringViaPrimitive:in:startingAt: matchTable:

i can simply change the name in #translatedPrimitives (MiscPrimitivePlugin ) method but i am looking for long term solution.

Good question.

Pharo is doing this in ByteString:

findSubstring: key in: body startingAt: start matchTable: matchTable ? ? ? ?key isWideString ifTrue: [^super findSubstring: key in: body startingAt: start matchTable: matchTable]. ? ? ? ?^self findSubstringViaPrimitive: key in: body startingAt: start matchTable: matchTable

I am not familiar with WideString usage, perhaps someone can comment as to whether the the #findSubstringViaPrimitive:in:startingAt:matchTable: is likely to be adopted in Squeak generally. If yes, then we should probably change MiscPrimitivePlugin class>>translatedPrimitives to look for that selector if present in the image. Or perhaps the check for WideString belongs in the primitive itself?

http://bugs.squeak.org/view.php?id=6366 has been solved differently in trunk and Pharo. Changes in Pharo are stamped with an anterior date and might come from another project (Sophie ?).

I think the check for WideString belongs to primitive, and super call belongs to fallback code.

If I understand correctly:

- The fix from Mantis 6366, now in Squeak trunk, resolves the problem - If Pharo adopts the Mantis 6366 fix, then no changes are required for VMMaker

Is that right?

Dave

My only issue is the awkward naming convention. A primitive doing foo should be called primitiveFoo not fooViaPrimitive. So if you want to rename it to primitiveFindSubstring:in:startingAt:matchTable: that'd be fine with me.

Cheers, - Andreas

David T. Lewis wrote:

On Tue, Nov 03, 2009 at 11:46:50AM +0100, arnaud Jean Baptiste wrote:

...

the MiscPrimitivesPlugin loop when generating.

the cause is :

the primitives: #findSubstring:in:startingAt:matchTable: was change to the primitive that name is now: #findSubstringViaPrimitive:in:startingAt: matchTable:

i can simply change the name in #translatedPrimitives (MiscPrimitivePlugin ) method but i am looking for long term solution.

Good question.

Pharo is doing this in ByteString:

findSubstring: key in: body startingAt: start matchTable: matchTable key isWideString ifTrue: [^super findSubstring: key in: body startingAt: start matchTable: matchTable]. ^self findSubstringViaPrimitive: key in: body startingAt: start matchTable: matchTable

I am not familiar with WideString usage, perhaps someone can comment as to whether the the #findSubstringViaPrimitive:in:startingAt:matchTable: is likely to be adopted in Squeak generally. If yes, then we should probably change MiscPrimitivePlugin class>>translatedPrimitives to look for that selector if present in the image. Or perhaps the check for WideString belongs in the primitive itself?

Dave