Any Suggestion How To Accomplish A Debug Macro?

Any Suggestion How To Accomplish A Debug Macro?

[Hubert]

I know there is no such thing as C #define's in Ada, but isn't there a 
way to make some sort of debug macro?
In my C++ code I use a lot of statements like

PRINT(DEBUG_CHANNEL, "TEXT" );

to print out debug messages and in release code, these defines aren't 
compiled. Is there any way to achieve something like this in Ada without 
surrounding it with an IF statement and a boolean flag?

Thanks


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: Any Suggestion How To Accomplish A Debug Macro?

[Simon Wright]

Hubert <herrdoktor@fumanchu.com> writes:

> I know there is no such thing as C #define's in Ada, but isn't there a
> way to make some sort of debug macro?
> In my C++ code I use a lot of statements like
>
> PRINT(DEBUG_CHANNEL, "TEXT" );
>
> to print out debug messages and in release code, these defines aren't
> compiled. Is there any way to achieve something like this in Ada
> without surrounding it with an IF statement and a boolean flag?

GNAT has pragma Debug[1]. I was always annoyed that this is controlled
by -gnata, which also controls assertions, but I see there's a pragma
Debug_Policy - stated to be equivalent to pragma Check_Policy (Debug).

[1] https://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Debugging---A-Special-Case.html

Re: Any Suggestion How To Accomplish A Debug Macro?

[Hubert]

Cool, thanks a bunch, that's exactly what I need. You're right, it would 
be better if there was a separate switch, but I take what I can get :)


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: Any Suggestion How To Accomplish A Debug Macro?

[sbelmont700]

On Monday, December 29, 2014 10:11:52 PM UTC-5, Hubert wrote:
>
> Is there any way to achieve something like this in Ada without 
> surrounding it with an IF statement and a boolean flag?
> 

TWYF, FWYT.  Having the compiler cull a bunch of your code, especially such I/O heavy code, and expecting it to work the same in the release is a bad idea (though there are better solutions than an if statement, e.g. observer pattern).

-sb

Re: Any Suggestion How To Accomplish A Debug Macro?

[Simon Wright]

sbelmont700@gmail.com writes:

> TWYF, FWYT.  Having the compiler cull a bunch of your code, especially
> such I/O heavy code, and expecting it to work the same in the release
> is a bad idea (though there are better solutions than an if statement,
> e.g. observer pattern).

We did desktop testing (mainly functional, some timing) on Windows for
deployment on powerpc-wrs-vxworks. On-target validation & verification
was hugely simplified, and I don't recall any instances of on-target
failures that were down to compilation differences.

We retained the same logging in the two environments; on the host, via a
low-priority task to standard output; on the target, via ethernet to a
logging computer. So the Ada code of the subsystem under test wasn't
altered.

Re: Any Suggestion How To Accomplish A Debug Macro?

[Brad Moore]

On 14-12-30 04:14 AM, Simon Wright wrote:
> Hubert <herrdoktor@fumanchu.com> writes:
>
>> I know there is no such thing as C #define's in Ada, but isn't there a
>> way to make some sort of debug macro?
>> In my C++ code I use a lot of statements like
>>
>> PRINT(DEBUG_CHANNEL, "TEXT" );
>>
>> to print out debug messages and in release code, these defines aren't
>> compiled. Is there any way to achieve something like this in Ada
>> without surrounding it with an IF statement and a boolean flag?
>
> GNAT has pragma Debug[1]. I was always annoyed that this is controlled
> by -gnata, which also controls assertions, but I see there's a pragma
> Debug_Policy - stated to be equivalent to pragma Check_Policy (Debug).
>
> [1] https://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Debugging---A-Special-Case.html
>


Another more portable solution would be to declare a static constant 
somewhere, and use the value of that constant to decide if logging 
should occur. If the compiler/linker supports dead code elimination, 
then the debug code can be eliminated if that variable is set to False.

Eg.

package Debug_Logging is
    Debug_Enabled : constant Boolean := False;  -- Edit this line
    procedure Log(Message : String);
end Debug_Logging;


with Debug_Logging;

procedure Foo is
begin
    -- if statement removed if Debug_Enabled is false
    if Debug_Enabled then
      Log("Entered Foo");
    end if;
end Foo;

This works in GNAT, and might work in other compilers as well. Worst 
case is that the Debug_Enabled boolean get evaluated in multiple places, 
but that overhead of evaluating a Boolean might still be acceptable for 
a compiler that doesn't do dead code elimination.

Brad

Re: Any Suggestion How To Accomplish A Debug Macro?

[Randy Brukardt]

"Brad Moore" <brad.moore@shaw.ca> wrote in message 
news:gCDow.832901$No4.618024@fx19.iad...
> On 14-12-30 04:14 AM, Simon Wright wrote:
>> Hubert <herrdoktor@fumanchu.com> writes:
>>
>>> I know there is no such thing as C #define's in Ada, but isn't there a
>>> way to make some sort of debug macro?
>>> In my C++ code I use a lot of statements like
>>>
>>> PRINT(DEBUG_CHANNEL, "TEXT" );
>>>
>>> to print out debug messages and in release code, these defines aren't
>>> compiled. Is there any way to achieve something like this in Ada
>>> without surrounding it with an IF statement and a boolean flag?

That's of course the Ada way. What's the point of avoiding the Ada way here? 
Everything in Ada is more verbose than C -- some of us think that's the 
advantage of Ada (more for readability than writability).


...
> Another more portable solution would be to declare a static constant 
> somewhere, and use the value of that constant to decide if logging should 
> occur.

He said he didn't want to do that.

I usually make these flags more complex (like an array of constants) so that 
various sets of tracing can be enabled in order to track whatever is wrong.

Indeed, in most of my programs, I use a flag set at runtime (controlled 
either through the GUI or through command-line switches. In that case, the 
code is always there (but a Boolean test is cheap), but that means I don't 
have to waste time with a compile-link-test-repeat cycle to trace a problem. 
(I admit, it's often necessary to add additional tracing to actually find 
the root cause, but the initial tracing at least can narrow it down 
quickly.)

...
> This works in GNAT, and might work in other compilers as well. Worst case 
> is that the Debug_Enabled boolean get evaluated in multiple places, but 
> that overhead of evaluating a Boolean might still be acceptable for a 
> compiler that doesn't do dead code elimination.

I think that the set of compilers that don't do dead code elimination is 
close to the empty set. (That was pretty much the first optimization we did 
in Janus/Ada, even before we had packages or floating point.) Whether the 
dead code elimination can get rid of everything (it won't get rid of string 
literals in Janus/Ada, for instance) is a different question.

But I don't think there is much reason (outside of the memory-constrained 
embedded system, or the system that has to be formally proved or validated) 
to ever removing the tracing. It's important to be able to turn it off, of 
course, but the runtime cost of it being off is so minimal (primarily 
caching/paging effects) that removing it isn't worth the effort. (And if you 
plan to keep it around forever, you'll spend more time making the traces 
make sense in the future -- which typically pays off very quickly.)

                                     Randy.

Re: Any Suggestion How To Accomplish A Debug Macro?

[Luke A. Guest]

Brad Moore <brad.moore@shaw.ca> wrote:
> On 14-12-30 04:14 AM, Simon Wright wrote:
>> Hubert <herrdoktor@fumanchu.com> writes:

> This works in GNAT, and might work in other compilers as well. Worst case
> is that the Debug_Enabled boolean get evaluated in multiple places, but
> that overhead of evaluating a Boolean might still be acceptable for a
> compiler that doesn't do dead code elimination.

Not strictly true as the compiler should see the "if var = true then" and
remove the if in dead code elimination leaving the contents of the if
statement. When the if statement is false (statically) the entire statement
can be eliminated.

Re: Any Suggestion How To Accomplish A Debug Macro?

[Georg Bauhaus]

"Randy Brukardt" <randy@rrsoftware.com> wrote:
> "Brad Moore" <brad.moore@shaw.ca> wrote in message 
> news:gCDow.832901$No4.618024@fx19.iad...
>> On 14-12-30 04:14 AM, Simon Wright wrote:
>>> Hubert <herrdoktor@fumanchu.com> writes:
>>> 
>>>> I know there is no such thing as C #define's in Ada, but isn't there a
>>>> way to make some sort of debug macro?
>>>> In my C++ code I use a lot of statements like
>>>> 
>>>> PRINT(DEBUG_CHANNEL, "TEXT" );
>>>> 
>>>> to print out debug messages and in release code, these defines aren't
>>>> compiled. Is there any way to achieve something like this in Ada
>>>> without surrounding it with an IF statement and a boolean flag?
> 
> That's of course the Ada way. What's the point of avoiding the Ada way here? 
> Everything in Ada is more verbose than C -- some of us think that's the 
> advantage of Ada (more for readability than writability).

The Ada way has been built into the Eiffel
programming language: "debug" is a keyword
of Eiffel and it works much like "begin" 
starts a block in Ada. Eiffel's "debug" is
controlled by flag set at compile time, though.

Re: Any Suggestion How To Accomplish A Debug Macro?

[J-P. Rosen]

Le 30/12/2014 23:11, Randy Brukardt a écrit :
> But I don't think there is much reason (outside of the memory-constrained 
> embedded system, or the system that has to be formally proved or validated) 
> to ever removing the tracing. It's important to be able to turn it off, of 
> course, but the runtime cost of it being off is so minimal (primarily 
> caching/paging effects) that removing it isn't worth the effort. (And if you 
> plan to keep it around forever, you'll spend more time making the traces 
> make sense in the future -- which typically pays off very quickly.)

I fully agree with that.
In AdaControl, there is a sophisticated tracing capability, and it's
enabled with a command line option. If a user has a problem, he just has
to rerun the program with -x and send me the output - that's usually
enough to identify the problem. I can't tell how much time it saved me.
And since AdaControl spends about 65% of its time in ASIS, the cost of
testing a boolean is neglectible.
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Any Suggestion How To Accomplish A Debug Macro?

[Dmitry A. Kazakov]

On Fri, 02 Jan 2015 21:37:47 +0100, J-P. Rosen wrote:

> Le 30/12/2014 23:11, Randy Brukardt a écrit :
>> But I don't think there is much reason (outside of the memory-constrained 
>> embedded system, or the system that has to be formally proved or validated) 
>> to ever removing the tracing. It's important to be able to turn it off, of 
>> course, but the runtime cost of it being off is so minimal (primarily 
>> caching/paging effects) that removing it isn't worth the effort. (And if you 
>> plan to keep it around forever, you'll spend more time making the traces 
>> make sense in the future -- which typically pays off very quickly.)
> 
> I fully agree with that.

This is all true, conditional compilation is rubbish, IMO.

However, it would be interesting to consider how tracing could be better
supported. I mean options:

1. To have zero-cost turned off tracing, e.g. some code modification
techniques or maybe something else. After all we have zero-cost exceptions,
why not tracing.

2. Ideas for the compilation units structure modification which would allow
to have tracing code physically separated from the functional code.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any Suggestion How To Accomplish A Debug Macro?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:fh7u81n706kr.131btl9yj1iz8.dlg@40tude.net...
> On Fri, 02 Jan 2015 21:37:47 +0100, J-P. Rosen wrote:
...
> However, it would be interesting to consider how tracing could be better
> supported. I mean options:
>
> 1. To have zero-cost turned off tracing, e.g. some code modification
> techniques or maybe something else. After all we have zero-cost 
> exceptions,
> why not tracing.

But "zero-cost exceptions" aren't really zero-cost, they just shift the cost 
to handling. And that's already the case; virtually all of the cost of 
tracing is when the tracing is enabled. (A Boolean compare being about the 
cheapest operation on most targets.) About all one could do would be to keep 
the tracing code out of the normal flow, which would decrease paging/caching 
costs a bit when tracing is off -- but that would not make a noticable 
difference on the vast majority of programs. It would be unlikely to be 
worth the work.

> 2. Ideas for the compilation units structure modification which would 
> allow
> to have tracing code physically separated from the functional code.

We've considered such ideas in the context of assertions, but nothing 
proposed really looked like a proper part of Ada. For tracing, it would be 
even harder, because tracing can be inserted anywhere in the flow of a 
program (not just at particular places like most assertions). Moreover, in 
both cases, there isn't a clear-cut boundary between them (for tracing, 
that's primarily human-readable output, which often is needed anyway; for 
assertions, that's predicate functions that you might want to use to insert 
pre-tests before operations).

I use separate logging and trace management packages, which (combined with 
my aversion to use clauses) show tracing code pretty well. It's not clear at 
all that we could do better with syntax mechanisms.

                               Randy.

Re: Any Suggestion How To Accomplish A Debug Macro?

[Niklas Holsti]

On 15-01-02 23:52 , Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:fh7u81n706kr.131btl9yj1iz8.dlg@40tude.net...
>> On Fri, 02 Jan 2015 21:37:47 +0100, J-P. Rosen wrote:
> ...
>> However, it would be interesting to consider how tracing could be better
>> supported. I mean options:

   [snip]

>> 2. Ideas for the compilation units structure modification which would
>> allow
>> to have tracing code physically separated from the functional code.
>
> We've considered such ideas in the context of assertions, but nothing
> proposed really looked like a proper part of Ada.

Just a comment that this idea is approaching "aspect-oriented 
programming", AOP, which promised to be a radically new way to structure 
programs, as important as procedural abstraction. ("Aspect" here does 
not mean the same as in the Ada RM; see 
http://en.wikipedia.org/wiki/Aspect_%28computer_programming%29.)

In this case, the tracing would be its own aspect of the program's 
functionality, specified and implemented separately from the other 
"real" functionality.

It appears that, unfortunately, AOP was not as useful, or not as easy to 
design into programming languages, as was hoped, and the field seems to 
be not very active currently.

I found AOP an interesting idea because it feels like an intermediate or 
hybrid between procedural/imperative programming and declarative 
programming. AOP thus supports the Ada philosophy of favouring static 
descriptions/declarations of problem domain concepts, over dynamic 
coding, but on the other hand the implicit and automatic invocation of 
aspect operations, that is typical of AOP, may not be attractive for the 
safety-critical domain.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .