1. trace()

While in a trace session, when we reach the line in our code that caused an
error the trace screen is closed and the error message is put to the screen

I think this is a floor in trace() and could be addressed easily. Rather
than kill the trace screen, leave it open and display the abort error in
the trace window until the user presses a key. When a key is pushed kill
the program in the usual manner.

This will let the user to get a good look at the trace variables at the
time of a crach before the trace window closes.

new topic     » topic index » view message » categorize

2. Re: trace()

Hayden McKay wrote:
> While in a trace session, when we reach the line in our code that caused an
> error the trace screen is closed and the error message is put to the screen
> 
> I think this is a floor in trace() and could be addressed easily. Rather
> than kill the trace screen, leave it open and display the abort error in
> the trace window until the user presses a key. When a key is pushed kill
> the program in the usual manner.
> 
> This will let the user to get a good look at the trace variables at the
> time of a crach before the trace window closes.

Thanks for the suggestion. I understand what you are asking,
but I don't think it's particularly easy to. I guess you'll have to
remember the names of the variables you are interested in,
and look up their values in ex.err. Remember also that you can
trigger a dump into ex.err at any time by pressing the exclamation
key (!) on the trace screen.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

3. Re: trace()

Hayden McKay wrote:
> 
> While in a trace session, when we reach the line in our code that caused an
> error the trace screen is closed and the error message is put to the screen
> 
> I think this is a floor in trace() and could be addressed easily. Rather
> than kill the trace screen, leave it open and display the abort error in
> the trace window until the user presses a key. When a key is pushed kill
> the program in the usual manner.
> 
> This will let the user to get a good look at the trace variables at the
> time of a crach before the trace window closes.
> 

Hi there Hayden,


What op sys are you using?  Windows, Linux, etc...


Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"

new topic     » goto parent     » topic index » view message » categorize

4. Re: trace()

Robert Craig wrote:
> 
> Hayden McKay wrote:
> > While in a trace session, when we reach the line in our code that caused an
> > error the trace screen is closed and the error message is put to the screen
> > 
> > I think this is a floor in trace() and could be addressed easily. Rather
> > than kill the trace screen, leave it open and display the abort error in
> > the trace window until the user presses a key. When a key is pushed kill
> > the program in the usual manner.
> > 
> > This will let the user to get a good look at the trace variables at the
> > time of a crach before the trace window closes.
> 
> Thanks for the suggestion. I understand what you are asking,
> but I don't think it's particularly easy to do. I guess you'll have to
> remember the names of the variables you are interested in,
> and look up their values in ex.err. Remember also that you can
> trigger a dump into ex.err at any time by pressing the exclamation
> key (!) on the trace screen.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> 

Hi there Rob,


If he's using Windows or DOS and he's interested in trying another debugger,
i guess he can try my 'personal' debugger, which doesnt abort when a
run time error occurs, but rather prints a red error message to screen like:

--code being debugged:
s=repeat(0,255)
for k=1 to 512 do --512 is much higher than 255
  s[k]=2          --would normally abort when k=256 (generates error message)
end for           --after error press right arrow key to step around this line.

--error message for line "s[k]=2" when k=256:
"That line would cause a Euphoria error:
   subscript value 256 is out of bounds,
   assigning to a sequence of length 255
The operation will not be performed."

It then gives the user the chance to try different values for variables
and execute the line over again.  For example, after that error he might
do either:
1.  Change the value of k to continue from another value and then
    possibly hit the 'up' arrow key to re-execute "s[k]=2"
2.  press the right arrow key to step out of the loop without executing "end
for"
3.  load s from a file, where the file has a Euphoria sequence stored in
    normal form: {1,2,3,"abc","etc."} (or has been stored via a command "??"),
    then step out of the loop with the right arrow key.



Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"

new topic     » goto parent     » topic index » view message » categorize

5. Re: trace()

I'm useing WinMe on a PentuimIII 550mhz 256mb ram. I'll have to give Al's
debugger a try. Being able to try a couple of different values would have
been perfect for the loop I was trying to correct.

nb. The status of the loop control variables were not always valid after a
    specific sequence insert. Was getting the attempt to substript an atom
    error wich has now been fixed.

p.s. I'm going to be useing linux mandrake on my new AMD4200x2 system wich
     only needs some RAM and a graphics adaptor to get up and running. I'm
     looking forward to it.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu