Is it possible to GetLastLine() for diagnostical reasons? - page 2

New comment
 
Alexandre Borela #:

The call stack is shown at the left window(the debug tab), its shows the functions that were called up to that point:

Okay thanks. Gotta keep an eye on that. At times I am deep into something so I overlook important side information.
 
Alexandre Borela #:
While your project to enhance debugging is great, they are not the same as the debug info the compiler
adds to the executable. I do something similar but simpler by having a "panic" macro to create a critical
error on my indicators if something goes wrong and the indicator cannot recover.

The function names and symbol tables are removed, stuff that maps memory location to names and allows
the debugger to have a call stack with the correct names. I am guessing they are also doing other optimizations.

I did a test and it made a huge difference on one of my indicators:

Release version:


Debug version:

Yes, I know about SYMBOLS and additional debug data within the code. Inserted by compiler at compile time, I need to check, why my code has given me the impression by insignificant size change. Good to see, the compiler does its job correctly in this concern.

Here is the most recent version of the lib_debug.mqh project, although its just a small helper for me. 

I have added following macro to the lib:

DBG_STOP_ARRAY_OUT_OF_RANGE(array, index)

it will be used as follows:

#define LIB_DEBUG
#include <lib_debug.mqh>

void some_func()
{
        int some_arr[];

        for(int cnt = NULL; (cnt < 100) %% !_StopFlag; cnt++)
        {
                DBG_STOP_ARRAY_OUT_OF_RANGE(some_arr, cnt);
                some_arr[cnt] = cnt;
        }

        return;
}


The macro will be removed if the file is compiled in release mode, so only works in debug mode. To forcefully enable debug mode, define compiler flag before including the lib_debug.mqh header

#define LIB_DEBUG


For call stack trace in logfile, follow this example:

//+------------------------------------------------------------------+
//| IndCalc()                                                        |
//+------------------------------------------------------------------+
/////////////////////////////////////
// Function debug trace code
#ifdef DBG_TRACE_IND_CALC
#undef DBG_TRACE_IND_CALC
#define DBG_TRACE_IND_CALC(x) x
#define DBG_TRACE_IND_CALC_RETURN(x) DBG_MSG_TRACE_RETURN_VAR(x)
#else
#define DBG_TRACE_IND_CALC(x)
#define DBG_TRACE_IND_CALC_RETURN(x) DBG_MSG_NOTRACE_RETURN_VAR(x)
#endif
/////////////////////////////////////
bool IndCalc(const int index, const bool live_mode, const bool analyzer_call)
{
DBG_TRACE_IND_CALC(
    DBG_MSG_TRACE_BEGIN;
    DBG_MSG_VAR(index);
    DBG_MSG_VAR(live_mode);
    DBG_MSG_VAR(analyzer_call);
    );
PERF_COUNTER_BEGIN;

    // Call zone update function
    const bool retval = zone_update(index, live_mode);
    DBG_TRACE_IND_CALC_RETURN(retval);
}

In this example, the call stack tracing is individually configurable per function, this way I can trace certain execution paths throughout the code.

It is important to use the return-macro instead of the normal return expression. - Also, do not use a function call within the brackets, it will be called twice by the macro. - I havenot found any other way to do it jet.

For functions without return value:

//+------------------------------------------------------------------+
//| IndCalc()                                                        |
//+------------------------------------------------------------------+
/////////////////////////////////////
// Function debug trace code
#ifdef DBG_TRACE_IND_CALC
#undef DBG_TRACE_IND_CALC
#define DBG_TRACE_IND_CALC(x) x
#define DBG_TRACE_IND_CALC_RETURN DBG_MSG_TRACE_RETURN
#else
#define DBG_TRACE_IND_CALC(x)
#define DBG_TRACE_IND_CALC_RETURN DBG_MSG_NOTRACE_RETURN
#endif
/////////////////////////////////////
void IndCalc(const int index, const bool live_mode, const bool analyzer_call)
{
DBG_TRACE_IND_CALC(
    DBG_MSG_TRACE_BEGIN;
    DBG_MSG_VAR(index);
    DBG_MSG_VAR(live_mode);
    DBG_MSG_VAR(analyzer_call);
    );
PERF_COUNTER_BEGIN;

    // Call zone update function
    DBG_TRACE_IND_CALC_RETURN;
}
I am currently to "lazy" to update the source in codebase...
Files:
lib_debug.mqh  100 kb
 
Dominik Christian Egert #:

Yes, I know about SYMBOLS and additional debug data within the code. Inserted by compiler at compile time, I need to check, why my code has given me the impression by insignificant size change. Good to see, the compiler does its job correctly in this concern.

Here is the most recent version of the lib_debug.mqh project, although its just a small helper for me. 

I have added following macro to the lib:

DBG_STOP_ARRAY_OUT_OF_RANGE(array, index)

it will be used as follows:


The macro will be removed if the file is compiled in release mode, so only works in debug mode. To forcefully enable debug mode, define compiler flag before including the lib_debug.mqh header

#define LIB_DEBUG


For call stack trace in logfile, follow this example:

In this example, the call stack tracing is individually configurable per function, this way I can trace certain execution paths throughout the code.

It is important to use the return-macro instead of the normal return expression. - Also, do not use a function call within the brackets, it will be called twice by the macro. - I havenot found any other way to do it jet.

For functions without return value:

I am currently to "lazy" to update the source in codebase...
It could be interesting to write a transpiler to insert these macros automatically similar to babel for javascript.
 
Oh, that would be a good idea, because it's a hell of work to keep everything up to date.

Also I wish for doxygen to be included by mql IDE, or some other doc notation system.

I was already thinking of some autoparcer for the doc, but there is no hook support in MetaEditor.

It is simply a very '90s IDE and surely not good for bigger projects.

At least the styler is more enriched by now.
12
New comment