Smalltalk › Squeak › Squeak - Dev

CharacterScanner and stopConditions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Nicolas Cellier

CharacterScanner and stopConditions

A few years ago, I have wrapped the stopConditions Array into a more complex TextStopCondition object.

This was because #endOfRun and #crossedX did occupy position of valid unicode charCode (A macron...).

But adding an intermediate object in inner loop costs (until some more aggressive inlining occur in the VM, and until COG is avaliable on ARM).

It also is one more hurdle for having primitive 103 working (or an equivalent).

The question is will we ever use anything else than #endOfRun and #crossedX for endOfRun and crossedX stop conditions?
If no, we shall better replace ^stopConditions endOfRun with more simple ^#endOfRun, same for ^#corssedX.
If we do so, the last message sent to stopConditions will be at: and at:put:, so we can just restore a stopConditions Array (as easy as changing the CharacterScanner class>>initialize).

Thoughts?

Nicolas Cellier

Re: CharacterScanner and stopConditions

I propose to commit, and tim tries the performances on the Pi.

If ever someone yells, we'll roll back.

2013/10/10 Nicolas Cellier <[hidden email]>

A few years ago, I have wrapped the stopConditions Array into a more complex TextStopCondition object.

This was because #endOfRun and #crossedX did occupy position of valid unicode charCode (A macron...).

But adding an intermediate object in inner loop costs (until some more aggressive inlining occur in the VM, and until COG is avaliable on ARM).
It also is one more hurdle for having primitive 103 working (or an equivalent).

The question is will we ever use anything else than #endOfRun and #crossedX for endOfRun and crossedX stop conditions?
If no, we shall better replace ^stopConditions endOfRun with more simple ^#endOfRun, same for ^#corssedX.
If we do so, the last message sent to stopConditions will be at: and at:put:, so we can just restore a stopConditions Array (as easy as changing the CharacterScanner class>>initialize).

Thoughts?

David T. Lewis

Re: CharacterScanner and stopConditions

On Thu, Oct 10, 2013 at 02:23:00AM +0200, Nicolas Cellier wrote:
> I propose to commit, and tim tries the performances on the Pi.
> If ever someone yells, we'll roll back.

You guys make a great team :-)

Dave

Nicolas Cellier

Re: CharacterScanner and stopConditions

There is however something lacking for making primitive 103 or cousin work.

A primitive has no idea of how to reach #endOfRun and #crossedX symbols, so answering hardcoded symbols is of no help, they must be registered somewhere...

A possibility would be to answer the index. For example, we could encode a:

    stopHelper := (1 to: stopConditions size)
        collect: [:i | (stopConditions at: i) ifNil: [i-1] ifNotNil: [i\\256]]
        as:ByteArray.

Then test in the inner scan loop:
(stopHelper at: i + 1) = i ifFalse: [^i + 1]

and in the outer loop:

[stopIndex := self scanWithHelper: stopHelper.

self perform: (stopConditions at: stopIndex)] whileFalse.

That would mean restoring some kind of TextStopConditions managing both the 258 stopConditions and the stopHelper... A bit too much to my taste. I think it's too late for my brain ;)

2013/10/10 David T. Lewis <[hidden email]>

On Thu, Oct 10, 2013 at 02:23:00AM +0200, Nicolas Cellier wrote:
> I propose to commit, and tim tries the performances on the Pi.
> If ever someone yells, we'll roll back.

You guys make a great team :-)

Dave