Re: [dev] Prebuilt Mozilla DLLs on tools.openoffice.org differ from those in the installer

[Frank Schoenheit, Sun Microsystems Germany]

Hi *,

>> Especially, the DLLs on the website use msvcr80.dll, while of the
>> ones in the installer, some use msvcr90.dll and others (ones not
>> actually used  by OOo, perhaps?) use msvcr80.dll.

Actually, *all* of the Mozilla libraries should be linked against
msvcr80.dll, while all of the "pure" OOo libs should be linked against
msvcr90.dll.

The reason is that Mozilla/SeaMonkey is built with an older compiler
(.NET 2005, IIRC), while OOo itself is built with a newer one (.NET 2008).

So if you say that in an OOo installed from a downloaded installer,
there are *Mozilla* libs (*not* OOo libs!) which are linked against
msvcr90.dll, I'd b somewhat surprised. Do you have an example?

> Most probably an oversight.  The prebuilts are checked into a 
> Hamburg-internal repository, and the accompanying README says "...and 
> upload to ", but this 
> has probably been forgotten the last time they were changed (at 
> , Frank?).

No, I updated the prebuilts at the website when I fixed this bug:
http://tools.openoffice.org/source/browse/tools/www/moz_prebuild/OOo3.2

Ciao
Frank

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Need you help on a string: Panel Deck Tab Bar

[Frank Schoenheit, Sun Microsystems Germany]

Hi Sophie,

> Does one of you recognize his baby and could enlighten us (L10n people 
> in cc of the mail) on what it is supposed to be/do:
> 
> [Panel Deck Tab Bar]
> 
> This string is located in the openoffice/accessibility/source/helper.po.

With the integration CWS slidecopy, a feature became available for
extensions to register arbitrary tool panels, to be displayed in a
per-application Task Pane (see
http://wiki.services.openoffice.org/wiki/Framework/Article/Tool_Panels
for a small documentation, and a Soylent Green screenshot :) ).

Those tool panels are organized in a tool panel deck, which basically is
what you know from Impress' Task Pane in current versions. One possible
layout for this tool panel deck is the "drawers", as shown in the
screenshot at the above side, and as known from Impress' Task Pane.

Another possible layout, which currently is not finalized, and thus not
available in the DEV300 builds, is a "tabbed" layout, where some kind of
tab bar (like in tabbed dialogs) is shown at the right/left hand side of
the tool panel deck, with one tab item per tool panel.

And "Panel Deck Tab Bar" is the Accessibility name for this thing.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Impress   http://graphics.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Working with OOO330 and DEV300

[Frank Schoenheit, Sun Microsystems Germany]

Hi Heiner,

> Lastly: RE will do always complete builds on DEV300 milestones from now 
> on.

Finally! That's good news indeed, thanks a lot for removing this
potential source of subtle errors!

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Impress   http://graphics.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] operator delete mismatch

[Frank Schoenheit, Sun Microsystems Germany]

Hi Terrence,

> A website page about building OOo says that non-product builds are
> used almost exclusively within Sun.  For a long time, I incorrectly
> took that to be a warning that they are hard to accomplish rather than
> merely a description of a regrettable state of affairs.  Perhaps we do
> not want to encourage a non-product build for a newcomer's very first
> attempt, but I could have been finding these assertions long ago.
> Would a change to the website be in order?

Certainly, go ahead.

Ciao
Frank
-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Impress   http://graphics.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] operator delete mismatch

[Frank Schoenheit, Sun Microsystems Germany]

Hi Terrence,

> Since I created issue 110236
>  yesterday, I
> have encountered many occurrences.
> 
> I have some time available.  Do you have any suggestions about what this
> means

usually, it means somebody did something like
  char* foo = new char[n];
  
  delete foo;
  // correct would be: delete[] foo;

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Impress   http://graphics.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Coding St{andards|yle}

[Frank Schoenheit, Sun Microsystems Germany]

Hi Thorsten,

> recently I was idly browsing through commit mails, and noticed two
> patterns that seem to have gotten into wider usage:
> 
>  * prefix abstract classes with an 'I' - presumably not to make it
>look as fashionable as an iPhone, but rather to denote it's an
>'interface' ;)
>  * use of fundamental types like long and int.
> 
> Whereas I think the former is quite sensible (also the added
> SAL_NO_VTABLE), I have some issues with the latter. Are there any
> reasons _in favor_ of that, except for platform apis & the
> occasional loop counter?

(Even the occasional loop counter should probably better be size_t ...)

Without knowing concrete examples, I can only guess what long and int
were used for.
Last time I used them (and your first item makes me suspect it were some
of my recent commit mails which triggered your post) was in a context
where the classes I used forced me to. That is, Rectangle, Size, Point,
and the like, work with "long". So, my client code of those usually
works with longs, too, at least as long as the variables are intended
for a roundtrip back to those classes.

In all other cases, I'd agree that long and int should not be used for
portability reasons.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] question about oDatabaseContext.getElementNames()

[Frank Schoenheit, Sun Microsystems Germany]

Hi Oliver,

> Is it correct, that "oDatabaseContext.getElementNames()" will return the 
> displayed name
> (shown in database brwoser)  and not the "registered Name" shown in Tools - 
> Options ?
> 
> for example the macro below will return "My Database", not "mydatabase"
> 
> 
>   
>   
>   file:///X:/MyDatabase.odb
>   
>   
>   mydatabase
>   
>   
> 

The code for this happen[s/ed] to be a little ... inconsistent. When the
config data is created by OOo itself, then the node name and the
property value are identical. When reading the data, the node name is
taken as registration name. Strictly, this is wrong, of course, but it's
noticed only when the node name and the prop value are not identical.

On the DEV300 code line, this has been fixed - now the property value is
taken as registration name, the node name can be an arbitrary logical
name (preferably something like "org." to ensure uniqueness).

In addition, an interface css.sdb.XDatabaseRegistrations [1] has been
introduced, which hides the configuration data from you, so there is no
need to tamper with it directly (The exception would be an extension
bringing its own configuration data with it, but even here, an on-demand
registration using XDatabaseRegistrations and the new XDeploymentHook
would be possible).

Ciao
Frank

[1]http://hg.services.openoffice.org/DEV300/file/1467f46f8817/offapi/com/sun/star/sdb/XDatabaseRegistrations.idl

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] boost 1.42

[Frank Schoenheit, Sun Microsystems Germany]

Hi Thorsten,

> just playing with a VS8.0 build (visual studio 2005), that according
> to the build guide is still a supported compiler -
> http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Windows_Build_Requirements

I was about to ask "where do you read something about 2005 there?" ...
'til I noticed obo just changed the 2005 into 2008 an hour ago :)

Indeed I think you won't have much fun with 2005 in other places, and
requiring 2008 is reasonable.

> Only that it's falling flat on its face with boost 1.39; upgrading
> gets me a reasonably smooth ride. Should we upgrade wholesale to
> 1.42, or only windows (or even only the 14.00.* compiler)?

If you really want to upgrade this, please do not again introduce a
platform dependency (or even compiler version dependency). Boost
versions were a mess before we went to 1.39, please let's keep the clean
"one version for all" state.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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, not quotable in public :)

> Think about that - do you really think that the probability of such an
> incident is so high that it justifies to abandon the superior bug
> detection abilities that a test with activated debugging code gives to
> us? Should we follow a dogma (in a neutral meaning!) or should we just
> measure the trade-off: by using non-pro builds in QA we lose something
> (100% certainty to test the exact code we deliver to users), but we
> could gain a lot.

Indeed. I surely think it's worth it, and what you told about assertions
in CAT0 tests seems to strengthen this (assuming that most of those
assertions indeed point to bugs).

> A variant of "everybody uses builds that give assertions" could be that
> the QA uses assertion enabled builds for CWS, but for tests on master
> uses pro builds.

kinda like that idea.

> I want to throw in an idea that has been discussed some months ago, just
> to see if this could be a good compromise. As all compromises it has its
> pros and cons. So I would like to encourage you to think about the pros
> as (I'm sure ;-)) you immediately will discover its cons.

Hmm. Okay, trying to focus on the pros ... We have assertion facilities
in each and every build - great! We can enable assertions at a
customer's site - nice for "remote debugging" purpose.

On the other hand ... there's surely cons. Thinking about it, the
changed class layout mentioned by Eike seems to be the only one which
cannot be discussed away, i.e. is not bearable. Would be interesting to
know how many places are affected there.

Other than that, there's just my ... gut feeling that shipping a product
with that much of "diagnostic code" is not good ... but that might be
/me only :)

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

> Okay, perhaps we can agree to strive for this goal first, and postpone
> the rest of the discussion. Perhaps we can try aborting discussions,

Ooops. Should read "aborting assertions", of course :)

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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 'til then.

But first lets get a effectively assertion-free office. Be sure you have
all my support on this (and supposedly Ingrid's and Christian's and
Philipp's as well).

So, where do we start? Beg our managers for 2 weeks for fixing all known
assertion issues in one CWS?

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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, a question which Christian and /me could never reach
consensus about with Stephan), then what you say immediately implies
that we need an additional assertion (OSL_ASSERT_ABORT?), simply
because, as said before, existing assertions in their majority are used
for things other than unrecoverable corrupt internal state.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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 assertions should be "tested with the common tests",
this immediately implies that testtool runs should be done on
non-product builds. Which brings the "QA should use non-products" topic
back onto the plate.

And I continue to think that if we're serious about assertions being a
cheaply available "first line of defense against bugs" (and it seems we
all agreed on that), then non-product builds should get a much higher
standing than they have now - in all departments: engineering, QA,
release engineering.

> Assertions should be visible enough to get reported and rare enough to
> allow usual testing and development on the nonpro builds.

Full agreement.

Still, we need the plan Stephan mentioned ... the plan how to reach
that. And effectively, I don't think we'll get anywhere without a
concentrated effort, much like it was done with warning-free code.

That is, we should dedicate time for making smoketest and cat-0 tests,
at the very least, assertion-free. Ideally, let's make all
testtool-tests assertion-free. Optionally, make API tests and complex
test assertion-free, too (though I think this would not be strictly
necessary in a first run).

Then, let's oblige everybody to use them in their daily work - at least
all developers and all QA engineers.

And finally, let's discuss how this obligation should look like, and if
it can reasonably be enforced by technical means (e.g. by aborting in
non-product builds).

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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 are only "internal state corrupt" messages and should
>   abort
> - everything else is tracing, logging

I'm somewhat unlucky with the terms "tracing" and "logging" ...

I don't want this to be a mere "trace" here: Tracing is used for "Oh, by
the way, user just selected Font X into Device Y", and stuff like that
(try enabling traces in the Ctrl-Shift-Alt-Dialog to see what I mean).
Tracing is *merely* informational, and usually carrying information
which is useful for following the program flow without a debugger. This
is what I would define as tracing.

With this, an OSL_ENSURE is not "tracing", it is an error report: At the
moment of the writing the context, it was assumed some condition is
always true. Over time, as the context evolved, this was violated -
reporting this violation surely is not "tracing" or "logging".

(Whether or not one should try to gracefully handle the violation is
exactly the question which is good for some more religious wars.)


I had hope that we would not need to start the whole discussion about
the diagnostics system, again, but it seems it might be necessary before
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, DBG_ASSERT, OSL_ENSURE, OSL_ASSERT,
OSL_PRECOND, OSL_POSTCOND, and more)
(3) error reports which the program does not survive, in particular in
a product build, i.e. at the customer's machine
(future: OSL_ASSERT_ABORT?)

Whether or not (2) should abort in non-product builds - well, multiple
people here said that they think that this would undermine the
acceptance of non-product builds, both for developers, and for users
brave enough to test developer snapshots as non-product builds.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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 non-informal assertions up to OSL_ASSERT_ABORT. And
>   Frank and Christian should be the first to do that for their
>   assertions, if those are, as they claim, only reporting seriously
>   messed up internal state unlike those chatty noncritical
>   observations us other devs seem to use assertions for.

Hmm, seems I expressed myself wrong somewhere.

I never claimed that my assertions are so serious that they should be
aborts. I claimed that the assertions I write point to a bug, if they
fire. However, I try my very best all the time to nonetheless gracefully
handle the situation, to let the user continue her work, even if not
everything went as expected, internally.

So, this kind of assertions are no traces, since if they fire, they
indicate a bug. Nonetheless, they (usually) should not abort ... (more
on this below)



For the "diagnostics system", and how it could look like:

I strongly agree that having two systems is weird, and they should be
unified. This was consensus everytime we discussed this in the past.

Also, I am fine with introducing assertions which abort when they fail.
Though, I believe they should be used with extreme caution only. There's
a reason why we spent *so much* time with crash reports, and fixing
crashes: In the user's perception, a crash/abort is one of the worst
things which can happen. I'd claim that we, as developers, usually have
more options than "abort", which can lead to a much better user experience.

Ciao
Frank
-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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 that may 
> superficially sound).
> ...
> If common understanding indeed is that OSL/DBG asserts flag situations
> where "[s]omething didn't go the way it was intended/expected" *in the
> sense that it is "a bug,"* then, honestly, for a product like OOo, I
> see absolutely no reason not to abort in such a case.

I intentionally did not want to discuss this in this thread here, we
both know that we have absolutely contrary opinions on this, and it
doesn't really help us solving the current question. So, please let's
leave out that question whether an end user program such as ours is
allowed to crash, if it could prevent this - we won't come to an
agreement on this here and now, as we never did whenever we discussed
that :)

> The thing I would agree on is that there are most probably uses of 
> OSL/DBG asserts in the OOo code base that do not flag bugs in the 
> software itself, but rather flag inappropriate or otherwise interesting 
> events, like unexpected user input or a full disk when the user tries to 
> save a document.  These inappropriate asserts have to be changed to 
> things like OSL_TRACE.

Which again (what a revenant ...) touches the question of available
diagnostics ...

Well, I know for sure that I wrote thousands of assertions in the last
10 years which *do* indicate bugs, and changing them to something like
OSL_TRACE is a no-go for me (since this would downgrade them to purely
informational status).

So, at the moment we have assertions which a) should be traces, really
b) indicate real bugs, but are recoverable (yes!) and c) indicate bugs,
and are unrecoverable.

All of those are currently mapped to a message box, which is the
problem. I suppose a main point where we disagree is how we solve this,
by mapping each and every occurrence to what it really should be.

>  My hope would be that 
> this---trivial---adjustment would happen over time, whenever somebody 
> stumbles over such an inappropriate assert firing.

Yes. I also think that we should let this evolve a little bit. Where we
disagree is that I don't think aborting is an appropriate measure.

> (And, enabling 
> aborting assertions in product builds should seriously only be 
> considered when it is known that there are no obviously inappropriate 
> assertions in the code.  One more reason why for now I am fine with 
> keeping assertions disabled in product builds.)

Yes.

> I assume that software developers strive to produce quality software, 
> that they are intrinsically motivated, and that they are interested in 
> using whatever adequate tools are available to help them.  Like tests, I 
> consider assertions useful tools here.  However, as I outlined in the 
> issue, the current state of assertions in OOo is such that they are not 
> useful, so developers do not consider them an adequate tool, so keep 
> away.  My hope is that once assertions in OOo *are* a useful tool (i.e., 
> once that backdrop of existing assertion noise is weeded out, and each 
> assertion a developer sees fire with high likelihood points to an error 
> in the code she wrote five minutes ago) people will actually use them.

We're on the same track here.

One nit to pick: Changing, hmm, medium level code such as svtools will
always bear the risk that you cannot check *all* existing clients, and
all existing call combinations / code paths. That's simply impossible
with a lot of classes there. So, stumbling over an assertion not
necessarily means you introduced the bug 5 minutes ago. However, it
still means somebody should be *urged* to fix it.

> Of course, what I want to reach with that issue is not reached (and the 
> issue not fixed) by simply letting assertions abort.

Okay, misunderstood this then.

> We need a plan how 
> to reach the desired zero assertion state.  I consciously left it open 
> for now how that plan should look like---I simply do not have the time 
> right now to think about it in the necessary depth.

Well, I read the issue as "the plan is to let assertions abort", which I
think, as said, won't work.

> However, what is my firm belief, is that aborting assertions are the 
> only viable way to ultimately reach---and then keep---the zero assertion 
> state.  I consider this technical approach a beautiful, highly effective 
> measure.

I might change my opinion on this once we have an effectively
assertion-free product. At the moment, we don't have, and we didn't have
back in times where assertions were considered P2 (like: fix
immediately) bugs.

> Much more effective than any social approach, which would be 
> prone to be circumvented, and which we have seen fail for too long by 
> now.  (There are analogies to our earlier warning-free

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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, and leave it to others to fix those? Really?

> I do, however build with DEBUG=true to see assertions.

This will only give you OSL assertions, not the tools-based ones, which
still are the majority. Also, it only gives you the assertions from
files you explicitly compile with this setting - i.e., if you use a
component in a library which you did not compile with debug, and this
component would report client errors via assertions, the you miss those,
too.

> 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 theory, in
practice there are *hundreds* or *thousands* of "assertions" (aka usages
of DBG_*) which do not match the definition. Saying "Assertions should
abort because otherwise they're not assertions" is, sorry, just closing
your eyes against reality.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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 for developer snapshots (perhaps even exclusively).
So, we indeed should keep end users in mind when discussing about
non-product builds.

Ciao
Frank


-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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,
>>   which at least in parts consists of finding bugs.
> 
> Here I strongly disagree. Assertions should be fought before a CWS sees 
> QA.

Sure. And we should not give a CWS to QA which introduced regressions.
Nonetheless, rumors say this happened.

> That's something developers should do. Testers have to test what the 
> customer will get.

Qa engineers, sloppily called "testers" :), have the responsibility to
ensure quality. A means to point out bugs are assertions. So, testers
should use this means, as it helps them doing their job.

I see your "testers should test what the customer gets" point, actually,
that one was always raised whenever we talked about that topic in the past.

See, we had a time where our QA worked on non-product builds (nearly)
exclusively. Still, they found the bugs, and I do not know of any case
where they did *not* find a bug which they would have found in a
product-build.
Still, I know *a lot of* bugs which could have been found if more
people, explicitly including QA, would have used non-product builds. For
instance, one of the stoppers I had for 3.1 would have been found if
anybody would simply have *opened the respective dialog* in a
non-product build, and would have cared for the assertion which
immediately sprung at him. Nobody did - either open the dialog or care
for the assertion, whatever ...

So, the bottom line is: I think the overall gain, when QA would use
non-product builds, is positive: QA would find more bugs than they would
miss.

>>   For OOO320, we stopped providing non-product builds at branch-off day,
>>   which was about half a year before the product was actually released.
>>   During a significant part of this time, there still happened heavy
>>   development on that code line, which is prone to introducing new
>>   assertion failures, going unnoticed in product builds.
> 
> That's not correct. OOO320 started end of September 2009. Branch date 
> was code freeze, afterwards only stopper bugs got accepted.
> We once decided to restrict non-product builds for code lines where 
> active development happens, and I still believe that is a good decision. 
> Release branches as we currently handle them are definitely not the 
> place for "heavy development".

That's my gut feeling only, but: If we would count the lines of code
changed in the OOO320 code line, then I believe the sheer number would
justify the term "heavy development" ...

To back this feeling a little bit: EIS says that there are 113 CWS' with
414 tasks, based on OOO320, targeted for OOo 3.2, in state integrated.
Add a few which were still based on DEV300, in the early days of OOO320.
No matter whether we can agree to call this "heavy development", I'd say
it is enough change happening to justify that we use non-product builds
on this code line.

As for the decision to not use non-product builds on release code lines:

Formerly we had a feature freeze, UI freeze, and code freeze, and the
release line was split at code freeze. Today, we have branch-off, which
is earlier (relative to the intended release time) than code freeze was.
Effectively, this means that a release branch now lives longer than it
did formerly. So, at least *one* fact which might influence such a
decision has changed, since this decision has been made.
So, maybe it is worth re-considering it.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

[dev] Should assertions abort?

[Frank Schoenheit, Sun Microsystems Germany]

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 is reported to the user, usually by a message box.
All of the above applies to non-product builds only, in particular, the
request, as I understand it, is *not* to extend assertions to product
builds.

Since this is a controversial topic, I think we should discuss it in a
wider audience before actually implementing the change - so, let's get
the party started ...


Actually, /me thinks we should *not* change the behavior as suggested.

An ::std::assert, which also aborts when hit, basically means something
like "My state is that inconsistent and unrecoverable, I can't
legitimately continue execution." In such a case, an abort is justified.
(However, in opposite to what seems to be suggested in the issue, this
case also justifies an abort in the product build, i.e. when running at
the customer's machine. Whether this is something a product like ours
should use more than to a negligible extent, is a separate question,
eligible for an even more controversial discussion).

However, OSL_*, and even more DBG_*, are a little bit different. In
particular, I always understood them (and I know a lot of others used
them that way, too) as "Something didn't go the way it was
intended/expected.". This surely indicates a bug which needs attention,
but it does *not necessarily* imply that an abort is the only legitimate
reaction. Contrary, a lot of code tries to get out of that concrete
situation gracefully, continuing with what still can be done. So, an
abort is not justified here, IMO.


When asking for the goal of the change, the issue says

  Without such a strict measure, the many assertions occurring in a run
  of OOo (...) would probably never go a away, and the assertion tool
  would remain practically useless (...)

But making assertions abort instead of "just" being reported would
worsen the situation, IMO: We have that many assertions in non-product
builds because a) too few developers actually use non-product builds
(which means they silently introduce new ones) and b) fixing existing
assertions is not a priority [1].
Aborting in case of an assertion would just make a) much worse. Also, it
would put the burden onto the shoulders of those actually *using* the
non-product builds, not of those *causing* the pain. I.e., it would
punish the "wrong" people.


Having said all this, I'd say the mentioned issue should be a WONTFIX.


The problem which the issue tries to address, however, is still valid,
and highly legitimate, in my opinion. Assertions are a cheap and
already-existing measure to improve our product quality (and in my
personal opinion, both the 3.1 and the 3.2 release have shown that we
should improve here). Still, too few people use non-product builds,
which means new assertions are introduced, which means more people are
scared away from using non-product builds ... which renders assertions
nearly useless.

So, my suggestions would be the following (admittedly, they're more on a
social level, than on a technical one, and thus harder to enforce):

- Developers should use non-product builds *only*. That's a very
  apparent measure, still, a lot of people don't do. If you ask why,
  often the answer is "it's unusable 'cause of the many assertions".
  Hmm?

- 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,
  which at least in parts consists of finding bugs.

- Report assertions as you find them, and fix them as you get the issues
  assigned. Give them high priority, as every assertion might be a
  little effort for you to fix, but it is a lot of paint for a lot of
  other people as long as it is not fixed.

- Get *serious* management backup for the three previous items.
  (That's something which is highly missing since MA left years
  ago :) )

- Provide non-product builds for release code lines, too. At least do so
  much longer than we did with OOO320 (This item strictly applies to
  Sun-internal workflows.):
  For OOO320, we stopped providing non-product builds at branch-off day,
  which was about half a year before the product was actually released.
  During a significant part of this time, there still happened heavy
  development on that code line, which is prone to introducing new
  assertion failures, going unnoticed in product builds.

- Basically: Understand that assertions are not there to hinder your
  work. They exist to help you (at pretty low costs) finding bugs in
  your code, and thus improving our product - which is something we all
  should be interested in, right?

- Consequently, *use* assertions when writing new code. The

Re: [dev] svx module split a little bit more: new editeng module

[Frank Schoenheit, Sun Microsystems Germany]

Hi Mathias,

> starting with the DEV300m72 build there is a new module called "editeng"
> that was split off from svx.
> ...
> This is the second step in the continuing effort to reduce the size of
> the svx module. Though a few unnecessary files could be removed, this
> will not reduce the code size of OOo, but it will create a better code
> separation and it helps people working on the different parts of the svx
> microcosmos as building the whole module will take less time.
> ...
> There's still room for further size reductions that could make working
> on svx code less time consuming.

Thanks for your ongoing efforts here, that's a worthy goal, as indeed
touching SVX code is a PITA right now.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Re: How to ignore implementation details exposed via GlobalEventBroadcaster

[Frank Schoenheit, Sun Microsystems Germany]

Hi Michael,

> actually, no.
> somebody _else_ could also listen for the OnCreate or whatever event and
> retain a hard reference. you cannot know whether this happens.
> if it happens, that hard reference will keep the disposed instance alive.

The cppuhelper implementations for the various
Weak/Agg/Component/Impl/Helper base classes reset their weak adapter
when they're about to be disposed. At least they do so when they're
implicitly disposed by their refcount dropping to zero, but I'd expect
they also do so when explicitly disposed, as long as the base class
methods are called.
>From then on, even if the C++ instance is technically still alive,
querying the adapted object at the adapter will return NULL.

However, for a few combinations of those Weak/Component helper classes
this was prone to race conditions, which has been fixed for 3.2 only.

> so, the fact that a WeakReference can be converted to a hard reference is
> no guarantee that the instance has not been disposed.

Well, it can't at least because even if the object is not disposed when
you retrieve the hard ref, it can be disposed from a concurrent thread
after that point, and before you can use it. So, /me thinks that in
multi-threaded scenarios, *nothing* is a guarantee that an object you
know is not disposed when you attempt to use it.

Ciao
Frank


-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Test Cleanup

[Frank Schoenheit, Sun Microsystems Germany]

Hi Stephan,

> I just embarked on a new project, namely to clean up and consolidate the 
> various test frameworks and corresponding tests available in the OOo 
> build environment.

That#s highly appreciated!

> - The so-called "UNO-API" and "Complex" tests.  These are located in 
> */qa/unoapi and */qa/complex, use OOoRunner from qadevOOo, and can be 
> executed via cwscheckapi or checkapi.

Not sure whether you mix things here, or whether I am simply not
up-to-date: To my knowledge, the complex test cases in */qa/complex are
not (read: cannot be) executed by (cws)checkapi. At least in all modules
I now, they're accompanied by some makefile which allows to invoke them
via "dmake run" or some such.

> ...
> I know that this picture is not perfectly realistic, and that there will 
> be obstacles along the way that require pragmatic workarounds.  Still, I 
> think it is important to know what the ideal should look like, even if 
> you have to deviate from it.

Agreed. I'd already be very happy if only some parts of this could be
achieved.

For the records, since you didn't mention it explicitly, though I think
it's on your list: (Un)Reliability of the tests is another major blocker
for their acceptance currently. Of course, in places where this is due
to the concrete test, not due to the test framework, this is to be
solved one by one only. But we shouldn't forget this important goal: If
tests do not run reliably, then the best test framework of the world
won't get us anywhere.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Adding and removing HIDs

[Frank Schoenheit, Sun Microsystems Germany]

Hi Mathias,

>> Le lundi 23 novembre 2009 à 15:00 +0100, Frank Schoenheit, Sun
>> Microsystems Germany a écrit :
>>> Yes. Don't forget to also add them to /util/hidother.src,
>>> otherwise our automation QA won't like your changes.
>> Hum, I have certainly forgotten that one...
> 
> It's only necessary if your HID is assigned by code, not in an rsc file.

Sure? In my understanding it is necessary for all HIDs which you assign
manually, either in the resources or in the C++ code. It is *not*
necessary for help IDs which are generated automatically, as it happens
for the standard control types in resources.

Finally, hidother.src is for generating the final hid.lst, which is for
the automation to know which "long name" to associate with a certain
numeric ID found at runtime. Without the hidother entry, the test tool
would only know that there's ID "123456", but test script authors cannot
address the respective UI element in their scripts, since there's no
programmatic name associated with 123456.

Ciao
Frank


-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Adding and removing HIDs

[Frank Schoenheit, Sun Microsystems Germany]

Hi Cédric,

> Hum... I have found out that some HID are defined in svx/inc/helpid.hrc
> and svx/source/src/app.hrc. What's the difference between those two?
> Should I add the new HIDs in both files as well?

No, please don't. Put your new ID in the same file as other IDs around
where your new ID lives.

The Help ID system is somewhat ... anachronistic. The basic idea is that
help IDs are globally unique. To ensure this, multiple number circles
are defined (svtools/solar.hrc), and within a module, you usually have
one of those circles.
For various reasons (e.g. code block moves, this applies to
svx/source/src, which formerly lived in an own module), the assignment
between a module and a number circle is not always clear. Also, bit rot
causes problems, since this system is not really maintainable.

A (quite old) documentation about help IDs is at
http://ui.openoffice.org/knowledge/help_ids.html. Not sure it is of much
help nowadays ...

One idea which came up during the new build system prototype is to get
rid of help IDs completely, and replace them with help strings
(something which the SmartID in VCL already can do). I hope we can do
this in a not too distant future, the IDs are a PITA.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Adding and removing HIDs

[Frank Schoenheit, Sun Microsystems Germany]

Hi Cédric,

> For the CWS cbosdo01, I'm adding some HIDs and removing one. What is the
> best way to proceed with those numbers?
> 
> In one case, I only need to add a few HIDs. For the moment, I have added
> them at the end of the block containing the other HID of the dialog: is
> it correct?

Yes. Don't forget to also add them to /util/hidother.src,
otherwise our automation QA won't like your changes.

> In another case, I will need to remove an autocorrection HID (the one
> for the tiny info-dialog) and add another one. Those aren't defined with
> the other HIDs: there is only a start and end there and some offset in
> the code. Should I leave an empty HID (HID_AUTOCORR_HELP_START + 20) and
> add the other one at the end (HID_AUTOCORR_HELP_START + 22)? or should I
> reuse the removed number?

You can reuse it. There's a certain chance that for a while, the control
carrying the new/old ID will direct help requests to the old topic, but
that's only until the help content has been adjusted (which ideally can
happen in your CWS, too).

Ciao
Frank


-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] OO Dialog sizes - MapAppFont

[Frank Schoenheit, Sun Microsystems Germany]

Hi Oliver,

> And how does oo convert from MapAppFonts to pixels ?

css.awt.XUnitConversion should allow this. The existing documentation at
http://api.openoffice.org/docs/common/ref/com/sun/star/awt/XUnitConversion.html
is somewhat sprase, this improved in the 3.2 version, which is not yet
online (but if you have an OOo build somewhere, you'd find it in the odk
module). The main point missing in the online doc is that you need to
pass css.util.MeasureUnits to the various methods. MeasureUnit.APPFONT
probably is what you'd need.

The interface is implemented by all view objects, i.e. the dialog itself
(not the dialog model) and the controls therein (not the control models).

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Build System and visibility

[Frank Schoenheit, Sun Microsystems Germany]

Hi Bjoern

> - map files
> - explicitly setting a compiler flag in the make file
> - XX_DLL_EXPORT/XX_DLL_IMPORT/XX_DLL_PRIVATE and friends
> 
> However, using the XX_DLL_PRIVATE and friends should be "enough for
> everyone", right?

At least we'd need a makefile-clause for setting a default, /me thinks.

For instance, for libs exporting the usual three UNO entry points
component_*, I would like to have a "make everything private" directive,
plus a PUBLIC statement for the three functions.

For other libs, which mainly provide tools for client code, a "make
everything public" directive would be useful.

Which means that you'd still need 2 of the 3 mechanisms, and the only
thing you could spare are the map files. Not sure this would be worth
the effort.

Ciao
Frank
-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Planned Xforms enhancements

[Frank Schoenheit, Sun Microsystems Germany]

Hi Samual,

> It is suggested in other forum posts that no developers are working on
> Xforms

This is true, sadly. There are no concrete plans, not to mention
timelines, to enhance the XForms support.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] build verbosity

[Frank Schoenheit, Sun Microsystems Germany]

Hi Stephan,

> What shell are you using, hombre?  "VERBOSE=TRUE dmake" is ca. as many 
> keystrokes as "dmake verbose=true" (not counting the little finger's 
> duty on the caps key).  ;)

Uhm. Learned something new today ;)

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] build verbosity

[Frank Schoenheit, Sun Microsystems Germany]

Hi Stephan,

> My gut feeling (admittedly) is that it is not too uncommon that some 
> poor (inexperienced) soul pastes some stretch of its (default) build 
> output into a mail to d...@ooo crying for help on why their build break, 
> and the details of the executed command lines do give us clues to 
> understand what is going on/wrong.

Still, I think that what you describe is more an exceptional case,
compared with the hundredths of builds happening all day everywhere. I
completely agree to Thorsten here that the default should care for the
needs of the majority.

Also, people learned (to some extent) to submit their configure switches
together with a build breaker, I think telling them "please come back
with a log of a 'dmake verbose=true'" will work, too.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] build verbosity

[Frank Schoenheit, Sun Microsystems Germany]

Hi Stephan,
> (And having three ways to request something 
> would be worse than having two ways, which already is worse than having 
> only one way. So while we are at it, if you stick with an environment 
> variable, what good is it to additionally have the dmake switch?)

Consistency, for one. See debug/DEBUG, nodebug/NODEBUG, depend/DEPEND,
optimize/OPTIMIZE, dbglevel/DBGLEVEL, product/PRODUCT, ... (more in
settings.mk).

Then, if you really need that output for a given directory, you're
certainly quicker with "dmake verbose=true" than with "export
VERBOSE=TRUE ; dmake ; export VERBOSE=".

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] build verbosity

[Frank Schoenheit, Sun Microsystems Germany]

Hi Stephan,

> Too much trouble.  (Plus, I will definitely not globally set an 
> environment variable "VERBOSE" to anything.  Who knows what strange side 
> effect that would have on completely unrelated programs.  If you had at 
> least named it "OOO_VERBOSE"...)

I think we can easily change this in a next CWS, if there's desire for
it ...

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] build verbosity

[Frank Schoenheit, Sun Microsystems Germany]

Hi Stephan,

> IMO, that should be reason to rather spend energy in improving the 
> precision of the output than in suppressing useful output.

I expected this earlier from you :)

Since our definitions of "useful" differ in this context, I suggest you
set VERBOSE=TRUE in your login script, where I won't, and so we can both
be happy :)

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] build verbosity

[Frank Schoenheit, Sun Microsystems Germany]

Hi Christian,

> The bots should use that - if not, complain at the admins of the
> corresponding bots.

Okay, will have a look on this when I next time have a build problem on
a bot.

> If you need to use some magic environment variable to see why the
> build did broke, the default is wrong. My 0,02€.

Sure. Unfortunately my experience is that with the parallel builds, and
the usually interleaved output of all the "sub builds", it's pretty
difficult to actually find the one line which contains the error. The
more if the error is produced by a tool which does not emit the file it
is working on. Compilers do, but a lot of our self-made tools don't.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] build verbosity

[Frank Schoenheit, Sun Microsystems Germany]

Hi Christian,

> build --html --dontgraboutput
> that way the output will not be interleaved

Hmm, never tried that, and admittedly somehow cannot believe that the
output of the different processes is /not/ interleaved then, but even if
so: You cannot specify this when you start a build on a build bot. My
note was towards those people saying "but I want to see as much output
as possible in the build bot log, to find the errors", which I think
simply does not work: The more verbose the output is, the more difficult
it is to actually find the line which *caused* the error, not just the
error message, simply because all those parallel processes output is mixed.

Ciao
Frank
-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

[dev] reminder: m60 switches to a new boost version

[Frank Schoenheit, Sun Microsystems Germany]

Hi,

as discussed a while ago in d...@ooo, CWS boost134 introduced a recent
boost version (1.39) into the OOo build. If you're building with
system-boost, 1.38 is required, at least.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Issues for CWS printerpullpages

[Frank Schoenheit, Sun Microsystems Germany]

Hi Regina,

> I have written some issues for CWS printerpullpages. But I didn't know 
> which component to use and to whom I should assign it. I guess, that it 
> makes no sense to run through the normal process, because it is a CWS.
> 
> Which component shall I use and to whom shall I assign it? I will change 
>   it then for those already submitted issues, which are not handled yet.

You should use the normal components and owners as you would for issues
found on the MWS. Well, PL, as owner of the CWS, might be able to
dispatch them, so assigning the issues to him is probably also right.
Also, you should set the keyword "new_implementation", to indicate that
the issue is about some new implementation which is not yet available in
MWS. Adding a summary prefix like [CWS printerpullpages] is also a good
habit, to transport the same information as the keyword more obviously.
(In fact, I do not know anybody evaluating the keyword, but the summary
prefix is a very good measure to tell everybody that this is about a CWS
"only".)

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Re: [tools-dev] Re: [dev] Mercurial-Implementation: OOo domain developer public keys

[Frank Schoenheit, Sun Microsystems Germany]

Hi Kendy,

> But anyway, 'trunk' or 'main repository' (for DEV300), 'feature repository' 
> (for OOO300, OOO310, ...),  and 'release repository' (for CWSes) sound best 
> to me.

Assuming you mixed the last two, as chloph outline: I don't think that's
a good idea.

As long as we do not have a *perfect* fitting name, we should stay with
MWS and CWS. All other terms I read so far potentially lead to wrong
associations (e.g. the "feature" problem in a CWS, as mentioned by
Heiner). Sure, you can correct this by explaining the terms, but you'll
always have people not knowing the explanation. I'd prefer having terms
which cannot be understood without explanation over terms which can be
understood the wrong way.

As cloph said, the development model of OOo is pretty unique, so I don't
see a need to forcefully use terms which have a different semantics in
different models.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Moving to bost 1.3?

[Frank Schoenheit, Sun Microsystems Germany]

Hi Eike,

> However, having the boost math lib would be of great benefit for Calc,
> so I strongly vote for possibly the latest version of boost that's
> available, but at least 1.35

I didn't hear any strong objections against using 1.39 (or 1.38 at least
for system-boost), so I think I'll go for that.

I'll leave the task of building boost and linking against it for you,
for a follow-up CWS :)

Ciao
Frank


-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] what configure changes for seamonkey

[Frank Schoenheit, Sun Microsystems Germany]

Hi Regina,

> I have copied seamonkey-1.1.14.source.tar.gz to \moz\download.
> Now I get the error:
> configure: error: Building SeaMonkey is supported with Microsoft Visual 
> Studio .NET 2005 only.

Uhm, yes, that error is because SeaMoney 1.1.x indeed cannot be compiled
with the 2008 compiler.

> Does that mean, that I must use the old precompiled mozilla libraries? 
> Will that work together with cws printerpullpages?

Shame on me! I planned to update
http://tools.openoffice.org/moz_prebuild/680/ when the CWS moz2seamonkey
is integrated, but since this happened during my vacation, I completely
forgot the site update.

Please get your prebuilts from
http://tools.openoffice.org/moz_prebuild/OOo3.2. (no, the old prebuilts
would not work.)

With apologies
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] what configure changes for seamonkey

[Frank Schoenheit, Sun Microsystems Germany]

Hi Regina,

> What changes are needed for my configure call?

configure itself didn't change, you still need --enable-mozilla.

> Do I still need the old mozilla files? Configure complains, that they 
> cannot be found. But perhaps there should be a change somewhere else?
> 
> I have found in the readme of \moz\download, that the file 
> seamonkey-1.1.12-source.tar.gz is needed to be found on 
> http://releases.mozilla.org/pub/mozilla.org/seamonkey/releases/1.1.13
> It is not there, but all old releases are on 
> ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/

Sorry, neither configure's help nor moz/download/readme is up-to-date, I
missed that. This has been fixed with issue 103721.

You need SeaMonkey 1.1.14 from
ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/1.1.14/.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Re: [tools-tinderbox] Moving to bost 1.3?

[Frank Schoenheit, Sun Microsystems Germany]

Hi Rene,

>> command - where's the "no net access from here onwards"-line drawn?
> 
> After the download of the sources.

Then let's define "download the pre-requisites" as a sub task of
"download the sources" :)

Finally, there might be people who could suggest that the pre-req-folder
could be maintained in an SCM, too, though I think this would be
overkill ...

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Re: [porting-dev] Re: [tools-dev] Moving to bost 1.3?

[Frank Schoenheit, Sun Microsystems Germany]

Hi Rene,

> The problem is for people who might want to use system-boost for their
> older distros not having boost >= 1.38. But it might be possible to use
> internal boost for them...

That's why I asked for opinions here. I'd like to have the best possible
compromise between "be up-to-date" and "don't lose any platforms".

So far, nobody stood up saying that an 1.39-requirement is a no-go :)

> BTW, if the problem only is that header (build still running),

no, there are much more of those.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Re: [tools-tinderbox] Moving to bost 1.3?

[Frank Schoenheit, Sun Microsystems Germany]

Hi Rene,

>>> Or invent a nice solution that does auto-downloads, and switch a few
>>> other huge external libs to that (like icu). ;)

Nice idea.

> That would be a problem for some builders unless you don't download it
> when the file is there...

Sure.

> For example, for Debian requiring any form of
> net access on a build is a no-go (and for some libs we have to use the
> internal versions, and be it sometime, in emergency)

What's the definition of "build" here? I.e., between getting the sources
(which most probably requires net access), and issueing the actual build
command - where's the "no net access from here onwards"-line drawn?

> And please also think on people bulding somewhere without net access..

Thorsten's PreReq-Cache could solve this. It would be needed, anyway -
you dont't want to download the complete tarball for each and every
build, if you do multiple of those.

A slight modification of the idea: Instead of getting all the tarballs
from /download, get them from $OOO_PRE_REQUISITES. If they're
not there, bail out (the same way you would bail out today when they're
not in download). This means multiple source trees would share the same
prereq-repository.
Adding an auto-download could be a second step to this.


Anybody volunteering to embark upon this? I'd say this would be a
tremendous improvement, but I myself don't really feel competent to hack
that deep in the OOo build environment.

Ciao
Frank
-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Re: [porting-dev] Re: [tools-dev] Moving to bost 1.3?

[Frank Schoenheit, Sun Microsystems Germany]

Hi Rene,

> So we either need something like  this (when did they change that?):
> [configure patch]

I'd prefer that. Making the source code dependent on different boost
versions (even if it's only about different headers to include) is too
prone to breakage, IMO.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Moving to bost 1.3?

[Frank Schoenheit, Sun Microsystems Germany]

Hi Caolán,

> We've been building with 1.39 for some time without any noticeable
> problems

good to know, thanks.

> except for one little buglet in the function_template header
> where a #if !defined(BOOST_NO_EXCEPTIONS) is in the wrong place.

Yeah, stumbled upon this, too.

Thanks & Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Re: [porting-dev] Re: [tools-dev] Moving to bost 1.3?

[Frank Schoenheit, Sun Microsystems Germany]

Hi Rene,
> The code as-is now will fail to build/work with system-boost < 1.39,
> I assume?

Most probably. Didn't explicitly try that, though.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org