Hi Richard, maybe this one fits.
: parsetest_2 ( "n-chars,n-numbers" -- n c-string u ) cr ." type test string now: " \ UI pad 1+ 40 accept pad c! \ read counted string into pad pad count 44 scan 44 skip evaluate \ evaluate string behind comma pad count 2dup 44 scan nip - \ string before comma ; there are no precautions if the accepted sting no comma or is malformed Regards Martin Am Donnerstag, 17. August 2017, 21:16:00 CEST schrieb Richard Burden: > Hi Martin, > > thank you for your prompt thoughts. It might take me a few days to > digest them since I've put so much time into this vexed subject I need > to catch up on other things. > > I am rapidly losing interest in trying to write my own "recogniser". > Based on my years of playing with F-PC an initial glance through your > thoughts show they are similar to mine. > > - accept a string > - move it to another buffer so it is preserved > - extract the information with new forth words > > I'm going to sleep on it :) > > Kind regards > Richard > > On 8/17/17, Martin <martin.bit...@t-online.de> wrote: > > Am Donnerstag, 17. August 2017, 11:56:25 CEST schrieben Sie: > >> Hi Richard! > >> > >> (I'm with gforth, but the behavior is the same. So maybe it helps you.) > >> > >> accept to tib destroys the former contents of tib without correcting >in > >> and > >> #tib. > >> > >> This one works for me: > >> : parsetest > >> > >> ." type test string now: " > >> > >> tib 40 accept > >> #tib ! \ set new end of tib > >> 0 >in ! \ restore start of tib > >> [char] , parse ; \ parse tib > >> > >> test: > >> > >> parsetest type test string now: $abcdefghi,654321 ok > >> > >> > >> So now .s shows (in gforth case) > >> > >> .s > >> 34236064 10 654321 ok > >> > >> That is correct but > >> > >> . type > >> > >> gives: > >> 654321 . typefghi ok > >> > >> because the tib is overwritten with the string ". type" > >> > >> So you have to save the parsed contents to an other buffer or have to > >> typed > >> it immediatly. > >> > >> (I hope there is a buffer called pad in amforth too) > >> > >> : parsetest > >> > >> ." type test string now: " > >> > >> tib 40 accept > >> #tib ! \ set new end of tib > >> 0 >in ! \ restore start of tib > >> [char] , parse \ parse tib > >> pad place ; \ save parsed content to pad > >> > >> test: > >> > >> parsetest type test string now: $abcdefghi,654321 ok > >> > >> . 654321 ok > >> pad count type > >> $abcdefghi ok > >> > >> An other disadvantage of replacing tib content ba accept is the loss of > >> the > >> end of tib. Par example: > >> parsetest . pad count type > >> will only give > >> parsetest . pad count type type test string now: $abcdefghi,654321 ok > >> with the number 654321 on stack and the string $abcdefghi in pad > >> the " . pad count type" in the former tib is lost and will never be > >> interpreted. > >> > >> A solution could be > >> > >> save >in and #tib > >> set accept to the end of tib > >> run accept > >> adapt >in #tib > >> parse and save > >> restore >in and #tib > >> > >> But what about using a second buffer and the words scan skip? > >> > >> kind regards > >> > >> Martin > >> > >> Am Mittwoch, 16. August 2017, 14:45:25 CEST schrieb Richard Burden: > >> > Hi all, > >> > > >> > I'm still stuck trying to get my recogniser to work on NMEA strings. > >> > Part of my challenge in understanding this appears to be the word > >> > parse. > >> > > >> > Consider this which works as expected: > >> > : ., [CHAR] , PARSE 2dup TYPE ; > >> > > >> > ok > >> > > >> > > ., $abcdefg,12345 .s > >> > > >> > $abcdefg3 12345 8 303 ok > >> > > >> > Which indicates the word ., correctly parsed for the comma and the > >> > remainder of the tib (which starts at address 300) was recognised as > >> > the number 12345 > >> > > >> > > ., $abcdefg,a12345 .s > >> > > >> > $abcdefg ?? -13 18 > >> > > >> > Again shows ., worked as expected and the rest of the tib, or "a12345" > >> > > >> > could not be interpreted > >> > > >> > My lack of understanding arises now if I try the following word: > >> > : parsetest > >> > > >> > ." type test string now: " > >> > tib dup 40 accept > >> > [char] , parse \ returns addr len of string delimited by , > >> > > >> > \ type > >> > > >> > ; > >> > > >> > parsetest > >> > type test string now: $abcdefg,12345 > >> > > >> > ok > >> > > >> > > .s > >> > > >> > 4 65535 310 14 300 ok > >> > > >> > > >> > I can see the tib address on the stack (300 ) and 14 characters were > >> > accepted. But PARSE no longer works. > >> > > >> > From other tests it appears parse is operating on the tib when it > >> > contained "parsetest" and not after the input string was accepted. > >> > > >> > Can anyone please confirm if I am correctly accepting the string or > >> > using PARSE incorrectly? > >> > > >> > Kind regards > >> > Richard > >> > > >> > ----------------------------------------------------------------------- > >> > --- > >> > -- -- Check out the vibrant tech community on one of the world's most > >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> > _______________________________________________ > >> > Amforth-devel mailing list for http://amforth.sf.net/ > >> > Amforth-devel@lists.sourceforge.net > >> > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > -- > > Getippt im 9,5 Fingersystem von mir persönlich > > > > > > -------------------------------------------------------------------------- > > ---- Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amforth-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > ---------------------------------------------------------------------------- > -- Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel -- Getippt im 9,5 Fingersystem von mir persönlich ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
