<< Back to previous view

[TTRACE-9] Use aprint when displaying value Created: 29/Oct/14  Updated: 17/Feb/15

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

Type: Enhancement Priority: Minor
Reporter: Jérémie Grodziski Assignee: Luc Préfontaine
Resolution: Unresolved Votes: 0
Labels: enhancement, print

Attachments: File use-aprint.diff    
Patch: Code and Test


Problem: when trace-ns is used, very long displays in the output stream is very hard to read when the fn calls are important and with voluminous data structure
Solution: Use Aprint library when printing value in the output string, now get syntax hightlighting and better layout of data structure
Tradeoffs: add a new dependency to tools.trace
Tests: yes, modify the cleanup fn to also clean the color information added by aprint, so 100% tests passed

Comment by Andy Fingerhut [ 30/Oct/14 7:36 AM ]

Jeremie, I am not certain, but I believe it is a policy of Clojure contrib libraries not to depend on libraries other than those in Clojure or Clojure contrib.

Perhaps if new arities were added to some existing tools.trace functions or macros, sprint or any other developer-desired function could be provided as arguments to control how printing occurs?

Comment by Jérémie Grodziski [ 30/Oct/14 8:17 AM ]

Hi Andy,

Thanks for your comment, yes I thought about that and known it would be the greatest concern...
I'll have a look at 2 possibilities:

  • the fastest: add new arg to tools.trace fns and macros for providing a filter that can add the colors and layout
  • the better: see if inlining the aprint code is worth considering, or better add the syntax hightlighting feature in clojure.pprint even though pprint is not used in tools.trace (and along with some neat library like Pretty that could be added to clojure.repl)

In the end, adding aprint (both for color and layout) made a HUGE difference for me in usability...

Comment by Alex Miller [ 30/Oct/14 10:18 AM ]

Andy, that is not a policy afaik, merely a preference to minimize them as much as possible. There are other contribs that have external dependencies. It's up to Luc as the contrib lead whether he thinks this is ok here.

Comment by Luc Préfontaine [ 30/Oct/14 10:59 AM ]

I've looked into this. 'Inlining aprint' in tools.trace would be my first choice.
However we need to get Vlad Bokov to fill a CA (I do not see him in the list of contributors)
and to grant us the rights to include part of is source code in tools.trace.

Being a regular user of this tool, I find the arity avenue painful. It happens that we use this in
integrated test mode to nail issues. Then the output goes to a file were tty ansi commands
are not welcomed.

I think we need a mode state to enable/disable this feature. In the repl you would need a single
statement to get the colored output whatever trace fns you are calling. That can be part of your
user profile.

Eventually this could migrate to core.pprint but that will require some time before it ends up in a clojure release.

Meanwhile we can keep this isolated in tools.trace so it can be moved later elsewhere.

Comments ?

Comment by Luc Préfontaine [ 30/Oct/14 12:50 PM ]

I sent an email to Vlad and the url to this ticket.
Will have a discussion off line first and then move along with the plan if we can.

Comment by Vlad Bokov [ 31/Oct/14 12:27 AM ]

Hi Jérémie, Alex and Luc,

I'm the author of aprint and really happy about you like my lib
Here are my thoughts about it:

1) I really like the idea to push it into tools.trace
2) Currently all the clojure contrib-libs have same patch acceptance policy as the lang, which I already wondered about https://github.com/clojure/clojure/pull/17#issuecomment-53628365 Try to understand, if a lib depends on another, the last one must share the same policy as the original, which is not the case, as I hardly stop accepting pull requests.
3) If you couldn't change this policy, I see "inlining" as best choice.

Now some points about the question "what will get inlined?"

4) I'm a bit surprised, that people don't share my intent to integrate it with repl like this https://github.com/greglook/whidbey, don't like colors, they simply like the layout. So coloring could be thrown away and we eliminate dependance on clansi. Or I could inline clansi (has MIT license), document a :^dynamic to turn on colors (which will get off by default)
5) Code for compact layout depends on jline and it's definitely won't get inside As such this will remain pprint/print-right-margin default value, which is 72 by default and isn't best choice in my opinion, but let it be. (or do you still run clojure on very old terminals?)
6) I don't see sense in introducing a new one :^dynamic for it, I suggest to rely on pprint/print-pretty and if it's true - use compact layout instead of pprint's default one

As such:

  • i could fill and sign a CA
  • prepare a dependent free patch for you, which includes only compact layout (and colors if you like) controlled by pprint/print-pretty and pprint/print-right-margin
Comment by Luc Préfontaine [ 17/Feb/15 9:03 PM ]

Hi Vlad,

any change on this one ?

I am about to issue 0.7.9. Dunno if you had some time to do the above steps.

Luc P.

Comment by Luc Préfontaine [ 17/Feb/15 9:05 PM ]


I still punch Clojure code on Hollerith cards so I am in unfamiliar territory when a line
exceeds 80 characters and the last 8 columns are not usable anyway

[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

Clojure 1.2-1.5.1


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.

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-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


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!

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")

Generated at Wed Jan 17 14:48:04 CST 2018 using JIRA 4.4#649-r158309.