On Mon, 2011-11-28 at 22:59 +0100, Michael Stahl wrote:
tests in sw run for me with this, please try it out:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=59e298823019093ee788104c2e95cb0c7b145d05
Works for me(tm).
*mumble*, paragraph anchored graphics are a pain anyway. I Would
[somehow this mail got eaten somewhere, so i'll send it again...]
On 22/11/11 13:15, Bjoern Michaelsen wrote:
Hi Michael, Stephan, all,
On Tue, Nov 22, 2011 at 12:46:52PM +0100, Michael Stahl wrote:
one requirement i would have on conditional compilation is that, whether
--disable-dbgutil
On Mon, 2011-11-28 at 12:51 +0100, Michael Stahl wrote:
finally, i have deployed our new aborting assertions for some definitely
wrong cases in SwIndex:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=0d2a6999fc320843e4db0c99d961414416a8451c
And I have abort on make subsequentcheck in
On 11/23/2011 06:55 PM, Norbert Thiebaud wrote:
For production builds, my assumption is they would
routinely log either nothing at all or *all* SAL_WARNs. So only if a user
would explicitly enable certain area-restricted SAL_INFOs (to find out more
about a reproducible problem he experiences)
On Wed, Nov 23, 2011 at 08:28:18AM +0100, Stephan Bergmann
sberg...@redhat.com wrote:
My understanding is as follows:
- There is a large number of OSL_TRACE calls all over the code base,
producing large amounts of output at runtime.
Agreed.
- Nobody wants to see all that output at once.
On 11/23/2011 10:05 AM, Miklos Vajna wrote:
Then forget the patch, all we need is to update
http://wiki.documentfoundation.org/Development/How_to_debug#Useful_macros
to reflect that now SAL_LOG controls OSL_TRACE messages, not dbglevel
1.
Thanks for the pointer. I will update that wiki page.
On 11/22/2011 10:50 AM, Stephan Bergmann wrote:
I pushed the proposed changes as
http://cgit.freedesktop.org/libreoffice/core/commit/?id=70a6b9ffbd676a1384433a86205d2cd4f2d4f4b1
and
http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=d45d5ee81e3d3f1779774af3f400ce3f1aa6697d.
Any further
On 11/22/2011 06:53 PM, Lubos Lunak wrote:
On Tuesday 22 of November 2011, Stephan Bergmann wrote:
On 11/22/2011 05:17 PM, Lubos Lunak wrote:
Does it really matter, when it is used only in debug builds anyway?
Debug builds are slower already anyway, and if the cost of generating the
output
On 11/22/2011 06:01 PM, Norbert Thiebaud wrote:
Well,
first I do like the ability to use these kind of infrastructures even
on release code...
...which I was careful to keep in mind while designing the interface.
But for the implementation, I kept it as simple as possible for now.
you'd
On Wed, Nov 23, 2011 at 9:24 AM, Stephan Bergmann sberg...@redhat.com wrote:
Second, static data is a problem, as is initialize-once data in a
multi-threaded world.
humm ?? initialize _before_ getting to the multithreaded part.
which a *library* like sal cannot do
who said that sal has to
On 11/23/2011 05:04 PM, Norbert Thiebaud wrote:
On Wed, Nov 23, 2011 at 9:24 AM, Stephan Bergmannsberg...@redhat.com wrote:
who said that sal has to auto-initialized the service.
main() explicitly call sal_init_trace_services(char*
log_env_descrition) (or whatever) and store the resulting
On Wed, Nov 23, 2011 at 10:12 AM, Stephan Bergmann sberg...@redhat.com wrote:
If you use a string as a trace-selector you will never get something
with performance good-enough for release code.
you need a numeric level and a numeric module/feature selector.
You need a system so that when the
On 11/23/2011 05:36 PM, Norbert Thiebaud wrote:
Seriously ? you need 'numbers' to be convinced that
b == 10
is more performant than (excerpt, not taking into account a couple of
epilogue/prologue among other things...)
[...]
Yes, I need numbers to be convinced that the difference is of
While a central registry of such defines could be useful also for consistency
and to avoid typos, it is the very central registry aspect that makes it
look unattractive to me.
Sure, but at least the technic I mentionned would allow for us to
_choose_ one way or another
If you stick with string
I pushed the proposed changes as
http://cgit.freedesktop.org/libreoffice/core/commit/?id=70a6b9ffbd676a1384433a86205d2cd4f2d4f4b1
and
http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=d45d5ee81e3d3f1779774af3f400ce3f1aa6697d.
Any further refinements (where to send the log output,
Hi,
On Fri, Nov 18, 2011 at 03:25:16PM +0100, Stephan Bergmann wrote:
For one, there are two sets of functionality that cater for the same
needs. One is osl/diagnose.h, the other is tools/debug.hxx.
There is also 3/4 of a log4j reimplementation in extensions/source/logging.
Just saying ...
On 18/11/11 15:25, Stephan Bergmann wrote:
The downside of that mixture is that the useful debugging technique of
aborting upon detection of a violated invariant is not available.---If
you make OSL_ASSERT (and OSL_ENSURE, OSL_FAIL, etc.) abort, it will
abort far too often for mundane
Hi Michael, Stephan, all,
On Tue, Nov 22, 2011 at 12:46:52PM +0100, Michael Stahl wrote:
one requirement i would have on conditional compilation is that, whether
--disable-dbgutil or --enable-dbgutil, objects built with debug=t
(resulting in OSL_DEBUG_LEVEL being set to non-zero) should always
On 11/22/2011 11:55 AM, Bjoern Michaelsen wrote:
There is also 3/4 of a log4j reimplementation in extensions/source/logging.
Just saying ...
Yes, based on com.sun.star.logging UNO interfaces and
comphelper/logging.hxx wrapper. Apparently only sparingly used, in
connectivity and
Agree. The only valid reason for not having all debug tools compiled in is
runtime performance and binary size.
Which brings up the question: Should my attempts to use the MSVC
debugging runtime (and debug code in its headers, i.e. -D_DEBUG) when
using --enable-dbgutil be reverted? It currently
On Tue, Nov 22, 2011 at 01:50:24PM +0100, Stephan Bergmann wrote:
Yes, based on com.sun.star.logging UNO interfaces and
comphelper/logging.hxx wrapper. Apparently only sparingly used, in
connectivity and package/source/xstor.
... and the now dormant Usage Tracking.
Needs revisiting, whether
On Mon, 2011-11-21 at 17:53 +0100, Stephan Bergmann wrote:
So, from a practical standpoint, failing smoketest on failed SAL_WARNs
would be right. On the other hand, there might be SAL_WARNs that
legitimately fire during smoketest (a trivial example would be if we
purposefully tested illegal
On 11/22/2011 03:05 PM, Caolán McNamara wrote:
Only thing left unresolved from my perspective is whether warnings on
windows works.
Maybe somebody using a Windows build could give input here, whether the
current state works well enough? (At least for a MinGW based one; given
that configure
Stephan Bergmann wrote:
based one; given that configure currently rejects --enable-dbgutil for an
MSVC based one I guess nobody cares for
debug output for that configuration at the moment, anyway?)
I think it's more a case of the Windows users struggling to get a basic build
going
On 22/11/11 13:54, Tor Lillqvist wrote:
Agree. The only valid reason for not having all debug tools compiled in is
runtime performance and binary size.
Which brings up the question: Should my attempts to use the MSVC
debugging runtime (and debug code in its headers, i.e. -D_DEBUG) when
if the MSVC debug stuff is indeed too difficult, then just comment it
out, put in a comment that says FIXME, and re-enable the
--enable-dbgutil stuff, that way windows devs at last get some
assertions and internal consistency checks.
But you can't build it with --enable-dbgutil ...
First of all: I see this has been already committed, after giving people only
slightly more than the weekend and the day after it to react, which I
consider too short for something with as large scope as this. Some of us
don't work on the weekends and have a backlog when they come back on
On Tue, Nov 22, 2011 at 1:41 AM, Stephan Bergmann sberg...@redhat.com wrote:
On 11/22/2011 06:35 AM, Norbert Thiebaud wrote:
The run tine flexibility is a great feature, but the proposed
implementation is scary perf-wise
I kept the implementation simplistic on purpose. First, remember that
On 11/22/2011 05:17 PM, Lubos Lunak wrote:
First of all: I see this has been already committed, after giving people only
slightly more than the weekend and the day after it to react, which I
consider too short for something with as large scope as this. Some of us
don't work on the weekends and
On Tuesday 22 of November 2011, Stephan Bergmann wrote:
On 11/22/2011 05:17 PM, Lubos Lunak wrote:
...
I did not commit it in order to stop any discussion. Sorry if it looked
that way. Rather, as I did not get any totally disagreeing reactions, I
thought it would be easier to polish this
On Fri, Nov 18, 2011 at 03:25:16PM +0100, Stephan Bergmann
sberg...@redhat.com wrote:
#define OSL_DEBUG_ONLY(s) _OSL_DEBUG_ONLY(s)
-#define OSL_TRACE _OSL_TRACE
-#define OSL_ASSERT(c) _OSL_ENSURE(c, OSL_THIS_FILE, __LINE__, 0)
-#define OSL_ENSURE(c, m) _OSL_ENSURE(c,
On 11/22/2011 11:50 PM, Miklos Vajna wrote:
These changes cause that without an
export SAL_LOG=+INFO
former OSL_TRACE() messages do not show up on the console, even with
dbglevel=2.
I like that SAL_LOG can now filter SAL_INFO messages, but are you sure
it's a good idea to disable them all by
On Fri, 2011-11-18 at 15:25 +0100, Stephan Bergmann wrote:
Alright, so we end up with
use assert if you want an assert
SAL_WARN if you want to warn about something odd, but which isn't
necessarily definitely wrong
SAL_INFO for verbose logging
Practical question though, is on windows where does
On 11/21/2011 01:30 PM, Caolán McNamara wrote:
On Fri, 2011-11-18 at 15:25 +0100, Stephan Bergmann wrote:
Alright, so we end up with
use assert if you want an assert
SAL_WARN if you want to warn about something odd, but which isn't
necessarily definitely wrong
SAL_INFO for verbose logging
On Mon, 2011-11-21 at 14:30 +0100, Stephan Bergmann wrote:
(One thing we
could IMO improve though, is to not rely on trying to save open
documents from within a signal handler, but instead rely on frequent
auto-save and roll back to the
On 11/21/2011 04:14 PM, Terrence Enger wrote:
On Mon, 2011-11-21 at 14:30 +0100, Stephan Bergmann wrote:
(One thing we
could IMO improve though, is to not rely on trying to save open
documents from within a signal handler, but instead rely
On Mon, 2011-11-21 at 14:30 +0100, Stephan Bergmann wrote:
On 11/21/2011 01:30 PM, Caolán McNamara wrote:
Practical question though, is on windows where does the output go ?
SAL_INFO/WARN just go to stderr for now. What should work to see them
even for a gui soffice.exe is to add
On Mon, 2011-11-21 at 16:23 +0100, Stephan Bergmann wrote:
True. So an improvement probably better left for the hypothetical
future where we have really fast save and/or save in the background.
Of course; in a world of interactive co-editing; we should really
stream everything people
On 11/21/2011 04:50 PM, Michael Meeks wrote:
Until then, I think we need to stick with the signal handler, sadly, it
is truly ugly, and I assume it can deadlock too if the signal happens at
certain places wrt. holding mutex', remarkably few posix calls are
signal-safe.
One indeed
On 11/21/2011 04:42 PM, Caolán McNamara wrote:
On Mon, 2011-11-21 at 14:30 +0100, Stephan Bergmann wrote:
On 11/21/2011 01:30 PM, Caolán McNamara wrote:
Practical question though, is on windows where does the output go ?
SAL_INFO/WARN just go to stderr for now. What should work to see them
At 11:53am -0500 Mon, 21 Nov 2011, Stephan Bergmann wrote:
It would be good if such impossible to proceed situations would
lead to uncaught exceptions [...] or clear error messages from within
LO (this functionality is unavailable (detailed error message:
...)), instead of LO silently doing
Hi Stephan,
On Monday, 2011-11-21 17:53:42 +0100, Stephan Bergmann wrote:
On 11/21/2011 04:42 PM, Caolán McNamara wrote:
On Mon, 2011-11-21 at 14:30 +0100, Stephan Bergmann wrote:
SAL_INFO/WARN just go to stderr for now. What should work to see them
even for a gui soffice.exe is to add
From what I vaguely remember it is Windows that closes those streams for
GUI executables,
Something like that, yes, although they are not closed in the sense
that they would first be open (inherited in the Unix sense); they
are never open in the first place in GUI executables, unless
explicitly
On Mon, Nov 21, 2011 at 6:30 AM, Caolán McNamara caol...@redhat.com wrote:
On Fri, 2011-11-18 at 15:25 +0100, Stephan Bergmann wrote:
Practical question though, is on windows where does the output go ?
Actually I have a similar scheme for my own stuff, and I send the
output to program_pid.log
On Fri, Nov 18, 2011 at 8:25 AM, Stephan Bergmann sberg...@redhat.com wrote:
Second, at runtime the environment variable SAL_LOG further limits
which
macro calls actually generate log output. The environment varialbe
SAL_LOG
must either be unset or must match the regular expression
On 11/22/2011 06:35 AM, Norbert Thiebaud wrote:
The run tine flexibility is a great feature, but the proposed
implementation is scary perf-wise
I kept the implementation simplistic on purpose. First, remember that
logging (at least for now) is only enabled in debug/dbgutil builds, and
that
46 matches
Mail list logo