On Fri, 2009-12-04 at 10:39 +0100, Øyvind Harboe wrote:
> 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.
Scripts that lack a test suite, so they are not tested in a quantitative
sense of the word. I do understand what you mean here: there is a
library of more-or-less working stuff, and it would be a nightmare to
try and re-recreate it in even a derivative of the current language.
Gradual migration has proven to be a non-starter, so I am now looking at
clean separation of mechanism and policy (i.e. language) as the only
practical means of improving the status quo for the future. Presently,
the command language will be an order of magnitude more difficult to
upgrade cleanly (without causing regressions). With my solution, the
only regressions should be stupid typos caused by splitting the code,
and the improvements should make it easier to fix the design bugs.
The current language places many unnecessary restrictions, which the
core can support while evolving into something more flexible. A new
language can exploit all of the new features. The old language can
continue to use these increasingly fine-grained mechanisms, but making
the same policy decisions. It can be frozen in time, allowing scripts
to work indefinitely... when those modules are loaded.
So, I am expressly saying, "I do _not_ want to switch away from Jim".
I just want other alternatives to be available.
> There would have to be some huge advantage or some
> robust way of getting retesting done.
Actually... there's a very simple idea: heterogeneous language support.
Call TCL scripts from Ruby, use 'python blah blah blah' from your TCL
scripts, make "$tcl->script($tcl->find('board/at91eb40a.cfg'))" work as
one might intuit under Perl.... No problem. ;)
Re-use, baby! Shebang! ((A remarkably apropos double entendre.))
> 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.
With proper libraries and loadable modules, it can be done out-of-tree
in a completely separate package... openocd-ruby, openocd-perl, et al..
> Your improved design can facilitate such a disaster so we should
> handle this carefully.
Yeah, having lots of front-ends like GCC would be a total disaster.
Apache, LLVM, Eclipse: they'd be much better of without so much choice.
No, wait... the other thing... yeah: the exact opposite of that. ;)
> (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.)
Choice. Freedom of choice. Good design will allow that, even if the
project itself does not. Once modularity has been achieved as I have
proposed, anyone can do this stuff in their own independent projects.
Today, there is no such option, and _that_ is all I want: options. ;)
Verily,
--Z
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
