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
