1. request for 2.5
RobC, can we get a local way in functions/procedures, to turn on/off tracing,
regardless of if it is with or without in the main?
Kat
2. Re: request for 2.5
Kat wrote:
> RobC, can we get a local way in functions/procedures, to turn on/off tracing,
> regardless of if it is with or without in the main?
You already have two levels of control over tracing:
with trace -- generates slower IL code that supports tracing
procedure myproc()
...
if something_funny_just_happened then
trace(1) -- or trace(3)
end if
...
...
trace(0)
...
end procedure
without trace
Why would you want even finer control?.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: request for 2.5
On 14 Oct 2004, at 8:15, Robert Craig wrote:
>
>
> posted by: Robert Craig <rds at RapidEuphoria.com>
>
> Kat wrote:
> > RobC, can we get a local way in functions/procedures, to turn on/off
> > tracing,
> > regardless of if it is with or without in the main?
>
> You already have two levels of control over tracing:
>
> }}}
<eucode>
> with trace -- generates slower IL code that supports tracing
> procedure myproc()
> ...
> if something_funny_just_happened then
> trace(1) -- or trace(3)
> end if
> ...
> ...
> trace(0)
> ...
> end procedure
> without trace
> </eucode>
{{{
>
> Why would you want even finer control?.
I realise the futility of arguing. I'll just wrap each procedure with such
constructs.
Kat
4. Re: request for 2.5
On Thu, 14 Oct 2004 08:15:11 -0700, Robert Craig
<guest at RapidEuphoria.com> wrote:
>Why would you want even finer control?.
1) There are *many* times when I study five or six lines in earnest,
then hit return/downarrow a dozen or more times to get round to the
next iteration. Disabling trace on the bottom half of a loop would
often be very useful.
2) I want to see _how_ a routine is called, not what it does. eg:
function getSet(object Type)
trace(1)
<some line that the debugger will pause on>
without trace
<rest of routine>
end function
It is quite common that the bug is not in the routine, but how it is
called, or how the (valid) results are being handled.
What would be nice is F9 to run to the end of the current routine.
2) I've entered a routine I'm not interested in, eg
Update(All,getSet(Type))
Now, I want to see what happens in Update, but I don't want to run
through what getSet() is doing. Maybe I could without trace around the
getSet routine, maybe sometime later I will want to trace through it.
Maybe I've already spent five minutes in the debugger.
One thing that would be nice is F10 to simply switch off all tracing
of the current routine, for this session. To make that permanent, then
obviously I put without trace/with trace around that routine, before I
next run the program. If it is easier for F10 to switch off just the
current line, that would be good too. Maybe a small undo buffer, but
otherwise once it is switched off, that's it this session.
I'm sure you understand that trace(1) at the start of Update() might
trigger thousands of times before the point of interest, and indeed
that some of the variables I want to test might be out of scope.
Regards,
Pete
PS Feel free to replace F9/F10 with any keystroke of your choice.
5. Re: request for 2.5
Pete Lomax wrote:
>
> On Thu, 14 Oct 2004 08:15:11 -0700, Robert Craig
> <guest at RapidEuphoria.com> wrote:
>
> >Why would you want even finer control?.
> 1) There are *many* times when I study five or six lines in earnest,
> then hit return/downarrow a dozen or more times to get round to the
> next iteration. Disabling trace on the bottom half of a loop would
> often be very useful.
>
> 2) I want to see _how_ a routine is called, not what it does. eg:
>
> function getSet(object Type)
>
> trace(1)
> <some line that the debugger will pause on>
> without trace
> <rest of routine>
> end function
>
> It is quite common that the bug is not in the routine, but how it is
> called, or how the (valid) results are being handled.
>
> What would be nice is F9 to run to the end of the current routine.
>
> 2) I've entered a routine I'm not interested in, eg
>
> Update(All,getSet(Type))
>
> Now, I want to see what happens in Update, but I don't want to run
> through what getSet() is doing. Maybe I could without trace around the
> getSet routine, maybe sometime later I will want to trace through it.
> Maybe I've already spent five minutes in the debugger.
> One thing that would be nice is F10 to simply switch off all tracing
> of the current routine, for this session. To make that permanent, then
> obviously I put without trace/with trace around that routine, before I
> next run the program. If it is easier for F10 to switch off just the
> current line, that would be good too. Maybe a small undo buffer, but
> otherwise once it is switched off, that's it this session.
> I'm sure you understand that trace(1) at the start of Update() might
> trigger thousands of times before the point of interest, and indeed
> that some of the variables I want to test might be out of scope.
Not trying to get picky, but what you've described would be more like
enhancements to the debugger rather than trace(). The trace() call just
starts the debugger running, it doesn't control what goes on once it
has started.
I agree, and I think so does RDS, that the debugger can do with some
serious improvements. Hopefully once v2.5 is out the door, RDS can
start that process.
But back to trace(). One technique I've used is a type of conditional
trace. This is where I start the debugger only when certain conditions
have been met.
Eg.:
trace( (id = 17) and (length(fldx) > 0 ) )
trace( equal(getenv("DEBUG"), "rtnx") )
--
Derek Parnell
Melbourne, Australia
6. Re: request for 2.5
On Thu, 14 Oct 2004 17:56:26 -0700, Derek Parnell
<guest at rapideuphoria.com> wrote:
> But back to trace(). One technique I've used is a type of conditional
> trace. This is where I start the debugger only when certain conditions
> have been met.
>
> Eg.:
> trace( (id = 17) and (length(fldx) > 0 ) )
> trace( equal(getenv("DEBUG"), "rtnx") )
That's brilliant!
Rob, document it!
--
MrTrick
7. Re: request for 2.5
Patrick Barnes wrote:
>
> Derek Parnell wrote:
> > But back to trace(). One technique I've used is a type of conditional
> > trace. This is where I start the debugger only when certain conditions
> > have been met.
> >
> > Eg.:
> > trace( (id = 17) and (length(fldx) > 0 ) )
> > trace( equal(getenv("DEBUG"), "rtnx") )
>
> That's brilliant!
>
> Rob, document it!
>
> --
> MrTrick
That *is* pretty cool but I've actually found myself throwing '?'s into my
programs when I want to check questionable variables. My program keeps
running while I keep an eye on only the variable I'm interested in.
Of course, this works best with Windows GUI programming when the console is
typically hidden/unused.
-- Brian
8. Re: request for 2.5
On Thu, 14 Oct 2004 17:56:26 -0700, Derek Parnell
<guest at RapidEuphoria.com> wrote:
>Not trying to get picky, but what you've described would be more like
>enhancements to the debugger rather than trace().
True.
>The trace() call just starts the debugger running, it doesn't control
>what goes on once it has started.
Hopefully being picky in an innoffensive way, actually, it does:
with trace
integer i
trace(1)
i=1
trace(0)
i=2
trace(1)
i=3
The trace window jumps from line 5 (trace(0)) to line 8 (i=3).
I have to admit that I cannot remember ever coding trace(0), but it
would probably cure a lot of the problems I experience, thanks.
I also have an idea which I'll post separately.
>
>I agree, and I think so does RDS, that the debugger can do with some
>serious improvements. Hopefully once v2.5 is out the door, RDS can
>start that process.
>
>But back to trace(). One technique I've used is a type of conditional
>trace. This is where I start the debugger only when certain conditions
>have been met.
>
>Eg.:
> trace( (id = 17) and (length(fldx) > 0 ) )
> trace( equal(getenv("DEBUG"), "rtnx") )
Just a small note of caution: be careful that the expression always
evaluates to 1 or 0. For example:
if index then -- ie index is not zero
trace(1)
else
trace(0)
end if
is not the same as trace(index), use trace(index!=0) instead.
Regards,
Pete
