Re: retrieving line number in case of error - "simple debugger"
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.tcl archive

Re: retrieving line number in case of error - "simple debugger"

From: Nicolas Castagne <castagne@imag.fr>
Date: Thu Sep 29 2005 - 18:04:31 CEST

Thanks for answer.

The example will be copied in Source Forge tomorrow.

Well, I conclude that as I thought, things are not that easy.

Let me open the topic, then.

Tcl is widely used to let end-users write scripts that impact a big
C/C++ application.
I myself currently develop a sort of modeler for physical models, that
will involve both a GUI and a Tcl-based end-user language.

The Tcl-based language will let the user decribe the model, by calling C
routine that will build the model in memory (hope it is clear enough).
The scripts will be written within a text canvas holded by the GUI, and
interpreted through a TclInterp ran by the GUI.

I really think that such a use of Tcl is not rare at all.

The general problem is then :
Given the fact that the end-user is not a technician, one need to offer
him basic and 'usable' debug facilities.

Now, the general question :
- what are the 'debug' facilities developpers usually offer to their
non-technician end-users ?
- how are they built ?

I am quite sure that a large, large knowledge and knowhow is available
on that question. But i can't find it (in the wiki, the archives, the
tips, etc.)

All the best !
Nicolas

Don Porter wrote:
> Nicolas Castagne wrote:
>
>>My two question are :
>>1/ Given a script, how can I retrieve the exact line on which the error
>>occured ?
>>2/ Do you know a nice HOWTO or code sample for building basic debug
>>features ?
>
> I started to answer, then discovered the details later in your
> article that you know all the answers I was about to give.
>
> Please copy that example into the Tcl Feature Request Tracker
> where I can more carefully look into it over time. The details
> involve enough time and effort that articles here will expire.
>
> I suspect this is a limitation of the bytecode compiler, but
> possibly something we can improve.
>
Received on Sat Oct 15 03:53:39 2005