Logging from CPLC

[mkoncek]

I would like to discuss the logging issue before making a new release. @judovana once suggested that CPLC should log everything using the provided MessagesListener with level to mark the importance. I tried to do that but it makes using JRD impossible due to the flood. See https://github.com/mkoncek/classpathless-compiler/blob/master/impl/src/main/java/io/github/mkoncek/classpathless/impl/LoggingSwitch.java#L121

If you uncomment lines 123-125 and remove lines 128-132 and try to run JRD... be ready to kill the process or get OOM'd. Currently CPLC logs many things and this will probably stay so to ease with development.

So... on your side: either implement some filtering or let's have a talk about what you would really need to log from CPLC. The current approach is that enabling system properties specifies what logging and where it happens - that is for my own debugging.

[judovana]

current logging is quite good - it prints ot all impoertant things. The onky missing peace is some verbosity control, where the default, will be exactly the current one.

[judovana]

if you really wish to improve this, then I would recomend to clone JRD, and try from there. And develop CPLC library + JRD binding together

[mkoncek]

I don't think there is currently any need for that. Logging as it is currently is fine for me. For you, it would be probably lots of garbage information. In case you need to debug the current approach works better than if the messages were going through JRD.

Therefore i think this can be closed.

[judovana]

I miss that garbage :)

Maybe you can introduce property which will force to pass to JRD compeltly all?

[mkoncek]

What do you mean? What would you be missing? Currently i am only sending compiler complaints to the JRD nothing more from my side. Here is an example of what would be sent at the finest level: log.txt

[judovana]

well yes. that is what would like to see if the proeprty if verbose or if that proeprty is set

-- Mgr. Jiri Vanek @.***

---------- Původní e-mail ---------- Od: mkoncek @.> Komu: pmikova/java-runtime-decompiler @. github.com> Datum: 18. 11. 2021 14:17:40 Předmět: Re: [pmikova/java-runtime-decompiler] Logging from CPLC (Issue # 220) "

What do you mean? What would you be missing? Currently i am only sending compiler complaints to the JRD nothing more from my side. Here is an example of what would be sent at the finest level: log.txt (https://github.com/pmikova/java-runtime-decompiler/files/7563032/log.txt)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (https://github.com/pmikova/java-runtime-decompiler/issues/220#issuecomment-972857112) , or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAWFCS362EPX52HT5BUSCK3UMT4GZANCNFSM5H3IOK3A) . Triage notifications on the go with GitHub Mobile for iOS (https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or Android (https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub) . "

[mkoncek]

Well, that is one part of the problem, the other is that in the most verbose mode, (in my case) I will get my process OOM-killed before than the compilation is finished. Because then it is much slower as well as wastes too much memory. I mentioned steps to reproduce in the first comment.

[judovana]

interesting. I would say that once you println the message, the memory would be cleaned. Where it remains stored?

-- Mgr. Jiri Vanek @.***

---------- Původní e-mail ---------- Od: mkoncek @.> Komu: pmikova/java-runtime-decompiler @. github.com> Datum: 18. 11. 2021 15:08:26 Předmět: Re: [pmikova/java-runtime-decompiler] Logging from CPLC (Issue # 220) "

Well, that is one part of the problem, the other is that in the most verbose mode, (in my case) I will get my process OOM-killed before than the compilation is finished.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (https://github.com/pmikova/java-runtime-decompiler/issues/220#issuecomment-972897678) , or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAWFCS43OALCLOCLUJBTEADUMUCFFANCNFSM5H3IOK3A) . Triage notifications on the go with GitHub Mobile for iOS (https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or Android (https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub) . "

[mkoncek]

I think the JRD window which shows error messages was not meant to be flooded and behaves suboptimally. The memory consumption will rise at least about 1 GB.

[judovana]

thats why it should be passed only under very very specific conditions - like some nice property.

-- Mgr. Jiri Vanek @.***

---------- Původní e-mail ---------- Od: mkoncek @.> Komu: pmikova/java-runtime-decompiler @. github.com> Datum: 18. 11. 2021 15:37:25 Předmět: Re: [pmikova/java-runtime-decompiler] Logging from CPLC (Issue # 220) "

I think the JRD window which shows error messages was not meant to be flooded and behaves suboptimally. The memory consumption will rise at least about 1 GB.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (https://github.com/pmikova/java-runtime-decompiler/issues/220#issuecomment-972923862) , or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAWFCS2HSVRFV456SDHMYV3UMUFRTANCNFSM5H3IOK3A) . Triage notifications on the go with GitHub Mobile for iOS (https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or Android (https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub) . "

[mkoncek]

Proposed property.

[judovana]

hmm. Need to try this. Originally I thought that the proeprty will be read by CPLC, and will contorl how much is passed to the listener

[judovana]

oh. it is in cplc. sorry. Stil lnee do try. TY@