1. new feature request: determining what the trace level is

Hi,
To easily restrict tracing to the bits of code I am interested in, (mine :)) a new function "trace_level" would be useful.
This would return the current value of trace. To be used as per this example:

global function bug_free_library_function(integer i1) 
      integer i2 
      i2 = trace_level() 
      -- function code here 
      i1 = 0 
      -- now restore the previous trace level, just before return 
      trace(i2) 
      return "success!" 
end function         
 
procedure my_buggy_proc() 
      sequence s1 
      integer i1 
      trace(1) 
      -- my buggy code here.. 
      i1 = 0 
      -- then a standard library call where I don't need trace on... 
      s1 = bug_free_library_function(i1) 
      -- the rest of my buggy code here 
end procedure 
 


Also, it would be nice to optionally suppress the display of trusted call variables and thier values from ex.err.
Comments ?

Regards, Alan

new topic     » topic index » view message » categorize

2. Re: new feature request: determining what the trace level is

alanjohnoxley said...

Hi,
To easily restrict tracing to the bits of code I am interested in, (mine :)) a new function "trace_level" would be useful.

This would return the current value of trace. To be used as per this example:

global function bug_free_library_function(integer i1) 
      integer i2 
      i2 = trace_level() 
      -- function code here 
      i1 = 0 
      -- now restore the previous trace level, just before return 
      trace(i2) 
      return "success!" 
end function         
 
procedure my_buggy_proc() 
      sequence s1 
      integer i1 
      trace(1) 
      -- my buggy code here.. 
      i1 = 0 
      -- then a standard library call where I don't need trace on... 
      s1 = bug_free_library_function(i1) 
      -- the rest of my buggy code here 
end procedure 
 


Also, it would be nice to optionally suppress the display of trusted call variables and thier values from ex.err.
Comments ?

Regards, Alan

This is not really practical because we are not going to add 'trace_level' to every standard library function just so users can avoid tracing through them.

However, you do know that you can press the down-arrow to avoid tracing through a function call?

The idea you suggest has some merit but I'd like to do it slightly differently. Let's make the trace() call a function instead. It can return the current trace level while setting a new level, and because we no longer have to use a function's return value, current code would not be affected.

global function bug_free_function(integer i1) 
      integer i2 
      i2 = trace(0) -- turn any tracing off 
      -- function code here 
      i1 = 0 
      -- now restore the previous trace level, just before return 
      trace(i2)  
      return "success!" 
end function         
 
procedure my_buggy_proc() 
      sequence s1 
      integer i1 
      trace(1) 
      -- my buggy code here.. 
      i1 = 0 
      -- then a library call where I don't need trace on... 
      s1 = bug_free_function(i1) 
      -- the rest of my buggy code here 
end procedure 
new topic     » goto parent     » topic index » view message » categorize

3. Re: new feature request: determining what the trace level is

"No worries"
Thanks Derek,
I'll use the down arrow - you are correct as usual, I was not aware of that :)
Although I have been using Euphoria since v1.4, months can go by without me coding.
Your solution to trace seems fine. For myself, I would be prepared to put in the extra couple of lines per library proc/func potentially involved with my bug,
but I consider it bad manners to alter someone else's code. Very likely, you have had someone blaming your code, only to discover the complainer changed it?
So I'll copy the library function, save in c:\euphoria\include\custom and update the comments and eu.cfg accordingly.

But there is still lots of output in ex.err thats not pertinent the vast majority of the time,
which makes it harder to pick my variables out.. Suggestions on this ?

The last auz/sa rugby test was darn close wasn't it!

Regards, Alan

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

4. Re: new feature request: determining what the trace level is

alanjohnoxley said...

Hi,
To easily restrict tracing to the bits of code I am interested in, (mine :)) a new function "trace_level" would be useful.

If you use a "without trace" line, then include your libraries, then add a "with trace" line underneath, like this:

without trace 
include std/search.e 
include other_trusted_library.e 
with trace 
include untrusted_and_buggy_library.e 

then, trace(1) will automatically skip over the routines in the trusted libraries, and only trace through your code.

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

5. Re: new feature request: determining what the trace level is

alanjohnoxley said...

But there is still lots of output in ex.err thats not pertinent the vast majority of the time, which makes it harder to pick my variables out.. Suggestions on this ?

There have been some user contributions focused around converting ex.err files to be more readable. It would be a great utility to have some sort of GUI to use to navigate the stack trace, filter top level variables by file, etc.

If it could be a console app, we might even be able to include it eventually as part of euphoria. Also, it might make sense to have an option to output the full dump of variables (rather than truncating really long stuff) for this purpose.

Maybe if someone could create a basic library that could read the ex.err, etc, then we could get ports to various GUI libraries (win32lib, wxEuphoria, Arwen, EuGTK, etc), plus a console version that could come bundled with Euphoria.

Matt

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

6. Re: new feature request: determining what the trace level is

Matt, let me say that my forehead is marked with "place icecream here". ;)
So I've been suffering all these years? I'll surround the trusted libraries with "without trace" like you say. I thought the "without/with" directives could only be specified once!
Sigh...

Thanks again,
Alan

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

7. Re: new feature request: determining what the trace level is

It should be easy enough to read ex.err and remove lines that belong to blocks starting with " ... called from c:\euphoria\include\"
and then look for "Global & Local Variables" and find similar blocks identified by the path.
Maybe it would be easier to simply only allow specified path(s) belonging to your app?
I'll write this as a console app and submit it... but has this not been done before?

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

8. Re: new feature request: determining what the trace level is

alanjohnoxley said...

But there is still lots of output in ex.err thats not pertinent the vast majority of the time

Right now I'm dreaming of C (which I am forced to use at work) creating any form of ex.err...

Mind you, that would be funky indeed, as even the simplest object has pages of methods, properties, actions, and other crud stuck to it... Still, when a 1.7 million line app says:

"An uncaught exception occurred. Somewhere."

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

Search



Quick Links

User menu

Not signed in.

Misc Menu