[dev] Re: refactoring OUString

[Stephan Bergmann]

On Fri, Jun 10, 2011 at 6:51 AM, tora - Takamichi Akiyama <
t...@openoffice.org> wrote:

> Sorry, this mail is too long...


No problem, I'll briefly go through your five items one by one:

1. Delegation of the responsibility to choose a type of memory allocator
> To achieve both stability and performance at the same time, I would like to
> propose "Don't do all of it in the SAL", rather "Delegate certain
> responsibility to its users, i.e. programmers."
>
> Who knows the type of life time of data? SAL does? No. The programmers do.
>

Do they?  Theoretically, they do have the information available that is
necessary to choose the most efficient approach that is still correct
(depending on how early data can be destroyed again, whether it needs to be
multi-thread safe or async safe, etc.).

However, in practice, the necessary information is often so big that
programmers will make mistakes, choosing approaches that are incorrect.  If
these are not caught at compile time, and lead to program failure, I think
this is a problem (and history shows it to be a rather severe one).


> 2. Potential dead lock
> A code for crash reporter has a potential, dead lock problem.
> http://hg.services.openoffice.org/DEV300/file/tip/sal/osl/unx/backtrace.c
> Asynchronous-unsafe functions such as fprintf() are used in the context of
> signal handler.
>
> Consider this situation:
> 1. A "Segment violation, aka SEGV" occurs in malloc() or free() due to
> memory corruption. Such a function holds the global mutex lock.
> 2. The first call of fprintf(), it internally calls malloc() to obtain a
> memory area as a text buffer. Then a dead lock occurs.
>
> For that topic, I would be posing a question later.


Yes, OOo's signal handler code is horribly broken.  I do not know whether
its original authors were unaware of the gross violations of correct
programming that are taking place here, but general consensus appears to be
that the code happens to work (by accident, I would say) most of the time,
and sometimes just locks up even worse than the crash that caused the signal
handler to be called in the first place.

Anyway, this should be cleaned up one day (and is indeed a topic for a
thread of its own).


> Please have a look at an additional code fragment in the destructor above:
>
>if ( Applicatoin::IsMemoryCheckRequested() )
>for ( iterator m_vector )  // Turn them to be a trap
>alter_page_attribute( *it,
> NO_READ_ACCESS|NO_WRITE_ACCESS|NO_EXEC );
>
> 1. soffice.bin is invoked with a new command line option such as
> "-memorycheck"
> 2. Applicatoin::IsMemoryCheckRequested() returns TRUE.
> 3. The memory pages being freed turns to be a trap.
> 4. A problematic code mistakenly attempts to read or write data in the
> already-freed-memory-area.
> 5. The trap sets off the alarm and an interruption is sent by the OS.
> 6. A signal handler in the SAL catches the interruption.
> 7. A crash report that reveals the exact location of the code is made.
>
> We have been cultivating thousands of test scenarios for more than a
> decade.
> Just leave the qatesttool running for a day and night with the option
> -memorycheck.
>
>
> 4. Utilizing the cutting-edge technology invented in the 21th century.
>
> solaris$ cat attempt-of-accessing-the-already-freed-memory-area.c
>
> #include 
> int main()
> {
>char *p = (char *) malloc(10);
>free(p);
>*p = 1;
>return 0;
> }
>
> $ cc -g attempt-of-accessing-the-already-freed-memory-area.c
>
> $ LD_PRELOAD=watchmalloc.so.1 MALLOC_DEBUG=WATCH,RW ./a.out
> Trace/Breakpoint Trap (core dumped)
>
> $ dbx ./a.out core
> ...
> program terminated by signal TRAP (write access watchpoint trap)
> Current function is main
>7   *p = 1;
>
> Is it easy enough?
>

Both approaches above (Applicatoin::IsMemoryCheckRequested and watchmalloc)
are good for debugging buggy software, but I do not think they are very good
answers to the question: "When designing classes like OUString etc., how
should efficiency be balanced against safety and maintainability?"

I understand that you argue that efficiency should be a priority, and safety
can be guaranteed (more or less thoroughly) by testing the code with the
mechanisms outlined above.

I rather argue that the abstractions available to the programmers should be
as safe as possible (even if that costs some efficiency), as programmers
will invariably make mistakes, so the potential for mistakes should be
minimized.  Testing code is all well and important (very much so!), but the
tests cannot find all problems (let alone the fact that test coverage for
OOo is still rather small).

This is probably just another facet of the everlasting dispute between the
dynamic and static typing camps.  I confess I am sold on the benefits of
type theory.

5. 99.9% use cases could be the default.
>
[...]

> In the case above, i.e. in the typical, 99.9% code of OpenOffice.org, I
> don't think multithread awareness is required.
>
> Therefore, the current implem

[dev] Re: Build DEV300_m106 on Linux breaks in module vcl

[Stephan Bergmann]

On Tue, May 31, 2011 at 2:26 PM, Simon Wilper wrote:

> syschild.cxx makes use of jvmaccess::VirtualMachine and
> ImplTestJavaException in GetParentWindowHandle.
>
> But actually it should work --without-java since the code passages in
> question are surrounded by #ifdef SOLAR_JAVA.
>
> Maybe I have a look at this when I find the time for it.


Turns out this is caused by changing vcl from the old (solenv/inc based)
build system to the new (solenv/gbuild based) one in one of the most recent
DEV300_m10X versions.  While solenv/inc/*.mk take care to pass -DSOLAR_JAVA
to C/C++ compilers only when appropriate, solenv/gbuild/gbuild.mk bluntly
always includes it in its gb_GLOBALDEFS.

diff --git a/solenv/gbuild/gbuild.mk b/solenv/gbuild/gbuild.mk
>
> --- a/solenv/gbuild/gbuild.mk
>
> +++ b/solenv/gbuild/gbuild.mk
>
> @@ -147,7 +147,6 @@
>
>   -DENABLE_LAYOUT_EXPERIMENTAL=0 \
>
>   -DENABLE_LAYOUT=0 \
>
>   -DOSL_DEBUG_LEVEL=$(gb_DEBUGLEVEL) \
>
> - -DSOLAR_JAVA \
>
>   -DSTLPORT_VERSION=$(STLPORT_VER) \
>
>   -DSUPD=$(UPD) \
>
>   -DVCL \
>
> @@ -179,6 +178,10 @@
>
>
>
>  endif
>
>
>
> +ifeq ($(SOLAR_JAVA),TRUE)
>
> +gb_GLOBALDEFS += -DSOLAR_JAVA
>
> +endif
>
> +
>
>  ifneq ($(strip $(ENABLE_GTK)),)
>
>  gb_GLOBALDEFS += -DENABLE_GTK
>
>  endif
>
>
should fix that.
-- 
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: refactoring OUString

[Stephan Bergmann]

On Thu, Jun 9, 2011 at 9:20 AM, tora - Takamichi Akiyama <
t...@openoffice.org> wrote:

> That is why I would like to encourage programmers to take care of the life
> time of data.
>

First of, I am doubtful that encouraging manual memory management is a good
idea.  Errors in manual memory management probably are the cause for the
vast majority of severe failures in C/C++ programs.  Hence, I would always
try to abstract from actual memory as much as possible.  (Performance
considerations are of course valid, but they must be balanced against safety
and maintainability considerations.)

What you describe with "Slicing cheese and throwing them out at once" can be
done, but I would not want to do it manually.  There are systems more clever
than C++, building on effect types and region-based memory management, that
exploit such optimizations.  But there, it is the language
implementation---and not the programmer writing a program in that
language---that carries out the proof that keeping data in a region of
memory that is discarded wholesale at a certain point in time is sound.

That said, it might work to map your various levels of data---from "data
lasting until the soffice.bin quits" to "data lasting until a current
function call returns"---to different C++ types with appropriate conversion
functions that potentially need to copy data, to statically ensure sound
memory access while on the one hand allowing to exploit optimized memory
management strategies and on the other hand still being safe if data does
escape from its anticipated level.  Would be a nice experiment.

-Stephan
-- 
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: __attribute__((packed)) for enum

[Stephan Bergmann]

On Wed, May 18, 2011 at 3:40 AM, tora - Takamichi Akiyama <
t...@openoffice.org> wrote:

> How big benefits could we get when such structure or class instances are
> produced in large numbers?
>

The "produced in large numbers" (plus "processed in bursts of large chunks,"
I would say) is the crucial point, indeed.  Saving a few bytes here and
there would probably not improve overall OOo performance, that's what I
wanted to say with my response.  But, of course, ultimately, only trying it
out would tell...

-Stephan
-- 
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: __attribute__((packed)) for enum

[Stephan Bergmann]

On Tue, May 17, 2011 at 8:44 PM, tora - Takamichi Akiyama <
t...@openoffice.org> wrote:

> Any thoughts?
>

Binary UNO requires that its enums are of specific size, but that should be
taken care of by the dummy max-value element in each enum.  Likewise for
enums in the C/C++ URE ABI.

Whether smaller enums have positive or negative runtime impact is hard to
tell up front, I would say---and hard to measure, I would guess, as I assume
the impact is negligible overall.  Similarly, I would assume the space
savings to be negligible, too.

-Stephan
-- 
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: DLL rebasing in OOo on Windows

[Stephan Bergmann]

On Thu, May 12, 2011 at 9:37 AM, Tor Lillqvist wrote:

> Is there any public discussion or documentation on the rebasing done at
> various stages in OOo? When building, in postprocess each DLL is rebased so
> that they have unique base addresses, and don't overlap if loaded at these
> addresses. But then in an installer custom action this is reverted (on
> non-server OSes) and each DLL is rebased back to the default 0x1000.
> Why? And what is the intended use case of the rebaseoo and rebasegui
> programs?
>

IIRC, undoing the rebasing during installation was introduced because it
(somewhat non-intuitively) improved cold-start performance.  There also was
a specific reason to not do it on certain Windows versions, but I forgot.
 In any event, Carsten (on cc) should know more.

-Stephan
-- 
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: RuntimeException: [msci_uno bridge error] UNO type of C++ exception unknown

[Stephan Bergmann]

I would first try and see whether some Windows debugger (MS Studio or WinDbg) 
lets you attach to soffice.exe and intercept C++ exceptions of type 
std::bad_alloc.  (Running OOo throws and catches lots of exceptions, so 
intercepting all C++ exceptions might produce too much noise, but it should 
normally not produce any std::bad_alloc ones.)  The stack trace of the throw 
then hopefully gives a clue already, without any additional debug-build-hassle.

-Stephan

On Apr 28, 2011, at 4:56 PM, Grover Blue wrote:
> "perhaps it's necessary to build OOo with debug information first"
> 
> I don't know how to do that, but I'm willing to try with some help.  The only 
> source I could find was for the java libraries.  This is a very critical 
> problem and needs to be resolved.  Too bad there isn't a developer exe 
> release with debugging enabled.
> 
> 
> On Tue, Apr 26, 2011 at 10:36 AM, Michael Stahl  
> wrote:
> On 26/04/2011 15:22, Grover Blue wrote:
> > I have a muti-threaded application that processes document mostly
> > asynchronous.  I synchronize all UnoRuntime.* API calls, but not such
> > calls as setting a table cell's value, etc.  Everything runs fine in
> > development, qa and in a production environment for one our clients.  We
> > have another client, however, where we are experience a complete
> > breakdown.  While processing, we continually get the following
> > exception.  Both clients are running version 3.3 of OpenOffice/UNO.  Has
> > anyone experienced this or is there a way to get more information/debug
> > OpenOffice?
> 
> you could run OOo with the debugger attached, and set a breakpoint on
> thrown exceptions.  but i'm not familiar with windows, and don't know
> whether that would actually work on our release builds.
> perhaps it's necessary to build OOo with debug information first...
> 
> > Here is how OpenOffice is launched from bootstrapconnector:
> > C:\Program Files\OpenOffice.org 3\program\soffice.exe -nologo -nodefault
> > -norestore -nocrashreport -nolockcheck -headless -nofirststartwizard
> > -accept=pipe,name=uno3869894507064209706;urp;
> >
> > Here is the RuntimeException:
> >
> > com.sun.star.uno.RuntimeException: [msci_uno bridge error] UNO type of
> > C++ exception unknown: "std.bad_alloc", RTTI-name=".?AVbad_alloc@std@@"!
> 
> it looks like the original exception on the C++ side is std::bad_alloc.
> this exception is thrown by operator new() when a memory allocation fails.
> there are also lots of places in OOo where this exception is thrown, also
> after checking that some allocation failed.
> 
> perhaps there is a leak somewhere?
> does the OOo process actually use enormous amounts of RAM?
> 
> can you see a problem by exporting the same document that fails to PDF via
> the UI?
-- 
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: Problems building DEV300_m105

[Stephan Bergmann]

On 04/15/11 14:47, Kristján Bjarni Guðmundsson wrote:


OK was able to build pango, with your instructions. However here is the
next problem, I have already dmake and deliver jpeg, so I don't
understand why it can't find the header file:

[ build C   ] svtools/source/filter/jpeg/jpegc
jpegc.c
c:/Backup/OpenOffice/ooo/svtools/source/filter/jpeg/jpegc.c(31) : fatal
error C1083: Cannot open include file: 'jpeglib.h': No such file or
directory
make: ***
[/cygdrive/c/Backup/OpenOffice/ooo/solver/300/wntmsci12.pro/workdir/CObject/svtools/source/filter/jpeg/jpegc.o
]
Error 2
dmake:  Error code 2, while making 'all'

1 module(s):
 svtools
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/Backup/OpenOffice/ooo/svtools/prj


A known problem that has been masterfixed in the meantime.  You should 
"hg pull -u http://hg.services.openoffice.org/DEV300"; to get all the 
DEV300_m105 and DEV300_m106 masterfixes, building should work a little 
better then...


-Stephan
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: How to find out whether the installed OOo is 32- or 64-bit

[Stephan Bergmann]

On 04/11/11 14:42, rony wrote:


On 11.04.2011 13:16, Stephan Bergmann wrote:

On 04/11/11 12:24, rony wrote:

What I would be after would be to get this information at installation
time without any user-interaction (most won't know what would be asked)
in a platform independent manner.

Something equivalent to a hyptohetic "uninfo bitness" returning either
"32", "64" or "32 64" (if a universal binary).


I don't think there is something better than inspecting the binaries
with platform specific tools right now.  Internally, of course, OOo
knows what "platform" (x86 Linux, x64 Linux, x86 Mac OS X, etc.) it
is---this is at least needed when filtering out extension material
that is not appropriate for the given platform.  (Also, the standard
ways to interact with an OOo installation is either via UNO, which
abstracts over those platform details, or through extensions, which
already support platform differences.)

It seems that this is some sort of a chicken and egg problem.

E.g. on MacOSX: if one uses Java to query the configuration via UNO, it
may be the case that 64-bit Java is used instead of a 32-bit Java when
getting in touch with OOo/UNO, which may be a 32-bit (and sometimes in
the future) a 64-bit implementation or both (universal binary).


Right, when you want to use the OOo's URE to set up a UNO connection to 
OOo, you easily run into this chicken/egg problem.



If no crash is to be expected, what configuration service/path should I
use to figure out the architecture/memory model? (Didn't find anything
in the schema "Setup.xcs" nor in "Setup-brand.cxu".) Or with other
words, is there an XML-file that carries this information, and if so
what is its name and element (this would be even easier to analyze
without the need to directyl interact with UNO).


Jochen (now on CC) should know how OOo's extension manager determines 
the current platform.


-Stephan
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: How to find out whether the installed OOo is 32- or 64-bit

[Stephan Bergmann]

On 04/11/11 12:24, rony wrote:

What I would be after would be to get this information at installation
time without any user-interaction (most won't know what would be asked)
in a platform independent manner.

Something equivalent to a hyptohetic "uninfo bitness" returning either
"32", "64" or "32 64" (if a universal binary).


I don't think there is something better than inspecting the binaries 
with platform specific tools right now.  Internally, of course, OOo 
knows what "platform" (x86 Linux, x64 Linux, x86 Mac OS X, etc.) it 
is---this is at least needed when filtering out extension material that 
is not appropriate for the given platform.  (Also, the standard ways to 
interact with an OOo installation is either via UNO, which abstracts 
over those platform details, or through extensions, which already 
support platform differences.)


-Stephan
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: How to find out whether the installed OOo is 32- or 64-bit

[Stephan Bergmann]

On 04/09/11 11:27, Rony G. Flatscher wrote:

for an installation routine it is necessary to determine whether the
installed version of OOo is 32- or 64-bit, as this determines which
libraries and configuration should be installed.

Is there a way to find that out (currently on Linux, but once MacOSX
and/or Windows gain 64-bit versions then the request would be for all
platforms)? If so, what would be the correct means?


Using the "file" command on .../program/soffice.bin (Linux) or 
.../program/soffice (Mac OS X) should mention either "32" or "64" 
somewhere in its output (which is not specified, so this is with a 
little luck---also note that at least Mac OS X could also have universal 
binaries where "file" would mention both "32" and "64").


-Stephan
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: oo 3.3: merging registry values different from oo 32 ?

[Stephan Bergmann]

On 03/31/11 11:51, Oliver Brinzing wrote:

If a value is set multiple times in a single configuration layer (and
all the extensions that are installed, say, per user are in one
configuration layer) it has never been specified which setting wins.


so it was pure luck that it worked till oo 3.2 ?


Yes.

-Stephan
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: oo 3.3: merging registry values different from oo 32 ?

[Stephan Bergmann]

On 03/30/11 18:57, Oliver Brinzing wrote:

if extension A sets this value to "false" and extension B sets same
value to "true", extension B will win, if B is installed after A.


If a value is set multiple times in a single configuration layer (and 
all the extensions that are installed, say, per user are in one 
configuration layer) it has never been specified which setting wins.


-Stephan
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: OOo Build on Win: unopkg prints debug info

[Stephan Bergmann]

On 03/15/11 09:24, Andor E wrote:

I'm building OOo 3.2.1 on Windows. For some reason unopkg and other
command line tools print trace info ("inserting new mapping") to the
console. I'm quite certain, that I didn't create a debug build. I've
even defined an envionment variable DEBUG=false. But it's still printing
these annoying lines. According to my build log the variable
OSL_DEBUG_LEVEL, which supposedly governs the trace output, is set to 0.
How do I disable the trace output?


Setting the DEBUG environment variable to any non-empty value (even 
"false") causes it to take effect (i.e., you do a debug build).


-Stephan
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: Relative URL

[Stephan Bergmann]

On 03/14/11 20:05, Jan wrote:

Writing

file://./theDocument.odt

gives me the error:

URL seems to be an unsupported one


The above is not a relative file URL, it is a file URL with authority 
"." and absolute path "/theDocument.odt".  A file URL with such an 
authority is not supported by OOo.  Rather, ./theDocument.odt is a 
relative URL (note that for proper relative URLs, there is no scheme 
involved, so there are no "relative file URLs.")


-Stephan
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

Re: [dev] MacOSX+OOo3.3+Java: howto setup ?

[Stephan Bergmann]

On 02/15/11 11:54, Rony G. Flatscher wrote:

trying to figure out the setup needs for OOo 3.3 on MacOSX, if wishing
to use Java from the commandline to bootstrap and work with OOo 3.3.


 
should be what you are looking for.  Not sure how well the automatic 
detection of an OOo installation part works on Mac OS X, but you can 
always do that manually via the com.sun.star.lib.loader.unopath Java 
system property.


-Stephan

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

[dev] CWS going into DEV300_m100

[Stephan Bergmann]

 
shows that there are currently six CWS integrated into work-in-progress 
DEV300_m100.


Will CWS sb138 and vcl118, both with nomination dates not coming later 
than the nomination dates of the above CWS, also be integrated into that 
milestone?


-Stephan

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

Re: [dev] OOo Windowsbuild with GNU compilers

[Stephan Bergmann]

On 02/08/11 12:10, Jan wrote:

from the website I understand that the standard Windows build requires
Microsoft compilers. Is there any plan to move this to using GNU
compilers? I am having a really difficult time porting an extension from
Linux to Windows because of MSVC "features".


There is a MinGW port of OOo in the works.  But note that, AFAIU, the 
two different Windows OOo versions (built with MSC vs. MinGW) would not 
be compatible at the level of C++ extension code, so that port would not 
necessarily help you with your specific problem.


-Stephan

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

Re: [dev] Re: Test case - source file correspondence?

[Stephan Bergmann]

On 02/08/11 11:06, Michael Stahl wrote:

if you want to write a test for some UNO component written in Java, you
can also use qadevOOo for that;


qadevOOo is obsolete and only still there so that the old qa/unoapi and 
qa/complex tests continue to work with minimal modifications.  For new 
tests, please use JUnit directly (together with any relevant helper 
code, see 
).


> if what you want to test is not accessible

via UNO, then you have to use JUnit directly (i can imagine that we have
some tests somewhere in OOo that do this, but don't know any particular one).


See, for example, 
. 
 (That these tests are marked as OOO_SUBSEQUENT_TESTS is, IIRC, not 
because they test against a complete OOo installation, but rather 
because in some way they depend on modules further up in the hierarchy.)


-Stephan

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

Re: [dev] Re: [l10n-dev] Dictionaries in OOo 3.3

[Stephan Bergmann]

On 02/01/11 09:21, Ariel Constenla-Haile wrote:

The problem is with the XCU file.
The value of the "Locations" property is written in two lines:

 
 %origin%/es_AR.aff
%origin%/es_AR.dic
 
 

if you change this and write the value in a single line:

 
 %origin%/es_ES.aff %origin%/es_ES.dic
 

the dictionary works.

It looks like something changed in the config. code, sure Stephan can tell if
this is a new feature or a bug.


In the first case, there is whitespace at the end of the list, so the 
new (OOo 3.3) configmgr implementation faithfully reports a third list 
element after that whitespace---an element that happens to be the empty 
string.  The old configmgr implementation behaved differently, so this 
example happened to work there as it probably had been intended by the 
example's author.


For OOo 3.3, an even better way to write string lists is with  
elements, like


%origin%/es_AR.aff%origin%/es_AR.dic

You can sprinkle as much whitespace as you like around the  elements.

-Stephan

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

Re: [dev] OO build with symbols not stripped

[Stephan Bergmann]

On 01/27/11 15:53, Viatcheslav.Sysoltsev wrote:

I am trying to elaborate fix for
http://www.openoffice.org/issues/show_bug.cgi?id=63383 (callouts copy
icorrectly from Draw to Writer) but have some issues with OO build.
I'd like to build OO with symbols to be able to debug it with gdb, but
the symbols get stripped from .so libraries during build.
I'm on opensuse11.1 x86_64, I use

./configure --enable-debug --disable-mozilla --without-junit
--disable-odk --enable-symbols
./bootstrap
source LinuxX86-64Env.Set.sh
export PKGFORMAT=installed
cd instsetoo_native&&  build --all -P4 -- -P4

but nevertheless symbols are not available for gdb. Looking for SwWW in
instsetoo_native/unxlngx6.pro/OpenOffice/installed/install I find it
only libmswordlx.so, which must be product of sw module build,
unfortunately the library is stripped of symbols. What I am doing wrong,
how to say the build system to let the symbols stay?


, 
integrated into DEV300_m77, fixed a bug that installation sets were 
stripped even when configured with --disable-strip-solver (which should 
be implied by --enable-symbols).


-Stephan

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

Re: [dev] Packing custom XCU with custom build

[Stephan Bergmann]

On 01/27/11 10:19, Andor E wrote:

I'm sorry. I should have noted, that I'm building OOo 3.2.1. main.xcd and
postprocess/packregistry seem to be new to OOo 3.3. Is there an equivalent
in OOo 3.2.1?


No, in 3.2.1, you will have to include your individual xcs/xcu files in 
scp2.


-Stephan

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

Re: [dev] Packing custom XCU with custom build

[Stephan Bergmann]

On 01/26/11 16:22, Andor E wrote:

I have created a custom XCU and schema. I want to distribute these files
with my own OOo build. I have modified already a lot of makefiles and .lst
files, but the build script doesn't pack my files. I haven't found any
documentation either.
Which files do I have to change, to add my files to the build process? Do I
have to localize a XCU? What's the meaning of all the constants in
build.lst? I haven't found any reference to the names anywhere else.


The easiest approach might be to add your xcs and xcu files to existing 
directories underneath officecfg/registry/schema and 
officecfg/registry/data, resp., modify the makefile.mk files in those 
directories appropriately (sections XCSFILES and XCUFILES, resp.), and 
have them included in main.xcd in postprocess/packregistry/makefile.mk.


-Stephan

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

Re: [dev] Re: loadComponentFromURL & AttributeError

[Stephan Bergmann]

On 01/20/11 13:43, Sandro wrote:

The simple demo that raises an error is:

import os
import uno
from com.sun.star.beans import PropertyValue

OutOfBoundsException =
uno.getClass("com.sun.star.lang.IndexOutOfBoundsException")


local = uno.getComponentContext()
resolver =
local.ServiceManager.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolv
er", local)
context =
resolver.resolve("uno:socket,host=192.168.5.1,port=8100;urp;StarOffice.Component
Context")
desktop =
context.ServiceManager.createInstanceWithContext("com.sun.star.frame.Desktop",
context)
filename = r"%s/template-debug.odt" % os.getcwd()
print filename, os.path.exists(filename)  # filename exists!!!
document = desktop.loadComponentFromURL(u"file://" +filename ,"_blank", 0, ())


Not having seen the exact text of the error message (i.e., not being 
sure it is a problem of having a "loadComponentFromURL" method available 
to call in the first place vs. a problem "within" the 
loadComponentFromURL call), one idea that comes to mind is that, in the 
failing scenario, u"file://"+filename happens to be no valid URL (e.g., 
filename not starting with a slash; filename containing spaces).


-Stephan

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

Re: [dev] loadComponentFromURL & AttributeError

[Stephan Bergmann]

On 01/20/11 11:25, Sandro wrote:

Hi I'm using uno from python. The script I use is working under Ubuntu 10.04
(OO 3.2) and Windows 2003 +OOo3 but in XP with OOo 3.2 (italian) is failing
with an attribute error on loadComponentFromURL.


Is the "OOo3" you use with Windows 2003 the same version as the OOo 3.2 
you use with XP?



Googling around it seems an error that was present in OOo 3.0.0 due to
URE_BOOTSTRAP, so I tryed it anyhow with no luck (I tried setting
os.environ['URE_BOOTSTRAP'] =
'vnd.sun.star.pathname:c:\\Programmi\\OpenOffice.Org
3\\program\fundamental.ini' both before and after 'import uno') I do see
that even in OOo3.2 URE_BOOTSTRAP is not set when I import uno,
nevertheless, the setting I reported abive does not work.


If there were any problems with URE_BOOTSTRAP and Python on Windows in 
OOo 3.2 (sorry, can't remember), I doubt the effect would have been a 
specific failure of loadComponentFromURL.  Rather, it would probably 
have caused Python UNO to not work at all.


-Stephan

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

Re: [dev] OpenOffice.org 3.4 release and some changes

[Stephan Bergmann]

On 01/19/11 13:58, Martin Hollmichel wrote:

On 01/19/2011 12:51 PM, Stephan Bergmann wrote:

On 01/19/11 12:19, Martin Hollmichel wrote:

* branch off for release will happen after stabilization phase


"Stabilization phase" might be an unlucky term here.  I hope it is not
meant to imply that there are phases where only select CWS (those
stabilizing the to-be-branched-off release) are allowed into the
DEV300 master.

I think this is a "one off" we need to go through for the 3.4 release.


But why is it better to put the 3.4 stabilization phase before 3.4 
branch off, instead of after?


-Stephan

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

Re: [dev] OpenOffice.org 3.4 release and some changes

[Stephan Bergmann]

On 01/19/11 12:19, Martin Hollmichel wrote:

* branch off for release will happen after stabilization phase


"Stabilization phase" might be an unlucky term here.  I hope it is not 
meant to imply that there are phases where only select CWS (those 
stabilizing the to-be-branched-off release) are allowed into the DEV300 
master.


-Stephan

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

Re: [dev] FYI: CWS removetooltypes01

[Stephan Bergmann]

On 01/14/11 12:58, Carsten Driesner wrote:

we are currently working on removing the long deprecated tool types (
e.g. ULONG, USHORT, BYTE, UINT16, UINT32, UINT64, INT16, INT32, INT64,
BOOL, TRUE, FALSE ) to get rid of problems with clashing Windows API
types. There is a never ending story with native Windows code and
precompiled header, although the are prewin and postwin includes.
If you are working on larger code sections please try to use other types
preferring sal types (e.g. sal_uInt8, sal_Int8, sal_Bool,
sal_True/sal_False ...)


(sal_Bool should of course only be used when interfacing API that 
demands it.  Everywhere else, please use plain bool.)


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

Re: [dev] Re: nsFontMetricsXft.cpp:(.text+0x65d): undefined reference to `FcCharSetHasChar'

[Stephan Bergmann]

On 01/06/11 11:45, Michael Stahl wrote:

On 06/01/2011 09:24, Stephan Bergmann wrote:

On 01/06/11 01:57, imacat wrote:

imacat said:

Michael Stahl said:

On 24/12/2010 06:25, imacat wrote:

ERROR: Error 65280 occurred while making /usr/local/src/OOO320_m19/moz/


This is interesting, as just yesterday I tried to build unxlngx6 of a
DEV300_m96 based CWS on a machine which I know is able to build unxlngx6
of DEV300_m95 based CWSs, and failed with some fontconfig symbol problem
when linking svtools.  I did not bother to look into the problem at that
time, and building on another machine succeeded.

But it looks like maybe some necessary setting from the old build system
has not yet been migrated to the new one.


but that is probably a different problem:
imacat seems to be building OOO320_m19; old build system only :)


Ah, right; "top-level make instead of build.pl" had fooled me.

-Stephan

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

[dev] Legal header copyright years

[Stephan Bergmann]

For new source files, I routinely use the legal header templates from 
  and 
.  Both 
still read "Copyright 2000, 2010 Oracle and/or its affiliates."


For new files, should that be changed?  To "Copyright 2000, 2011 Oracle 
and/or its affiliates."?


If yes, will somebody who feels responsible for the above templates 
adapt them accordingly?


-Stephan

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

Re: [dev] Re: nsFontMetricsXft.cpp:(.text+0x65d): undefined reference to `FcCharSetHasChar'

[Stephan Bergmann]

On 01/06/11 01:57, imacat wrote:

imacat said:

Michael Stahl said:

On 24/12/2010 06:25, imacat wrote:

===
ERROR: Error 65280 occurred while making /usr/local/src/OOO320_m19/moz/
rmdir /tmp/rSwBAs6SnU
make: *** [all] Error 1
%
===
% strings /usr/lib/libfontconfig.so.1.3.0 | grep FcCharSetHasChar
FcCharSetHasChar

indeed, it's not clear to me why it doesn't work.
but maybe there is another libfontconfig.so.1 somewhere that gets used
instead...
GNU ld has an option to print the libraries it uses:  -Wl,--trace


 It seems that this is related to the issue that I run the top-level
make instead of build.pl.  --enable-mozilla works if I run build.pl.
Sorry for the bothering and thank you for your help. ^_*'


This is interesting, as just yesterday I tried to build unxlngx6 of a 
DEV300_m96 based CWS on a machine which I know is able to build unxlngx6 
of DEV300_m95 based CWSs, and failed with some fontconfig symbol problem 
when linking svtools.  I did not bother to look into the problem at that 
time, and building on another machine succeeded.


But it looks like maybe some necessary setting from the old build system 
has not yet been migrated to the new one.


-Stephan

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

Re: [dev] Provoke crash reporter on Windows

[Stephan Bergmann]

On 12/17/10 09:28, Andor E wrote:

I'm trying to create my own crash reporter for OOo. My problem is, that I'm
unable to crash OOo in a reliable way on Windows. On Linux it's quite easy
with the kill command. But Windows has no equivalent. So how do I test on
Windows, if the crash reporter is actually working as planned? There must be
a better way, than using defective documents from the issue tracker.


See .

-Stephan

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

Re: [dev] Help required for uno interprocess logging

[Stephan Bergmann]

On 12/15/10 10:15, Sudeep Krishnadasan wrote:

Does the current implementation of uno urp maintain unique identifier
for each method calls?
If no then, could you please share your ideas on, How to maintain
unique id for each method calls processed through uno urp bridge and
log the same on client as well as server side?


First of all, note that 
 will completely 
change the code of the URP implementation.


The URP implementation does not assign unique IDs to calls.  However, if 
you want to attach an incrementing counter to the calls, you obviously 
need to do so consistently (e.g., attaching it to the special 
queryInterface calls on either both ends or on none).  See 
 
for all the special calls involved in URP.


-Stephan

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

Re: [dev] OpenOffice sample TextReplace throws BootstrapException

[Stephan Bergmann]

On 12/11/10 16:52, Ariel Constenla-Haile wrote:

If you are using version 3.4... are you  one of the
developers?


well I don't dare to call myself that, so let's say I'm a community contributor.


What you do is truly great, btw.  Thanks a lot Ariel.

-Stephan

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

Re: [dev] program message: general input/output error

[Stephan Bergmann]

On 12/07/10 22:03, Terrence Enger wrote:

and it does not open the document.  Hacking around with gdb, I see the
program trying to open

 
file:///home/terry/OOo_hacking/localbuild/OpenOffice/installed/install/en-US/openoffice.org/basis3.4/program/libraries/libmswordli.so

which the program resolves as

 
/home/terry/OOo_hacking/localbuild/OpenOffice/installed/install/en-US/openoffice.org/basis3.4/program/libraries/libmswordli.so

which I lack.  Indeed, I lack a file with that basename anywhere
within localbuild/.  Is there anything obvious that I could have done


This might be broken in DEV300_m94 and fixed in DEV300_m95.  (At least, 
an unxlngi6.pro DEV300_m95 build I inspected contained 
openoffice.org/basis3.4/program/libmswordli.so.) 
 appears to 
be relevant, but its commit message contains neither CWS name nor issue 
number.


-Stephan

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

Re: [dev] URGENT: how can i fix this.. ??

[Stephan Bergmann]

On 11/19/10 15:46, kushal likhi wrote:

i built the project on the m83 milestone.
its working very good when building using the m83.
.
but now when shifted to the m93 tree, the services are not getting
registered,, but this issue was fixed by my mentor,, but now i get NO Dialog
box!!! :(
.
what could be the issue???
.
is it something to do with the htmlexservices.cxx file???
.
you can see the code at:
http://hg.services.openoffice.org/cws/impresshtmlex/file/a83d871b92f9/sdext/source/htmlex
.
the interesting files are: htmlexServices.cxx ,,
HTMLExExporterDialog.cxx/hxx
.
i am clueless, and its the last moment problem..
.
does anyone have any idea why their is no dialog??(but i still get a dialog
with my m83build and .pro compile,, but not on m93)
.
i would be helpful if anyone could help me out... have to get it done by
tonight..


Registration of OOo UNO components changed from active to passive 
format, see 
.


For a dynamic library UNO component named foo, this means the following 
changes:


- Remove the definition of the component_writeInfo function that went 
into foo.


- In the source directory where foo is built, add a foo.component file 
that lists the service/singleton implementations contained in foo 
(essentially the same information that the removed component_writeInfo 
would have produced).  For an example, see sfx2/util/sfx.component.


- In the corresponding makefile.mk, add

  ALLTAR : $(MISC)/foo.component

  $(MISC)/foo.component ...

at the end to fill in the missing library name in the .component file; 
again, see sfx2/util/makefile.mk for details ("SHL1TARGETN" might need 
to be adjusted if foo is not defined as SHL1TARGETN but as SHL2TARGETN 
etc. in your makefile.mk).


- Deliver the generated .component file from the module's prj/d.lst; 
again, see sfx2/prj/d.lst.


- Include foo in the my_components list (which is C-locale sorted, btw, 
please keep it that way) in postprocess/packcomponents/makefile.mk.


- Remove any UNO_COMPONENT flag from any definition for foo in scp2.

That's it,
-Stephan

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

Re: [dev] Dev builds m92 and m93 core dumps

[Stephan Bergmann]

On 11/16/10 17:06, Paul Gress wrote:

My platform OS - Solaris Express 11 (b151a)
Hardware - HP Z800 Dual 5590 processors, 24 gig ram

When I start OOO exactly 55 seconds later I get a core dump, leaving the
program alone, non-interactive, it happens by itself. The core dumps
started with m92 on Opensolaris b134. I upgraded today to Solaris
Express 11 and installed m93 and still the same core dump.


pstack on core file"


bash-4.0$ pstack core
core 'core' of 1711: /opt/ooo-dev3/program/soffice.bin -writer
- lwp# 12 / thread# 12 
f8cb69ed xmlFreeNodeList (90ca948, 0) + 9d
f8cb2931 xmlFreeDoc (9295640, fef7, ef6de7c8, f0073906) + 161
f0073921  (efa4d6f0, fec564b4, ef6de7e8, f007a4d0)
f007a4e2  (efa4d6f0, 1, ef6de838, fe499332)
fe499377 __1cEcppuLOWeakObjectHrelease6M_v_ (efa4d6f0, ef439d40,
f002d8dc, f007d3fc) + 53
f007d40e  (efa4d6f0, fab91834, ef6de8a8, f0090752)
f00907cf  (efa7e8d4, fab91834, ef6de8d8, f008af40)
f008af52  (efa7e8d4, 1, ef6de8f8, fe499332)
fe499377 __1cEcppuLOWeakObjectHrelease6M_v_ (efa7e8d4, 11, ef43ce16,
f008be84) + 53
f008be96  (efa7e8d4, ef6de968, 85fb6e8, ef439d40)
ef43a6a1  (ef6de9f0, efa703e0, ef6deacc, ef6dead0)
ef43776c  (ef6deac8, ef896c0c, ef6deacc, ef6dead0)
f724d759  (ef6deac8, efa6d684, ef6deacc, ef6dead0, ef6deb00, 0)
f724e391  (efa6d680, efa6d684, ef6deba0, ef6ded20)
f724f948
__1cHdp_miscUgetOnlineUpdateInfos6FrknDcomDsunEstarDunoJReference4n0ERXComponentContext___rkn0EJReference4n0DKdeploymentRXExtensionManager___rkn0EJReference4n0HbAXUpdateInformationProvider___pknE_STLGvector4n0EJReference4n0HIXPackage___n0MJalloc


"ExtensionManager" and "UpdateInformationProvider" -> indeed appears to 
be a problem with the thread that polls for extension updates, as 
already suggested by Mathias.  Dirk (on cc) might know more.


-Stephan


(ef6ded60, efa6d680, ef6dec90, efa6d684, 0, ef6ded20) + 600
f040505a  (ef6dedc8, efa6d660, ef6dedcc, efe4cf8a)
efe4d108  (efa7d0f4, efa7d0f4, ef6dee48, ef6dee54)
efe38b72  (efa7d0dc, ef6deef7, ef6def14, efe38f45)
efe3911c  (efa7d0dc)
efe41619  (efa7d0dc, ef6defa0, ef6defc8, ef6defa0)
fec0ac87  (85dc2c8, fef7, ef6defe8, feeed61e)
feeed673 _thrp_setup (fea33a40) + 9b
feeed920 _lwp_start (fea33a40, 0, 0, 0, 0, 0)


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

Re: [dev] mercurial help

[Stephan Bergmann]

On 11/16/10 17:00, kushal likhi wrote:

yup connection is slow,, it took days to get the prestiene copy,, so is
there any faster way???


unfortunately not (at least none that I am aware of); also see thread at 



-Stephan

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

Re: [dev] mercurial help

[Stephan Bergmann]

On 11/16/10 15:40, kushal likhi wrote:

when i try to push my updates to the main repository by issuing the command:
hg push ssh://h...@hg.services.openoffice.org/cws/impresshtmlex
then it asked me whether you want to continue connecting,, then i typed
"yes"
.
after that it started to use the network and showed "searching for changes"
.
and it hanged there,,first i thought that its downloading something,, so i
{studied+slept+went to college+gave exam+came back} (total 19 hrs) but it
still was on this state all the time using network.
i tried again, but similar thing.
i double checked the ssh key and .hgrc file, they looked fine.
.
any idea whats happening??


 is at DEV300_m85, 
and there are ca. 2000 changesets between DEV300_m85 and current 
DEV300_m93.  They would all need to be pushed if you updated your local 
repository to DEV300_m93.  Maybe pushing them up your connection indeed 
takes s long?


-Stephan

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

Re: [dev] Dev builds m92 and m93 core dumps

[Stephan Bergmann]

On 11/16/10 00:10, Paul Gress wrote:

On 11/15/10 06:01 PM, Paul Gress wrote:
I should of at least attached the relevant text of the core dump:

8611/12: Incurred fault #6, FLTBOUNDS %pc = 0xF8C869ED
8611/12: siginfo: SIGSEGV SEGV_MAPERR addr=0x0058
8611/12: Received signal #11, SIGSEGV [default]
8611/12: siginfo: SIGSEGV SEGV_MAPERR addr=0x0058


This truss output shows that soffice.bin crashed due to a SEGV.  What 
would be needed to track this down is a stack trace obtained from the 
generated core file.


-Stephan

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

Re: [dev] importing a .docx, assertions raised

[Stephan Bergmann]

On 10/15/10 17:08, Terrence Enger wrote:

Now, I understand that each raised assertion should be filed as an
issue, but nine distinct assertions (some repeated lotsa times) seems
like a bit of a muchness.  Will someone here please tell me to go
ahead?


I would suggest you go ahead anyway (if you have the energy).


(*) Sometimes I generate a backtrace of a raised assertion that I am
 reporting.  Is this helpful?  As I have debugging symbols and am
 running on a system less powerful than the documented minimum, it
 can take quite a while to generate the backtrace.


It probably depends on whether the assertion is reproducible.  If it is 
not, a backtrace might be valuable.


-Stephan

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

Re: [dev] SfxItemPool::Store(): some advice needed

[Stephan Bergmann]

On 10/18/10 14:29, Daniel Rentz wrote:

Am 18.10.2010 13:54, schrieb Stephan Bergmann:

Note that for a given STL container type T the relevant size type is not
std::size_t but T::size_type.


Knowing this, but being curious, is there an STL implementation used in
OOo, where T::size_type is different to std::size_t for any container
type T?


Without actually checking it out:  I don't think so, and I would be 
surprised to learn otherwise.


But still... :)

-Stephan

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

Re: [dev] SfxItemPool::Store(): some advice needed

[Stephan Bergmann]

On 10/13/10 15:35, Michael Stahl wrote:

because the new *pArr is an STL container, this should be a size_t, not an
USHORT.


Note that for a given STL container type T the relevant size type is not 
std::size_t but T::size_type.


-Stephan

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

Re: [dev] subsequenttests

[Stephan Bergmann]

On 09/24/10 13:22, Stephan Bergmann wrote:

- Gregor, please remove the subsequenttests step from the buildbots again.


PING.  (At least OOO330_m9 based builds on Windows-2003 currently 
needlessly go red as they erroneously do the subsequenttests step.)


-Stephan

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

Re: [dev] openoffice 3.2.1 startup problem

[Stephan Bergmann]

On 10/01/10 12:15, vlad f halilov wrote:

That's it http://mha96.ccs.ru/out.jpg

No errors. Just freezed both windows, document and IME ... On my side,
IME status appear in non 'C' locale. In binary distribution not appear
at all. Tested on u4/u7/u8 Solaris 10.


Ah, ok.  Sorry, got no clue (apart from the advice to attach a debugger...)

-Stephan

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

Re: [dev] subsequenttests

[Stephan Bergmann]

On 09/30/10 14:19, Frank Schönheit wrote:

However, if you have a complex test for which you can show that it works
reliably enough on all relevant platforms and on all buildbots so that
it can be executed during every build -- no problem to actually include
that test in every build (i.e., go down the "if there ever crop up new
tests..." route detailed in the OP).


What would be your requirement for "can show"? 10 tests in a row which
don't fail? 100? 1000? On one, two, three, four, five, or six platforms?

In other words: I'd prefer doing it the other way 'round: Include tests
for which we're *very* sure that they work reliably, and later exclude
those for which reality prove us wrong.

Personally, I'd put a large number (but not all) of dbaccess/qa/complex,
forms/qa/integration, and connectivity/qa/complex (the latter only after
the integration of CWS dba34b) into the "reliable" list. At the moment,
I execute all of those manually for each and every CWS, but this is
somewhat unfortunate, given that we (nearly) have a ready infrastructure
to automate this.


I am not better at giving useful numbers here than you or anybody else 
are.  If you want your tests integrated directly in the build, and think 
their failure rate is acceptable, go ahead, put them in the build. 
People will start telling you if your assumption about tolerable failure 
rates matches theirs.  (And if it doesn't, be prepared to remove your 
tests from the build again.  Basically, that's what I've been through 
with integrating the currently existing subsequenttests wholesale into 
the build.)


-Stephan

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

Re: [dev] subsequenttests

[Stephan Bergmann]

On 09/30/10 15:51, Frank Schönheit wrote:

Well, this "the trick is ..." part is exactly why I think that
issueing a statement like "from now on, we do tests for our code"
won't work - this is a complex topic, with a lot of "tricks" to know,
so "Just Do It!" is an approach which simply doesn't work. But okay,
that's a different story.


I beg to differ: If code is not testable, it is not good and needs to
be changed.


You didn't get my point. Writing *good* and *useful* tests needs
education, for most, if not all of us. "Just do it!" won't give you
those tests, but just a pile of frustrated developers.

So, the learning which is needed here (and the "is needed here" is the
part which some of those saying "just do it!" miss) will be on a long
and hard road.

I didn't mean to say we should not take this road. I just wanted to say
(and this was probably the wrong forum here) that words are easy, while
doings are more difficult.


The assumption behind "write new tests" was that people are learning 
while doing.  At least for me, that's always worked out best.  It was 
not meant to imply that writing those tests, especially the first ones, 
is easy.


If you have difficulties getting started, just talk to me, and I'm sure 
we get any initial blockers out of the way.  (Admittedly, I seem to be 
unable to write nice getting-started tutorials...)


-Stephan

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

Re: [dev] openoffice 3.2.1 startup problem

[Stephan Bergmann]

On 10/01/10 10:53, vlad f halilov wrote:

Hello. I have succesfully builded OOo 3.2.1 with  instruction for
Solaris 10 (no any errors) for x86 arch. After selecting any application
(writer, calc etc), it freeze with attached screenshot. But with binary
package (from openoffice.org) all working fine. Locale is ru_RU.UTF-8.
On 'C' locale, all working fine with both (mine and binary) distr's.
Only one different in startup found with cyrillic locale - no 'IME
Status' window in binary version. I found no way to disable 'IME status'
window in my environment, so please ask, which configure keys or patch
used by team for compiling solaris 10 x86 distributive?


Your screenshot (I assume it contained an error box) got stripped from 
the mail -- can you just write down the box's content (translated to 
English, in case it is in Russian)?


Whether and why those IME status windows appear, I must admit I have no 
idea either (I myself notice them sometimes popping up on Solaris Gnome, 
sometimes not).


-Stephan

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

Re: [dev] macro run error

[Stephan Bergmann]

On 09/29/10 22:54, Soohong Min wrote:

I am built Openoffice 3.2.1 and am trying to run it with macro.
BTW, I was in strange situation I cannot understand this.
My issue is that I got error message I run this code.

oUrl = "private:factory/swriter"
--->oDoc = starDeskTop.loadcomponentFromUrl(Url, "_blank", 0, Array())
When my code read loadcomponentFromUrl, it makes error.

'Basic runtime error
An exception occured
Type:com.sun.star.lang.WrappedTargetRuntimeException
Message: exception occured raising singleton

"/singletons/com.sun.star.deployment.thePackageManagerFactory: loading
component library faild:

file:///opt/openoffice.org3/program/../basis-link/program/deploymentlr.uno.so

BTW, I open 'edit' in macro, as I tried to debug it, it works well.
But I tried to run it on command line, I got above error message at
loadcomponentfromUrl.

soffice -invisible "macro:///Standard.Module1.Main"


Strange.  Which platform are you on, and where did you get OOo from? 
(The "lr" in "deploymnetlr.uno.so" indicates a platform, but it is none 
of the "standard" ones.)  What might give a clue is to call


 ldd -r /opt/openoffice.org3/basis-link/program/deploymentlr.uno.so

-Stephan

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

Re: [dev] subsequenttests

[Stephan Bergmann]

On 09/24/10 15:32, Frank Schönheit wrote:

If there ever crop up new tests that do require a complete OOo
installation,


While I agree that the unoapi tests are quite fragile, the current
subsequenttests are more than this. In particular, there are complex
test cases which I'd claim are much more stable. (More precise, I'd
claim this for the complex tests in at least forms and dbaccess, since
we spent significant efforts in the past to actually make them stable
and reliable.)

So, I would be somewhat unhappy to throw all those "they require a
running OOo instance" tests into the same "unreliable" category.


See the list of sporadic failures at the end of 
. 
 Many of them deal with problems during process shut down, and many of 
them are probably generic enough to not only affect qa/unoapi tests, but 
also qa/complex tests.


However, if you have a complex test for which you can show that it works 
reliably enough on all relevant platforms and on all buildbots so that 
it can be executed during every build -- no problem to actually include 
that test in every build (i.e., go down the "if there ever crop up new 
tests..." route detailed in the OP).



Other than that, I'd claim that for a halfway complex implementation,
you pretty early reach a state where you need an UNO infrastructure at
least, and quickly even a running office. So, I don't share your
optimism that new tests can nearly always be written to not require a
running OOo.


The trick is to let writing tests guide you when writing an 
implementation, so that the resulting implementation is indeed (unit) 
testable.  See for example 
 for some food for 
thought.  However, how well this works out for us needs to be seen, 
indeed...



One reason more to keep a subsequenttests infrastructure which can be
run all the time (i.e. excludes unoapi) - we'll need it more sooner than
later, if we take "write tests" serious.


The subsequenttests infrastructure will not go away.  And I urge every 
developer to routinely run subsequenttests for each CWS (just as you 
routinely ran cwscheckapi for each CWS in the past) -- it is just that 
its output is apparently not stable enough for automatic processing.


-Stephan

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

Re: [dev] subsequenttests

[Stephan Bergmann]

On 05/31/10 10:24, Stephan Bergmann wrote:

Just a reminder.  As announced
(<http://www.openoffice.org/servlets/ReadMsg?list=interface-announce&msgNo=1266>
"cwscheckapi replaced with subsequenttests"), subsequenttests is the new
tool to run all kinds of OOo developer tests (that require a complete
installation set to test against), particularly replacing cwscheckapi.

With CWS sb120 integrated in DEV300_m80, the framework and tests will
hopefully be reliable enough for actual use, see
<http://tools.openoffice.org/servlets/ReadMsg?list=tinderbox&msgNo=360>
"new step for buildbots."

Developers are encouraged to run subsequenttests now, similarly to how
they ran cwscheckapi in the past. See the first link above for details.

Due to a code change in CWS sb120, Gregor's buildbot framework will no
longer patch away the subsequenttests step in DEV300_m80, so most of the
buildbots (those running on Gregor's framework) will automatically start
to include that step. There are apparently problems with X11 on some of
the bots (see the second link above), and there might still be sporadic
failures (see
<http://wiki.services.openoffice.org/w/index.php?title=Test_Cleanup#unoapi_Tests_2>),
potentially causing buildbot builds to go red. I leave it up to Gregor
to disable any test steps again that turn out to cause trouble; please
inform him about problems you encounter. (Due to vacation schedules, we
probably won't be able to track down those X11 problems for the next two
weeks.)


Unfortunately it seems impossible to stabilize the old test code and, 
even more so, OOo itself to the point that subsequenttests would be 
reliable enough to routinely run during every build.  Experiments (with 
local machines on CWS sb123 and with buildbots at 
<http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=9754&OpenOnly=false&Section=Tests>) 
show that even if individual machines manage to successfully run 
subsequenttests 50, 60, times in a row, they all do fail sooner or 
later, without pattern (see the lengthy lists at 
<http://wiki.services.openoffice.org/wiki/Test_Cleanup#unoapi_Tests_2>).


The old, existing tests are definitely not useless (they do find errors 
in new code, occasionally).  But they are obviously too fragile to tie 
the decision whether a build succeeded or failed to the random outcome 
of whether the tests succeeded or failed.


Therefore, I propose the following two things:

1  Keep the old tests for manual developer execution.  With CWS sb123, 
they should be in a shape where they mostly work, so that a developer 
could run them to see whether they unearth any problems in newly written 
code.  But, of course, this would occasionally need manual 
interpretation of the test results:  If they fail just once, and 
re-running them succeeds, you probably hit one of those spurious 
failures unrelated to your new code.  If they fail repeatedly, maybe 
even on multiple platforms, it smells like you broke something.  There 
will be a Mechanism A to (manually) execute those tests.


2  Urge developers to write new, solid tests for new code or code under 
maintenance.  These should typically be unit tests (i.e., should not 
require a complete OOo instance), which would have (at least) three a 
advantages over the old, qadevOOo based tests:  They would run quickly, 
they would not suffer from OOo's fragility, and they could be run 
directly within the build process.  There will be a Mechanism B to 
(automatically) execute those tests.


For the Mechanisms A and B:  As long as those new tests are indeed all 
unit tests, Mechanism B is simply to build and execute the tests 
unconditionally from within the build system (as is, for example, 
already done in basegfx/test/).  And that implies that Mechanism A can 
for now simply be the existing subsequenttests tool (which should then 
no longer be included in buildbot scripts, of course; and note that CWS 
sb129 adds a -k switch to subsequenttests, a la make, making it more 
useful with our sporadically failing tests).


If there ever crop up new tests that do require a complete OOo 
installation, we could then shift things as follows:  Use plain 
subsequenttests as (part of) Mechanism B (and add it back to the 
buildbots) and add a switch like --extra to subsequenttests as Mechanism 
A, to run the old tests (whose makefiles would need to be adapted to 
only trigger on something like "$(OOO_SUBSEQUENT_TESTS)"=="extra" 
instead of "$(OOO_SUBSEQUENT_TESTS)"!="").


So, action items:

- Gregor, please remove the subsequenttests step from the buildbots again.

- All developers, write new tests.

-Stephan

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

Re: [dev]Openoffice environment setting

[Stephan Bergmann]

On 09/21/10 18:26, Soohong Min wrote:

But I don't use vanila. Where can I check environment setting for
installing Openoffice intel package?


You need to check with the providers of your distro OOo, how they set it up.

-Stephan

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

Re: [dev]Openoffice environment setting

[Stephan Bergmann]

On 09/21/10 16:24, Soohong Min wrote:

My issue is that I wanna move previous installed Openoffice to other
machine which doesn't have any distribution package for Openoffice.
I could launch it without any error but I tried to start it with
python scritp as follows:


import socket  # only needed on win32-OOo3.0.0
import uno

# get the uno component context from the PyUNO runtime
localContext = uno.getComponentContext()

# create the UnoUrlResolver
resolver = localContext.ServiceManager.createInstanceWithContext(
"com.sun.star.bridge.UnoUrlResolver", 
localContext )

# connect to the running office
ctx = resolver.resolve(
"uno:socket,host=localhost,port=2002;urp;StarOffice.ComponentContext"
)
smgr = ctx.ServiceManager

# get the central desktop object
desktop = smgr.createInstanceWithContext( "com.sun.star.frame.Desktop",ctx)

# access the current writer document
model = desktop.getCurrentComponent()

# access the document's text property
text = model.Text

# create a cursor
cursor = text.createTextCursor()

# insert the text into the document
text.insertString( cursor, "Hello World", 0 )
ctx.ServiceManager


I got error msg at this part:
localContext = uno.getComponentContext()
AttributeError: 'module' object has no attribute 'getComponentContext


If you use a vanilla OOo (i.e., downloaded from openoffice.org), this 
should just work if you run the Python script with the Python 
interpreter bundled in the OOo installation 
(.../openoffice.org3/program/python).


-Stephan

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

Re: [dev] Classpath management in Java UNO extensions

[Stephan Bergmann]

On 09/20/10 15:56, Benson Margulies wrote:

If our UNO extension depends on some additional JAR files, do we need
to manifest them somehow, or just pack them into the OXT?


Yes, sure.  Bundle them in the OXT and put them on the 
META-INF/MANIFEST.MF Class-Path of the OXT's UNO component JAR that nees 
them.


-Stephan

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

Re: [dev]setting URE_BOOTSTRAP

[Stephan Bergmann]

On 09/18/10 01:33, Soohong Min wrote:

I am trying to set URE_BOOTSTRAP as follows:

export 
URE_BOOTSTRA=vnd.sun.star.pathname:/home/openoffice3.2/program/fundamentalrc


Missing a "P"?  The OOo python start script at 
 
only sets URE_BOOTSTRAP if it is unset.



BTW,
After I will check my  URE_BOOTSTRAP with python scripts

print (os.environ['URE_BOOTSTRAP'])
It indicates that
vnd.sun.star.pathname:${exec_prefix}/lib/ooo-3.2/program/fundamentalrc

I don't know why this is happening.

My issue is that I got error message related to LoadComponentFromUrl
Error. So to solve this problem, I tried to set URE_BOOTSTRAP but I
cound not fix it.


There should never be a need to set URE_BOOTSTRAP manually -- a 
correctly set up OOo will take care of that itself.


-Stephan

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

Re: [dev] UniString removal

[Stephan Bergmann]

On 09/18/10 20:48, Caolán McNamara wrote:

On Sat, 2010-09-18 at 19:31 +0200, Bartosz wrote:

At TODO list there is topic about String and UniString removal:
http://wiki.services.openoffice.org/wiki/To-Dos#General_Refactoring_Improvements

I found some declaration of the String, ByteString, UniString at:
http://svn.services.openoffice.org/opengrok/xref/DEV300_m87/tools/inc/tools/string.hxx
Also OString declaration at file:
http://svn.services.openoffice.org/opengrok/xref/DEV300_m87/sal/inc/rtl/string.hxx
and OUString at:
http://svn.services.openoffice.org/opengrok/xref/DEV300_m87/sal/inc/rtl/ustring.hxx

What is the main differents between them and which one is obsolete?


There are basically four string classes

rtl::OString  the favoured class where each unit is 8bit


...and of arbitrary encoding (ISO 8859-1, or UTF-8, or ...)


rtl::OUString the favoured class where each unit is 16bit


... and of fixed UTF-16 encoding


ByteString, deprecated 8bit strings
UniString (alias "String") deprecated 16bit strings

Generally should replace ByteString with rtl::OString and UniString with
rtl::OUString. But also see rtl::OUStringBuffer and rtl::OStringBuffer
when replacing UniString/ByteString as they're often necessary.


And if any constructs cannot be converted easily, it should be discussed 
(at interface-disc...@ooo) whether to enhance the rtl classes.


-Stephan

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

Re: [dev] rtl::OUString has no member named 'toString'

[Stephan Bergmann]

On 09/16/10 15:19, Pavel Laštovička wrote:

On 16.9.10 13:44, Stephan Bergmann wrote:

On 09/16/10 12:35, Pavel Laštovička wrote:

I get these errors during compilation of configmgr with profiling
enabled (-DTIMELOG).
For example:
RTL_LOGFILE_CONTEXT_TRACE1(aLog, "component: %s",
RTL_LOGFILE_OU2A(_aRequest.getComponentName().toString()) );


Which version of OOo, and which file and line exactly?


For example configmgr/source/backend/backendaccess.cxx, line 737.
Version OOO320m19. But the error occurs in more that one file.


Short answer: Use recent code, OOO330_m7 or DEV300_m87.  Longer answer: 
At least in this particular case, it should help to simply drop the 
".toString()".


-Stephan

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

Re: [dev] rtl::OUString has no member named 'toString'

[Stephan Bergmann]

On 09/16/10 12:35, Pavel Laštovička wrote:

I get these errors during compilation of configmgr with profiling
enabled (-DTIMELOG).
For example:
RTL_LOGFILE_CONTEXT_TRACE1(aLog, "component: %s",
RTL_LOGFILE_OU2A(_aRequest.getComponentName().toString()) );


Which version of OOo, and which file and line exactly?

-Stephan

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

Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because

[Stephan Bergmann]

On 09/15/10 08:12, rony wrote:

 administra...@flatscher:~$ ls -alF /home/administrator/.openoffice.org/>  
hadm-ooo.txt

 insgesamt 12
 drwxr-xr-x  3 root  root  4096 2010-09-06 10:04 ./
 drwxr-xr-x 33 administrator administrator 4096 2010-09-14 22:13 ../
 drwx--  3 root  root  4096 2010-09-06 10:04 3/


This is the problem:  First, /home/administrator/.openoffice.org is 
owned by "root" and not writable by anybody else (esp. not 
"administrator").  Second, /home/administrator/.openoffice.org/3 is 
owned by "root" and not even traversable by anybody else (esp. not 
"administrator").


Whatever you did to end up with such a setup, I suggest you

  sudo chown -R administator:administrator 
/home/administrator/.openoffice.org


to clean up the mess.  :)

-Stephan

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

Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because

[Stephan Bergmann]

On 09/14/10 08:21, rony wrote:

The logfile (and a text-file giving information on the system) can be
found at:.


One odd thing in 
 
is that all attempts to access the OOo per-user data in 
/home/administrator/.openoffice.org/3/user fail with EACCESS (Permission 
denied).  It looks like user "administrator" has no rights to access his 
home directory (/home/administrator).  What is the output of "ls -alF 
/home/administrator", "ls -alF /home/administrator/.openoffice.org", "ls 
-alF /home/administrator/.openoffice.org/3", and "ls -alF 
/home/administrator/.openoffice.org/3/user"?


-Stephan

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

Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because

[Stephan Bergmann]

On 09/13/10 15:13, rony wrote:

O.K., I uninstalled everything on this weekend that smelled like Java,
however the behaviour of the Ubuntu-installed OOo did not change, i.e.
OOo could not get started, the error message is just:

 Running soffice from the command line gives the following output on the 
commandline:

 javaldx failed!


So, this happens while no "genuine" (from download.openoffice.org) OOo 
is installed, just the one that comes with Ubuntu?  (Otherwise, it could 
be some unexpected interference between the two installations.)


What might give a clue is to run

  strace -f -o logfile .../soffice

(with "..." replaced with the path to soffice) and make the resulting 
logfile (which can be huge) available.  Strictly speaking, this is 
probably the wrong forum for this problem, as it appears to be specific 
to the Ubuntu-specific OOo, but I might nonetheless find time to have a 
quick glance at the output, to see if something obvious goes wrong.


-Stephan

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

Re: [dev] Passive UNO Component Registration

[Stephan Bergmann]

On 09/08/10 16:04, rony wrote:

Approximately when would you think this infrastructure will be available
(maybe the earliest estimation) ?


 is 
tentatively scheduled for OOo 3.4.


-Stephan

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

[dev] Passive UNO Component Registration

[Stephan Bergmann]

As has already leaked during OOoCon  :)  I am currently working on a 
new, passive way to register UNO components (removing the need for 
component_writeInfo, regcomp, and friends).  See 
 for 
the details.


(While, strictly speaking, this is UNO specific and should thus go to 
d...@udk.openoffice.org, I consider its consequences for all of OOo 
important enough to warrant this wider distribution.)


-Stephan

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

Re: [dev] no module named uno error

[Stephan Bergmann]

On 09/06/10 16:57, Soohong Min wrote:

I installed Openoffice on the arm, beagleboard after crosscompiling.
To use internal python, should I build Openoffice again?


Whether or not OOo's internal python is included is controlled by 
--with-system-python configure option.


-Stephan

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

Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because the UI language cannot be determined !

[Stephan Bergmann]

On 09/06/10 12:39, rony wrote:

On 06.09.2010 11:55, Stephan Bergmann wrote:

On 09/06/10 11:37, Rony G. Flatscher wrote:

After a fresh install of a German Ubuntu-desktop 10.4.1 and starting any
OOo module a popup error comes along informing one that OOo cannot
determine the user-interface language and then aborts.


So that would be the OOo included in the Ubuntu distro, right?

Yes.


Was there any OOo user data left from a previous OOo (probably some 
hidden directory starting with ".o" in the home directory)?


Which OOo version is this, by the way?


Before trying out OOo the first time on that new installation the
headless openjdk got installed (there was no Java installed at all),


OOo without Java should work fine (minus the parts using Java, of 
course), so you might want to check whether OOo starts if you remove 
Java again.


-Stephan

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

Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because the UI language cannot be determined !

[Stephan Bergmann]

On 09/06/10 11:37, Rony G. Flatscher wrote:

After a fresh install of a German Ubuntu-desktop 10.4.1 and starting any
OOo module a popup error comes along informing one that OOo cannot
determine the user-interface language and then aborts.


So that would be the OOo included in the Ubuntu distro, right?  Looks 
completely broken, esp. strange on "a fresh install."  (That "UI 
language cannot be determined" message is somewhat of a red herring, it 
typically means that the OOo installation is so screwed up that starting 
it fails really early, trying to access the first UNO component, which 
happens to be configmgr.)


-Stephan

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

Re: [dev] no module named uno error

[Stephan Bergmann]

On 09/06/10 01:01, Rene Engelhard wrote:

But a "vanilla" OpenOffice.org install doesn't do that. And the only
way (unless you put all the .pys and the needed .so files into pythons
site-packages) way to do that is to include OpenOffice.orgs internal python
copy.


...and actually use it, i.e., call .../openoffice.org3/program/python 
from the OOo installation instead of system python (in case this was not 
obvious).


-Stephan

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

Re: [dev] openoffice building problem

[Stephan Bergmann]

On 09/03/10 08:18, Bartosz wrote:

I have strange build problem with DEV300m87.
Previous revision (DEV300m85) was built without problems, but now at the end of 
compilation I have error after type of command:

  source LinuxX86Env.Set.sh&&  ./bootstrap&&  cd instsetoo_native&&  build --all

At the end of compilation I have following errors (see below).
How I should resolve this kind of errors (there is a huge amount of that kind 
of errors)?


You configured with something like --enable-debug, right?  What 
apparently happens here is the following:  During instsetoo_native, 
certain code that is compiled during the OOo build is executed.  In 
debug mode, some harmless, expected situations within the code (incl. 
the ones listed below) are reported, unfortunately prefixed with 
"ERROR".  Now, the instsetoo_native perl code had a bug (at least, I 
think it is fixed by now, Ingo on cc should know the details) to parse 
the output of the programs it starts for occurrences of "error" etc., 
and fail if it encounters any.


So, in short, you should either update to the latest OOo version (in 
case the bug is indeed already fixed), or not --enable-debug.


-Stephan


**
ERROR: Thread:  1 :Error osl_getAsciiFunctionSymbol: 
/home/a/Pulpit/rozne/dev/openoffice/solver/300/unxlngi6.pro/bin/../lib/javaloader.uno.so:
 undefined symbol: component_canUnload
**

**
ERROR: Thread:  1 :Error osl_getAsciiFunctionSymbol: 
/home/a/Pulpit/rozne/dev/openoffice/solver/300/unxlngi6.pro/bin/../lib/javavm.uno.so:
 undefined symbol: component_getImplementationEnvironmentExt
**

**
ERROR: Thread:  1 :Error osl_getAsciiFunctionSymbol: 
/home/a/Pulpit/rozne/dev/openoffice/solver/300/unxlngi6.pro/bin/../lib/javavm.uno.so:
 undefined symbol: component_canUnload
**

**
ERROR: Thread:  1 :Error osl_loadModule: 
/home/a/Pulpit/rozne/dev/openoffice/solver/300/unxlngi6.pro/lib/libjava_gcc3.so:
 cannot open shared object file: No such file or directory
**

**
ERROR: Thread:  1 :Error osl_loadModule: 
/home/a/Pulpit/rozne/dev/openoffice/solver/300/unxlngi6.pro/lib/libgcc3_java.so:
 cannot open shared object file: No such file or directory
**

**
ERROR: *
**
.. creating log file log_DEV300_en-US.log
.. cleaning the output tree ...

**
ERROR: ERROR: Found an error in the logfile. Packaging failed.
in function: analyze_and_save_logfile
**

**
ERROR: Saved logfile: 
/home/a/Pulpit/rozne/dev/openoffice/instsetoo_native/unxlngi6.pro/OpenOffice/archive/logging/en-US/log_DEV300_en-US.log
**
Thu Sep  2 19:01:47 2010 (03:38 min.)
dmake:  Error code 255, while making 'openoffice_en-US.archive'


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

Re: [dev] Re: Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions

[Stephan Bergmann]

On 08/24/10 13:31, Rene Engelhard wrote:

On Tue, Aug 24, 2010 at 01:19:43PM +0200, Stephan Bergmann wrote:

Please do not put an absolute path into plain OOo's jurt.jar Class-Path.


It's for *Debians* OOo. The path won't change in Debian anyways (and if it did
it would automaticatilly be adapted). I don't think there's a safe way
to detect the problem in "vanilla" OOo.


Your Debian-only fix is of course fine with me.

-Stephan

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

Re: [dev] Re: Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions

[Stephan Bergmann]

On 08/24/10 10:41, Rene Engelhard wrote:

On Tue, Aug 24, 2010 at 10:26:58AM +0200, Rene Engelhard wrote:

On Tue, Aug 24, 2010 at 08:50:13AM +0200, Stephan Bergmann wrote:

The static
NativeLibraryLoader.loadLibrary(PipeConnection.class.getClassLoader(),
"jpipe"); in class com.sun.star.lib.connections.pip.PipeConnection
within jurt.jar effectively depends on finding a jpipe dynamic library
(libjpipe.so on Linux) through the Class-Path in the jurt.jar
META-INF/MANIFEST.MF, "ridl.jar unoloader.jar ../../lib/ ../bin/".


So the symlink is the problem? Grmpf.

Why can't you for one time just handle symlinks correctly


For one, there is no "correct" handling of symlinks.  Sometimes, you 
want to treat them transparently, sometimes not.  And for another, it is 
the Java machinery that threats the symlinks "incorrectly" here, not "us."



Hmm. Or I just "fix" the Class-Path: there.
Stephan, can I just put a /usr/lib/ure/lib there (in addition to ../../lib/)
or will there be other stuff still not working then?


Please do not put an absolute path into plain OOo's jurt.jar Class-Path. 
 (And whether there would "be other stuff still not working" I don't 
know---you would need to try it out.)


-Stephan

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

Re: [dev] Re: Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions

[Stephan Bergmann]

On 08/23/10 14:09, Rene Engelhard wrote:

On Mon, Aug 23, 2010 at 11:42:22AM +0200, Michael Stahl wrote:

i think i remember this error... it is caused by not finding some URE
dynamic libraries, like libjpipe.so.
the Java UNO bridge apparently uses native code via JNI for some things.


Then that is a bug in the bridge or the extension itself IMHO ...


on a Ubuntu box here the libraries seems to be in /usr/lib/ure/lib/libjpipe.so

so try adding "/usr/lib/ure/lib/" to CLASSPATH, see if that helps.


.. because ure-link is exactly what points to that /usr/lib/ure thing.
Anything which assumes that the ure is inside the OOo dir is wrong;
the only valid assumption is that *ure-link* is. That's how the three-layewr
OOo interface was defined.


The static 
NativeLibraryLoader.loadLibrary(PipeConnection.class.getClassLoader(), 
"jpipe"); in class com.sun.star.lib.connections.pip.PipeConnection 
within jurt.jar effectively depends on finding a jpipe dynamic library 
(libjpipe.so on Linux) through the Class-Path in the jurt.jar 
META-INF/MANIFEST.MF, "ridl.jar unoloader.jar ../../lib/ ../bin/".


This works in standard OOo installations, where the jpipe dynamic 
library is found relative to jurt.jar within the URE installation either 
in ../../lib (Unix) or ../bin (Windows).


This fails if you either use a jurt.jar copied elsewhere, or the given 
OOo installation does not preserve the above requirement.


-Stephan

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

Re: [dev] Changed an extension from ".jar" to ".oxt", now extension gets installed but cannot be used ?

[Stephan Bergmann]

On 07/26/10 15:20, TJ Frazier wrote:

On the page
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/File_Format

I added a little description, for a better overview of .oxt files.
However, rony's problem relates to deploying old extensions, which might
need another sentence in the Note in the lead section. Something like,
"For an extension previously deployed as a jar," [if that's a proper
description] "the entire jar should be exported as above." [if that's
the proper solution].


Not sure it is worth to discuss that in the Dev Guide at all.  (And "the 
entire jar should be exported as above" would IMO not help to avoid the 
trap that caught Rony, either.)


-Stephan

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

Re: [dev] Changed an extension from ".jar" to ".oxt", now extension gets installed but cannot be used ?

[Stephan Bergmann]

On 07/25/10 23:24, rony wrote:

Is there something I must also denote in the "description.xml" file to


you need a "META-INF\manifest.xml" where you list all your files, for example:


.. cut (thank you very much for that very helpful snippet!) ...


http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/File_Format


Thank you very much for this link as well!

Here is my current, timid "manifest.xml", which does not cause the
"RegistrationClassName" to be followed:

 
 
  http://openoffice.org/2001/manifest";>

  

 


To avoid a misunderstanding:  You cannot rename 
ScriptProviderForooRex.jar to ScriptProviderForooRex.oxt and include a 
description.xml and META-INF/manifest.xml in that zip.  Instead, you 
need to create a new zip ScriptProviderForooRex.oxt that includes 
ScriptProviderForooRex.jar, description.xml, and META-INF/manifest.xml. 
 Then, a manifest:full-path="ScriptProviderForooRex.jar" should work.


-Stephan

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

Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?

[Stephan Bergmann]

On 07/16/10 15:16, rony wrote:

On 16.07.2010 14:51, Stephan Bergmann wrote:

Can you present the exact failing code here?  What type is the
variable named "right," and how exactly does the (reflective, IIUC)
call to setPropertyValue look like?

Yes, but you need to fasten your seat-belt!
;-)


Sorry, even with your in-depth explanation, I remain clueless of what 
causes your problem.  As you say you have a workaround, maybe we should 
leave this mystery unfathomed...


-Stephan

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

Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?

[Stephan Bergmann]

On 07/16/10 13:48, rony wrote:

On 16.07.2010 08:48, Stephan Bergmann wrote:

On 07/15/10 22:10, Rony G. Flatscher wrote:

today I stumbled over the following interesting (read: time-consuming)
problem: while caching Java objects representing individual UNO_ENUM
values, all of a sudden om.sun.star.lang.DisposedException started to be
thrown. Here is one such received exception message:

  ... getCause(): [com.sun.star.lang.DisposedException:
  java_remote_bridge
  com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f
  is disposed]


That DisposedException had more than likely a different reason.  Java
objects representing UNO enumeration type values are completely
"local" -- none of their methods initiate any URP communication.

This is the use case using the Java bridge, where invocations of UNO
APIs via Java are carried out using Java reflection (this allows me to
basically address UNO typelessly from the perspective of Rexx users):

 * get all the enum values of "com.sun.star.style.ParagraphAdjust"
   and cache them for later use, e.g. the value for "RIGHT" is
   assigned to a local variable named "right",
 * then, later,  an XParagraphCursor is queried for its XPropertySet
   and then this is used to setPropertyValue("ParaAdjust", right).

   It is in this invocation where unexpectedly the above exception is
   thrown.

Now, querying for the enum value "RIGHT" before using it in the
setPropertyValue() works reliably.


Can you present the exact failing code here?  What type is the variable 
named "right," and how exactly does the (reflective, IIUC) call to 
setPropertyValue look like?


The DisposedException indicates either a problem in the bridge (say, it 
is asked to marshal an object of unexpected type, and thus shuts down) 
or in the remote soffice.bin process (it likely crashed).


-Stephan

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

Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?

[Stephan Bergmann]

On 07/15/10 22:10, Rony G. Flatscher wrote:

today I stumbled over the following interesting (read: time-consuming)
problem: while caching Java objects representing individual UNO_ENUM
values, all of a sudden om.sun.star.lang.DisposedException started to be
thrown. Here is one such received exception message:

 ... getCause(): [com.sun.star.lang.DisposedException:
 java_remote_bridge
 com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f
 is disposed]


That DisposedException had more than likely a different reason.  Java 
objects representing UNO enumeration type values are completely "local" 
-- none of their methods initiate any URP communication.


-Stephan

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

Re: [dev] Help running soffice.bin from Python

[Stephan Bergmann]

On 07/10/10 23:07, John Porter Simons wrote:

I'm trying to spawn an OpenOffice subprocess from Python. Rather than
running "soffice" which then runs "soffice.bin" I'm trying to run
"soffice.bin" directly, so I have a convenient handle on its PID.


Note that this is not supported and will generally not work.  The 
soffice script around soffice.bin is there for a reason (various 
reasons, actually).



This works from the terminal:
/usr/lib/openoffice/program/soffice.bin -headless
-accept="socket,port=8100;urp;"

It runs and waits patiently for connections. However when I do the same
thing with Python's subprocess.Popen(), it returns immediately with code 77.

Anyone know what code 77 is? I tried grepping through the source but 77
occurs a whole bunch of times. Anybody know where the error codes are
enumerated?


That is E_FATAL_ERROR, defined in desktop/source/inc/exithelper.hxx and 
used in desktop/source/app/app.cxx.


-Stephan

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

Re: [dev] hg.services.openoffice.org broken

[Stephan Bergmann]

On 07/01/10 14:22, Noel Power wrote:

Maybe I am not subscribed to enough lists but...
On Thu, 2010-07-01 at 10:35 +0200, Stephan Bergmann wrote:

ls
 > hg push ssh://h...@hg.services.openoffice.org/cws/sb127
remote: Received disconnect from 12.184.192.15: 2: fork failed: Resource 
temporarily unavailable

abort: no suitable response from remote hg!

is there any info on when this situation might be resolved?


appears to be working again

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

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

[Stephan Bergmann]

On 07/01/10 14:38, Frank Schönheit wrote:

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?

Sure. For instance nspr4.dll and nss3.dll in an OOo installed from 
OOo_3.2.1_Win_x86_install_en-US.exe downloaded on June 25.


Phh. Indeed: In the RC2 which I have here (and which should be identical
to the final release), nspr4.dll is linked against msvcr90.dll.

The strange thing is: In the respective WNTMSCIruntime.zip, which is
committed to the sun-internal repository (in a module called
moz_prebuild), and used during the build, the nspr4.dll is linked
against msvcr80.dll.

Conclusion: The files which finally appear in the install don't
originate from the location they're expected to. Or I am simply not
up-to-date - perhaps moz_prebuild is not the expected source of those
files anymore.

In any way, that's a question for our release engineering, I'd say.


Maybe caused by RE not doing full builds?

-Stephan

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

Re: [dev] hg.services.openoffice.org broken

[Stephan Bergmann]

On 07/01/10 10:12, Stephan Bergmann wrote:

Browsing there gives

"Internal Server Error

The server encountered an internal error or misconfiguration and was 
unable to complete your request.


Please contact the server administrator, y...@example.com and inform them 
of the time the error occurred, and anything you might have done that 
may have caused the error.


More information about this error may be available in the server error 
log."



I had no success with y...@example.com, so try here instead.  ;)


And it appears not only the web front end is affected, but also

> hg push ssh://h...@hg.services.openoffice.org/cws/sb127
remote: Received disconnect from 12.184.192.15: 2: fork failed: Resource 
temporarily unavailable

abort: no suitable response from remote hg!

-Stephan

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

[dev] hg.services.openoffice.org broken

[Stephan Bergmann]

Browsing there gives

"Internal Server Error

The server encountered an internal error or misconfiguration and was 
unable to complete your request.


Please contact the server administrator, y...@example.com and inform them 
of the time the error occurred, and anything you might have done that 
may have caused the error.


More information about this error may be available in the server error log."


I had no success with y...@example.com, so try here instead.  ;)

-Stephan

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

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

[Stephan Bergmann]

On Jun 30, 2010, at 7:54 PM, Christian Lohmaier wrote:
> On Wed, Jun 30, 2010 at 5:24 PM, Stephan Bergmann
>  wrote:
>> On 06/30/10 17:05, Tor Lillqvist wrote:
>> 
>> Actually generating those prebuilts is something of a black art (esp. on
>> Windows), so it might be hard to trace back why the differences wrt msvcr
>> versions exist.
> 
> Cannot speak for windows build, but "dmake zip" in moz after compiling
> moz will create those zips.
> I'd not call that "black art" :-)

The black art is how to set up a (Hamburg setsolar based) build environment so 
that the prerequisites for building moz are available (which is not normally 
built in the Hamburg setsolar environment, as the prebuilts are used instead) 
and the resulting binaries match the OOo baseline for the respective platform.

-Stephan

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

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

[Stephan Bergmann]

On 06/30/10 17:05, Tor Lillqvist wrote:

I noticed that the prebuilt Mozilla DLLs in the 
http://tools.openoffice.org/moz_prebuild/OOo3.2/WNTMSCIruntime.zip file (linked 
from the http://tools.openoffice.org/moz_prebuild/OOo3.2/ page) differ from the 
ones included with the OOo_3.2.1_Win_x86_install_en-US.exe installer.

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. Is this intentional? Is this set of 
msvcr90.dll-using Mozilla DLLs (and then corresponding headers and import 
library) available prebuilt in similar zip files outside Sun? Is this 
intentional product differentiation or just an oversight?


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?).


Actually generating those prebuilts is something of a black art (esp. on 
Windows), so it might be hard to trace back why the differences wrt 
msvcr versions exist.


-Stephan

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

Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage

[Stephan Bergmann]

On 06/24/10 22:51, Terrence Enger wrote:

This is about a sal_Bool rather than a bool, but I shall raise
the question anyway.

It just happens that I was running OO under gdb, and the
following output had already caught my attention.

Breakpoint 1, connectivity::OSkipDeletedSet::moveAbsolute (this=0xa85faa14, 
_nPos=1, _bRetrieveData=244 'ô') at 
/home/terry/OOo_hacking/DEV300_m83/connectivity/source/commontools/TSkipDeletedSet.cxx:170
170 sal_Bool OSkipDeletedSet::moveAbsolute(sal_Int32 _nPos,sal_Bool 
_bRetrieveData

Is the funny value of _bRetrieveData sufficient grounds to create
an issue?


Technically, it should be OK; a sal_Bool value == 0 represents false, 
while anything != 0 represents true.  However, using anything but 0/1 is 
error-prone and probably dubious, so looking into it would definitely be 
worthwhile.  (There is a slim chance that this is caused by compiler 
optimizations and is thus harmless, or that gdb displays garbage instead 
of the true function arguments, but the values for this and _nPos look 
reasonable enough to let you assume that the value for _bRetrieveData is 
correct also.)


-Stephan

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

Re: [dev] Re: "FASTBOOL macro" vs "bool" - decrease memory usage

[Stephan Bergmann]

On 06/24/10 14:24, Rene Engelhard wrote:

On Thu, Jun 24, 2010 at 02:15:29PM +0200, Michael Stahl wrote:

isn't bool ususally (or at least sometimes) 4 bytes in size?


$ cat test.cxx
#include 

int main() {
printf("%d\n", sizeof(bool));
}
$ g++ -o lala ./test.cxx
$ ./lala
1


sizeof(bool) is implementation-defined, but typically 1.

-Stephan

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

Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage

[Stephan Bergmann]

On 06/24/10 12:42, Niklas Nebel wrote:

On 06/24/10 12:29, Mathias Bauer wrote:

The idea is so good that someone is already working on it. :-)
There is ongoing work to replace a lot of ancient types like BOOL, 
USHORT etc. by sal_... types, with the exception that BOOL/FASTBOOl 
will be replaced by bool.


"BOOL -> bool" will cause problems. Memory usage for "new BOOL[n]", 
mixed use with sal_Bool (pointers, references), the occasional "special" 
value (SfxChildWinInfo::bVisible). Shouldn't we go the safe way and 
change BOOL to sal_Bool instead?


Re memory usage: BOOL[n] and bool[n] would each be n bytes in size, or 
what am I missing?


Re mixed use with sal_Bool: haven't encountered this problem often over 
the last years (and I liberally use bool instead of sal_Bool/BOOL since 
ages) -- also, it might be better to try to adapt the mismatching uses 
of sal_Bool to bool, too, leaving usage of sal_Bool to the only place it 
belongs, C++ UNO.


Re the occasional "special" value: I guess one day we should bite the 
bullet and clean those up for good.


-Stephan

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

Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage

[Stephan Bergmann]

On 06/24/10 11:17, Bartosz wrote:

Maybe we should change it to (or remove this macro):
  typedef bool  FASTBOOL;


Yes, best would certainly be to remove the typedef and change 
occurrences of  FASTBOOL to plain bool (watching out for potential 
misuses that tunnel values other than true/false through a variable of 
type FASTBOOL).


-Stephan

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

Re: [dev] subsequenttests

[Stephan Bergmann]

On 06/07/10 14:14, Mathias Bauer wrote:

On 31.05.2010 10:24, Stephan Bergmann wrote:

Just a reminder.  As announced
(<http://www.openoffice.org/servlets/ReadMsg?list=interface-announce&msgNo=1266> 


"cwscheckapi replaced with subsequenttests"), subsequenttests is the new
tool to run all kinds of OOo developer tests (that require a complete
installation set to test against), particularly replacing cwscheckapi.

With CWS sb120 integrated in DEV300_m80, the framework and tests will
hopefully be reliable enough for actual use, see
<http://tools.openoffice.org/servlets/ReadMsg?list=tinderbox&msgNo=360>
"new step for buildbots."

Developers are encouraged to run subsequenttests now, similarly to how
they ran cwscheckapi in the past. See the first link above for details.

Due to a code change in CWS sb120, Gregor's buildbot framework will no
longer patch away the subsequenttests step in DEV300_m80, so most of the
buildbots (those running on Gregor's framework) will automatically start
to include that step. There are apparently problems with X11 on some of
the bots (see the second link above), and there might still be sporadic
failures (see
<http://wiki.services.openoffice.org/w/index.php?title=Test_Cleanup#unoapi_Tests_2>), 


potentially causing buildbot builds to go red. I leave it up to Gregor
to disable any test steps again that turn out to cause trouble; please
inform him about problems you encounter. (Due to vacation schedules, we
probably won't be able to track down those X11 problems for the next two
weeks.)


As expected, all build bots that don't skip that test, break. Some of 
them, as expected, because of DISPLAY problems, some others because they 
can't generate a PDF file in some of the test (what apparently worked in 
CWS sb120). Do we nevertheless want to keep these tests running on the 
build bots. "Side effects" of this will be that all CWS based on m80 and 
later will have status "red" in EIS.


By now, its probably too late to be able to extract information exactly 
where the tests started to break on the various bots when DEV300_m80 
became available end of May, right?  :(


-Stephan

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

Re: [dev] Re: Build Open office 3.20 on window XP

[Stephan Bergmann]

On 06/22/10 09:31, Bjoern Michaelsen wrote:

Am Mon, 21 Jun 2010 11:59:41 +0200
schrieb Ruediger Timm :


AFAIK tcsh shell is not really supported any more (though it might be
on that 3.2 code base - I just do not remember exactly). Could you
just try using bash instead?


If that is truely the case, we should _really_ make
--with-use-shell=bash the default finally and make it _only_ produce a
bash environment script. Everything else is confusing as hell to
newcomers. Actually, we should change the default by now, regardless of
how well supported tcsh is:

http://qa.openoffice.org/issues/show_bug.cgi?id=112591


See  for 
clarification; --with-use-shell is gone since DEV300_m77, dmake now 
always uses bash; configure still produces to-be-sourced scripts for 
both bash and tcsh, though (but note that these two things are rather 
independent of each other).


-Stephan

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

Re: [dev] Working with OOO330 and DEV300

[Stephan Bergmann]

On 06/18/10 19:41, Jens-Heiner Rechtien wrote:
But wait, what if some OOO330 changesets should not be merged in DEV300? 
These changesets will be either dummy merged* into DEV300 or merged and 
immediately backed out with an inverse patch. Thus *all* OOO330 
changesets will be in DEV300 but a few of them might not have an effect 
on the code line.


*) dummy merge: pull a few changesets and configure in .hgrc
[ui] merge = internal:local
before doing the merge. This way all changes from the pulled changesets 
are discarded but the changesets are still recorded as merged.


Just to be sure:  "Dummy merge" won't work for files added on OOO330.

-Stephan

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

[dev] dropping clipboard tests from smoketestoo_native

[Stephan Bergmann]

Any objections against finally fixing 
 
"smoketestoo_native: Paste Object -> error" for good and removing any 
tests from smoketestoo_native that use the system-wide clipboard (and 
are thus unreliable due to race conditions)?


-Stephan

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

Re: [dev] Re: BigPointerArray, SvPointerArray vs STL containers

[Stephan Bergmann]

On 06/17/10 15:46, Bartosz wrote:

2010/6/16 Eike Rathke wrote:

Hi Bartosz,

On Tuesday, 2010-06-15 09:06:19 +0200, Bartosz wrote:


After replace svArrays by STL containers, in some cases I observed boost of 
performance.

For example:
 for (USHORT i = 0;  i < aEntries.size();  ++i)

Please ensure to adapt also all types where necessary, in this case the
result may even be an endless loop if aEntries happens to contain more
than 64k entries.. instead of   USHORT i   it should be   size_t i


Hi Eike.

I think that if the endless loop didn't exist before SvArrays replace, then
it will not exist after SvReplace.
I think previous code:
USHORT nCnt = aEntries.Count();
USHORT i;
for (i = 0;  i<  nCnt&&   0 == aRes.Len();  ++i)

may also even to endless loop.


No, as SvArrays Count() returns USHORT (IIRC), while std::vector size() 
returns std::vector::size_type, which can be larger than USHORT.  If you 
change the type of aEntries from an SvArray to std::vector, you really 
must change the type of i from USHORT to std::vector::size_type.


-Stephan

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

Re: [dev] subsequenttests

[Stephan Bergmann]

On 05/31/10 16:18, Rene Engelhard wrote:

On Mon, May 31, 2010 at 03:47:00PM +0200, Stephan Bergmann wrote:

svp not possible? The smoketest at least works with it.

No idea what you mean.


SAL_USE_VCLPLUGIN="svp" aka. headless.
As said, works for me for the smoketest in 3.2.x.


Ah---see my response at 
<http://tools.openoffice.org/servlets/ReadMsg?list=tinderbox&msgNo=364>.


-Stephan

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

Re: [dev] subsequenttests

[Stephan Bergmann]

On 05/31/10 15:20, Rene Engelhard wrote:

On Mon, May 31, 2010 at 01:25:26PM +0200, Stephan Bergmann wrote:

On 05/31/10 11:55, Bernd Eilers wrote:
what X Server do the subsequenttests use by the way xvfbd or xvnc or  
something else?
subsequenttests and below sets up nothing.  The started soffice  
instances simply use whatever DISPLAY points to.


svp not possible? The smoketest at least works with it.


No idea what you mean.

-Stephan

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

Re: [dev] subsequenttests

[Stephan Bergmann]

On 05/31/10 11:55, Bernd Eilers wrote:
what X Server do the subsequenttests use by the way xvfbd or xvnc or 
something else?


subsequenttests and below sets up nothing.  The started soffice 
instances simply use whatever DISPLAY points to.


-Stephan

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

Re: [dev] subsequenttests

[Stephan Bergmann]

On 05/31/10 10:37, Rene Engelhard wrote:

On Mon, May 31, 2010 at 10:24:17AM +0200, Stephan Bergmann wrote:
With CWS sb120 integrated in DEV300_m80, the framework and tests will  
hopefully be reliable enough for actual use, see  

[...]
the bots (see the second link above), and there might still be sporadic  
failures (see  
<http://wiki.services.openoffice.org/w/index.php?title=Test_Cleanup#unoapi_Tests_2>), 
potentially causing buildbot builds to go red.  I leave it up to Gregor  


So it's not reliable enough.

to disable any test steps again that turn out to cause trouble; please  
inform him about problems you encounter.  (Due to vacation schedules, we  
probably won't be able to track down those X11 problems for the next two  
weeks.)


How should people getting "accused" of breaking stuff then handle red
tinderboxes where the red status is caused by this?


Nobody gets accused.  Erroneous red statuses, while they admittedly 
suck, are not too uncommon, for various reasons.  People know how to 
handle them (by looking at the logs, finding out what caused the 
breakage, and taking a note in the CWS EIS data in case the cause is 
external to their CWS).


I am all for doing everything to reduce false positives to as low a 
level as practically possible, and I am especially determined to do so 
for the parts "I own."  However, we cannot improve subsequenttests 
without trying it out, in the wild.  We need to balance the value we get 
out of these tests against the annoyances that the false positives cause.


Timing of CWS sb120 hitting the master and me going on two weeks of 
vacation might be a little unfortunate.  That's why I put it into 
Gregor's hands to get that balancing right for now.  But be assured that 
I will evaluate the usefulness of subsequenttests as soon as I return, 
based on any data that has accumulated by then.


-Stephan

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

[dev] subsequenttests

[Stephan Bergmann]

Just a reminder.  As announced 
( 
"cwscheckapi replaced with subsequenttests"), subsequenttests is the new 
tool to run all kinds of OOo developer tests (that require a complete 
installation set to test against), particularly replacing cwscheckapi.


With CWS sb120 integrated in DEV300_m80, the framework and tests will 
hopefully be reliable enough for actual use, see 
 
"new step for buildbots."


Developers are encouraged to run subsequenttests now, similarly to how 
they ran cwscheckapi in the past.  See the first link above for details.


Due to a code change in CWS sb120, Gregor's buildbot framework will no 
longer patch away the subsequenttests step in DEV300_m80, so most of the 
buildbots (those running on Gregor's framework) will automatically start 
to include that step.  There are apparently problems with X11 on some of 
the bots (see the second link above), and there might still be sporadic 
failures (see 
), 
potentially causing buildbot builds to go red.  I leave it up to Gregor 
to disable any test steps again that turn out to cause trouble; please 
inform him about problems you encounter.  (Due to vacation schedules, we 
probably won't be able to track down those X11 problems for the next two 
weeks.)


-Stephan

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

Re: [dev] How to run quickstarter?

[Stephan Bergmann]

On 05/23/10 19:56, Ariel Constenla-Haile wrote:

On Sunday 23 May 2010, 14:15, Terrence Enger wrote:

Uh oh.  This time my attempt to install "only for me" displays a
message box, give or take my retyping, ...

loading component library failed:
   
file:///home/terry/OOo_hacking/localbuild/openoffice.org3/program/../.open

office.org/3/user/uno_packages/cache/uno_packages/giOaFu_/QuickStartFixer_L
inux_x86.oxt/Linux_x86/QuickStartFixer.uno.so

and trying to install "for all users" gives a superficially
similar message.  The named file exists, permissions -rw-r--r--,
282635 bytes.

I am sorry to be a nuisance.  Any further suggestions?  I have a
non-product build with debugging symbols, in case that suggests
any way I can help.


quite strange... it builds (with the OOo SDK build env.) fine and also works 
for me on Fedora and Ubuntu (32 and 64 bits). 


Most probably due to libstlport_gcc.so vs. libstlport_gcc_stldebug.so 
mismatch due to product/non-product mismatch.


-Stephan

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

Re: [dev] Re: [releases] recommended stlport settings?

[Stephan Bergmann]

On 05/10/10 09:59, Stephan Bergmann wrote:

On 04/26/10 10:43, Caolán McNamara wrote:

On Sun, 2010-04-25 at 19:44 +0200, Rene Engelhard wrote:
We can only improve things here when we eventually drop the 
STLport-requirement

(and become URE-incompatible on the affected platforms).


If we continue to build and package into the install sets stlport on
Linux x86, but not actually build OOo itself against it, its quite
likely that stuff will work out ok (i.e. legacy binary x86 extensions
that link against stlport will continue to work) as there's no explicit
use of stl types in the public ure interfaces. Not 100% certain about
that though :-)


I always thought there actually were traces of STLport in the URE ABI, 
in some obscure corner of it.  And I am pretty sure I actually checked 
that, a long time ago.  Anyway, checking on DEV300_m77 unxlngi6, it 
appears there are no such traces, not in the ABI designated by those 
dynamic libraries not listed as "private" in ure/source/README (apart 
from the STLport library itself, of course).


Of course, it turns out that my recent checking was conducted in the 
wrong way (I simply grepped for traces of STLport-exported symbols in 
the mangled C++ symbols exported from the URE API libs).  Looking more 
closely, it turns out that the URE ABI *is* tainted by STLport after all:


Classes cppu::OPropertySetHelper (cppuhelper/propshlp.hxx) and 
cppu::UnoUrlDescriptor and cppu::UnoUrl (both cppuhelper/unourl.hxx) 
each have a std::auto_ptr member and non-inline constructors etc.


(And even if one would argue that those classes are not used in OOo 
extensions---which would probably hold true for the UnoUrl stuff, at 
least---it would still be unsound to recompile URE without STLport: 
Thanks to three layer OOo extracting out URE, multiple office 
installations, old and new, can share a single URE installation, and at 
least OPropertySetHelper is used within non-URE OOo code.  The only 
sound way out of that problem is to change URE incompatibly, which 
brings us back to where we started...)


:(

-Stephan

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

Re: [dev] Re: [releases] recommended stlport settings?

[Stephan Bergmann]

On 04/26/10 10:43, Caolán McNamara wrote:

On Sun, 2010-04-25 at 19:44 +0200, Rene Engelhard wrote:

We can only improve things here when we eventually drop the STLport-requirement
(and become URE-incompatible on the affected platforms).


If we continue to build and package into the install sets stlport on
Linux x86, but not actually build OOo itself against it, its quite
likely that stuff will work out ok (i.e. legacy binary x86 extensions
that link against stlport will continue to work) as there's no explicit
use of stl types in the public ure interfaces. Not 100% certain about
that though :-)


I always thought there actually were traces of STLport in the URE ABI, 
in some obscure corner of it.  And I am pretty sure I actually checked 
that, a long time ago.  Anyway, checking on DEV300_m77 unxlngi6, it 
appears there are no such traces, not in the ABI designated by those 
dynamic libraries not listed as "private" in ure/source/README (apart 
from the STLport library itself, of course).


So, I made a quick hack to verify that not building against our STLport 
would actually work, see patch below.  Some notes:


The hack for now is only for the Hamburg setsolar environment 
(solenv/config/sdev300.ini), configure.in would still need to be 
adapted.  There is a new build environment variable, 
OOO_INCLUDE_STLPORT; for USE_SYSTEM_STL!=YES it controls whether to 
include (and thus build) OOo's STLport library in installation sets 
nonetheless.  (stlport/makefile.mk now only controls whether to build 
STLport, while the new stlport/systemstl/makefile.mk controls whether to 
 copy the stlport/systemstl wrapper files to solver.)


The hack for now is only for unxlngi6.  And at least for Linux, it 
appears, there is not even a need to explicitly link executables that 
can load OOo extensions (uno.bin, soffice.bin) against the STLport 
library, so that legacy extension libraries linking against the STLport 
library can find it:  The Linux dynamic loader apparently uses the 
executable's RPATH, among other places, to locate an extension library's 
dependencies, so finds the STLport library in ure/lib via that.


This sounds promising, I would say.

-Stephan



diff -r 331c22de59dc scp2/source/ooo/makefile.mk
--- a/scp2/source/ooo/makefile.mk   Thu Apr 22 18:47:26 2010 +0200
+++ b/scp2/source/ooo/makefile.mk   Mon May 10 09:35:29 2010 +0200
@@ -123,6 +123,10 @@
 SCPDEFS+=-DUSE_SYSTEM_STL
 .ENDIF
 
+.IF "$(OOO_INCLUDE_STLPORT)" == "TRUE"

+SCPDEFS+=-DOOO_INCLUDE_STLPORT
+.ENDIF
+
 .IF "$(WITH_MOZILLA)" == "NO"
 SCPDEFS+=-DWITHOUT_MOZILLA
 .ENDIF
diff -r 331c22de59dc scp2/source/ooo/ure.scp
--- a/scp2/source/ooo/ure.scp   Thu Apr 22 18:47:26 2010 +0200
+++ b/scp2/source/ooo/ure.scp   Mon May 10 09:35:29 2010 +0200
@@ -842,7 +842,8 @@
 #endif
 
 #if !defined USE_SYSTEM_STL || \

-(defined USE_SYSTEM_STL && defined _C52 && defined IS_LP64)
+(defined USE_SYSTEM_STL && defined _C52 && defined IS_LP64) || \
+defined OOO_INCLUDE_STLPORT
 File gid_File_Dl_Stlport
 TXT_FILE_BODY;
 Dir = SCP2_URE_DL_DIR;
diff -r 331c22de59dc solenv/config/sdev300.ini
--- a/solenv/config/sdev300.ini Thu Apr 22 18:47:26 2010 +0200
+++ b/solenv/config/sdev300.ini Mon May 10 09:35:29 2010 +0200
@@ -631,6 +631,8 @@
SOLAR_OJDK16PATH 
%SOLAR_ENV_ROOT%/openjdk-6-b08-linux-i586
SO_PACK %SOLAR_ENV_ROOT%/pack/%WORK_STAMP%
SRC_ROOT 
%SOLAR_SOURCE_ROOT%/%WORK_STAMP%/ooo%UPDMINOREXT%
+USE_SYSTEM_STL YES
+OOO_INCLUDE_STLPORT TRUE
}
common2
{
diff -r 331c22de59dc stlport/makefile.mk
--- a/stlport/makefile.mk   Thu Apr 22 18:47:26 2010 +0200
+++ b/stlport/makefile.mk   Mon May 10 09:35:29 2010 +0200
@@ -34,29 +34,7 @@
 
 .INCLUDE :	settings.mk
 
-.IF "$(USE_SYSTEM_STL)"=="YES"

-
-.IF "$(OS)"=="SOLARIS" && "$(COM)"!="GCC"
-# System STL when building with SunStudio is just a version of STLport
-# which comes with the compiler
-all:
-   @echo "Nothing to do"
-.ELSE #"$(OS)"=="SOLARIS" && "$(COM)"!="GCC"
-#
-# If you choose to build without stlport, some headers will be used to bring 
the
-# sgi extensions into the std namespace:
-$(INCCOM)$/stlport$/functional \
-$(INCCOM)$/stlport$/hash_map \
-$(INCCOM)$/stlport$/hash_set \
-$(INCCOM)$/stlport$/numeric \
-$(INCCOM)$/stlport$/slist \
-$(INCCOM)$/stlport$/rope \
-$(INCCOM)$/stlport$/vector: systemstl$/$$(@:f)
-$(MKDIRHIER) $(@:d)
-$(COPY) $< $@
-.ENDIF #"$(OS)"=="SOLARIS" && "$(COM)"!="GCC"
-
-.ELSE # "$(USE_SYSTEM_STL)"
+.IF "$(USE_SYSTEM_STL)" != "YES" || "$(OOO_INCLUDE_STLPORT)" == "TRUE"
 
 # --- Files 

 .EXPORT : CC CXX
@@ -161,12 +139,14 @@
 BUILD_FLAGS=-f sunpro6.mak
 .ENDIF # "$(CCNUMVER)">="00050008"
 
-OUT2INC= \

-stlport$/SC5$/*.SUNWCCh
+.IF "$(USE_SYSTEM_STL)" != "YES"
+OUT2INC = stlport$/SC5$/*.SUNWCCh
+.END
 .ENDIF
 
-OUTDIR2INC= \

-stlport
+