On Wed, Jul 9, 2008 at 1:40 PM, Duane Ellis <[EMAIL PROTECTED]> wrote: > Øyvind Harboe wrote: >> >> I want something that does not really require parsing at all. No parsing >> is better than *any* parsing, no matter how simple. >> > > So you want every command to adapt its output in a unique way that is unique > to the host side language being used?
Nope. If they are happy with a particular representation they can use that one even if it was originally written for something else. The point is that the representation of the output is really defined by the application and not OpenOCD. > So if I use PERL on the host side - openocd should generate responses in > "Data::Dumper" format.. Because - Perl should be able to read a > "data:dumper" output? OpenOCD does not generate anything. Instead of *parsing* a fixed format, you can *generate* that output for Perl. Generating is easier than parsing. > And if I use Python - OpenOCD should generate information in "Python Pretty > Print" format? (or what eve format Python uses). Generating is *much* easier than parsing. > > And another format for a C HOST program. Again, generating is easier than parsing. > And another format for a Visual Basic format. Again, generating is easier than parsing. > And another format for TclTK on the host. Actually Tcl wouldn't need a conversion as the OpenOCD API is native to Tcl. :-) > I believe that over complicates things in OpenOCD. Actually it *greatly* simplifies thinsg in OpenOCD and it *does* give you the defined format you are after. See flash_banks example that I've commited. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
