Cobra Forums

I've been using tracing and it turned out the info I wanted to see ( variables) was getting lost in the the file/line/class position info.

I added a new (additional) trace form 'trace print' that prints its expression list without the position info.
In addition if any of the expressions is a String it prints just that (without the 'name=') part.
e.g.

Code: Select all

trace print  r, v                                 # gives trace: r=<rvalue> v=<vvalue>
trace print 'searchHook'', r , 'value=[v]'   # gives trace: SearchHook r=<rValue> value=<vvalue>


(Another possibility would be to change Tracer.trace to put the position info first with the trace expressions after them...??)

While testing this I found theres no compile-time suppression of tracing (as there is for tests, asserts, nil checking) etc
(I'm presuming that was just an oversight or not yet got to item ??)

so I added that as well.
new commandline option -include-traces default yes
and had it also switched off for the -turbo option switch

Code: Select all

cobra -include-traces:no  file.cobra

Any utility to anyone else for all or part of this ?

I was using "trace on" and "trace off" for disabling regions of trace output at compile-time. I also tend to delete my trace statements soon after the bug is fixed. But I can see the utility of the command line switch.

"trace print" is interesting. What happens if someone says "print trace"?

Is there a way to do this that would be expression-oriented and then could be used anywhere? Something like (just making this up now):

Code: Select all

tw.writeLine(trace(invoice.total))
# invoice.total=45.00

Where trace(expr) expands to the expression source + CobraCore.toTechString(expr). I don't know that 'trace' would be the right keyword though. 'describe' and 'source' come to mind.

-Chuck

yah trace on/off works but have to edit the file + recompile ( and its method specific so have to find all the traces calls and edit the methods they're in) - different use case
I'll gen a Ticket and patch .

The gen-trace-string-expression thing is probably useful but not for this (trace print equiv) since using it (for tracing/debug) wont go away when tracing turned off or compile disabled.
possible names traceStr | varStr | vartrace...

You'd want something that is parsed like a function call that acts like a (compile time) macro
- substituting the things it generates for itself ( and someway of denoting the stringSourceof(expr)

Code: Select all

macro vartrace (x)  strSourceof(x) = CobraCore.toTechString(x)


One other random thought around tracing was that the output form of Tracer.trace could be described in a little substitution pattern then the order and placement of
items could be adjusted on a per app basis

Code: Select all

var _traceFormat as String = "(<exprList> <exprListSep>=;); <File>; <Line>; <Class>"
pro traceFormat from var
..
# for trace print like format
Trace.traceFormat="(<exprList> <exprListSep>= )"


Yes Toto it is possible.
I've got an implementation for your (builtin) 'trace(x)' expression - expands to "x=[CobraCore.toTechString(x)]".
allowed anywhere a string is.

I chose to name it traceStr for the moment since what it generates is the string a trace of the same expression would.
Its implemented by token resubstitution at the Tokeniser level.
Questions:
Do you want a patch for it?
Its currently hardwired to this one name + substitution - should it be genericised for easy (future) additional (builtin and later perhaps user) replacements ?
The syntax makes it look like a normal method ( except its not defined anywhere) rather than a macro substitution.
Would it be better to delineate it differently somehow syntactically ?
e.g.
:traceStr(x) # plans for other uses of leading : ?
traceStr$(x) OR trace$ # fm Basic $ == Str
$traceStr(x) # like shell variable expansion .... ${traceStr(x)} - getting yuckier and wordier
other?
%traceStr(x) %traceStr(x)% @traceStr(x)

Code: Select all

   def main is shared
      .xy='zz zz zzz zzzz z zzzzzzz'
      a = 47
      b = [1,2,3,4,5]
      c={'a':'b', 'b':'c', 'c':'d'}
      x=@['Haere','Mae']
      print traceStr(a)
      print traceStr(b)
      #print traceStr(b)
      s = traceStr(x) 
      print s   
      .xx(traceStr(c))
      Console.writeLine(traceStr(.xy))
      
   def xx(s as String) is shared
      print "xx::", s   

Outputs:

a=47
b=List<of int>[1, 2, 3, 4, 5]
x=String[]['Haere', 'Mae']
xx:: c=Dictionary<of String, String>{'a': 'b', 'b': 'c', 'c': 'd'}
.xy='zz zz zzz zzzz z zzzzzzz'


I broke a piece of ticket:32 off to ticket:52. The first is for the command line option -include-trace:no and is now done in development. The second is for handling "debug expression" output.

I'll genericise the handling slightly around using '@' as the initial character and post a patch to the ticket.

patch added to ticket:52
Generic support for named macros substituting back into parser input stream.
syntax expects '@' as leading character on macro name
Implemented only builtin macros

Code: Select all

@debug(expr)  # expands as described above for traceStr
@dts(expr) # possibly a better abbreviated name - descriptive-tech-string
@toTS(expr) # shorthand for CobraCore.toTechString(expr)


See note on ticket about deficiency compared with original patch on ticket:32 and comment above Jul 24.