Support for logging

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Support for logging

Utkarsh Ayachit
Folks,

Of late I've been finding myself needing some sort of logging support
when debugging complex issues in ParaView and the more I thought about
it, the more I realized it should really be in VTK too and hence this
email.

I wonder what folks thought about adding support for generating logs
to VTK. This goes beyond the vtkTimerLog we currently have.
vtkTimerLog is great to log filter execution times etc. but it lacks
features like levels of verbosity, among others that are needed in a
general purpose logging infrastructure. We could potentially make
vtkTImerLog use the chosen logging infrastructure under the covers,
but that's a separate discussion and not entirely relevant to the
topic at hand.

To illustrate a case where this is useful in VTK: has anyone ever
tried to debug why a filter is re-executing? One often ends up in the
weeds of vtkExecutive and subclass and is fraught with frustration.
Now, imagine that the vtkExecutive subclass just generated a log
indicate which pipeline pass it's executing, and why -- things would
be so easy! The log could be added only at higher levels of verbosity,
thus not pollute application logs with internal details, but would be
easily generate-able/accessible when needed. Same is true for
rendering pipelines, determining if the VBOs, for example, are being
regenerated and why can be easily logged and aid tracking down
performance issues.

If we are convinced of the need for a logging support, then the
question becomes which logging library to use? I have been using for
loguru[1] with great success for a multi-threaded app. I love it's
output generation style, plus how well it handles logs from multiple
threads. It's C++ friendly, header only, minimal external
dependencies.

Thoughts? Suggestions?

Utkarsh


[1] https://github.com/emilk/loguru
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Sebastien Jourdain via vtk-developers
Great idea.  For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable.

Alan

________________________________________
From: vtk-developers <[hidden email]> on behalf of Utkarsh Ayachit <[hidden email]>
Sent: Tuesday, August 7, 2018 8:29 AM
To: [hidden email]
Subject: [EXTERNAL] [vtk-developers] Support for logging

Folks,

Of late I've been finding myself needing some sort of logging support
when debugging complex issues in ParaView and the more I thought about
it, the more I realized it should really be in VTK too and hence this
email.

I wonder what folks thought about adding support for generating logs
to VTK. This goes beyond the vtkTimerLog we currently have.
vtkTimerLog is great to log filter execution times etc. but it lacks
features like levels of verbosity, among others that are needed in a
general purpose logging infrastructure. We could potentially make
vtkTImerLog use the chosen logging infrastructure under the covers,
but that's a separate discussion and not entirely relevant to the
topic at hand.

To illustrate a case where this is useful in VTK: has anyone ever
tried to debug why a filter is re-executing? One often ends up in the
weeds of vtkExecutive and subclass and is fraught with frustration.
Now, imagine that the vtkExecutive subclass just generated a log
indicate which pipeline pass it's executing, and why -- things would
be so easy! The log could be added only at higher levels of verbosity,
thus not pollute application logs with internal details, but would be
easily generate-able/accessible when needed. Same is true for
rendering pipelines, determining if the VBOs, for example, are being
regenerated and why can be easily logged and aid tracking down
performance issues.

If we are convinced of the need for a logging support, then the
question becomes which logging library to use? I have been using for
loguru[1] with great success for a multi-threaded app. I love it's
output generation style, plus how well it handles logs from multiple
threads. It's C++ friendly, header only, minimal external
dependencies.

Thoughts? Suggestions?

Utkarsh


[1] https://github.com/emilk/loguru
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Andras Lasso
VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated?

Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity.

Andras

From: "Scott, W Alan via vtk-developers" <[hidden email]>
Sent: Tuesday, August 7, 2018 6:38 PM
To: Ayachit, Utkarsh (External Contacts); [hidden email]
Subject: Re: [vtk-developers] [EXTERNAL] Support for logging

Great idea.  For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable.

Alan

________________________________________
From: vtk-developers <[hidden email]> on behalf of Utkarsh Ayachit <[hidden email]>
Sent: Tuesday, August 7, 2018 8:29 AM
To: [hidden email]
Subject: [EXTERNAL] [vtk-developers] Support for logging

Folks,

Of late I've been finding myself needing some sort of logging support
when debugging complex issues in ParaView and the more I thought about
it, the more I realized it should really be in VTK too and hence this
email.

I wonder what folks thought about adding support for generating logs
to VTK. This goes beyond the vtkTimerLog we currently have.
vtkTimerLog is great to log filter execution times etc. but it lacks
features like levels of verbosity, among others that are needed in a
general purpose logging infrastructure. We could potentially make
vtkTImerLog use the chosen logging infrastructure under the covers,
but that's a separate discussion and not entirely relevant to the
topic at hand.

To illustrate a case where this is useful in VTK: has anyone ever
tried to debug why a filter is re-executing? One often ends up in the
weeds of vtkExecutive and subclass and is fraught with frustration.
Now, imagine that the vtkExecutive subclass just generated a log
indicate which pipeline pass it's executing, and why -- things would
be so easy! The log could be added only at higher levels of verbosity,
thus not pollute application logs with internal details, but would be
easily generate-able/accessible when needed. Same is true for
rendering pipelines, determining if the VBOs, for example, are being
regenerated and why can be easily logged and aid tracking down
performance issues.

If we are convinced of the need for a logging support, then the
question becomes which logging library to use? I have been using for
loguru[1] with great success for a multi-threaded app. I love it's
output generation style, plus how well it handles logs from multiple
threads. It's C++ friendly, header only, minimal external
dependencies.

Thoughts? Suggestions?

Utkarsh


[1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&amp;reserved=0
_______________________________________________
Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0

Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0

Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0

Follow this link to subscribe/unsubscribe:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0

_______________________________________________
Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0

Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0

Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0

Follow this link to subscribe/unsubscribe:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Allie Vacanti
+1. The loguru outputs I've seen are very nice.

I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I

Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic.

On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso <[hidden email]> wrote:
VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated?

Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity.

Andras

From: "Scott, W Alan via vtk-developers" <[hidden email]>
Sent: Tuesday, August 7, 2018 6:38 PM
To: Ayachit, Utkarsh (External Contacts); [hidden email]
Subject: Re: [vtk-developers] [EXTERNAL] Support for logging

Great idea.  For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable.

Alan

________________________________________
From: vtk-developers <[hidden email]> on behalf of Utkarsh Ayachit <[hidden email]>
Sent: Tuesday, August 7, 2018 8:29 AM
To: [hidden email]
Subject: [EXTERNAL] [vtk-developers] Support for logging

Folks,

Of late I've been finding myself needing some sort of logging support
when debugging complex issues in ParaView and the more I thought about
it, the more I realized it should really be in VTK too and hence this
email.

I wonder what folks thought about adding support for generating logs
to VTK. This goes beyond the vtkTimerLog we currently have.
vtkTimerLog is great to log filter execution times etc. but it lacks
features like levels of verbosity, among others that are needed in a
general purpose logging infrastructure. We could potentially make
vtkTImerLog use the chosen logging infrastructure under the covers,
but that's a separate discussion and not entirely relevant to the
topic at hand.

To illustrate a case where this is useful in VTK: has anyone ever
tried to debug why a filter is re-executing? One often ends up in the
weeds of vtkExecutive and subclass and is fraught with frustration.
Now, imagine that the vtkExecutive subclass just generated a log
indicate which pipeline pass it's executing, and why -- things would
be so easy! The log could be added only at higher levels of verbosity,
thus not pollute application logs with internal details, but would be
easily generate-able/accessible when needed. Same is true for
rendering pipelines, determining if the VBOs, for example, are being
regenerated and why can be easily logged and aid tracking down
performance issues.

If we are convinced of the need for a logging support, then the
question becomes which logging library to use? I have been using for
loguru[1] with great success for a multi-threaded app. I love it's
output generation style, plus how well it handles logs from multiple
threads. It's C++ friendly, header only, minimal external
dependencies.

Thoughts? Suggestions?

Utkarsh


[1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&amp;reserved=0
_______________________________________________
Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0

Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0

Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0

Follow this link to subscribe/unsubscribe:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0

_______________________________________________
Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0

Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0

Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0

Follow this link to subscribe/unsubscribe:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers




_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

David E DeMarle
+1, lending moral support for the idea of better log facilities.

+0 for loguru. +1 for yeah by all means lets use something standard
and good but -1 for any new non critical dependency

Although I too have only rarely ever found vtkDebugMacro to be useful
in practice I still think it should feed into the new logs rather than
be some independent feature. Same goes for timerlogs - they should
interoperate sooner rather than later.

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti
<[hidden email]> wrote:

>
> +1. The loguru outputs I've seen are very nice.
>
> I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I
>
> Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic.
>
> On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso <[hidden email]> wrote:
>>
>> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated?
>>
>> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity.
>>
>> Andras
>> ________________________________
>> From: "Scott, W Alan via vtk-developers" <[hidden email]>
>> Sent: Tuesday, August 7, 2018 6:38 PM
>> To: Ayachit, Utkarsh (External Contacts); [hidden email]
>> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging
>>
>> Great idea.  For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable.
>>
>> Alan
>>
>> ________________________________________
>> From: vtk-developers <[hidden email]> on behalf of Utkarsh Ayachit <[hidden email]>
>> Sent: Tuesday, August 7, 2018 8:29 AM
>> To: [hidden email]
>> Subject: [EXTERNAL] [vtk-developers] Support for logging
>>
>> Folks,
>>
>> Of late I've been finding myself needing some sort of logging support
>> when debugging complex issues in ParaView and the more I thought about
>> it, the more I realized it should really be in VTK too and hence this
>> email.
>>
>> I wonder what folks thought about adding support for generating logs
>> to VTK. This goes beyond the vtkTimerLog we currently have.
>> vtkTimerLog is great to log filter execution times etc. but it lacks
>> features like levels of verbosity, among others that are needed in a
>> general purpose logging infrastructure. We could potentially make
>> vtkTImerLog use the chosen logging infrastructure under the covers,
>> but that's a separate discussion and not entirely relevant to the
>> topic at hand.
>>
>> To illustrate a case where this is useful in VTK: has anyone ever
>> tried to debug why a filter is re-executing? One often ends up in the
>> weeds of vtkExecutive and subclass and is fraught with frustration.
>> Now, imagine that the vtkExecutive subclass just generated a log
>> indicate which pipeline pass it's executing, and why -- things would
>> be so easy! The log could be added only at higher levels of verbosity,
>> thus not pollute application logs with internal details, but would be
>> easily generate-able/accessible when needed. Same is true for
>> rendering pipelines, determining if the VBOs, for example, are being
>> regenerated and why can be easily logged and aid tracking down
>> performance issues.
>>
>> If we are convinced of the need for a logging support, then the
>> question becomes which logging library to use? I have been using for
>> loguru[1] with great success for a multi-threaded app. I love it's
>> output generation style, plus how well it handles logs from multiple
>> threads. It's C++ friendly, header only, minimal external
>> dependencies.
>>
>> Thoughts? Suggestions?
>>
>> Utkarsh
>>
>>
>> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&amp;reserved=0
>> _______________________________________________
>> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
>>
>> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
>>
>> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
>>
>> Follow this link to subscribe/unsubscribe:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
>>
>> _______________________________________________
>> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
>>
>> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
>>
>> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
>>
>> Follow this link to subscribe/unsubscribe:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> https://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://public.kitware.com/mailman/listinfo/vtk-developers
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Utkarsh Ayachit
@Andras, as Allie mentioned, the vtkDebugMacro is woefully inadequate.
I'd recommend scanning the logs generated by loguru. They are
immensely superior is quality than any VTK-based log dump. While we
could change all of the message processing to go via the logging
infrastructure, that'd probably be a separate discussion since it'll
depend greatly on which logging infrastructure we pick.

@Dave , I understand your reluctance for new dependencies, but "use
something standard" and no external dependency are inherently
contradictory :). `loguru` is header only. We could "wrap" it under a
VTK-specific header and then use loguru internally, only if enabled.
But since logs should always be generatable to be useful, I don't see
who would want to build without logging enabled.


On Tue, Aug 7, 2018 at 5:55 PM David E DeMarle <[hidden email]> wrote:

>
> +1, lending moral support for the idea of better log facilities.
>
> +0 for loguru. +1 for yeah by all means lets use something standard
> and good but -1 for any new non critical dependency
>
> Although I too have only rarely ever found vtkDebugMacro to be useful
> in practice I still think it should feed into the new logs rather than
> be some independent feature. Same goes for timerlogs - they should
> interoperate sooner rather than later.
>
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti
> <[hidden email]> wrote:
> >
> > +1. The loguru outputs I've seen are very nice.
> >
> > I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I
> >
> > Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic.
> >
> > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso <[hidden email]> wrote:
> >>
> >> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated?
> >>
> >> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity.
> >>
> >> Andras
> >> ________________________________
> >> From: "Scott, W Alan via vtk-developers" <[hidden email]>
> >> Sent: Tuesday, August 7, 2018 6:38 PM
> >> To: Ayachit, Utkarsh (External Contacts); [hidden email]
> >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging
> >>
> >> Great idea.  For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable.
> >>
> >> Alan
> >>
> >> ________________________________________
> >> From: vtk-developers <[hidden email]> on behalf of Utkarsh Ayachit <[hidden email]>
> >> Sent: Tuesday, August 7, 2018 8:29 AM
> >> To: [hidden email]
> >> Subject: [EXTERNAL] [vtk-developers] Support for logging
> >>
> >> Folks,
> >>
> >> Of late I've been finding myself needing some sort of logging support
> >> when debugging complex issues in ParaView and the more I thought about
> >> it, the more I realized it should really be in VTK too and hence this
> >> email.
> >>
> >> I wonder what folks thought about adding support for generating logs
> >> to VTK. This goes beyond the vtkTimerLog we currently have.
> >> vtkTimerLog is great to log filter execution times etc. but it lacks
> >> features like levels of verbosity, among others that are needed in a
> >> general purpose logging infrastructure. We could potentially make
> >> vtkTImerLog use the chosen logging infrastructure under the covers,
> >> but that's a separate discussion and not entirely relevant to the
> >> topic at hand.
> >>
> >> To illustrate a case where this is useful in VTK: has anyone ever
> >> tried to debug why a filter is re-executing? One often ends up in the
> >> weeds of vtkExecutive and subclass and is fraught with frustration.
> >> Now, imagine that the vtkExecutive subclass just generated a log
> >> indicate which pipeline pass it's executing, and why -- things would
> >> be so easy! The log could be added only at higher levels of verbosity,
> >> thus not pollute application logs with internal details, but would be
> >> easily generate-able/accessible when needed. Same is true for
> >> rendering pipelines, determining if the VBOs, for example, are being
> >> regenerated and why can be easily logged and aid tracking down
> >> performance issues.
> >>
> >> If we are convinced of the need for a logging support, then the
> >> question becomes which logging library to use? I have been using for
> >> loguru[1] with great success for a multi-threaded app. I love it's
> >> output generation style, plus how well it handles logs from multiple
> >> threads. It's C++ friendly, header only, minimal external
> >> dependencies.
> >>
> >> Thoughts? Suggestions?
> >>
> >> Utkarsh
> >>
> >>
> >> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&amp;reserved=0
> >> _______________________________________________
> >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
> >>
> >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
> >>
> >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
> >>
> >> _______________________________________________
> >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
> >>
> >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
> >>
> >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
> >>
> >>
> >> _______________________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >>
> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://public.kitware.com/mailman/listinfo/vtk-developers
> >>
> >>
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > https://public.kitware.com/mailman/listinfo/vtk-developers
> >
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://public.kitware.com/mailman/listinfo/vtk-developers
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Robert Maynard-4
What are the plans for controlling logging when running MPI jobs? Will
each rank have a separate log file? I would think for larger MPI runs
we might want logging disabled by default
On Wed, Aug 8, 2018 at 8:28 AM Utkarsh Ayachit
<[hidden email]> wrote:

>
> @Andras, as Allie mentioned, the vtkDebugMacro is woefully inadequate.
> I'd recommend scanning the logs generated by loguru. They are
> immensely superior is quality than any VTK-based log dump. While we
> could change all of the message processing to go via the logging
> infrastructure, that'd probably be a separate discussion since it'll
> depend greatly on which logging infrastructure we pick.
>
> @Dave , I understand your reluctance for new dependencies, but "use
> something standard" and no external dependency are inherently
> contradictory :). `loguru` is header only. We could "wrap" it under a
> VTK-specific header and then use loguru internally, only if enabled.
> But since logs should always be generatable to be useful, I don't see
> who would want to build without logging enabled.
>
>
> On Tue, Aug 7, 2018 at 5:55 PM David E DeMarle <[hidden email]> wrote:
> >
> > +1, lending moral support for the idea of better log facilities.
> >
> > +0 for loguru. +1 for yeah by all means lets use something standard
> > and good but -1 for any new non critical dependency
> >
> > Although I too have only rarely ever found vtkDebugMacro to be useful
> > in practice I still think it should feed into the new logs rather than
> > be some independent feature. Same goes for timerlogs - they should
> > interoperate sooner rather than later.
> >
> > David E DeMarle
> > Kitware, Inc.
> > Principal Engineer
> > 21 Corporate Drive
> > Clifton Park, NY 12065-8662
> > Phone: 518-881-4909
> >
> > On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti
> > <[hidden email]> wrote:
> > >
> > > +1. The loguru outputs I've seen are very nice.
> > >
> > > I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I
> > >
> > > Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic.
> > >
> > > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso <[hidden email]> wrote:
> > >>
> > >> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated?
> > >>
> > >> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity.
> > >>
> > >> Andras
> > >> ________________________________
> > >> From: "Scott, W Alan via vtk-developers" <[hidden email]>
> > >> Sent: Tuesday, August 7, 2018 6:38 PM
> > >> To: Ayachit, Utkarsh (External Contacts); [hidden email]
> > >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging
> > >>
> > >> Great idea.  For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable.
> > >>
> > >> Alan
> > >>
> > >> ________________________________________
> > >> From: vtk-developers <[hidden email]> on behalf of Utkarsh Ayachit <[hidden email]>
> > >> Sent: Tuesday, August 7, 2018 8:29 AM
> > >> To: [hidden email]
> > >> Subject: [EXTERNAL] [vtk-developers] Support for logging
> > >>
> > >> Folks,
> > >>
> > >> Of late I've been finding myself needing some sort of logging support
> > >> when debugging complex issues in ParaView and the more I thought about
> > >> it, the more I realized it should really be in VTK too and hence this
> > >> email.
> > >>
> > >> I wonder what folks thought about adding support for generating logs
> > >> to VTK. This goes beyond the vtkTimerLog we currently have.
> > >> vtkTimerLog is great to log filter execution times etc. but it lacks
> > >> features like levels of verbosity, among others that are needed in a
> > >> general purpose logging infrastructure. We could potentially make
> > >> vtkTImerLog use the chosen logging infrastructure under the covers,
> > >> but that's a separate discussion and not entirely relevant to the
> > >> topic at hand.
> > >>
> > >> To illustrate a case where this is useful in VTK: has anyone ever
> > >> tried to debug why a filter is re-executing? One often ends up in the
> > >> weeds of vtkExecutive and subclass and is fraught with frustration.
> > >> Now, imagine that the vtkExecutive subclass just generated a log
> > >> indicate which pipeline pass it's executing, and why -- things would
> > >> be so easy! The log could be added only at higher levels of verbosity,
> > >> thus not pollute application logs with internal details, but would be
> > >> easily generate-able/accessible when needed. Same is true for
> > >> rendering pipelines, determining if the VBOs, for example, are being
> > >> regenerated and why can be easily logged and aid tracking down
> > >> performance issues.
> > >>
> > >> If we are convinced of the need for a logging support, then the
> > >> question becomes which logging library to use? I have been using for
> > >> loguru[1] with great success for a multi-threaded app. I love it's
> > >> output generation style, plus how well it handles logs from multiple
> > >> threads. It's C++ friendly, header only, minimal external
> > >> dependencies.
> > >>
> > >> Thoughts? Suggestions?
> > >>
> > >> Utkarsh
> > >>
> > >>
> > >> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&amp;reserved=0
> > >> _______________________________________________
> > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
> > >>
> > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
> > >>
> > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
> > >>
> > >> Follow this link to subscribe/unsubscribe:
> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
> > >>
> > >> _______________________________________________
> > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
> > >>
> > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
> > >>
> > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
> > >>
> > >> Follow this link to subscribe/unsubscribe:
> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
> > >>
> > >>
> > >> _______________________________________________
> > >> Powered by www.kitware.com
> > >>
> > >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> > >>
> > >> Search the list archives at: http://markmail.org/search/?q=vtk-developers
> > >>
> > >> Follow this link to subscribe/unsubscribe:
> > >> https://public.kitware.com/mailman/listinfo/vtk-developers
> > >>
> > >>
> > >
> > > _______________________________________________
> > > Powered by www.kitware.com
> > >
> > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> > >
> > > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> > >
> > > Follow this link to subscribe/unsubscribe:
> > > https://public.kitware.com/mailman/listinfo/vtk-developers
> > >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > https://public.kitware.com/mailman/listinfo/vtk-developers
> >
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://public.kitware.com/mailman/listinfo/vtk-developers
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Utkarsh Ayachit
Logging will be disabled by default. If we add decide to add
`vtkErrorMacro`, `vtkWarningMacro` to log, then those will get logged
by default. One will request additional verbosity either via
environment variables or command line arguments or something.

For MPI, I think it should indeed be separate files per rank, if
logging to file was requested.
On Wed, Aug 8, 2018 at 8:31 AM Robert Maynard
<[hidden email]> wrote:

>
> What are the plans for controlling logging when running MPI jobs? Will
> each rank have a separate log file? I would think for larger MPI runs
> we might want logging disabled by default
> On Wed, Aug 8, 2018 at 8:28 AM Utkarsh Ayachit
> <[hidden email]> wrote:
> >
> > @Andras, as Allie mentioned, the vtkDebugMacro is woefully inadequate.
> > I'd recommend scanning the logs generated by loguru. They are
> > immensely superior is quality than any VTK-based log dump. While we
> > could change all of the message processing to go via the logging
> > infrastructure, that'd probably be a separate discussion since it'll
> > depend greatly on which logging infrastructure we pick.
> >
> > @Dave , I understand your reluctance for new dependencies, but "use
> > something standard" and no external dependency are inherently
> > contradictory :). `loguru` is header only. We could "wrap" it under a
> > VTK-specific header and then use loguru internally, only if enabled.
> > But since logs should always be generatable to be useful, I don't see
> > who would want to build without logging enabled.
> >
> >
> > On Tue, Aug 7, 2018 at 5:55 PM David E DeMarle <[hidden email]> wrote:
> > >
> > > +1, lending moral support for the idea of better log facilities.
> > >
> > > +0 for loguru. +1 for yeah by all means lets use something standard
> > > and good but -1 for any new non critical dependency
> > >
> > > Although I too have only rarely ever found vtkDebugMacro to be useful
> > > in practice I still think it should feed into the new logs rather than
> > > be some independent feature. Same goes for timerlogs - they should
> > > interoperate sooner rather than later.
> > >
> > > David E DeMarle
> > > Kitware, Inc.
> > > Principal Engineer
> > > 21 Corporate Drive
> > > Clifton Park, NY 12065-8662
> > > Phone: 518-881-4909
> > >
> > > On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti
> > > <[hidden email]> wrote:
> > > >
> > > > +1. The loguru outputs I've seen are very nice.
> > > >
> > > > I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I
> > > >
> > > > Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic.
> > > >
> > > > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso <[hidden email]> wrote:
> > > >>
> > > >> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated?
> > > >>
> > > >> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity.
> > > >>
> > > >> Andras
> > > >> ________________________________
> > > >> From: "Scott, W Alan via vtk-developers" <[hidden email]>
> > > >> Sent: Tuesday, August 7, 2018 6:38 PM
> > > >> To: Ayachit, Utkarsh (External Contacts); [hidden email]
> > > >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging
> > > >>
> > > >> Great idea.  For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable.
> > > >>
> > > >> Alan
> > > >>
> > > >> ________________________________________
> > > >> From: vtk-developers <[hidden email]> on behalf of Utkarsh Ayachit <[hidden email]>
> > > >> Sent: Tuesday, August 7, 2018 8:29 AM
> > > >> To: [hidden email]
> > > >> Subject: [EXTERNAL] [vtk-developers] Support for logging
> > > >>
> > > >> Folks,
> > > >>
> > > >> Of late I've been finding myself needing some sort of logging support
> > > >> when debugging complex issues in ParaView and the more I thought about
> > > >> it, the more I realized it should really be in VTK too and hence this
> > > >> email.
> > > >>
> > > >> I wonder what folks thought about adding support for generating logs
> > > >> to VTK. This goes beyond the vtkTimerLog we currently have.
> > > >> vtkTimerLog is great to log filter execution times etc. but it lacks
> > > >> features like levels of verbosity, among others that are needed in a
> > > >> general purpose logging infrastructure. We could potentially make
> > > >> vtkTImerLog use the chosen logging infrastructure under the covers,
> > > >> but that's a separate discussion and not entirely relevant to the
> > > >> topic at hand.
> > > >>
> > > >> To illustrate a case where this is useful in VTK: has anyone ever
> > > >> tried to debug why a filter is re-executing? One often ends up in the
> > > >> weeds of vtkExecutive and subclass and is fraught with frustration.
> > > >> Now, imagine that the vtkExecutive subclass just generated a log
> > > >> indicate which pipeline pass it's executing, and why -- things would
> > > >> be so easy! The log could be added only at higher levels of verbosity,
> > > >> thus not pollute application logs with internal details, but would be
> > > >> easily generate-able/accessible when needed. Same is true for
> > > >> rendering pipelines, determining if the VBOs, for example, are being
> > > >> regenerated and why can be easily logged and aid tracking down
> > > >> performance issues.
> > > >>
> > > >> If we are convinced of the need for a logging support, then the
> > > >> question becomes which logging library to use? I have been using for
> > > >> loguru[1] with great success for a multi-threaded app. I love it's
> > > >> output generation style, plus how well it handles logs from multiple
> > > >> threads. It's C++ friendly, header only, minimal external
> > > >> dependencies.
> > > >>
> > > >> Thoughts? Suggestions?
> > > >>
> > > >> Utkarsh
> > > >>
> > > >>
> > > >> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&amp;reserved=0
> > > >> _______________________________________________
> > > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
> > > >>
> > > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
> > > >>
> > > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
> > > >>
> > > >> Follow this link to subscribe/unsubscribe:
> > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
> > > >>
> > > >> _______________________________________________
> > > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
> > > >>
> > > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
> > > >>
> > > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
> > > >>
> > > >> Follow this link to subscribe/unsubscribe:
> > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> Powered by www.kitware.com
> > > >>
> > > >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> > > >>
> > > >> Search the list archives at: http://markmail.org/search/?q=vtk-developers
> > > >>
> > > >> Follow this link to subscribe/unsubscribe:
> > > >> https://public.kitware.com/mailman/listinfo/vtk-developers
> > > >>
> > > >>
> > > >
> > > > _______________________________________________
> > > > Powered by www.kitware.com
> > > >
> > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> > > >
> > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> > > >
> > > > Follow this link to subscribe/unsubscribe:
> > > > https://public.kitware.com/mailman/listinfo/vtk-developers
> > > >
> > > _______________________________________________
> > > Powered by www.kitware.com
> > >
> > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> > >
> > > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> > >
> > > Follow this link to subscribe/unsubscribe:
> > > https://public.kitware.com/mailman/listinfo/vtk-developers
> > >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > https://public.kitware.com/mailman/listinfo/vtk-developers
> >
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

David E DeMarle
In reply to this post by Utkarsh Ayachit
@Dave , I understand your reluctance for new dependencies, but "use
something standard" and no external dependency are inherently
contradictory :). `loguru` is header only. We could "wrap" it under a
VTK-specific header and then use loguru internally, only if enabled.
But since logs should always be generatable to be useful, I don't see
who would want to build without logging enabled.

:)

Yes, loguru seems really lightweight. As long as we use Ben's best practices so that it can be updated and upstreamed and use system we'll be fine.

Until the logging proves itself to be "essential enough" (whatever that means) I recommend that we keep the dependency optional. Then when someone is trying to deploy a VTK enabled app on some strange system or distro and they hit a hard and weirdo compile error, they can make due.

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909


On Wed, Aug 8, 2018 at 8:27 AM Utkarsh Ayachit <[hidden email]> wrote:
@Andras, as Allie mentioned, the vtkDebugMacro is woefully inadequate.
I'd recommend scanning the logs generated by loguru. They are
immensely superior is quality than any VTK-based log dump. While we
could change all of the message processing to go via the logging
infrastructure, that'd probably be a separate discussion since it'll
depend greatly on which logging infrastructure we pick.

@Dave , I understand your reluctance for new dependencies, but "use
something standard" and no external dependency are inherently
contradictory :). `loguru` is header only. We could "wrap" it under a
VTK-specific header and then use loguru internally, only if enabled.
But since logs should always be generatable to be useful, I don't see
who would want to build without logging enabled.


On Tue, Aug 7, 2018 at 5:55 PM David E DeMarle <[hidden email]> wrote:
>
> +1, lending moral support for the idea of better log facilities.
>
> +0 for loguru. +1 for yeah by all means lets use something standard
> and good but -1 for any new non critical dependency
>
> Although I too have only rarely ever found vtkDebugMacro to be useful
> in practice I still think it should feed into the new logs rather than
> be some independent feature. Same goes for timerlogs - they should
> interoperate sooner rather than later.
>
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti
> <[hidden email]> wrote:
> >
> > +1. The loguru outputs I've seen are very nice.
> >
> > I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I
> >
> > Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic.
> >
> > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso <[hidden email]> wrote:
> >>
> >> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated?
> >>
> >> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity.
> >>
> >> Andras
> >> ________________________________
> >> From: "Scott, W Alan via vtk-developers" <[hidden email]>
> >> Sent: Tuesday, August 7, 2018 6:38 PM
> >> To: Ayachit, Utkarsh (External Contacts); [hidden email]
> >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging
> >>
> >> Great idea.  For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable.
> >>
> >> Alan
> >>
> >> ________________________________________
> >> From: vtk-developers <[hidden email]> on behalf of Utkarsh Ayachit <[hidden email]>
> >> Sent: Tuesday, August 7, 2018 8:29 AM
> >> To: [hidden email]
> >> Subject: [EXTERNAL] [vtk-developers] Support for logging
> >>
> >> Folks,
> >>
> >> Of late I've been finding myself needing some sort of logging support
> >> when debugging complex issues in ParaView and the more I thought about
> >> it, the more I realized it should really be in VTK too and hence this
> >> email.
> >>
> >> I wonder what folks thought about adding support for generating logs
> >> to VTK. This goes beyond the vtkTimerLog we currently have.
> >> vtkTimerLog is great to log filter execution times etc. but it lacks
> >> features like levels of verbosity, among others that are needed in a
> >> general purpose logging infrastructure. We could potentially make
> >> vtkTImerLog use the chosen logging infrastructure under the covers,
> >> but that's a separate discussion and not entirely relevant to the
> >> topic at hand.
> >>
> >> To illustrate a case where this is useful in VTK: has anyone ever
> >> tried to debug why a filter is re-executing? One often ends up in the
> >> weeds of vtkExecutive and subclass and is fraught with frustration.
> >> Now, imagine that the vtkExecutive subclass just generated a log
> >> indicate which pipeline pass it's executing, and why -- things would
> >> be so easy! The log could be added only at higher levels of verbosity,
> >> thus not pollute application logs with internal details, but would be
> >> easily generate-able/accessible when needed. Same is true for
> >> rendering pipelines, determining if the VBOs, for example, are being
> >> regenerated and why can be easily logged and aid tracking down
> >> performance issues.
> >>
> >> If we are convinced of the need for a logging support, then the
> >> question becomes which logging library to use? I have been using for
> >> loguru[1] with great success for a multi-threaded app. I love it's
> >> output generation style, plus how well it handles logs from multiple
> >> threads. It's C++ friendly, header only, minimal external
> >> dependencies.
> >>
> >> Thoughts? Suggestions?
> >>
> >> Utkarsh
> >>
> >>
> >> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&amp;reserved=0
> >> _______________________________________________
> >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
> >>
> >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
> >>
> >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
> >>
> >> _______________________________________________
> >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
> >>
> >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
> >>
> >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
> >>
> >>
> >> _______________________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >>
> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://public.kitware.com/mailman/listinfo/vtk-developers
> >>
> >>
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > https://public.kitware.com/mailman/listinfo/vtk-developers
> >
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://public.kitware.com/mailman/listinfo/vtk-developers
>

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Sebastien Jourdain via vtk-developers
In reply to this post by Utkarsh Ayachit
As strictly a client of VTK, I would like to express the strong desire
to NOT get yet-another-logger added to my app just because I link in
VTK. Please make sure it's "opt-in" only. We have two apps, one
already uses log4cpp, and one uses g2log, and we just went through a
large pain trying to turn off logging in one of our other client
libraries.

So.... if you do add this, please make it off by default, and easy to
switch on and off entirely. (And easy to integrate with any
pre-existing backend application logging facility...)


Thanks,
David C.

On Wed, Aug 8, 2018 at 8:45 AM Utkarsh Ayachit
<[hidden email]> wrote:

>
> Logging will be disabled by default. If we add decide to add
> `vtkErrorMacro`, `vtkWarningMacro` to log, then those will get logged
> by default. One will request additional verbosity either via
> environment variables or command line arguments or something.
>
> For MPI, I think it should indeed be separate files per rank, if
> logging to file was requested.
> On Wed, Aug 8, 2018 at 8:31 AM Robert Maynard
> <[hidden email]> wrote:
> >
> > What are the plans for controlling logging when running MPI jobs? Will
> > each rank have a separate log file? I would think for larger MPI runs
> > we might want logging disabled by default
> > On Wed, Aug 8, 2018 at 8:28 AM Utkarsh Ayachit
> > <[hidden email]> wrote:
> > >
> > > @Andras, as Allie mentioned, the vtkDebugMacro is woefully inadequate.
> > > I'd recommend scanning the logs generated by loguru. They are
> > > immensely superior is quality than any VTK-based log dump. While we
> > > could change all of the message processing to go via the logging
> > > infrastructure, that'd probably be a separate discussion since it'll
> > > depend greatly on which logging infrastructure we pick.
> > >
> > > @Dave , I understand your reluctance for new dependencies, but "use
> > > something standard" and no external dependency are inherently
> > > contradictory :). `loguru` is header only. We could "wrap" it under a
> > > VTK-specific header and then use loguru internally, only if enabled.
> > > But since logs should always be generatable to be useful, I don't see
> > > who would want to build without logging enabled.
> > >
> > >
> > > On Tue, Aug 7, 2018 at 5:55 PM David E DeMarle <[hidden email]> wrote:
> > > >
> > > > +1, lending moral support for the idea of better log facilities.
> > > >
> > > > +0 for loguru. +1 for yeah by all means lets use something standard
> > > > and good but -1 for any new non critical dependency
> > > >
> > > > Although I too have only rarely ever found vtkDebugMacro to be useful
> > > > in practice I still think it should feed into the new logs rather than
> > > > be some independent feature. Same goes for timerlogs - they should
> > > > interoperate sooner rather than later.
> > > >
> > > > David E DeMarle
> > > > Kitware, Inc.
> > > > Principal Engineer
> > > > 21 Corporate Drive
> > > > Clifton Park, NY 12065-8662
> > > > Phone: 518-881-4909
> > > >
> > > > On Tue, Aug 7, 2018 at 1:25 PM Allie Vacanti
> > > > <[hidden email]> wrote:
> > > > >
> > > > > +1. The loguru outputs I've seen are very nice.
> > > > >
> > > > > I tend to find the vtkObject::Debug logging to be largely useless, as it prints very verbose information and it's usually easier to just add a manual print statement when something like this is needed. Source modification is usually needed to set the Debug flag on, and at that point, why not just dump the exact piece of info we care about, when we care about it? I
> > > > >
> > > > > Something that would let us categorize the log entries ('rendering' for mappers/renderers, 'pipeline' for executive info, 'filter' for algorithm details, 'dataset' for dataset changes, 'verbose' for every-little-set-and-get-ever) to more easily filter out the stuff we're not interested in would be fantastic.
> > > > >
> > > > > On Tue, Aug 7, 2018 at 1:03 PM, Andras Lasso <[hidden email]> wrote:
> > > > >>
> > > > >> VTK has already a logging API that sends messages to stdout/stderr by default but it can be easily configured to send messages to any logging system. Do you mean you would keep the current logging API and just change the default logging backend to something more sophisticated?
> > > > >>
> > > > >> Somewhat related issue: For me, it has never been completely clear how VTK debug logs could be used in practice, as most often it is very difficult to set DebugOn for an object (or group of relevant objects). It would be probably better to enable logging by default for all objects and split current debug level to 3 levels (info/debug/trace) for better control of verbosity.
> > > > >>
> > > > >> Andras
> > > > >> ________________________________
> > > > >> From: "Scott, W Alan via vtk-developers" <[hidden email]>
> > > > >> Sent: Tuesday, August 7, 2018 6:38 PM
> > > > >> To: Ayachit, Utkarsh (External Contacts); [hidden email]
> > > > >> Subject: Re: [vtk-developers] [EXTERNAL] Support for logging
> > > > >>
> > > > >> Great idea.  For someone that doesn't know where to place breakpoints, but has to try to debug datasets that cannot be sent to Kitware, this would be incredibly valuable.
> > > > >>
> > > > >> Alan
> > > > >>
> > > > >> ________________________________________
> > > > >> From: vtk-developers <[hidden email]> on behalf of Utkarsh Ayachit <[hidden email]>
> > > > >> Sent: Tuesday, August 7, 2018 8:29 AM
> > > > >> To: [hidden email]
> > > > >> Subject: [EXTERNAL] [vtk-developers] Support for logging
> > > > >>
> > > > >> Folks,
> > > > >>
> > > > >> Of late I've been finding myself needing some sort of logging support
> > > > >> when debugging complex issues in ParaView and the more I thought about
> > > > >> it, the more I realized it should really be in VTK too and hence this
> > > > >> email.
> > > > >>
> > > > >> I wonder what folks thought about adding support for generating logs
> > > > >> to VTK. This goes beyond the vtkTimerLog we currently have.
> > > > >> vtkTimerLog is great to log filter execution times etc. but it lacks
> > > > >> features like levels of verbosity, among others that are needed in a
> > > > >> general purpose logging infrastructure. We could potentially make
> > > > >> vtkTImerLog use the chosen logging infrastructure under the covers,
> > > > >> but that's a separate discussion and not entirely relevant to the
> > > > >> topic at hand.
> > > > >>
> > > > >> To illustrate a case where this is useful in VTK: has anyone ever
> > > > >> tried to debug why a filter is re-executing? One often ends up in the
> > > > >> weeds of vtkExecutive and subclass and is fraught with frustration.
> > > > >> Now, imagine that the vtkExecutive subclass just generated a log
> > > > >> indicate which pipeline pass it's executing, and why -- things would
> > > > >> be so easy! The log could be added only at higher levels of verbosity,
> > > > >> thus not pollute application logs with internal details, but would be
> > > > >> easily generate-able/accessible when needed. Same is true for
> > > > >> rendering pipelines, determining if the VBOs, for example, are being
> > > > >> regenerated and why can be easily logged and aid tracking down
> > > > >> performance issues.
> > > > >>
> > > > >> If we are convinced of the need for a logging support, then the
> > > > >> question becomes which logging library to use? I have been using for
> > > > >> loguru[1] with great success for a multi-threaded app. I love it's
> > > > >> output generation style, plus how well it handles logs from multiple
> > > > >> threads. It's C++ friendly, header only, minimal external
> > > > >> dependencies.
> > > > >>
> > > > >> Thoughts? Suggestions?
> > > > >>
> > > > >> Utkarsh
> > > > >>
> > > > >>
> > > > >> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femilk%2Floguru&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=CiukFppwivi35wrjPasMsrHDDl6qYr4wEhjsnQDWlww%3D&amp;reserved=0
> > > > >> _______________________________________________
> > > > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
> > > > >>
> > > > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
> > > > >>
> > > > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
> > > > >>
> > > > >> Follow this link to subscribe/unsubscribe:
> > > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
> > > > >>
> > > > >> _______________________________________________
> > > > >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=2knVTY4AKF5un%2BtsHBC6d9IwxdQU3fcg8k2B0F4y6eE%3D&amp;reserved=0
> > > > >>
> > > > >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=FGooxIKSrpR%2F9M%2BqZSmIbUqWzgTWcmQdCIrCzGac0JI%3D&amp;reserved=0
> > > > >>
> > > > >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=5yBu79VulvgbW7TSIX5NUsCbR5qUNTliI0U5Ax3yZ%2Bs%3D&amp;reserved=0
> > > > >>
> > > > >> Follow this link to subscribe/unsubscribe:
> > > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C0d8cae5a8ec54917f3b408d5fc842b32%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636692567166365790&amp;sdata=VOEka8wGfLzP3j5hAQUVLPFV9XS1CMolWwPCpzSgj3A%3D&amp;reserved=0
> > > > >>
> > > > >>
> > > > >> _______________________________________________
> > > > >> Powered by www.kitware.com
> > > > >>
> > > > >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> > > > >>
> > > > >> Search the list archives at: http://markmail.org/search/?q=vtk-developers
> > > > >>
> > > > >> Follow this link to subscribe/unsubscribe:
> > > > >> https://public.kitware.com/mailman/listinfo/vtk-developers
> > > > >>
> > > > >>
> > > > >
> > > > > _______________________________________________
> > > > > Powered by www.kitware.com
> > > > >
> > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> > > > >
> > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> > > > >
> > > > > Follow this link to subscribe/unsubscribe:
> > > > > https://public.kitware.com/mailman/listinfo/vtk-developers
> > > > >
> > > > _______________________________________________
> > > > Powered by www.kitware.com
> > > >
> > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> > > >
> > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> > > >
> > > > Follow this link to subscribe/unsubscribe:
> > > > https://public.kitware.com/mailman/listinfo/vtk-developers
> > > >
> > > _______________________________________________
> > > Powered by www.kitware.com
> > >
> > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> > >
> > > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> > >
> > > Follow this link to subscribe/unsubscribe:
> > > https://public.kitware.com/mailman/listinfo/vtk-developers
> > >
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://public.kitware.com/mailman/listinfo/vtk-developers
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Utkarsh Ayachit
> So.... if you do add this, please make it off by default, and easy to
> switch on and off entirely. (And easy to integrate with any
> pre-existing backend application logging facility...)

Indeed. Logging will be off by default.
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Bill Lorensen
ITK has a logging API. It may be a starting point for to "wrap" a
third party resource.

See: https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkLoggerManager.h


On Wed, Aug 8, 2018 at 7:53 AM, Utkarsh Ayachit
<[hidden email]> wrote:

>> So.... if you do add this, please make it off by default, and easy to
>> switch on and off entirely. (And easy to integrate with any
>> pre-existing backend application logging facility...)
>
> Indeed. Logging will be off by default.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://public.kitware.com/mailman/listinfo/vtk-developers
>



--
Unpaid intern in BillsParadise at noware dot com
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Sean McBride
In reply to this post by Sebastien Jourdain via vtk-developers
On Wed, 8 Aug 2018 10:47:01 -0400, David Cole via vtk-developers said:

>As strictly a client of VTK, I would like to express the strong desire
>to NOT get yet-another-logger added to my app just because I link in
>VTK. Please make sure it's "opt-in" only. We have two apps, one
>already uses log4cpp, and one uses g2log, and we just went through a
>large pain trying to turn off logging in one of our other client
>libraries.

I had a similar thought.  I haven't looked at this loguru, but hopefully you can choose where it logs things to.  On macOS for example, it would be nice if VTK logging eventually invokes the os_log functions in usr/include/os/log.h.

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 [hidden email]
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Bill Lorensen
We definitely should hide what ever third party spi.

On Wed, Aug 8, 2018, 11:53 AM Sean McBride <[hidden email]> wrote:
On Wed, 8 Aug 2018 10:47:01 -0400, David Cole via vtk-developers said:

>As strictly a client of VTK, I would like to express the strong desire
>to NOT get yet-another-logger added to my app just because I link in
>VTK. Please make sure it's "opt-in" only. We have two apps, one
>already uses log4cpp, and one uses g2log, and we just went through a
>large pain trying to turn off logging in one of our other client
>libraries.

I had a similar thought.  I haven't looked at this loguru, but hopefully you can choose where it logs things to.  On macOS for example, it would be nice if VTK logging eventually invokes the os_log functions in usr/include/os/log.h.

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 [hidden email]
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Jean-Christophe Fillion-Robin-2
Hi,

Here are some suggestions and comment:

* using "loguru" (or any other logging backend) should be an implementation details specific to the application using the library (e.g of application ParaView, 3D Slicer, VTK examples, VTK tests, and many more).

* existing logging macros (vtkErrorMacro, vtkDebugMacro, ...) should be kept around along with their existing behavior as well as the vtkOutputWindow

* new categorical logging macro should be introduced.

    - each message would be associated with a type (info, error, warning), a category (e.g vtk.rendering.opengl2.shaderprogram) and a context (line, file, function) 
          - for sake of performance, context would be available only for Debug (and may be RelWithDebInfo) or only if explicitly enabled
    - enable/disable logging at run-time based on rules, ...
    - this presentation nicely summarizes  the type of features that could be integrated in VTK. See https://www.kdab.com/wp-content/uploads/stories/slides/Day2/KaiKoehne_Qt%20Logging%20Framework%2016_9_0.pdf

* since it is not uncommon to have application using both ITK and VTK, would also be nice to discussed with ITK community

Such approach would allow to gradually transition existing VTK module to the new categorical logging and would prevent existing user code from breaking




On Wed, Aug 8, 2018 at 4:08 PM, Bill Lorensen <[hidden email]> wrote:
We definitely should hide what ever third party spi.

On Wed, Aug 8, 2018, 11:53 AM Sean McBride <[hidden email]> wrote:
On Wed, 8 Aug 2018 10:47:01 -0400, David Cole via vtk-developers said:

>As strictly a client of VTK, I would like to express the strong desire
>to NOT get yet-another-logger added to my app just because I link in
>VTK. Please make sure it's "opt-in" only. We have two apps, one
>already uses log4cpp, and one uses g2log, and we just went through a
>large pain trying to turn off logging in one of our other client
>libraries.

I had a similar thought.  I haven't looked at this loguru, but hopefully you can choose where it logs things to.  On macOS for example, it would be nice if VTK logging eventually invokes the os_log functions in usr/include/os/log.h.

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 [hidden email]
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers




_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Allie Vacanti
While we're possibly retooling logging...

I'd love to see the behavior of these macros change to reduce the verbosity. If we want vtkDebugMacro to log every set and get, ok, but it'd be nice to have the messages shortened. Right now, every debug/warning prints 3 lines, eg

"""
Warning: In /path/to/source/file, line XXX
vtkClassName (0xOBJ_ADDRESS): Actual log message.
<empty line>
"""

I do find the extra information to be extremely valuable, but with the amount of data logged by debug macros, it becomes a chore to dig through the output. What if the log messages were compacted to something more dense, like:

"""
[Warning] Actual log message. (vtkClassName@0xOBJ_ADDRESS, /path/to/source/file:XXX)
"""

Is this something that anyone else would find useful?


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Bill Lorensen
The debug macro is only active for debug builds.

On Thu, Aug 9, 2018, 6:36 AM Allie Vacanti <[hidden email]> wrote:
While we're possibly retooling logging...

I'd love to see the behavior of these macros change to reduce the verbosity. If we want vtkDebugMacro to log every set and get, ok, but it'd be nice to have the messages shortened. Right now, every debug/warning prints 3 lines, eg

"""
Warning: In /path/to/source/file, line XXX
vtkClassName (0xOBJ_ADDRESS): Actual log message.
<empty line>
"""

I do find the extra information to be extremely valuable, but with the amount of data logged by debug macros, it becomes a chore to dig through the output. What if the log messages were compacted to something more dense, like:

"""
[Warning] Actual log message. (vtkClassName@0xOBJ_ADDRESS, /path/to/source/file:XXX)
"""

Is this something that anyone else would find useful?


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Allie Vacanti
On Thu, Aug 9, 2018 at 9:45 AM, Bill Lorensen <[hidden email]> wrote:
The debug macro is only active for debug builds.

Yes. I'm referring to the readability of the output when it's enabled. A few have mentioned that it's not terribly useful in its current state, and making the output more compact would be an improvement IMO.

As it is, trying to watch the terminal while a program is executing is near impossible as it moves too quickly, and digging through the markup to find the relevant messages is tedious. Fitting 3x more messages in the same number of lines would improve both usecases for me.

On Thu, Aug 9, 2018, 6:36 AM Allie Vacanti <[hidden email]> wrote:
While we're possibly retooling logging...

I'd love to see the behavior of these macros change to reduce the verbosity. If we want vtkDebugMacro to log every set and get, ok, but it'd be nice to have the messages shortened. Right now, every debug/warning prints 3 lines, eg

"""
Warning: In /path/to/source/file, line XXX
vtkClassName (0xOBJ_ADDRESS): Actual log message.
<empty line>
"""

I do find the extra information to be extremely valuable, but with the amount of data logged by debug macros, it becomes a chore to dig through the output. What if the log messages were compacted to something more dense, like:

"""
[Warning] Actual log message. (vtkClassName@0xOBJ_ADDRESS, /path/to/source/file:XXX)
"""

Is this something that anyone else would find useful?



_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Support for logging

Utkarsh Ayachit
I think some prototyping is in order before we down the rabbit hole.
Allie, I'll sync up with you and see what would be good initial pass.
Don't think I have enough time to do what everyone is suggesting soon,
so I may have to table this for now.

Thanks everyone for the feedback. Hopefully we can get back to this in
near future.

Utkarsh
On Thu, Aug 9, 2018 at 9:54 AM Allie Vacanti
<[hidden email]> wrote:

>
> On Thu, Aug 9, 2018 at 9:45 AM, Bill Lorensen <[hidden email]> wrote:
>>
>> The debug macro is only active for debug builds.
>
>
> Yes. I'm referring to the readability of the output when it's enabled. A few have mentioned that it's not terribly useful in its current state, and making the output more compact would be an improvement IMO.
>
> As it is, trying to watch the terminal while a program is executing is near impossible as it moves too quickly, and digging through the markup to find the relevant messages is tedious. Fitting 3x more messages in the same number of lines would improve both usecases for me.
>
>> On Thu, Aug 9, 2018, 6:36 AM Allie Vacanti <[hidden email]> wrote:
>>>
>>> While we're possibly retooling logging...
>>>
>>> I'd love to see the behavior of these macros change to reduce the verbosity. If we want vtkDebugMacro to log every set and get, ok, but it'd be nice to have the messages shortened. Right now, every debug/warning prints 3 lines, eg
>>>
>>> """
>>> Warning: In /path/to/source/file, line XXX
>>> vtkClassName (0xOBJ_ADDRESS): Actual log message.
>>> <empty line>
>>> """
>>>
>>> I do find the extra information to be extremely valuable, but with the amount of data logged by debug macros, it becomes a chore to dig through the output. What if the log messages were compacted to something more dense, like:
>>>
>>> """
>>> [Warning] Actual log message. (vtkClassName@0xOBJ_ADDRESS, /path/to/source/file:XXX)
>>> """
>>>
>>> Is this something that anyone else would find useful?
>>>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://public.kitware.com/mailman/listinfo/vtk-developers
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers