Øyvind Harboe wrote:
>>If one element is added - in the wrong place - or - something is moved -
>>BOOM - nothing works. A classic "off-by-one" bug.
>
>
> When we decide that flash_banks is an official API, it's output can
> *NEVER* change.
>
> If you want a different output, you have to define a
> *But* I don't think an openocd *user* should need to know TCL in order to
> use openocd.
The goal is to let the user be blissfully ignorant of tcl.
Configuration of almost all targets should be possible with simple commands.
> In other words, the syntax of configuring
> openocd should not requ
> If one element is added - in the wrong place - or - something is moved -
> BOOM - nothing works. A classic "off-by-one" bug.
When we decide that flash_banks is an official API, it's output can
*NEVER* change.
If you want a different output, you have to define a new command(or
arguments to the o
duane> should we generate a different output for each of these languages?
Øyvind> I have explained this badly because you completely misunderstand me.
No, I understood you completely.
Sorry for my long reply - but I feel it is the only way to explain this
- for I think the 5th time - (not to
Duane Ellis wrote:
> ville> So, even a single example where something stupidly simple data
> ville> is fetched would help to get started with port and external
> ville> scripting. The example may very well be written in TCL (which
> ville> seems to give a very simple socket interface) or Ruby,
On Fri, Jul 11, 2008 at 1:23 PM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> ville> So, even a single example where something stupidly simple data
> ville> is fetched would help to get started with port and external
> ville> scripting. The example may very well be written in TCL (which
> ville> s
ville> So, even a single example where something stupidly simple data
ville> is fetched would help to get started with port and external
ville> scripting. The example may very well be written in TCL (which
ville> seems to give a very simple socket interface) or Ruby, or
ville> Python, or lua,
On Fri, Jul 11, 2008 at 10:43 AM, Ville Voipio
<[EMAIL PROTECTED]> wrote:
>
>> It is a frustrating job writing documentation against
>> what is currently a moving target. The problem is that documentation
>> might not get written afterwards of course! Let's try to avoid that.
>
> I agree. And we d
On Fri, Jul 11, 2008 at 10:46 AM, Ville Voipio
<[EMAIL PROTECTED]> wrote:
>> Comments?
>>
>> Objections?
>>
>>
>> - No syntax change
>> - .cfg files are now Jim Tcl.
>
> Just a stupid question: Do we want to keep them having the extension ".cfg"
> or should we move to ".tcl"? There are pros and con
On Fri, Jul 11, 2008 at 10:59 AM, Spen <[EMAIL PROTECTED]> wrote:
>> - No syntax change
>> - .cfg files are now Jim Tcl.
>> - Add Tcl if you want to .cfg files
>> - If a command fails, it throws a Tcl exception, printing
>> filename & line number
>>
>>
>
> Looks ok to me.
Committed.
> just a quic
> - No syntax change
> - .cfg files are now Jim Tcl.
> - Add Tcl if you want to .cfg files
> - If a command fails, it throws a Tcl exception, printing
> filename & line number
>
>
Looks ok to me.
just a quick test and i noticed that when using exit from a telnet session
we get:
Runtime error,
> Comments?
>
> Objections?
>
>
> - No syntax change
> - .cfg files are now Jim Tcl.
Just a stupid question: Do we want to keep them having the extension
".cfg" or should we move to ".tcl"? There are pros and cons for both
approaches. The main benefit would be to emphasize that they are indee
> It is a frustrating job writing documentation against
> what is currently a moving target. The problem is that documentation
> might not get written afterwards of course! Let's try to avoid that.
I agree. And we do not need any "beginners' guide" at this point.
However, I do not think I am th
On Fri, Jul 11, 2008 at 10:05 AM, Ville Voipio
<[EMAIL PROTECTED]> wrote:
>> My preference is to throw a Tcl exception by default upon
>> a failed OpenOCD command.
>
> I second this one. All bad commands in a configuration file have to produce
> some error message with some indication of their posi
> My preference is to throw a Tcl exception by default upon
> a failed OpenOCD command.
I second this one. All bad commands in a configuration file have to
produce some error message with some indication of their position in the
file.
Also, if we have decided to move into JIM/Tcl (which I think
Patch attached.
Comments?
Objections?
- No syntax change
- .cfg files are now Jim Tcl.
- Add Tcl if you want to .cfg files
- If a command fails, it throws a Tcl exception, printing filename & line number
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger
I'm considering changing .cfg files to tcl.
This *DOES NOT* involve any syntax changes!
This *DOES NOT* involve any behavioural changes *if we do not want to*.
The main issue is with exceptions/errors:
- If a tcl exception occurs, tcl will terminate w/an error message.
Bonus: file name & line n
17 matches
Mail list logo
