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
