Smalltalk › Squeak › Squeak VM

VMMaker : Inlining loop with MiscPrimitivesPlugin on Pharo

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Jean Baptiste Arnaud

VMMaker : Inlining loop with MiscPrimitivesPlugin on Pharo

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.

David T. Lewis

Re: VMMaker : Inlining loop with MiscPrimitivesPlugin on Pharo

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

Nicolas Cellier

Re: VMMaker : Inlining loop with MiscPrimitivesPlugin on Pharo

2009/11/3 David T. Lewis <[hidden email]>:

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

Andreas.Raab

Re: VMMaker : Inlining loop with MiscPrimitivesPlugin on Pharo

In reply to this post by David T. Lewis

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

johnmci

Re: VMMaker : Inlining loop with MiscPrimitivesPlugin on Pharo

In reply to this post by Nicolas Cellier

The original bug, if you follow the chain of mantis entries, bugs,
related bugs was discovered in Sophie.
http://bugs.squeak.org/view.php?id=5331

So it's possible I moved a flavour of the fix into Pharo a year back
when it was "re-discovered" as
part of moving some other features into Pharo.

On 2009-11-03, at 5:06 AM, Nicolas Cellier wrote:

> 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 ?).

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================

David T. Lewis

Re: VMMaker : Inlining loop with MiscPrimitivesPlugin on Pharo

In reply to this post by Nicolas Cellier

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

>
> 2009/11/3 David T. Lewis <[hidden email]>:
> >
> > 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

Jean Baptiste Arnaud

Re: VMMaker : Inlining loop with MiscPrimitivesPlugin on Pharo

it's seems not.

i integrate the fix seems that loop.

On Nov 6, 2009, at 4:47 AM, David T. Lewis wrote:

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