Hi Enoch,
> When cleaning up my code to make it uploadable through the minicom > plugin as well I noted that commented #include's are not recognized by > the shell (though promised). Below is a patch that straightens things > up. Many thanks for it. > > Also, I seek confirmation that amforth will not change it's single line > only ( comment ) behavior As I understand the forth standard, a multiline ( ) comment is only available for file content (section 11 of the standard text). Otherwise a "parse area" is used to detect the closing ). If the parsing area is exhausted, a refill is not requested, leaving a somewhat strange state IMHO. A small test with gforth gave me the following mt@ayla:~$ gforth Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit ( foo ok bar ) :2: Undefined word >>>bar<<< ) Backtrace: $7F7DAC7B4A68 throw $7F7DAC7CACE0 no.extensions $7F7DAC7B4D28 interpreter-notfound1 The same "program" from a file works fine mt@ayla:~$ cat test.fs ( foo bar ) mt@ayla:~$ gforth test.fs Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit bye mt@ayla:~$ I'd recommend using ( comments ) on a single line basis only. That seems to be a save bet for all systems. Its not impossible that amforth gets the multiline comments on the commmand prompt, I'd not hold my breath waiting however ;) Matthias ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
