On 23/11/2019 06:27, Chris Sherlock wrote:
On 23 Nov 2019, at 2:11 am, Stephan Bergmann wrote:
Sure, if one is willing to invest in adding sal.osl.noisyarea and reclassifying
existing uses. Which is typically not the case when you do a one-off
SAL_LOG=... debug run. Which is where judicious
> On 23 Nov 2019, at 2:11 am, Stephan Bergmann wrote:
>
> On 22/11/2019 14:55, Luboš Luňák wrote:
>> SAL_LOG=+INFO.sal.osl-INFO.sal.osl.noisyarea . Problem solved :).
>
> Sure, if one is willing to invest in adding sal.osl.noisyarea and
> reclassifying existing uses. Which is typically not
On 22/11/2019 14:55, Luboš Luňák wrote:
SAL_LOG=+INFO.sal.osl-INFO.sal.osl.noisyarea . Problem solved :).
Sure, if one is willing to invest in adding sal.osl.noisyarea and
reclassifying existing uses. Which is typically not the case when you
do a one-off SAL_LOG=... debug run. Which is wh
On Friday 22 of November 2019, Stephan Bergmann wrote:
> On 22/11/2019 12:13, Luboš Luňák wrote:
> > On Thursday 21 of November 2019, Stephan Bergmann wrote:
> >> * Too much trivial SAL_INFO noise (that was once added ad-hoc and should
> >> arguably have only been in a developer's local build) can
On 22/11/2019 12:13, Luboš Luňák wrote:
On Thursday 21 of November 2019, Stephan Bergmann wrote:
* Too much trivial SAL_INFO noise (that was once added ad-hoc and should
arguably have only been in a developer's local build) can make it
unnecessarily hard to see the more relevant SAL_INFOs (and l
On Thursday 21 of November 2019, Stephan Bergmann wrote:
> My concerns are:
>
> * We may eventually want to enable SAL_WARN/SAL_INFO for production
> builds, at which point the space cost of log message strings might
> become an issue.
Space cost? The size of /usr/lib64/libreoffice/program/*.so h
On Friday 22 of November 2019, Chris Sherlock wrote:
> > On 21 Nov 2019, at 10:47 pm, Luboš Luňák wrote:
> > E.g. currently while writing the Skia VCL backend I've added SAL_INFO to
> > pretty much to each of the drawing functions. And of course normally
> > nobody wants to see that, but it can be
> On 21 Nov 2019, at 10:47 pm, Luboš Luňák wrote:
>
> On Thursday 21 of November 2019, Stephan Bergmann wrote:
>> On 21/11/2019 11:25, Chris Sherlock wrote:
>>> Just a quick query to the ML - when I’m attempting to troubleshoot
>>> issues with EMF files, I use SAL_INFO to see what records it is
On 21/11/2019 12:47, Luboš Luňák wrote:
Hm, sounds rather like a misuse of the SAL log facility to me. (Each
use of it comes at a cost, so it shouldn't be used too lightly for
anything but logging unusual events.)
E.g. currently while writing the Skia VCL backend I've added SAL_INFO to
prett
On Thursday 21 of November 2019, Stephan Bergmann wrote:
> On 21/11/2019 11:25, Chris Sherlock wrote:
> > Just a quick query to the ML - when I’m attempting to troubleshoot
> > issues with EMF files, I use SAL_INFO to see what records it is reading.
> > It’s already helped me work out some issues,
On 21/11/2019 11:25, Chris Sherlock wrote:
Just a quick query to the ML - when I’m attempting to troubleshoot
issues with EMF files, I use SAL_INFO to see what records it is reading.
It’s already helped me work out some issues, in particular the last one
was around custom line caps.
How else
my iPhone
Begin forwarded message:
> From: "Stephan Bergmann (via Code Review)"
> Date: 21 November 2019 at 7:14:46 pm AEDT
> To: Stephan Bergmann
> Cc: Chris Sherlock
> Subject: [ABANDONED] Remove some excessive log formatting
> Reply-To: sberg...@redhat.com
>
&g
12 matches
Mail list logo
