{-- Sat, 30 Jun 2012 15:54:09 +0200: Matthias <mtr...@web.de> wrote: --}
>> Could you reply with an example showing the exact command line
>> options you are giving and the output you get when it does not
>> work.
Matthias> <keith:... output omitted ...>
Matthias> With the --no-error-on-output option everything works well.
Ah, I think this is working as I intended but the behavior may be
somewhat surprising to others, I'm not sure. I made the assumption that
well behaved upload files never generate output because in my use cases
for the class I was helping develop they consisted of one of two types
of files:
1) definitions of words
2) tests written using the tester.frt package from the library
In both these cases, output generally indicated a problem and I wanted
to flag problems as quickly as possible so the kids didn't get confused
about the source of the error. The current version of the script
supports a couple of different ways to handle this situation. The
--no-error-on-output command line option is one. That is my least
preferred option, which is part of why I gave it such a long option
name.
My preferred methods would be to modify the file with comments that
direct the script to treat specific lines generating output more
appropriately. I'm going to show some solutions based on your test file
but I don't have access to my microcontroller to test these right now so
they may not be completely correct.
The brute force solution is to ignore all output for the entire file and
all the files it includes through #include directives. This would be
done by making the following change to the file:
\ this is a test
\ #error-on-output no
ver 1000 ms cr
1000 ms
ver cr ver
1000 ms
words
1000 ms
1 2 + .
1000 ms
This would be the solution to use if you have an existing file or set of
files that you know generate a lot of output.
There are two more refined approaches, using the "#expect-output-next"
directive. The first is to use this directive without any arguments
before a line that will generate output. This will allow any output
from that line. In your test file:
\ this is a test
\ #expect-output-next
ver 1000 ms cr
1000 ms
\ #expect-output-next
ver cr ver
1000 ms
\ #expect-output-next
words
1000 ms
\ #expect-output-next
1 2 + .
1000 ms
You can also match the output more exactly by specifying a regular
expression to the "#expect-output-next" directive which will cause an
error if the output does not match that regular expression. The regular
expression syntax is that expected by the python "re" module. This can
be useful for writing host-based test cases for words that generate
serial output. In your test file:
\ this is a test
\ #expect-output-next amforth 4.9 ATmega1280
ver 1000 ms cr
1000 ms
\ #expect-output-next amforth 4.9 ATmega1280
ver cr ver
1000 ms
\ #expect-output-next
words
1000 ms
\ #expect-output-next 3
1 2 + .
1000 ms
Notice for example that this would verify that "1 2 + ." resulted in 3
being printed. It should pass. If you change the "#expect-output-next
3" comment to "#expect-output-next 4" it should cause an error.
I didn't try to write the regular expression to correctly match the
output of "words" since that may vary and because it would be huge. ;-)
Note that the implementation that captures regular expression that is
used to check the output in #expect-output-next may have a few quirks
due to the way that whitespace is stripped/compressed, etc. It's been
working for me but I haven't tried to explore the ugly corner cases.
Matthias> Yeah, I tried it myself and it's really easy. It now talks
Matthias> with the controller and tries to detect its name to load the
Matthias> device.py file from the core/devices/<controller> directory.
Matthias> This gives me the huge number of register names and other
Matthias> specific constants without filling up the dictionary on the
Matthias> controller.
Neat! I didn't have a chance to look at the implementation closely, but
from a brief glance it looks great and like it would be very useful.
Matthias> My next topic on the wishlist is the inclusion of the
Matthias> environment variable AMFORTH_LIB for a list of directories
Matthias> in which the tool looks for a given file.
That would be really handy as well. I unfortunately don't have time to
work on it right now but if you don't get to it before I get time I'll
take a crack at it when I do.
--- 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
