<< Back to previous view

[TTRACE-8] Documentation describing the features of tools.trace Created: 04/Apr/14  Updated: 14/May/14  Resolved: 14/May/14

Status: Closed
Project: tools.trace
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Anders Conbere Assignee: Luc Préfontaine
Resolution: Completed Votes: 0
Labels: None


 Description   

I've been working on debugging some clojure systems and a coworker suggested that one helpful tool might be tools.trace. But the current documentation does nothing to help me understand how it might help.

For example here is a selection from the README:

```
(trace (* 2 3)) ;; To trace a value

(trace tag (* 2 3)) ;; To trace a value and assign a trace tag
```

But I as a total newb, have no idea what a trace is, why that would be useful, or why I would want to assign it to a tag (or even what a tag is).

I could pop open lein, get it installed, and play with it for a bit, but it's not clear to me why I should.



 Comments   
Comment by Luc Préfontaine [ 14/May/14 8:21 AM ]

I revamped the readme a bit but left stuff of larger scope open to experiment by the developper
(trace-ns/trace-vars and so forth).
Tracing existed for decades in Lisp, a simple Google search would give you an idea of what to expect.

Comment by Luc Préfontaine [ 14/May/14 8:23 AM ]

Modified README, no code change





[TTRACE-3] untrace-var* removes only the highest level of tracing created by trace-var* Created: 29/Aug/13  Updated: 15/May/14  Resolved: 14/Mar/14

Status: Closed
Project: tools.trace
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Luc Préfontaine Assignee: Luc Préfontaine
Resolution: Completed Votes: 0
Labels: enhancement
Environment:

Clojure 1.2-1.5.1



 Description   

Calling trace-var* (or using the macro trace-vars) multiple times on the same var(s) adds multiple tracing levels.
To remove tracing completely, untrace-vars* has to be called at least the same number of times on the traced var(s).

This behavior is annoying at the REPL where a single call to untrace-vars* would untracing much more simpler.
However such a behavior might be desirable when programatically driven.

Comments welcomed.



 Comments   
Comment by Luc Préfontaine [ 14/Mar/14 5:33 PM ]

After mulling over this, I think that the "recursive" behavior is not needed.
I see no added value even from a programmatic standpoint of allowing this behavior.

So calling trace-vars* on the same var has now on will not have any effect
after the first call.

Hence a single call to untrace-vars* will remove the trace at all times.

Took me some time but finally got through it

Comment by Luc Préfontaine [ 14/Mar/14 5:50 PM ]

trace-var* is now a noop if the fn is already traced

Comment by Luc Préfontaine [ 15/Mar/14 3:53 PM ]

Official release 0.7.8, bad readme in 0.7.7





[TTRACE-7] clone-throwable on type java.lang.Throwable either wastes computation or is missing cond Created: 02/Dec/13  Updated: 15/May/14  Resolved: 14/Mar/14

Status: Closed
Project: tools.trace
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Andy Fingerhut Assignee: Luc Préfontaine
Resolution: Completed Votes: 0
Labels: None


 Description   

The body of clone-throwable is currently:

(extend-type java.lang.Throwable
  ThrowableRecompose
  (clone-throwable [this stack-trace args] 
    (try
      (let [ctor (.getConstructor (class this) (into-array [java.lang.String]))
            arg (first args)]
        (string? arg)
        (doto (.newInstance ctor (into-array [arg])) (.setStackTrace stack-trace))
        :else (doto (.newInstance ctor (into-array [(str arg)])) (.setStackTrace stack-trace)))
      (catch Exception e# this))))

Note that the return value of (string? arg) disappears into nowhere, as is the :else, and both doto's are always executed.

It appears that perhaps there should be a cond wrapped around the body of the let, as there is in the clone-throwable implementation for type java.nio.charset.CoderMalfunctionError earlier in the file, or these unnecessary bits of code should be removed.



 Comments   
Comment by Luc Préfontaine [ 14/Mar/14 5:14 PM ]

Yep, missing cond. Fixed.

Comment by Luc Préfontaine [ 14/Mar/14 5:53 PM ]

Missing cond added

Comment by Luc Préfontaine [ 15/Mar/14 3:53 PM ]

Official release 0.7.8, bad readme in 0.7.7





[TTRACE-4] trace-ns traces all vars in the ns, not just fns Created: 12/Sep/13  Updated: 15/May/14  Resolved: 14/Mar/14

Status: Closed
Project: tools.trace
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Chris Jeris Assignee: Luc Préfontaine
Resolution: Completed Votes: 0
Labels: None
Environment:

Clojure 1.5.1, tools.trace 0.7.6


Attachments: Text File tools.trace-4.patch    
Patch: Code and Test

 Description   

trace-ns traces every var in the given namespace, fns and non-fns alike. This is counterintuitive from the docstring (which says "trace all fns in the given name space") – when I have a data object like a map in a var, it may happen to implement IFn, but if I trace it I can't assoc onto it any more.

trace.demo> (def x {:foo 1 :bar 2})
#'trace.demo/x
trace.demo> (trace/trace-ns 'trace.demo)
nil
trace.demo> x
#<trace$trace_var_STAR_$fn__1682$tracing_wrapper__1683 clojure.tools.trace$trace_var_STAR_$fn__1682$tracing_wrapper__1683@2b0ce330>
trace.demo> (assoc x :baz 3)
ClassCastException clojure.tools.trace$trace_var_STAR_$fn__1682$tracing_wrapper__1683 cannot be cast to clojure.lang.Associative  clojure.lang.RT.assoc (RT.java:691)

I assume it's useful to retain the ability to trace IFn's that aren't fns at the level of trace-var. The attached patch instead changes trace-ns to check that traced values are fn? (not just ifn?) before wrapping them. Andy Fingerhut suggests that, if the ability to trace IFn's that aren't fns is not actually all that useful, it's simpler just to change ifn? to fn? in trace-var*.



 Comments   
Comment by Luc Préfontaine [ 14/Mar/14 5:19 PM ]

Agree. Fixed.

Comment by Luc Préfontaine [ 14/Mar/14 5:51 PM ]

Fix accepted. Only fns are traced.

Comment by Luc Préfontaine [ 15/Mar/14 3:52 PM ]

Official release 0.7.8, bad readme in 0.7.7





[TTRACE-1] Two convenience predicate functions useful for IDE-tools Created: 23/Apr/12  Updated: 15/May/14  Resolved: 01/Dec/12

Status: Closed
Project: tools.trace
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Frank Siebenlist Assignee: Luc Préfontaine
Resolution: Completed Votes: 0
Labels: enhancement

Patch: Code and Test

 Description   

In our IDE-tool clj-ns-browser, we show the user a list of vars and make it easy to add a trace by selecting a var and clicking a button.

In order to only enable the button for a var that is traceable, we use predicate "var-traceable?".

In order to change the button text from "trace" to "untrace", we use predicate "var-traced?".

Both "var-traceable?" and "var-traced?" are aware of tools.trace internals - ideally, we would like to remain oblivious to trace's inners...

Our implementations for the predicates is at: https://gist.github.com/2472261

Thanks for the great tool!



 Comments   
Comment by Luc Préfontaine [ 14/Nov/12 5:56 PM ]

Done, however the names where changed to traced? and traceable?.

Comment by Luc Préfontaine [ 14/Nov/12 6:18 PM ]

Done is 0.7.4

Comment by Luc Préfontaine [ 01/Dec/12 3:38 PM ]

Done, "good" version is 0.7.5 (readme & comments need an update in 0.7.4")





[TTRACE-2] Eliminate a few uses of Reflection in tools.trace Created: 28/Oct/12  Updated: 15/May/14  Resolved: 01/Dec/12

Status: Closed
Project: tools.trace
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Andy Fingerhut Assignee: Luc Préfontaine
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File ttrace-2-eliminate-reflection-v1.txt    
Patch: Code

 Description   

There are a few instances of reflection in tools.trace code that can be eliminated with suitable type hints.



 Comments   
Comment by Andy Fingerhut [ 28/Oct/12 10:32 PM ]

ttrace-2-eliminate-reflection-v1.txt dated Oct 28 2012 eliminates all current uses of reflection in tools.trace code by adding type hints.

Comment by Luc Préfontaine [ 14/Nov/12 6:14 PM ]

Done in 0.7.4

Comment by Luc Préfontaine [ 01/Dec/12 3:36 PM ]

Issued 0.7.5, mising readme but was fixed in 0.7.4

Comment by Luc Préfontaine [ 01/Dec/12 3:37 PM ]

Fixed in 0.7.5





[TTRACE-6] Remove unnecessary (?) (def ~name) from deftrace Created: 29/Nov/13  Updated: 15/May/14  Resolved: 14/Mar/14

Status: Closed
Project: tools.trace
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Andy Fingerhut Assignee: Luc Préfontaine
Resolution: Completed Votes: 0
Labels: None


 Description   

I was working on enhancements to a lint tool and trying it out on contrib libraries to see if any of them have redefinitions of symbols. It found that every use of deftrace causes a redefinition. Looking at deftrace's definition, I cannot see any reason for the (def ~name) before the later (defn ~name ...) expression. The later expression is done unconditionally, unlike the way deftest or defmulti always def a var, then redefine it if it was unbound.

I could easily be missing something important here, but is there a reason for the (def ~name)?



 Comments   
Comment by Nicola Mometto [ 29/Nov/13 10:52 AM ]

Removing the def, (deftrace x [] #'x) wouldn't compile anymore.

What about replacing the def with a declare?

Comment by Luc Préfontaine [ 14/Mar/14 5:13 PM ]

Switched to declare. This satisfies the compiler.

Comment by Luc Préfontaine [ 14/Mar/14 5:53 PM ]

Replaced the def by declare

Comment by Luc Préfontaine [ 15/Mar/14 4:05 PM ]

Official release 0.7.8, bad readme in 0.7.7





[TTRACE-5] test_trace.clj unnecessarily calls (run-tests) at the end Created: 29/Nov/13  Updated: 15/May/14  Resolved: 14/Mar/14

Status: Closed
Project: tools.trace
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Andy Fingerhut Assignee: Luc Préfontaine
Resolution: Completed Votes: 0
Labels: None

Attachments: File ttrace-5-v1.diff    
Patch: Code

 Description   

Both 'mvn test' and 'lein test' run all tests twice with that (run-tests) near the end of the file. With that line removed, both of those commands run the set of tests once, as expected.



 Comments   
Comment by Andy Fingerhut [ 29/Nov/13 9:13 AM ]

Patch ttrace-5-v1.diff removes the unnecessary call to (run-tests). All tests pass once rather than twice after applying it

Comment by Luc Préfontaine [ 15/Mar/14 4:05 PM ]

Fixed in official release 0.7.8, bad readme in 0.7.7





Generated at Sat Aug 30 01:25:26 CDT 2014 using JIRA 4.4#649-r158309.