<< Back to previous view

[TLOG-20] log/info removes quotes from strings making debugging harder than it needs to be. Created: 19/Jul/17  Updated: 19/Jul/17

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

Type: Defect Priority: Major
Reporter: Lonnie Souder Assignee: Alexander Taggart
Resolution: Unresolved Votes: 0
Labels: None


 Description   

log/info removes quotes from strings making debugging harder than it needs to be. I found that {:test1 "", :test2 "2"} is logged as {:test1 , :test2 2}. I see the same issue when I print a map using println. prn prints the map with the quotes which is better for debugging.

I will make a patch and add it later.






[TLOG-16] Add ClojureScript support? Created: 21/Jul/16  Updated: 21/Jul/16

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

Type: Enhancement Priority: Major
Reporter: Daniel Compton Assignee: Alexander Taggart
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It would be really neat if there was a unified Clojure/ClojureScript logging library. I'm thinking it would have the same API as the Clojure one. I'm not 100% sure how appenders would work though. Would a patch for this be considered?






[TLOG-14] Logging backend (factory) for Android Created: 02/Apr/15  Updated: 05/Apr/15

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

Type: Enhancement Priority: Major
Reporter: Alexander Yakushev Assignee: Alexander Yakushev
Resolution: Unresolved Votes: 0
Labels: android, enhancement
Environment:

Android



 Description   

I would like to use tools.logging on Android. Android OS already provides a logging backend (in the form of android.util.Log class), so it is enough to write a factory for it in tools.logging.impl. I would like to write this factory if the maintainers agree to accept the patch.

The created factory would not strongly depend upon any Android classes, it will use Class/forName to check for Android environment. About the position of this factory between others: I think it is best to put it just before java.util.logging, so that more specific implementations are preferred.



 Comments   
Comment by Alexander Taggart [ 05/Apr/15 11:40 AM ]

Would it be reasonable to leverage SLF4J here? See http://www.slf4j.org/android/

Comment by Alexander Yakushev [ 05/Apr/15 12:14 PM ]

While it is indeed possible to do go this route, I just didn't want to pull in another wrapper (slf4j-android) in addition to clojure.tools.logging (which is also a wrapper). Could be matter of taste though.

On a related note, I still had to rewrite all existing factories in clojure.tools.logging.impl. They all use eval which is not available in the limited Android environment, so I turned them into macros that expand only if the respective classes are on the classpath at AOT time. Have you considered adopting similar behavior for mainline tools.logging, or is there specific requirement to keep eval?

Comment by Alexander Taggart [ 05/Apr/15 12:46 PM ]

The multiple wrapping used to bug me too, but I figured they're providing a different set of features. Really, tools.logging just provides some clojure-specific behaviour (e.g., conditional evaluation via macros, binding out and err, using ns by default), whereas SLF4J is proving a common java API, which in turn means I don't need to maintain an ever-growing list of java logging implementations .

As for the use of eval, ironically, it was added precisely to avoid the logging implementation becoming fixed at the time of performing AOT. This makes sense if one is, say, AOTing a generic library. Absence of the ability to eval was not foreseen.

It might be possible to conditionally skip the eval when eval is not present, though ad hoc feature detection isn't something I'd want to do without significant input from the community. Perhaps a better route would be to use 1.7's reader conditionals, though I only see platform-based distinctions between clj/cljs/cljr; nothing suggesting a way to vary based on android.

Comment by Alexander Yakushev [ 05/Apr/15 12:55 PM ]

I see. I thought the case for eval there is rather marginal (if you AOT compile tools.logging without the logging implementation) but apparently someone needs that. I also do AOT compilation but I compile everything together and at once, so macro approach works for me.

Perhaps then I shouldn't bother you with this, and just maintain my fork for Android projects. It's too much work, at least for now, to cater to all possible platforms in a single version.

Comment by Alexander Taggart [ 05/Apr/15 1:05 PM ]

If the android platform has enough significant differences from vanilla clj, then I would think that's precisely the purpose of 1.7's conditional reader support. I suggest reaching out to the dev mailing list.





Generated at Sat Jul 22 07:55:39 CDT 2017 using JIRA 4.4#649-r158309.