Re: [Amforth] New forth interaction script

[pito <pi...@vo...>]

Hi Keith,
I'm trying to run your script under winXP. I had to install
"pyreadline-1.7.1.win32.exe" in order to get imported the readline.
Also I changed the /dev/.. to COM6 (my BT module) and speed to 115k.
Let me ask you following, pls - how to specify an Editor into the
script - ie. my C:\WinAVR\pn\pn.exe (Programmers Notepad)?

|I=Entering amforth interactive interpreter
|I=using device.py for atmega1284p
(ATmega1284P)> 100 100 + .
200  ok
(ATmega1284P)> #edit myfrt
|D=#edit myfrt
Error: No editor specified.  Use --editor or EDITOR environment
variable
(ATmega1284P)>

thnks,
pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Keith Amidon" <ca...@pi...>
Komu: "Matthias Trute" <mt...@we...>
Předmět: Re: [Amforth] New forth interaction script
Datum: 3.7.2012 - 3:18:51

> {-- Sat, 30 Jun 2012 15:54:09 +0200: Matthias
> <mt...@we...> 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/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>