{-- Tue, 03 Jul 2012 20:02:55 +0200: Matthias <mtr...@web.de> wrote: --}
Matthias> Editing the source files builds a rather high barrier for
Matthias> your excellent tool. For me your ideas sound like
Matthias> introducing concepts like Design By Contract
Matthias> (http://en.wikipedia.org/wiki/Design_by_contract). Something
Matthias> the Forthers do not (yet?) think about.
Actually, my motivation was a lot simpler. I wasn't sure if the regular
expression I use to match an error being indicated by the amforth
interpreter really covered all cases. That expression (without the
delimiting double quotes included below) is:
" \?\? -\d+ \d+ \r\n> $"
Is it correct? I spent some time looking at the main interpreter trying
to verify it but I don't read assembly and forth fluently enough yet to
be sure without investing more time than I had available.
If the above regular expression will catch all errors explicitly
indicated by the interpreter, then I think it would be reasonable to
change the default behavior to *not* generate an error on output as it
*will still generate an error* if the error regular expression matches.
This won't cause an upload of a tester.frt based test file to fail on
the first test that has an error which I really want for the class in
which we're using this, but I can easily get that behavior by adding the
comment at the top of the file for those cases.
Matthias> I collect the changes in the repository at
Matthias>
http://amforth.svn.sourceforge.net/viewvc/amforth/trunk/tools/amforth-term.py?view=log
Wonderful. I don't really see any need for this to live outside the
amforth repository, so if I get a chance to make further improvements
I'll prepare patches against the code there.
--- Keith
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
