I'm receiving unmapped variable errors with any function calls using named parameters.

I assume the compiler is not filtering out the named'parameter= portion of statement when generating the variables to be traced.

Linux Ashell ver: 6.5.1648.1
COMPIL/V 6.5(885)

I have a lot of sample code using named parameters and haven't seen this, so I may need a specific example. Here's a simple one (that doesn't complain, at least with compiler 886) ...

Here's a link to download the latest ashdevxtr with TRACE_BEGIN/TRACE_END that results in

I see the problem - it arises only in IF statements. Should be fixed in the next update.

I think this is fixed in 6.5.1650.0 / Compiler 888 (beta)...

ash65notes.txt
ash-6.5.1650.0-w32-upd.zip
ash-6.5.1650.0-w32c-upd.zip
ash-6.5.1650.0-el7-upd.tz
compil-6.5.888-el7.tz

I'm having an issue using TRACE_BEGIN/END without the optionlist, there are no trace.prints added.

If I add an option list such as, ++PRAGMA TRACE_BEGIN (2,"conv","",""), I can turn them on with set debug tags +conv

This is EL7 Version 7.0.1756.2

I'm not sure if this is a feature, a bug, or just a documentation ambiguity. The issue appears to be that the actual default debug level (first arg in the options list) is one, not zero. Which is arguably a good thing, since it allows you to turn the tracing on and off with SET DEBUG {1} and SET NODEBUG.

If we were to make the default trace level be zero, then you wouldn't be able to turn those traces off.

Does that seem better? Or did this behavior change recently?

Thought using a TRACE_BEGIN/END block would work the same as trace.print "some trace".

The trace.print by itself doesn't require setting the debug level they just get traced. It seems a TRACE_BEGIN/END block should be consistent with the behavior of the trace.print

That seems like a good logical point based on syntax consistency. I'm just not sure how practical it is though, since it means you have to modify the program to turn off the tracing. While that's true for trace.print as well, those are individual statements, which, at least in my case are used just like print statements to output messages unconditionally (errors, status, etc.) Otherwise, at least in my case, I always include the (level,"tags") argument so I can enable the traces selectively without recompiling.

The practical difference with the TRACE_BEGIN pragma is that it activates an onslaught of trace messages, making it hard (for me) to imagine ever wanting to unleash that unconditionally.

I'm also somewhat concerned that given the way it operates now, there may be programs with "silent" TRACE_BEGIN pragmas which would suddenly be activated by an A-Shell update if we changed the existing behavior. (Although admittedly, the likelihood of that isn't terribly great, considering that the documentation does seem to describe it your way.) Still, I can imagine the panic/embarrassment following an update when some long-forgotten TRACE_BEGIN pragma suddenly causes users' screens to explode with cryptic trace messages.

Is this actually creating a problem for you, or are we just having a theoretical discussion?

Just theoretical. I thought initially the PRIVATE_BEGIN/END was just not working because the documentation made it seem like they work the same as the trace.print.

We don't use trace.print for end-user feedback, so I was only thinking about development.

I can see your point. A documentation update would be good to remove this confusion.

Thanks

Ok good, we can agree on that. I'll work with Ty to correct the doc.

I'm not sure the documentation update happened on this one, given that I was about to post about trace_being/end not working again. It's been a year and I had forgotten about this detail. Thankfully I searched the forum before posting.

Thanks for the nudge. I'll take the documentation master out to the woodshed and see if we can get this sorted!

Actually, re-reading the TRACE_BEGIN and _END topic now, it appears that it was updated to say that the default dbglvl was 1, requiring SET DEBUG to enable the traces. Does it seems like it requires a more explicit/visible warning?

I see it now. It probably doesn't matter if you make it explicit or more visible. Need to use it more often, so we don't forgot the optionlist is necessary.