On Fri, Dec 4, 2009 at 10:31 AM, Zach Welch <z...@superlucidity.net> wrote: > On Fri, 2009-12-04 at 07:48 +0100, Øyvind Harboe wrote: >> On Fri, Dec 4, 2009 at 3:04 AM, Zachary T Welch <z...@superlucidity.net> >> wrote: >> > Commands that do not need to use Jim should be registered as >> > high-level command handlers. >> >> Why is that? >> >> Nb! "ls" *does* need to use jim to return a list of directory >> names used by other jim commands. > > Did you read my summary message? Quoting this thread's first message: > """ > If the command layer provides some wrappers for Jim's return > handling mechanisms, then all handlers can be converted to use the > high-level command mechanisms -- and Jim can be isolated therein. > It's simple refactoring, but are there objections to doing this? > """ > > We need command_return_list() and similar helpers, whereby the low-level > language primitives are hidden away in the command layer. Once this is > done, then we can add support for new languages, and upgrading Jim > itself is no longer intractable as it is today.
Gotit. I see the design improvement. Note that I'll have *major* problems with switching away from jim tcl when we have a large library of *tested* target config scripts. There would have to be some huge advantage or some robust way of getting retesting done. Although this is an improvement in the OpenOCD design, I think splitting OpenOCD across multiple scripting languages and implementations of each of those languages would be detrimental to OpenOCD. Your improved design can facilitate such a disaster so we should handle this carefully. (This is not counting the headaches of renewed discussions about which language to choose.... Duane wrote up in docs some of the reasons why we're using jim tcl.) -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
