Interesting - there is no #skipToAll: in pharo, I wonder why not? It sounds like what I was looking for - and I���m surprised its not there. There is #skipTo:  for an object (which sounds right, just not the string equivalent).

I���m not doing anything special, just want to take some lines from the end of a class comment and use them in an exercism exercise - but its not different than many applications - find some tag and use the text after it. I���m kind of surprised its not in Pharo.

Tim


On 1 Jun 2019, at 12:25, Richard O'Keefe <raoknz@gmail.com> wrote:

If you want to move around in strings, you might want to use a ReadStream.
In some Smalltalk systems there is a method called #skipToAll:.
Here's how mine starts out:

    skipToAll: aSequence
      "If the remaining elements can be parsed as <a><aSequence><b>,
       return true leaving the position where?  Otherwise return false.      
       GNU Smalltalk, Dolphin, and VisualAge:
         leave the position after <aSequence>, consistent with #upToAll:,
         and implementable in this class.  (GST uses the KMP algorithm.)
       VisualWorks and ST/X:
         leave the position before <aSequence>, inconsistent with #upToAll:,
         and only implementable for positionable streams.      
       Squeak 5.2 and Pharo 6.0:
         not provided.
       I cannot be compatible with everything.  The semantics of
       #skipToAll: should obviously match #upToAll:, so I'll fit
       in with GNU, Dolphin, and VisualAge Smalltalk.
      "

So
    (myReadStream skipToAll: 'marker')
      ifTrue:  [loc := myReadStream position]
      ifFalse: [alternative code].

HOWEVER, I have a bad feeling about this.  The entire approach, as with much
concerning strings in a Unicode age, seems fraught with peril.  Consider
input = 'the need for vigilance is never-ending'
marker = 'end'
Should the marker be found or not?
input = '.... Si<floating acute accent> ...'
marker = 'Si'
Should the marker be found or not?
My code is NOT sensitive to these issues.
I would like to say that it was because I was writing a compatibility
method, so my code was compatibly broken,
but to be honest, I was stupid and forgot to think it through.
I would think that there would need to be an '... asTokens: aBoolean'
variant that checks that a match
 - is not followed by floating diacriticals
 - is not preceded by an alphanumeric if the target begins with one
 - is not followed by an alphanumeric if the target ends with one.

My own preference is to write a lexical analyser for the mini-language
I'm using, and NOT try to hack at it using general-purpose string
methods.

Perhaps you can tell us more about the context?  What is the application-
level task you are trying to solve?



On Sat, 1 Jun 2019 at 22:01, Tim Mackinnon <tim@testit.works> wrote:
Maybe this is a dumb question - and often I���m surprised when asking these, but why is there no way to ���find after��� a string.

I find it rather boring to try and parse a string, after a known marker - thus:
(loc := aString findString: ���marker���) > 0 ifTrue: [ loc := loc + ���marker��� size ].

Is there a better way? This whole pattern seems very old and clunky and not smalltalk like?

Couldn���t we have: findAfter: aString ifAbsent: aBlock ?

Or is there a whole better pattern for string searching that I���m missing ?

Tim