On 03/18/10 19:16, Terrence Enger wrote:
Long version: I just managed to provoke ...
Error: Invalid MediaDescriptor detected:
Found no URL.
From
File
/home/terry/OOo_hacking/DEV300_m75/comphelper/source/misc/mediadescriptor.cxx
at Line 586
Abort ?
On Fri, 2010-03-19 at 10:16 +0100, Niklas Nebel wrote:
On 03/18/10 19:16, Terrence Enger wrote:
Long version: I just managed to provoke ...
Error: Invalid MediaDescriptor detected:
Found no URL.
From
File
On Fri, 2010-02-12 at 09:11 +0100, Frank Schoenheit, Sun Microsystems
Germany wrote:
Hi,
issue 109142 (http://www.openoffice.org/issues/show_bug.cgi?id=109142)
requests to change the behavior of assertions (OSL_ASSERT/DBG_ASSERT and
friends) to abort if their condition is not met. The
Thorsten Behrens wrote:
Mathias Bauer wrote:
The idea is the unification of pro and non-pro build. We have discussed
that only as an idea to save time in release engineering and a nice
opportunity for additional diagnostic abilities for customer problems,
but maybe it can help in our current
Eike Rathke wrote:
Hi Mathias,
On Monday, 2010-02-15 12:34:10 +0100, Mathias Bauer wrote:
startup would become ~6% larger by converting all #ifdef DBG_UTIL to
if (bDBG_UTIL==true). The influence on startup performance would be a
little bit less than this 6%, but probably measurable.
On 02/12/10 17:18, Christian Lippka wrote:
If you change code at one place, you may cause an assertion to
trigger at another place.
Since triggered assertions indicate programming errors, the above
sentence is equivalent to If you change code at one place, you may
introduce a programming
On 02/15/10 10:16, Stephan Bergmann wrote:
On 02/12/10 17:18, Christian Lippka wrote:
If you change code at one place, you may cause an assertion to
trigger at another place.
Since triggered assertions indicate programming errors, the above
sentence is equivalent to If you change code at one
Hi Stephan,
Not necessarily. The point is that triggered assertions need to be
sufficiently rare.
Okay, perhaps we can agree to strive for this goal first, and postpone
the rest of the discussion. Perhaps we can try aborting discussions, and
see how they work, perhaps we have other ideas
Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Bjoern,
Assertions should be tested with the common tests (cwscheckapi has
decent code coverage) preventing the non-pro master to become unusable.
Ah!
Did you know that testtool, the program for running automated UI level
tests on
Hi Mathias,
On Monday, 2010-02-15 12:34:10 +0100, Mathias Bauer wrote:
startup would become ~6% larger by converting all #ifdef DBG_UTIL to
if (bDBG_UTIL==true). The influence on startup performance would be a
little bit less than this 6%, but probably measurable.
[...]
bDBG_UTIL would be
Hi Mathias,
I tend to like the idea of using non-pro builds in QA, but we must
recall why we have stopped to do that in the past. Rüdiger mentioned the
performance problem, maybe there have been others.
Would be interesting to know. The only thing I heard in the past
whenever I asked is, hmm,
Mathias Bauer wrote:
The idea is the unification of pro and non-pro build. We have discussed
that only as an idea to save time in release engineering and a nice
opportunity for additional diagnostic abilities for customer problems,
but maybe it can help in our current discussion also.
Please
Hi Björn,
As said before an aborting assertion should only be used for corrupt
internal state.
Well, to me that wasn't that clear 'til now.
If we add unrecoverable before corrupt (and here we're back at the
question of how an office suite should behave to the user in case of
internal errors,
On Fri, 2010-02-12 at 17:18 +0100, Christian Lippka wrote:
If this is still not understandable, I will draw you a flow chart
on monday at your office :-)
If you send me pictures of the whiteboard or scans of the paper, I will
try to key them in. Or course, before there is any benefit, we shall
Frank Schoenheit, Sun Microsystems Germany wrote:
Hi,
issue 109142 (http://www.openoffice.org/issues/show_bug.cgi?id=109142)
requests to change the behavior of assertions (OSL_ASSERT/DBG_ASSERT and
friends) to abort if their condition is not met. The current behavior is
that the assertion text
On 02/12/10 09:11, Frank Schoenheit, Sun Microsystems Germany wrote:
issue 109142 (http://www.openoffice.org/issues/show_bug.cgi?id=109142)
requests to change the behavior of assertions (OSL_ASSERT/DBG_ASSERT and
friends) to abort if their condition is not met. The current behavior is
that the
On 02/12/10 09:30, Rich wrote:
speaking as a user here, not a coder - if software can continue with
operating, it should. yes, it should warn me, but it should run as long
as possible, either allowing me to save the document, copy data out of
it or whatever.
The irony is, once you have hit a
Stephan Bergmann wrote:
On 02/12/10 09:30, Rich wrote:
speaking as a user here, not a coder - if software can continue with
operating, it should. yes, it should warn me, but it should run as
long as possible, either allowing me to save the document, copy data
out of it or whatever.
The
Hi Frank,
I am indifferent regarding whether assertions should abort, but please
let me comment your suggestions below:
On 02/12/10 09:11, Frank Schoenheit, Sun Microsystems Germany wrote:
Hi,
issue 109142 (http://www.openoffice.org/issues/show_bug.cgi?id=109142)
requests to change the
On Fri, 12 Feb 2010 10:30:59 +0200
Rich ric...@nakts.net wrote:
speaking as a user here, not a coder - if software can continue with
operating, it should. yes, it should warn me, but it should run as
long as possible, either allowing me to save the document, copy data
out of it or whatever.
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
On Fri, 12 Feb 2010 10:30:59 +0200
Rich ric...@nakts.net wrote:
speaking as a user here, not a coder - if software can continue with
operating, it should. yes, it should warn me, but it should run as
long as possible, either
Hi Ruediger,
- QA should use non-product builds *only*. Yes, I am not kidding about
this. An assertion which fails indicates a *bug*, that's the very
original intention of assertions: report bugs. Speaking strictly,
QA which refuses to use non-product builds refuses to do their job,
On Fri, 12 Feb 2010 13:12:08 +0200
Rich ric...@nakts.net wrote:
(non-product, i assume ?)
ahem, yes.
if the plan is to use these non-product builds for
developers only, then i stand corrected and have no opinion on the
issue :)
Thats the plan as I understood Stephan (didnt he clarify that
Hi Rich,
(non-product, i assume ?)
oh, it does. if you want any testers at all from the community :)
it was discussed almost a year ago on this same mailing list - if you
want testers, make test builds usable.
On the medium run, it indeed might be interesting to give out
non-product builds
Hi Bjoern,
I am one of the devs that rarely use a non-pro build, but not because
it's unusable 'cause of the many assertions, but because there are
simply to many differences from the product build in them, causing
issues (first of all: annoying build breakers).
So you prefer not using them,
Am 12.02.2010 12:05, schrieb bjoern michaelsen - Sun Microsystems -
Hamburg Germany:
On Fri, 12 Feb 2010 09:11:21 +0100
Frank Schoenheit, Sun Microsystems Germanyfrank.schoenh...@sun.com
wrote:
- Developers should use non-product builds *only*. That's a very
apparent measure, still, a lot
Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Rich,
(non-product, i assume ?)
oh, it does. if you want any testers at all from the community :)
it was discussed almost a year ago on this same mailing list - if you
want testers, make test builds usable.
On the medium run, it indeed
Christian Lippka wrote, On 02/12/10 12:34:
Assertions are the first, cheapest and easiest way of defense in the
fight for software quality.
My 2c, assertions must not abort, developer must use non pro builds,
assertions should be used in every new peace of code.
I fully agree.
-1 for
Hi Stephan,
However,
contrary to how you read it below, I never intended to suggest that
aborting on an assertion was not appropriate in a product build. It is
my firm belief that a program that aborts upon assertions is arguably
more robust than one that carries on (however paradoxical
On Fri, 12 Feb 2010 12:43:29 +0100
Malte Timmermann malte.timmerm...@sun.com wrote:
-1 for discussing here whether or not QA should use non-pros, because
it IMHO has absolutely no influence on how assertions should behave.
And if you want QA to use non-pros, they for sure would give up quite
Am 12.02.2010 13:10, schrieb bjoern michaelsen - Sun Microsystems -
Hamburg Germany:
For example, Frank is claiming his asserts are all serious issues and
thus shouldnt be degraded to mere traces. So keeping his asserts as
assertions, even if they abort should not scare anyone, right?
No it
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
On Fri, 12 Feb 2010 12:43:29 +0100
Malte Timmermann malte.timmerm...@sun.com wrote:
-1 for discussing here whether or not QA should use non-pros, because
it IMHO has absolutely no influence on how assertions should behave.
And if
On 2/12/10 11:02 AM, Stephan Bergmann wrote:
On 02/12/10 09:30, Rich wrote:
speaking as a user here, not a coder - if software can continue with
operating, it should. yes, it should warn me, but it should run as
long as possible, either allowing me to save the document, copy data
out of it or
On 02/12/10 12:34, Christian Lippka wrote:
But you can never be 100% sure that you didn't introduced assertions
since you can't check every code path there is that may be affected
by your changes. Therefore assertions will pop up in the master and
an abort will render non pro unusable so people
On 2/12/10 12:32 PM, Frank Schoenheit, Sun Microsystems Germany wrote:
On the topic of what is an assertion: Yes, assertions should abort.
Otherwise, they are not an assertion, but something that is better
covered by OSL_TRACE.
Sigh. Again: No matter how the term assertion is defined in
On Fri, 12 Feb 2010 12:34:33 +0100
Christian Lippka christian.lip...@sun.com wrote:
So you see OSL_ASSERTS from your code, but you never see asserts from
code that your code uses. Or things you break with your code in other
places.
Im covering very broad ranges of modules with DEBUG=true, not
Am 12.02.2010 13:28, schrieb Stephan Bergmann:
On 02/12/10 12:34, Christian Lippka wrote:
But you can never be 100% sure that you didn't introduced assertions
since you can't check every code path there is that may be affected
by your changes. Therefore assertions will pop up in the master and
On Fri, 12 Feb 2010 13:10:01 +0100
bjoern michaelsen - Sun Microsystems - Hamburg Germany
bjoern.michael...@sun.com wrote:
Current situation:
- assertions might be anything from a informal I didnt expect this
external data to a critical internal state corrupt
Desired situation:
-
On 02/12/10 13:38, Christian Lippka wrote:
Am 12.02.2010 13:28, schrieb Stephan Bergmann:
On 02/12/10 12:34, Christian Lippka wrote:
But you can never be 100% sure that you didn't introduced assertions
since you can't check every code path there is that may be affected
by your changes.
On 2/12/10 1:33 PM, bjoern michaelsen - Sun Microsystems - Hamburg
Germany wrote:
On a second thought: Frank is afaid his asserts will get lost in all
the OSL_TRACEs we have today, Stephan wants assertions to be assertions.
Proposal:
- Make all current OSL_TRACEs to a new OSL_TRACE_VERBOSE
On Fri, 12 Feb 2010 14:38:18 +0100
Philipp Lohmann philipp.lohm...@sun.com wrote:
The obvious optimization for that process would be leaving things as
they are and introduce an OSL_ASSERT_ABORT for those who really want
that.
still one would need:
- to get rid of DBG_ASSERT, because it makes
On 2/12/10 3:05 PM, bjoern michaelsen - Sun Microsystems - Hamburg
Germany wrote:
still one would need:
- to get rid of DBG_ASSERT, because it makes absolutely no sense to
have both DBG_ASSERT and OSL_ASSERT).
Feel free to do that in gsl. Anything that makes you happier ;-)
- to move all
Hi Bjoern,
- to get rid of DBG_ASSERT, because it makes absolutely no sense to
have both DBG_ASSERT and OSL_ASSERT).
Welcome to the How should our diagnostics system look like discussion.
I think we started that topic at least three times in the last 4 years :)
- to move all the
Hi Bjoern,
With assertions being assertions and give up meaning reporting it,
thats exactly the desired behavior.
Current situation:
- assertions might be anything from a informal I didnt expect this
external data to a critical internal state corrupt
Desired situation:
- assertions
Hi Bjoern,
Assertions should be tested with the common tests (cwscheckapi has
decent code coverage) preventing the non-pro master to become unusable.
Ah!
Did you know that testtool, the program for running automated UI level
tests on OOo, can capture and report assertions?
If you claim that
On 02/12/10 15:05, bjoern michaelsen - Sun Microsystems - Hamburg
Germany wrote:
On Fri, 12 Feb 2010 14:38:18 +0100
Philipp Lohmann philipp.lohm...@sun.com wrote:
The obvious optimization for that process would be leaving things as
they are and introduce an OSL_ASSERT_ABORT for those who
Am 12.02.2010 13:44, schrieb Stephan Bergmann:
On 02/12/10 13:38, Christian Lippka wrote:
Am 12.02.2010 13:28, schrieb Stephan Bergmann:
On 02/12/10 12:34, Christian Lippka wrote:
But you can never be 100% sure that you didn't introduced assertions
since you can't check every code path there
Am 12.02.2010 15:05, schrieb bjoern michaelsen - Sun Microsystems -
Hamburg Germany:
On Fri, 12 Feb 2010 14:38:18 +0100
Philipp Lohmannphilipp.lohm...@sun.com wrote:
The obvious optimization for that process would be leaving things as
they are and introduce an OSL_ASSERT_ABORT for those who
On Fri, 12 Feb 2010 17:31:18 +0100
Christian Lippka christian.lip...@sun.com wrote:
If we make the office crash in non pro than there will be never a
chance to get the qa to work on non pro again.
Depends. If we make the master crash on tests in every milestone, sure.
As said before an aborting
On 02/12/10 17:54, bjoern michaelsen - Sun Microsystems - Hamburg
Germany wrote:
On Fri, 12 Feb 2010 17:31:18 +0100
Christian Lippka christian.lip...@sun.com wrote:
If we make the office crash in non pro than there will be never a
chance to get the qa to work on non pro again.
Depends. If we
On Fri, 2010-02-12 at 15:53 +0100, Frank Schoenheit, Sun Microsystems
Germany wrote:
finding consensus ... (and finally, perhaps it's good for something)
So, in my opinion we would need 3 levels, at least, not 2:
(1) traces (today: OSL_TRACE, DBG_TRACE)
(2) error reports (today: DBG_ERROR,
51 matches
Mail list logo
