Re: [dev] Fwd: DEV300_m29/solver/300/unxlngi6.pro/inc/com/sun/star/uno/Any.hxx:268
On Thu, 2008-08-21 at 17:14 +0900, Hung Nguyen Vu wrote: Sorry for cross-posting but I seems that I have asked in a wrong mailing list. So I forward this email. When I compile DEV300_m29 with dmake, I get the following *warning*: /home/vuhung/public_html/foss/src/DEV300_m29/solver/300/ unxlngi6.pro/inc/com/sun/star/uno/Any.hxx:268: warning: lowering visibility of 'sal_Bool com::sun::star::uno::operator==(const com::sun::star::uno::Any, const C) [with C = bool]' to match its type Is that safe to ignore the warning? Basically yes, it is safe to ignore the warning. What is your compiler version, i.e. gcc -v. Some various vendors gcc versions between about 4.1.X and 4.3.0 had various slightly different experimental visibility features in them. One of them was sort of an attempt (IIUC) to make visibility markup a sort of C++ language extension and so giving these sort of warnings when (what was felt to be) logical inconsistencies in markup was detected Now in gcc 4.3.0 things have settled down visibility-wise and such a compiler shouldn't warn about this. *some* gcc variant's visibility stuff doesn't always work right, and can cause horrific hard-to-find crashes. But I think that if your compiler gets past the configure tests for common visibility brokenness then you should be safe regardless of those warnings. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Fwd: DEV300_m29/solver/300/unxlngi6.pro/inc/com/sun/star/uno/Any.hxx:268
On Thu, 2008-08-21 at 17:34 +0900, Hung Nguyen Vu wrote: Should I upgrade my gcc? What version of gcc is recommended for building OOo 3? Those actual warnings are basically spurious, ignore them. But, I know that your particular compiler, given as it is equivalent to the RHEL-5 gcc, actually probably *does* has a bug with visibility which IIRC may cause OOo to crash when it loads some old .sdw files, the workaround it to disable visibility or to apply the openoffice.org.2.0.3-dangerousvisibility.patch patch found in the RHEL-4/CentOS openoffice.org src.rpm. It's pretty uncommon, but it can happen. If you are just building OOo for hacking around with, then I wouldn't bother changing your compiler for it. I don't think I've met a compiler yet that doesn't have *some* bug that has affected openoffice.org in some way:-), but I'm pretty happy with gcc 4.3.0/4.3.1 whose only known bug that has affected me is with -fasynchronous-unwind-tables on i386 which isn't enabled by default on that architecture anyway. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Fwd: DEV300_m29/solver/300/unxlngi6.pro/inc/com/sun/star/uno/Any.hxx:268
On Thu, 2008-08-21 at 22:17 +0900, Hung Nguyen Vu wrote: Where is the patch or src.rpm? http://cvs.fedora.redhat.com/viewvc/devel/openoffice.org/openoffice.org.2.0.3-ooo66018.cppuhelper.dangerousvisibility.patch?hideattic=0revision=1.2view=markup As you recomended,I am compiling gcc 4.3.1 on my machine which will keep me busy for a while until I get back. Well, personally I'd recommend just building it with what you've got and worry about the visibility bug if you ever actually encounter the crash :-) C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] scp2 PATCH flags for OOo 3.0.1
On Wed, 2008-08-13 at 11:02 +0200, Stephan Bergmann wrote: Please all remember to appropriately set PATCH flags in scp2 What this means, how to know what to do, and why might be clear inside Hamburg, but not for external developers. Probably best to give some concrete examples. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Debugging OOo
On Wed, 2008-08-13 at 02:11 +0200, Michael Strobel wrote: Hi All, Adding debug symbols to certain modules of OOo would satisfiy my needs. If you configure with --enable-symbols OOo is built with -g which is sufficient to debug it. Alternatively you can e.g. just whack export ARCH_FLAGS=-g and rebuild a module or two. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] checking whether the C compiler works... configure: error: cannot run C compiled programs.
On Tue, 2008-08-05 at 11:57 +0800, JiangChuang wrote: Dear everyone, I'm building OpenOffice.org(OOH680_m12) for the platform of ARM on the ScratchBox environment. I've got the following error message: /home/arm/ooo_OOH680_m12_src/libxml2 - See `config.log' for more details. dmake: Error code 1, while making 'unxlngr.pro/misc/build/so_configured_so_libxml2' ---* tg_merge.mk *--- sb_gcc_wrapper (sb_gcc_wrapper): sb_gcc_wrapper cannot be recognized Maybe you are trying to run a compiler of a wrong architecture? [sbox-DIABLO_ARMEL: ~] I'm not really familiar with the scratchbox environment nor with your own environment to know what *should* happen, but these all look like generic errors, and not specific to OOo at all. You need to check the config.log in libxml2/unxlngr.pro/... and see the invocation of gcc used there, and see exactly why it failed to create a a.out that ran. And Maybe you are trying to run a compiler of a wrong architecture? looks like something to check out. Does even hello world work in this env ? With scratchbox (though, I don't know if anyone has even built OOo with scratchbox before, so this may be an ambitious build) if I understand correctly, the x86 hosted cross-compiler (as gcc) should create arm output, but any arm binaries executed from the scratchbox environment should get run magically by qemu so that executing them works fine. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Error message for the platform of ARM on the scratchbox environment
On Mon, 2008-08-04 at 13:08 +0800, JiangChuang wrote: Hi, everyone, I'm ChuangJiang and from Beijing RedFlag2000 Chinese CO. LTD..I'm building OpenOffice.org(OOH680_m12) for the platform of ARM on the ScratchBox environment. And I have a problem and ask you for help. Building the module of sal, I've get the following error messages: Inconsistency detected by ld.so: ../sysdeps/unix/sysv/linux/dl-origin.c: 48: _dl_get_origin: Assertion `linkval[0] == '/'' failed! I think I recognize this. This is actually not specific to ARM at all, just a generic problem with the $ORIGIN linker option with a very recent glibc which I'm told is now fixed again in glibc. You'll find that e.g. running typeconfig will fail but /path/to/typesconfig will work. See e.g. https://bugzilla.redhat.com/show_bug.cgi?id=457560 C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Default Paper Size notes
I've tried to document at http://wiki.services.openoffice.org/wiki/DefaultPaperSize where the default paper sizes comes from under Linux. i.e. where VCL gets its default paper size from, and from where applications pick the default paper size for page styles. Bottom line is that we seem to have two different mappings from locale to paper size that cries out to me to be merged together as some i18npool api. Letter: en_US, en_CA, fr_CA, es_MX, es_VE according to svx/source/items/paperinf.cxx Letter: en_US, en_CA, fr_CA according to psprint/source/printer/printerinfomanager.cxx While GTK has: Letter: en_US, en_CA, es_PR, es_US according to gtk/gtkpapersize.c C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: vanilla linux builds
On Sun, 2008-07-27 at 19:08 +0200, Fridrich Strba wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Caolan McNamara wrote: | What is the version of gtk2/glib2 that Hamburg builds against at the | moment ? 2.4.x for both AFAIK. So a vanilla Fedora 3, ... is compiler-wise compatible with upstream, Ah, it perhaps *was*, as that's the setup I used for making upstream-qa-able workspaces for the last few years, but no longer unfortunately as the FC-3 compiler seems to create a situation where chart2 objects end up blank, something which doesn't happen with e.g. the O3-build-bot, hence my mucking around for a new baseline I can create locally. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Help getting started building with ooobuild
On Wed, 2008-07-23 at 22:22 -0700, Dan Kegel wrote: I'm trying to use ooobuild, but am stuck at checking for libxul-xpcom ... Package libxul-xpcom was not found in the pkg-config search path. It probably tries that because of something like... if $PKG_CONFIG --exists libxul ; then .. do good stuff .. else PKG_CHECK_MODULES( MOZILLAXPCOM, $MOZ_FLAVOUR-xpcom ) .. where your error comes from .. So more than likely, if you're at the leading edge of mozilla/firefox/xulrunner land, then you need the package that provides /usr/lib/pkgconfig/libxul.pc, e.g. a xulrunner development package Otherwise, if you're not at the leading edge of moz land, then --with-system-mozilla=xulrunner or =firefox C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] vanilla linux builds
Do we have a buildbot or any other piece of infrastructure that is capable of providing an installset that uses or matches the buildsystem of the vanilla linux builds provided by www.openoffice.org i.e. i386, builds with the same compiler, builds with the vclplugs, provides rpms, installs cleanly on oldest qa-used platforms. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] vanilla linux builds
On Tue, 2008-07-22 at 13:37 +0200, Christian Lohmaier wrote: Hi *. On Tue, Jul 22, 2008 at 10:48 AM, Caolan McNamara [EMAIL PROTECTED] wrote: Do we have a buildbot or any other piece of infrastructure that is capable of providing an installset that uses or matches the buildsystem of the vanilla linux builds provided by www.openoffice.org i.e. i386, builds with the same compiler, builds with the vclplugs, provides rpms, installs cleanly on oldest qa-used platforms. Well - if the O3-Iso http://wiki.services.openoffice.org/wiki/O3-build would have the GTK stuff needed to build the vclplugs, the O3-bot would match those requirements. That's almost ideal. Is it known if e.g. a master DEV300_mXX built with O3 passes QA without any known errors ? What is the version of gtk2/glib2 that Hamburg builds against at the moment ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Where to find debuggable versions of OpenOffice.org
On Wed, 2008-07-09 at 15:54 +0200, Philipp Lohmann wrote: non product build != debuggable build a non product build contains no more debugging information than the product build; the non product build activates assertions (per default in the form of popping up dialog boxes) which may or may not hint problems. A build complete with debug info is possible on Windows I think, however on other platforms the libraries grow so much, that the office does not fit FWIW, what most linux distros do is to build a product version, so no debugging assertions and so on. But a product version with symbols enabled and then (as with other applications) the standard distro build process extracts debuginfo into a separate rpm, leaving a stripped OOo behind. And gdb and other tooling understands such separated debuginfo. So, for a sample DEV300_m23 that gives a 486Meg debuginfo package at http://kojipkgs.fedoraproject.org/packages/openoffice.org/3.0.0/0.0.23.1.fc10/i386/openoffice.org-debuginfo-3.0.0-0.0.23.1.fc10.i386.rpm and for what it's worth, in the case of fedora, the simple text report spat out on a OOo crash can be symbol-ified with http://people.redhat.com/caolanm/ooocvs/ooomapstack which takes the backtrace from the stripped OOo and a matching unpacked debuginfo and adds the symbols back in (regardless of prelink symbol munging) In theory at least I guess that vanilla OOo could consider building with symbols enabled and use the debuginfo tooling to extract the debuginfo and keep it available for download for installation by the dedicated. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] customizing oo 2.4.1 ... - disable automatic update / skip registration / ...
On Mon, 2008-07-07 at 19:23 +0200, Oliver Brinzing wrote: Hi, is there a way to customize oo 2.4.1, so the - registration wizard on first start will be skipped (I noticed the new procedure is different from oo 2.0) The most annoying dialog created by man at least can be disabled with something like.. sed -i -e s#Patch.*# xsi:nil=\true \/#g /path/to/share/registry/data/org/openoffice/Office/Common.xcu and copying http://people.redhat.com/caolanm/ooo/RegisterAndLicence.xcu to /path/to/share/registry/modules/org/openoffice/Setup/RegisterAndLicence.xcu C - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Please help for creating com.sun.star.awt.Toolkit service
On Fri, 2008-06-20 at 12:28 +0200, Eike Rathke wrote: Hi Stephan, On Thursday, 2008-06-19 14:30:09 +0200, Stephan Bergmann wrote: On Windows, the L... version should also work, by accident. Highly unportable though. gcc has a -fshort-wchar feature (like mozilla uses) and SunPro has a U string option. I've wondered if there would be any advantage to hacking up some sort of const_rtl_uString magic which would implement a rtl_uString compatible layout string struct that could be initialized from a L/U string, eliding the rtl_uString constructor for such const rtl_uStrings enabling them to be stored in the rodata section. Maybe giving some measurable startup performance advantage. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] deliver's verbosity
On Wed, 2008-06-11 at 20:56 +0200, Pavel Janík wrote: Hi, On 11.6.2008, at 20:49, Frank Schönheit - Sun Microsystems Germany wrote: Is there an option I missed? If not, is there a possibility to introduce one? VERBOSE=TRUE deliver -verbose also works. The option is there, just not listed in the help output which I guess could be considered a titchy bug. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Problems with system vs. OOo libstdc++.so.6 mismatch on Linux
On Fri, 2008-06-06 at 09:30 +0200, Oliver Braun wrote: #if defined _gcc3 !(defined FREEBSD || defined NETBSD \ || defined MACOSX || defined SYSTEM_STDLIBS || defined(WNT)) Does this mean with switching to gcc4 we no longer ship libstdc++ ? If you're referring to _gcc3. That comes from solenv/inc/settings.mk as -D_$(COMID) and even for those of us that currently build with gcc4 that remains as gcc3 from.solenv/inc/tg_compv.mk .IF $(CCNUMVER)=00030001 COMID=gcc3 .ENDIF And similiarly e.g. the library names for gcc 4.X.Y built OOo are libuno_cppuhelpergcc3.so not libuno_cppuhelpergcc4.so so there's no need to add a _gcc4 or anything like that. Probably best to consider gcc3 as gcc2. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] build failed: GetOldStyleDics undefined.
On Thu, 2008-05-22 at 15:02 -0400, Terrence Enger wrote: Greetings. I am trying to build BEA300_m2 on Ubuntu 8.04 (hardy). Creation of libhyphenli.so fails with messages ... ../../../../unxlngi6.pro/slo/hyphenimp.o: In function `Hyphenator::getLocales()': /home/terry/OOo_hacking/BEA300_m2/lingucomponent/source/hyphenator/altlinuxhyph/hyphen/hyphenimp.cxx:167: undefined reference to `GetOldStyleDics(char const*)' /home/terry/OOo_hacking/BEA300_m2/lingucomponent/source/hyphenator/altlinuxhyph/hyphen/hyphenimp.cxx:172: undefined reference to `MergeNewStyleDicsAndOldStyleDics(_STL::listSvtLinguConfigDictionaryEntry, _STL::allocatorSvtLinguConfigDictionaryEntry , _STL::vectorSvtLinguConfigDictionaryEntry, _STL::allocatorSvtLinguConfigDictionaryEntry const)' This happens with configure parameters ... I think the quick answer is to drop --with-system-hunspell IIRC, that area is in a little bit of flux at the moment wrt to --with-system flags. The slow answer is the proper fix is in workspace hunspellexternal, see issue http://www.openoffice.org/issues/show_bug.cgi?id=87604 which has an earlier patch that might also work for you. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] 3103 uncallable methods in DEV300_m13
See http://people.redhat.com/caolanm/callcatcher/DEV300_m13/ for full list. Top three offenders are unchanged, but what might be of interest is that callcatcher now can parse and use linker map files, so the scan is extended to include some modules that export headers and symbols for use by other modules but have linker maps which can be used to show what symbols are not-exported from the library and are also not used within the library, i.e. unusable outside the .so and unused inside the .so. The nice win is that it shows that configmgr has 142 unused methods and that even sal has a tiny amount. FWIW I think I've submitted patch for most of the new entries on the list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] CHINA001 (was: Re: [dev] List of 2730 uncallable methods in DEV300_m10)
On Fri, 2008-05-09 at 17:54 -0400, Kohei Yoshida wrote: Hi Niklas, On Fri, 2008-05-09 at 19:17 +0200, Niklas Nebel wrote: example: CHINA001 In the interest of removing the unused code, I'd like know what those CHINA001 labels are for. Is it okay to perhaps review those commented out lines and see if we can remove them permanently? Its connected to the binfilter stuff, comments in the non-binfilter code with CHINA001 should basically indicate that the code was removed from the non-binfilter code because it was believed only needed to support other-code that is now solely in the binfilter, i.e. the legacy 5.2 binfilter filters and other similar things. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] List of 2730 uncallable methods in DEV300_m10
On Fri, 2008-05-09 at 16:47 +0200, Eike Rathke wrote: while ScCompressedArray::GetPrevValue() is currently unused it is the counterpart of GetNextValue() and IMHO should be kept for completeness of implementation. Perhaps #ifdef FUTURE around it, or else I can add such things to the whitelist if that's undesirable. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] List of 2730 uncallable methods in DEV300_m10
On Fri, 2008-05-09 at 20:01 +0200, Mathias Bauer wrote: A warning to everyone committing such cleanups to cvs: please use non-pro builds on at least one platform Indeed. The unused methods are always pulled from a .pro build. The same issue arises with stuff used only on one platform but included in all platforms, e.g. some ole2 stuff under windows. Another interesting discovery was that removing ctors can be dangerous at times because some compilers automatically create default or copy ctors for classes even if they aren't used. ... I found this problem mainly in binfilter - a fact that doesn't surprise a lot. Yeah, given the rather poor state of standalone C++ parsing frameworks the current mechanism is a somewhat horrific (but functional) scraping of the output gcc assembly stage. The output data is correct, but there is the limitation that it's not easy to tell that a specific ctor of a range of ctors is unused vs that objects of that class are impossible to actually create at all even if other code accepts pointers to such objects and call methods on them. FWIW http://people.redhat.com/caolanm/GoOOoCon08.odp has some brief notes on it. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] List of 2730 uncallable methods in DEV300_m10
On Thu, 2008-05-08 at 00:22 -0400, Kohei Yoshida wrote: On Tue, 2008-05-06 at 09:10 +0100, Caolan McNamara wrote: If I recall correctly, the module with the most unused methods that doesn't have anything in the pipeline to remove them is sc, so there's where the lowest hanging fruit should be. Since no one has raised hands, let me tackle that. The patch at #i85185# removes a handful of these methods just to get it started. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] CWS upload area
On Thu, 2008-05-08 at 17:43 +0200, Gerd Weiss - Sun Germany - ham02 -Sys Admin wrote: Hello all, I would like to ask you supporting me developing a CWS upload area for OpenOffice.org. At current state I could arrange to host a ftp server for up/downloading CWS builds. Looks good, I can log in anyway. What sort of space is available ? Be super neat if our build-bots could be tweaked to directly (if the person building asks for it) upload their output install sets to it. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] List of 2730 uncallable methods in DEV300_m10
See http://people.redhat.com/caolanm/callcatcher/DEV300_m10/ for full list. Top three offenders are... 1521 binfilter 403 sc 198 sd C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] List of 2730 uncallable methods in DEV300_m10
On Tue, 2008-05-06 at 09:54 +0200, Malte Timmermann wrote: Methods with very strange names, hard to speak ;) No just kidding - it means that very likely (100%?) these methods are never used/called from somewhere. *cough*, yes. Maybe a what the hell are they, might be useful. They're the non-virtual methods in those modules that are not referenced by anything at all, i.e. nothing calls those methods so they would appear to be dead code. Auto-excluded from the list are well-formed operators that should be encouraged, i.e. unused assignment operators and copy constructors are excluded as are const variants of methods if there is a used non-const variant. Also excluded are the unused methods in those modules that arise from using the various OOo macros that create loads of generally unused DeleteAndDestroy and _ForEach etc methods. Of course, there might be some reason to hold onto those symbols, i.e. a) they are symbols which are dlopened somewhere else in OOo, maybe the case for about 1% of them, i.e. only the handful of C symbols at the top of the binfilter list b) they are debugging-only symbols which should be inside some #if OSL_DEBUG X line c) they are used on some other platform, but just not linux, and should be inside the same #ifdef as their callers d) there's some bug in the script I think for a good number of these modules I've already submitted patches for the unused methods which'll hopefully work their way into the DEV300 line over the next few weeks (and mba has a workspace which should take care of the majority of the binfilter ones). If I recall correctly, the module with the most unused methods that doesn't have anything in the pipeline to remove them is sc, so there's where the lowest hanging fruit should be. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] cairocanvas.uno.so build error (on DEV300_m9)
On Tue, 2008-04-22 at 01:28 -0300, Ariel Constenla-Haile wrote: Hi all, while building DEV300_m9 I get the following linking error: /build/openoffice/DEV300_m9/canvas/source/cairo/cairo_spritehelper.cxx:160: undefined reference to `cairocanvas::doPolyPolygonImplementation(basegfx::B2DPolyPolygon, cairocanvas::Operation, _cairo*, com::sun::star::uno::Sequencecom::sun::star::rendering::Texture const*, cairocanvas::SpriteCanvas*)' http://www.openoffice.org/issues/show_bug.cgi?id=88260 C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Beijing Conference gotchas ?
Not sure I'll be at the Beijing conference at this early stage, but nevertheless as of the 14th Apr according to Chinese Embassy in Ireland http://ie.china-embassy.org/eng/Consular/AboutVisa/t112836.htm For the purpose to do business or attend a meeting or conference, single or double entry are required. The original version of invitation letter from an authorized Chinese Government Department or Government-authorized Company, the two-way flight ticket, and hotel booking confirmation are required. This seems to suggest, on the face of it, that to attend OOoCon I'd need an invitation letter from some government approved body ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] shared extensions, which layer ?
Where should unopkg add --shared stuff end up in a 3 layer OOo, into the basis layer or the brand layer ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] shared extensions, which layer ?
On Tue, 2008-04-08 at 15:20 +0200, Stephan Bergmann wrote: Caolan McNamara wrote: Where should unopkg add --shared stuff end up in a 3 layer OOo, into the basis layer or the brand layer ? Shared extensions go into the brand layer. Quoting http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo: * The share/extension/install directory can contain brand specific Extensions that are deployed shared at installation time. * This implies that the shared Extension layer (share/uno_packages) is in the Brand layer, not the OOo-Basis layer. (TODO: a future extension might be to add a third Extension layer in the OOo-Basis layer.) I guess if I wanted to e.g. share them between two optionally available brands right now I could simply try and link the two uno_packages dir to some single location. Just kicking around packaging the BrOffice.org brand in additional to the stock OOo brand, and want to try and keep things simple wrt. the existing packaged extensions and upgrade paths. Also (for the moment at least) if someone has extensions installed under OOo2 systemwide they won't be migrated automagically to OOo3 as the locations are different now. I note that if I simply move the OOo2 uno_packages dir into OOo3 that it works, anyone know if I have any sort of guarantee that it should work ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Benchmarking multiple versions of OOo
On Mon, 2008-04-07 at 12:39 -0600, Andrew Z wrote: **Thoughts 1. The cold start simulator is not perfect. The first pass of the first iteration is generally the slower than the first iteration of the second pass. The difference varies from -0.93s to +5.92s. I ran some tests at one stage on exactly the same version of OOo for 20+ runs running the coldstart reset between each run, and then 20+ warmstart runs. But the deviation between runs was too large for me to accept :-( And the deviation from un-installing a version, and re-installing the same version swings wildly too, so I retired in defeat. I just couldn't trust the results sufficiently to reliably determine if a change X made OOo faster or slower by comparing one set of results against the other from two different install sets :-( What I really want is something like Michael's http://live.gnome.org/iogrind but that just says your app burned up 110,000 bogoios and 90,000,000 bogocpus and every time you run it it says 110,000 bogoios and 90,000,000 bogocups. It doesn't even matter too much if it the ratio is wildly different to the real world as long as it's consistent between runs and reducing measurable bogoios reduces real world work by some amount. 2. So I don't hurt performance, I sleep for 0.10 seconds while waiting for OpenOffice.org to start accepting UNO connections, but 0.10 seconds may be too high because of the small differences in warm startup. How about launching OOo with a document that had a starbasic macro hooked to onload (or whatever it was) to avoid the connect, fail, retry cycle of connecting to the uno port, and have it do a big killall -9 soffice.bin at the end. That's sort of what I tried out. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Current Selection
On Fri, 2008-04-04 at 11:01 +0300, ashok _ wrote: On Thu, Apr 3, 2008 at 9:54 PM, Caolan McNamara wrote: Am I right in that it is not possible to simply generically query any given xModel's getCurrentSelection() result to answer the question is something selected. C. No, you can ... - queryInterface the selection object for selection ranges (com.sun.star.text.TextRanges) - get the first selected range - get a cursor over the range - if the cursor is collapsed (cursor.isCollapsed() ) it means no text was selected, otherwise it means text was select Hmm, I suspect that wouldn't give a correct answer to is something selected? in the case of a spreadsheet or drawing XModel instead of a text document, nor in the case of a text document if e.g. only a graphic is selected. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Current Selection
Am I right in that it is not possible to simply generically query any given xModel's getCurrentSelection() result to answer the question is something selected. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] rpath $ORIGIN and libvbaobjSUFFIX.uno.so
So in m4 all of the libraries have an rpath of $ORIGIN or $ORIGIN: $ORIGIN../ure-link/lib or some other variant. Except libvbaobjSUFFIX.uno.so which has no rpath. Is that outlier correct ? I assume so given the explicit SHL9RPATH=OXT in sc/util, but I just want to be sure here. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] RFC: java 1.5
On Tue, 2008-03-04 at 16:39 +0100, Rony G. Flatscher wrote: Taking all of this into account it seems to be a very attractive goal to create (or employ thired party) libraries in Java as that would truly help to cut down porting costs, as usually you won't have no porting costs with Java. E.g. look at the XML processing Java libraries that are also used in OOo. A minimum base-line of java 1.5 for the java bits of OOo should be no problem for libgcj, so there's no problem (in theory at least) for the various ports of OOo to platforms that either don't have a port of or cannot use the traditional sun java or free icedtea version. e.g. fedora on arm-eabi, debian on mips, s390 etc where gcj is the only solution. Just keep away from the sun.* classes which are documented in the sun java api itself as not to be used and all should be good wrt. portability between those java implementations. But the launch time for our java-based wizards isn't exactly speedy and helpcontent2 when it was moved from the java app to the libxslt based c++ one slashed multi-language build times, so using java ain't without some pitfalls :-) C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Will you please exept my humble request.
On Wed, 2008-02-20 at 18:50 -0600, Tobias Mann wrote: The Maemo 3.2 and 4.0 operating systems do not have a version of open office yet. The developers of this Linux OS have not been able to port Open Office to the Maemo 3.2 or 4.0 platform, because of Maemo's lack of support of ( Ooo ) and Java. The maemo target architecture is the Nokia N770 to N810, i.e. linux arm eabi right ? As such 2.4.0 does has an arm eabi port, and gij/gcj is available for arm eabi which can give java support. Regardless of having gij or not, OOo (in 2.4.0) can safely be configured using --without-java to create a build of OOo that doesn't require java with the corresponding loss of related features. Some (early) .rpms for an arm-eabi architecture built using --without-java can be found at http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/armeabiport01/ Might be worth finding out if they would even *fit* on a nokia device and if at runtime they can even fit into memory. I believe there is likely a little alignment glitch in those rpms (because I built them on qemu and not real arm arch) but they should be sufficient for an experiment anyway. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Where our products install to
On Fri, 2008-02-08 at 14:05 +0100, Petr Mladek wrote: I think that the best solution would be to get rid of share/dict/ooo and look for the dictionaries into a common place, for example /usr/share/myspell. It would be nice get rid of share/dict/ooo/dictionary.lst. The dictionaries have well defined names. It is possible to create symlinks for compatible languages, ... Well, there might be problems with symlinks on Windows but it would be very useful on Linux. Specifically wrt dictionaries, as you probably know that's precisely what we do on fedora where we've done away with dictionary.lst (well it still works if you want to use it) and just auto-detect them and the language/locale they service based on their names and add looking in a system /usr/share/myspell location as well the shared OOo one and then the per-user one. If there's any interest in it, then I could try and perhaps upstream this work and co-opt the existing --without-myspell-dicts or whatever its called into a sort of --with-system-dicts=LOCATION and bind the code off that, or something of that nature. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] We need your help
On Fri, 2008-01-25 at 15:58 +0100, Kay Ramme - Sun Germany - Hamburg wrote: Hi Tobias, Tobias Mann wrote: The entire Nokia N800 and N810 need a version of Open Office for The Operating System Tablet OS 2007 and 2008. I doubt it really helps as it's a bit of a tangent but FWIW there's a linux-arm-eabi port of OOo in 2.4.0. Though it's only known to work under qemu-arm, on a real arm you'd probably have to echo 3 /proc/cpu/alignment and your changes of getting to fit into a real N8x0 are probably slim. Maybe abiword + gnumeric might be more practical. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Building OOH680_m4 from scratch breaks in connectivity
On Tue, 2008-01-22 at 19:47 +0100, Giuseppe Castagno wrote: Hi all, On Debian lenny I'm trying to build tag OOH680_m4 from scratch and while building module connectivity I got the following errors: ... /home/beppe/ooo-b/ooh680-m4-std/build/current/connectivity/source/drivers/evoab2/NDatabaseMetaData.cxx: Yeah, I just hit that as well a while ago. My patch for it is at http://www.openoffice.org/issues/show_bug.cgi?id=85487 C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] fixing a translation ?
Just a very simple question. If there is a misspelling/mistake in a translation e.g. the same text has been used for insert column and delete column in a particular language and a replacement string has been provided. What's the way to fix it, is it simply to commit the change to the appropriate localize.sdf or does that lead to the fix getting clobbered by some other out-of-tree set of translation data ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: About the OOo dialog layouting patches
On Mon, 2007-12-03 at 09:24 +0100, Mathias Bauer wrote: Michael Meeks wrote: If we want to do this for OpenOffice.org, we should decide about this now. Because in that case we will need to rewrite lots of the modal dialogs anyway. So replacing them now with a 1:1 layouted modal dialog is just wasted resources. Changing a modal dialog to a non modal one is more than just moving the controls to another window, trust me. This can be read as please stop what you are doing, now ;-) I don't think so. IMHO we just need some coordination. I didn't read Christian's statement as a plea to do everything in one step, as I understood he just opted for agreeing on the general goal. We won't redesign and rewrite all existing dialogs into non-modal panes at once. But it would be good and nice to actually start now with some of them. As an example, I would like to convert all Format-whatever dialogs into parts of a formatting pane. In fact we are currently discussing ways to implement that with the developers from RedFlag2000. And we will need the layouter for this. (*) A concern is that the great is made the enemy of great and the bar for initial entry of the much-needed new layouting ability is made dependant on an extended set of requirements that pushes it further into the future. We're talking about widget layout for many years and this is the closest we've seen to date. Just getting it *in* without disrupting existing dialogs seems the vital bit. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] question about writer2latex
On Mon, 2007-11-19 at 15:52 +0200, Zvi Har'El wrote: Hi, Writer2latex is also responsible to the xhtml export from OOo writer. Writer2latex has fixed many bugs, e.g, current xhtml export doesn't generate footnotes and endnotes, and Writer2later 0.5 when doing xhtml export handles footnotes and endnotes correclty. I have installed Writer2latex 0.5 as an export plugin in OOo 2.3 and it satisfies all my needs, but I am certain there should be give na high priority in updating the default version. Updating to the latest version is the suggestion given here: http://qa.openoffice.org/issues/show_bug.cgi?id=83346 Perhaps that's the right issue to track. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] windows buildbot error message, bit of help ?
On Tue, 2007-11-06 at 17:14 +, Caolan McNamara wrote: On Tue, 2007-11-06 at 17:32 +0100, Hans-Joachim Lankenau wrote: hi! looks like version changes in assemblies happen outside of the source code (no further comment...). so ccache takes the cached object as the code didn't change... should be fixed now (disabled ccache in these places). That's most excellent, if we're back on track that's awesome work :-) Neat, *that* works, now just http://qa.openoffice.org/issues/show_bug.cgi?id=81911 fails at install set creation time. This business of creating multi-platform install sets for qa purposes without local access to a windows machine and compiler is still a formidable multi-week barrier that the misery of which cannot even be begun to be understood by someone inside the SO organization (except for poor ause who gets to try and stitch it together for us) C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] building error in SRC680_m234
On Thu, 2007-11-01 at 09:51 +0800, shizhoubo[OOoFrm] wrote: Hi dear all, I'm from Beijing Redflag Chinese 2000 Company and I'm trying to implement some new feature into one of the latest build, but when building SRC680_m234 ( clean ) in cygwin 1.5.24, I keep getting this loading component library failed error in the final step, could anyone please read the log in the attachment and give me some suggestions please? Thanks very much in advance. I'm not a windows builder, but this looks like http://qa.openoffice.org/issues/show_bug.cgi?id=82951 C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] crack-addled string hackery fun
I was playing around with strings to see if there was a route to elide
the constructors of OString and OUStrings especially for global const
strings initialised during startup
So e.g.
static const CONST_AGG_OSTRING(sGlobal, ::);
and
static const CONST_AGG_OUSTRING(TMP, TMP);
which are, respectively, a thing called sGlobal which can be used fairly
transparently as a const OString and TMP as a const OUString. Both are
created on the stack without a constructor call and avoid duplication of
the string literal itself. I'm not sure it's worth it, but it's sort of
fun.
Clearly as mentioned in the inline comment OUStrings are a challenge so
a real world impl have mess around with per-compiler wchar_t prefixes
and size checks like icu does, and/or hack around with -fshort-wchar
like mozilla appears to do. The horror follows...
#ifndef _STRINGHACK_HXX_
#define _STRINGHACK_HXX_
#include rtl/string.h
#include rtl/ustring.h
namespace rtl
{
class OString;
class OUString;
}
templateint LENGTH struct const_OString
{
struct internal_String
{
oslInterlockedCount refCount;
sal_Int32 length;
sal_Charbuffer[LENGTH];
};
union
{
const internal_String* pRealData;
rtl_String* pData;
};
const internal_String aData;
operator rtl::OString() const
{
return *(reinterpret_castconst rtl::OString*(this));
}
};
#define CONST_AGG_OSTRING( name, constAsciiStr ) \
const_OStringsizeof(constAsciiStr) name = \
{{name.aData}, {0x4000|1, \
((sal_Int32)sizeof(constAsciiStr)-1), \
constAsciiStr}}
//The downside here is that gcc L wchar_t is 32bit by default,
//-fshort-wchar can hack it to 16bits. Some other compilers default to
// 16bit or have alternative prefixes see:
// http://bugs.icu-project.org/trac/ticket/2957
#ifdef SAL_UNICODE_NOTEQUAL_WCHAR_T
#define CONST_AGG_OUSTRING( name, constAsciiStr ) \
::rtl::OUString name(RTL_CONSTASCII_USTRINGPARAM(constAsciiStr))
#else
templateint LENGTH struct const_OUString
{
struct internal_String
{
oslInterlockedCount refCount;
sal_Int32 length;
wchar_t buffer[LENGTH];
};
union
{
const internal_String* pRealData;
rtl_uString* pData;
};
const internal_String aData;
operator rtl::OUString() const
{
return *(reinterpret_castconst rtl::OUString*(this));
}
};
#define CONST_AGG_OUSTRING( name, constAsciiStr ) \
const_OUStringsizeof(constAsciiStr) name = \
{{name.aData}, {0x4000|1, \
((sal_Int32)(sizeof(L##constAsciiStr)/sizeof(wchar_t))-1), \
L##constAsciiStr}}
#endif
#endif
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] build bot install-time failures, a way to see what failed ?
Is there any way in the build-bot infrastructure to get a hold of the install time log on failure, e.g. I have a build that fails at http://buildbot.go-oo.org/buildbot/Win-XP/builds/136/step-shell_5/1 with ERROR: ERROR: Could not register all components for file services.rdb (gid_Starregistry_Services_Rdb)! Any chance the buildbot could be tweaked to just cat the install log file of e.g. d:/termite/slavedir/Win-XP/workdir/instsetoo_native/wntmsci11.pro/OpenOffice/msi/logging/en-US/log_SRC680_en-US.log at the end of a build so we can see what fails. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Some thoughts about our community
On Tue, 2007-10-09 at 16:26 +0200, Juergen Schmidt wrote: Caolan McNamara wrote: On Mon, 2007-10-08 at 12:48 -0400, Allen Pulsifer wrote: The one rational Simon offers that is a little bit different than the usual is the following: In many cases (including some very well-known open source projects) [the JCA] also allows the original donor to offer commercial offerings, thus ensuring the project continues to have engagement funded by its major participants. What might be concerning Sun is that a foundation owning the copyright to OOo code, even one that has an explicit mechanism to allow major contributors to continue to make commercial closed source versions of OOo, would probably remove the ability of Sun to unilaterally sub-licence StarOffice under a proprietary license to other co-operations either for profit or as a major bargaining chip for the promotion of other products. well making some profit with OpenOffice.org or a product based on OpenOffice.org is really helpful to pay all the developers on the project ;-) I don't know the details, i assume Sun spend more money on the project than they make profit with StarOffice. Anyway but Sun is not the only company that is making profit (or not) with a product based on OpenOffice.org. Sun does it with StarOffice where everybody can see the 1:1 relation between both products. There are other products/brands like Oxygenoffice or EuroOffice ... Novell makes profit with their Desktop product and oh wonder the main application that make the whole product interesting is what? *OpenOffice.org* correct. ... A further example is IBM with LotusNotes or Symphony where you also can't see a 1:1 relation as well. Sure, and there is no issue with branded versions of OOo, or with making a profit out of OOo, all the companies represented here attempt to make a profit out of it. My point is simply that Sun is the only one of these groups that can re-licence the OOo code-base to third parties outside of provisions of the LGPL, and that's a possible important factor in requiring that ownership of OOo copyright be shared between the author and Sun, rather that between the author and some independent foundation, even if that foundation had an opt-out for e.g. Sun to link non-LGPL code into OOo to create StarOffice. From my point of view it's cool when products can benefit from each other. And i personally would like to see more of these collaborations independent of they are based on StarOffice or OpenOffice.org or another brand. And so do I, and I have no problem with StarOffice itself, Sun has contributed gigantically to OOo, and if they feel a need to link some non-LGPL compatible code into OOo, e.g. due to no suitable replacement or other reasons, in an effort to make a better final product then that's a prerogative I can accept that Sun has earned. My point isn't really around StarOffice. It's that I would feel hard-done by as a contributor to OOo to find my work extended in some *other* third-party applications without that enhancement available back to the community. And Sun can facilitate this by deciding to re-licence it to a third-party in a way that allows them to avoid the LGPL and extend their version of OOo in a proprietary fashion. I could even imagine accepting giving another group an opt-out from the provisions of the LGPL if it was for the greater good of OOo and there was some representative body for OOo which agreed to it, but the current governance does allow Sun to make that decision all on their own, and to reap benefits from doing so which could be totally unrelated to the good of OOo. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Some thoughts about our community
On Mon, 2007-10-08 at 12:48 -0400, Allen Pulsifer wrote: The one rational Simon offers that is a little bit different than the usual is the following: In many cases (including some very well-known open source projects) [the JCA] also allows the original donor to offer commercial offerings, thus ensuring the project continues to have engagement funded by its major participants. What might be concerning Sun is that a foundation owning the copyright to OOo code, even one that has an explicit mechanism to allow major contributors to continue to make commercial closed source versions of OOo, would probably remove the ability of Sun to unilaterally sub-licence StarOffice under a proprietary license to other co-operations either for profit or as a major bargaining chip for the promotion of other products. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Classic MS Word file format question
On Thu, 2007-09-20 at 19:31 +0200, Timothy Parez wrote: Hi, I couldn't find anything, so I'm hoping some of the devs here might know. Is there any value in the Office 2000/2004 doc file format that contains the date when the file was originally created. I realize you can do this by looking at the properties in the filesystem, but people can change this info. Well, like all ole2 file formats there are some properties in the SummaryInformationStream, i.e. http://msdn2.microsoft.com/en-us/library/aa372045.aspx And also there is dttmCreated in the Document Properties area of the .doc, which is specific to msword. search for doc on wotsit.org to get the file format and then search the resulting documentation for dttmCreated. The summary properties are the easiest to extract with either the mswindows apis or libgsf for non-windows. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] About building OOo
On Fri, 2007-08-17 at 00:02 +0800, JiangChuang wrote: Hi, Peter, Nice to see you. How are you? Yes. I'm building for a Lemote Box. Sort sort of MIPS64-like processor, is there a java or java-alike gcj port to that platform ? Looks like it's not finding/recognizing java during build time. I'm not sure what the current status of porting to this hardware is, but seeing as you're already able to get *that* far then there must be a semi-secret porting project to that arch underway, so whoever got the port this far should know what the current status is :-) C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Any reason we include libdb_java42.[dll|so] in installsets ?
Do we need db.jar and libdb_java42.[dll|so] anymore ? As far as I can see they are not necessary at build-time anymore, but we currently include libdb_java via gid_File_Lib_Dbjava in scp2 into our installsets. Is there any reason for this, i.e. anything I'm unaware of that makes use of it ? I'd like to remove it from the install set if truly unnecessary, so comment in http://www.openoffice.org/issues/show_bug.cgi?id=80016 if you know better :-) C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Link-Error with Boost (attachment)
On Thu, 2007-07-19 at 18:47 +0200, A. Klitzing wrote: Forgotten attachment plain text document attachment (error_boost2) That looks like that formatclipboard.obj isn't being linked into the final library now at all. I suspect that you either *moved* formatclipboard.obj to the EXCEPTIONOBJS section or somehow else didn't compile it fully. You should have formatclipboard.obj in the SLOFILES section and the EXCEPTIONSFILES section in sw/source/ui/uiview/makefile.mk, e.g. see srcview.obj ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Link-Error with Boost
On Thu, 2007-07-19 at 16:45 +0200, A. Klitzing wrote: Hi again, What does I need to do to fix that problem? Regards, André -ltl680li -li18nisolang1gcc3 -lcomphelp4gcc3 -lucbhelper4gcc3 -luno_cppuhelpergcc3 -luno_cppu -lvos3gcc3 -luno_sal -luno_salhelpergcc3 -licuuc -li18nutilgcc3 -lavmedia680li -lxml2 -ldl -lpthread -lm -Wl,-Bdynamic -lstlport_gcc_stldebug ../unxlngi6/slo/formatclipboard.o: In function `boost::detail::shared_count::shared_countSfxPoolItem(SfxPoolItem*)': formatclipboard.cxx:(.text._ZN5boost6detail12shared_countC1I11SfxPoolItemEEPT_[boost::detail::shared_count::shared_countSfxPoolItem(SfxPoolItem*)]+0x66): undefined reference to `boost::throw_exception(std::exception const)' collect2: ld returned 1 exit status dmake: Error code 1, while making '../unxlngi6/lib/libsw680li.so' ---* tg_merge.mk *--- This likely means that OOo has been configured to use the external boost headers. The copy that OOo has internally has hacked some of the headers to disable exceptions IIRC, and so it is likely that the file formatclipboard.cxx is in a no exceptions makefile.mk in sw. So, quick workaround is to add formatclipboard.obj to the EXCEPTIONSFILES section of the makefile.mk in sw/source/ui/uiview like one of the other examples there. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] heads up on cairo 1.4.8 and crashes
On Fri, 2007-06-15 at 12:19 +0100, Caolan McNamara wrote: FWYi, it *seems* that OOo's gtk theming and cairo 1.4.8 don't play well together causing: X-Error: RenderBadPicture (invalid Picture parameter) Major opcode: 154 Minor opcode: 7 Resource ID: 0x3800597 Serial No:9507 (9507) so if there are mysterious crashes/immediate exits on e.g. right clicking twice in OOo, then the cairo version may be relevant. cairo 1.4.4 in comparison is fine. FYI cairo 1.4.10 has been released to fix this. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] To OOo Builders ...
On Thu, 2007-06-28 at 15:28 +0200, Kay Ramme - Sun Germany - Hamburg wrote: Hi builders, while building OOo on multiple machines because of some map file issues ;-), I was wondering, if I am the only one being annoyed by the excessive verbosity of the build system ... actually slowing down build performance unnecessarily. If others have the same feeling, I am going to submit some patches to get the verbosity under control again ... FWIW, I build with build build-flags -- other-dmake-flags -s where the -s suppresses a goodly part of the output. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] 470 versions in issuezilla, can we drop a couple of hundred ?
On Tue, 2007-06-26 at 08:13 +0200, Frank Schönheit - Sun Microsystems Germany wrote: To not end up with fruitless discussions here, I suggest somebody (Caolan?) submits an issue to collab.net requesting the possibility to limit the version list when submitting an issue. Then let's get Stefan on board, and see what collab.net says about it. Well, logged as http://qa.openoffice.org/issues/show_bug.cgi?id=78883 Not sure that it is on collab's tracker as a simple against website bug. Feel free to reassign it if anyone has a better idea as to where it should go. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] 470 versions in issuezilla, can we drop a couple of hundred ?
On Fri, 2007-06-22 at 20:01 +0200, Frank Schönheit - Sun Microsystems Germany wrote: Hi Caolan, There are 470, four hundred and seventy! versions listed by issuezilla for e.g. tools. way too much, agreed. The better solution would be if Version was a free-text field, but alas ... Can we cull these to at least remove all the milestones current - 5, and consider dropping the release candidates and the 1.0.X releases. What would we do then with the issues which currently have one of those versions set? We cannot simply remove the versions, this would violate the data integrity. We would have to reset this field for the affected issues. I'd hope that we could just remove the ability to *add* new bugs against those milestones. i.e. that we'd just list the last couple of milestones and the actual releases as options on the bug submission pages. I'm all for leaving the current version that bugs are logged against untouched. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] heads up on cairo 1.4.8 and crashes
FWYi, it *seems* that OOo's gtk theming and cairo 1.4.8 don't play well together causing: X-Error: RenderBadPicture (invalid Picture parameter) Major opcode: 154 Minor opcode: 7 Resource ID: 0x3800597 Serial No:9507 (9507) so if there are mysterious crashes/immediate exits on e.g. right clicking twice in OOo, then the cairo version may be relevant. cairo 1.4.4 in comparison is fine. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] crash reporter, what are the various distro's strategies ?
So when OOo crashes, what are the strategies that distros employ here if any ? For RH we don't build the crashreporter (as it's basically unusable info for Sun), but we do configure to enable using it, and replace it in the install set with a simple replacement that tests for the set of common problems that historically caused crashes, e.g. nvidia drivers, a11y enabled, selinux settings and insane local library butchering, and prompts the unfortunate user to log the supplied text to the RH bugzilla, and we map the stack back to source with http://people.redhat.com/caolanm/ooocvs/ooomapstack after throwing out the nvidia driver using reports At some stage in the past the ooobuild OOo would spawn off the gnome gnome bug-buddy, but that's no longer the case is it ? So do other distros have various solutions here, or just simply crash out and/or dump core ? What I'm thinking about aiming at is a shared cross-distro crash repository where we can auto submit the distro OOo crashes, and the distros can plug in their various stack mappers, with quick and dirty gnomebugzilla-alike tooling to merge the duped backtraces together. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] crash reporter, what are the various distro's strategies ?
On Fri, 2007-05-18 at 15:43 +0200, Bernd Eilers wrote: Caolan McNamara wrote: So when OOo crashes, what are the strategies that distros employ here if any ? Sun has a SOAP receiving service for crash reports, I'm aware of the tooling there, but this is somewhat orthogonal as the Sun tooling is internal and doesn't factor into this much. For RH we don't build the crashreporter (as it's basically unusable info for Sun), This is because Sun would not have the debug information created during building those Releases which would be needed to 'resolv' the crash But we do of course, and are both able to and actually do the mapping. And probably other distros can as well, and actually any of the distros using debuginfo rpms can use the simple RH ooomapstack tooling without much modification I'd assume. This ooomapstack utility most likely will also need access to debug information kept during the build, wouldn´t it? Yup, not a problem. We keep that info around for all our packages e.g. for the latest Fedora Core 6 it just needs an unpacked http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/i386/debug/openoffice.org-debuginfo-2.0.4-5.5.22.i386.rpm so any potential cross-distro crash server would just need a little fedora core disto specific plugin to go fetch the matching debuginfo rpm and run ooomapstack on it. I see a few potential problems with that: 1.) Crash data does contain dump of memmory which in some cases might contain personal information which end-users would not want others to be able to find on public websites. All that's at stack here is the basic simple stack traces, without memory dumps. So the issue doesn't arise. 2.) Who should host this repository? Or are you thinking about some kind of distributed or partly distributed repository? Well, that's the nub of the issue isn't it. But I don't see this as affecting Sun in any way, i.e. this isn't intended as pumping more data into Suns database, just an alternative crash reporter for the distro builders that might point at a shared database. Certainly there may be issues of scalability and it may be impractical. I was thinking of whipping something Red Hat specific together and giving it a whirl during the up and coming development cycle when there are a limited number of users to get a feel for how much data and server load would be involved when not considering vast number of window users and where all traces would generally come from a very homogeneous environment. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Windows: Help needed
On Thu, 2007-05-10 at 09:30 +0200, Oliver Braun wrote: For manual overrides (e.g. for debugging), use LD_LIBARRAY_PATH, which was invented for that purpose (I consider it a bug that we still use it in our start script). I dropped LD_LIBRARY_PATH in the startup script for a bit, because we have rpath ORIGIN we don't need it in OOo itself. But the snag I ran into is that with the current layout at least we do need it so that third party uno components spawned by OOo which are deployed into /uno_packages/ can link against the /path/to/ooo/program libraries :-( C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Windows: Help needed
On Thu, 2007-05-10 at 10:52 +0200, Oliver Braun wrote: Caolan McNamara wrote: I dropped LD_LIBRARY_PATH in the startup script for a bit, because we have rpath ORIGIN we don't need it in OOo itself. But the snag I ran into is that with the current layout at least we do need it so that third party uno components spawned by OOo which are deployed into /uno_packages/ can link against the /path/to/ooo/program libraries :-( If spawned in process, I would expect those libraries to already be mapped into memory. And for out-of-process components we could adapt the launcher to set LD_LIBRARY_PATH appropriately. FWIW http://dba.openoffice.org/drivers/postgresql/ is an example. Post installation without LD_LIBRARY_PATH it won't appear in the base downdown connect to an existing database list, with LD_LIBRARY_PATH it will. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Using zlib
On Mon, 2007-04-30 at 15:03 +0300, Alan Yaniger wrote: Hi list-members, I want to open a compressed file using the zlib in the OOo source tree. I assume I should add an include for external/zlib/zlib.h. What do I need to add to my directory's makefile.mk so that the linker will include the library? If you really want to use zlib directly, then for examples see, e.g. filter/source/flash i.e makefile.mk like... SHL1STDLIBS=$(ZLIB3RDLIB) swfwriter1.cxx for the include lines C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
On Tue, 2007-04-17 at 10:50 +0200, Stephan Bergmann wrote: Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 See http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE for work on this. That's most excellent, I like the .rdb split, that's where I got stalled when I made a stab at this for last years OOoCon. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] openoffice.org addons, website and repository
I see there's some text at http://wiki.services.openoffice.org/wiki/Extensions_repository around having an openoffice.org addon website equivalent to that of https://addons.mozilla.org What's the current progress of this? And is there any plans in the works to have any integration into our tools-extension manager to browse an online list of addons ? Or at least consideration of support for this on the proposed extensions site. i.e. some sort of xml description format for the extensions repository which can categorize the available addons into the architectures and operating systems that various addons are available for ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SRC680_m201 777 unused methods nagmail
On Thu, 2007-04-05 at 16:37 +0200, Mathias Bauer wrote: Hi Caolan, Caolan McNamara wrote: 116 methods: http://people.redhat.com/caolanm/callcatcher/m201.sw.log first entry is AddressMultiLineEdit::Modified 18 methods: http://people.redhat.com/caolanm/callcatcher/m201.starmath.log first entry is ConvertMathMLToMath(unsigned short) To avoid duplicate work: did you already commit some of the changes? We didn't commit anything directly, but jnavrati submitted a patch to remove the majority of the sw ones as http://www.openoffice.org/issues/show_bug.cgi?id=75235 And also two patches to remove the majority of the dbaccess ones. There are still a handful of the more tricky ones outstanding for sw (some of which are c-style symbols which might be dlopened by something, if so let me know and I'll whitelist them in the tooling). So you'd really need to regenerate a new list of the unused methods of sw post os94, and for dbaccess post dba23a. The sc list should still be valid, and would now give the biggest wins as it's the longest list of unused methods. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] gcj 4.1.2 and java component registration time
On Tue, 2007-02-27 at 18:17 +1100, Jim Watson wrote: On 23/02/2007, at 10:03 PM, Caolan McNamara wrote: For some reason I'm seeing a failure at registration of java components during the install. Similar failure here for GNU/Linux SPARC in m203 using gcc4.3 experimental gcj/ecj And for some other bizarre reason I have a workaround, i.e. remove xmerge.jar from @regcompjars in solenv/bin/modules/installer/ globals.pm That does not help here. But also in globals.pm, playing with javamaxservices=15, I find that any number 11 works OK. Yeah, that's right isn't it. I had made both changes, and clearly mistook which of the changes made the substantial difference considering the other as a debugging aid :-) C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] gcj 4.1.2 and java component registration time
For some reason I'm seeing a failure at registration of java components during the install. And for some other bizarre reason I have a workaround, i.e. remove xmerge.jar from @regcompjars in solenv/bin/modules/installer/globals.pm That's just a voodoo programming workaround, maybe some explanation will show up at some stage and the problem can get resolved correctly. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [gsl-dev] Re: [dev] VCL performance , feature improvements for Sommer of Code?
On Thu, 2007-02-22 at 09:11 +0100, Mathias Bauer wrote: Hi, this mail goes to dev@gsl.openoffice.org and [EMAIL PROTECTED] Please follow up on the gsl list. Philipp Lohmann - Sun Germany wrote: Clemens Eisserer wrote: What do you think about writing out a summer-of-code slot this year for enhancing VCL. VCL itself is a great toolkit and I guess because of not-existing-manpower it will be used for another couple of years, but I think it lacks some features of modern toolkits. Ah, a diplomat :-) Some areas which could be improved: - Performance. Sometimes slow, sometimes bad feeling. E.g. menus in OpenOffice, Support for doublebuffering Both valid. The menu thing may extend to framework, though. - Layout Managers. Implement Layout-Managers (already existing?) and adopt important dialogs to use them. A long term wish of mine. There even were two attempts at writing Layouting code, one by mmeeks, one by cmc. Both had already progressed to a demo dialog. However there was no resolution about which way to go finally. I think we deadly need something like that. Currently extensions are restricted to non-resizable dialogs and IMHO that is one of the biggest barries to a better usability of extensions. I think we need to be able to dock extension GUI elements like we can dock our navigator. This will need a layouter as the strategy of our internal elements (overwriting a virtual resize method) does not apply to external ones. Perhaps it's time to revive one of the pilots? AFAIK Christian Lippka also invested some time for it. I'm still rather a fan of my springs approach, though sadly my original implementation was utter rubbish. What I thought might be convenient with the springs idea was that... a) There is a java SpringLayout things in the awt so springs are fairly familiar b) It's possible to incrementally change dialogs and leave old one working like they always did while adding springs to new ones, I was (and still am) a bit frightened of the more extensive rework of dialog ideas where stuff like valid values are tested for in javascript which becomes part of the dialog description. c) And it seemed plausible to add a SpringLayout api to our uno one along the lines of the java one so that extensions could describe their dialogs' layout I reworked my implementation of springs in java and submitted it to libgcj as an implemenation of the sun java equivalent. So the work went *somewhere* at least, I always meant to re-work that final java one back into c++ and take up the show it can work for the more complicated tab dialog layout case challenge. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
On Tue, 2007-02-13 at 09:54 +0100, Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 Yeah, I'm very much in favour of this myself. Split the build into two parts the API stable ure stuff, and the rest. I'm trying to home-brew some hackery to fake this up. The current practical problems are of course as listed above and that to e.g. build the sdk separately from OOo and then to build OOo against that sdk+ure combination you need to have a) config_office, dmake, solenv, instsetoo_native, soltools, scp2 and readlicense_oo in both the sdk+ure and OOo build trees b) have bridges, cli_ure, codemaker, cppu, cppuhelper, cpputools, idlc, io, javaunohelper, jurt, jvmaccess, jvmfwk, offapi, offuh, rdbmaker, registry, remotebridges, ridljar, sal, salhelper stlport, stoc, store, udkapi, ure, unoil, xml2cmp, odk, sdk_oo autodoc, udm, cosv, unodevtools, jut in the ure tree b) and jvmfwk3rc and unorc are generated in the ure tree for both itself and for the final OOo product, as well as the forementioned .rdb files so you need to cheat and stick them into a package generated from the ure build and reuse them from inside the OOo build and then fiddle with some variables to add the sdk includes and the ure libs to the SOLARINC and SOLARLIB etc. So it's certainly kludgy to try and do it right now, but is a very attractive goal for me to be able to just rebuild the portion of OOo affected by whatever bug I've just fixed. And a nice thin edge of a wedge to make OOo more modular at build-time as well as at runtime. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to change dictionary directory
On Tue, 2007-02-06 at 12:17 +0100, Matthias B. wrote: My self-compiled OOo looks for its dictionaries in /opt/openoffice.org2.1/share/dict. How can I change this (preferably at compile-time) to /usr/share/ooo-dict ? I want to change the directory for spell checker, thesaurus and hyphenation. Where the default systemwide location is set is /opt/openoffice.org2.1/share/registry/data/org/openoffice/Office/Paths.xcu and defaults to e.g. /opt/openoffice.org2.1/share/dict and the OOo dictionaries are expected to be under ooo in that dir C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote: What about making binfilter SO only module? ;-) -1 Unfortunately .sdw etc documents exist and are a fact of life, we do still need to import them. e.g. my performance review still comes in .sdw format, we wouldn't want to drop importing that :-) The binfilter just needs to be reduced even further. Here's a list of some potential candidate methods for removal :-) http://people.redhat.com/caolanm/callcatcher/m201.binfilter.log C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SRC680_m201 777 unused methods nagmail
On Thu, 2007-02-01 at 11:59 +0100, Thomas Lange - Sun Germany - ham02 - Hamburg wrote: 18 methods: http://people.redhat.com/caolanm/callcatcher/m201.starmath.log first entry is ConvertMathMLToMath(unsigned short) please report any false positives to me About Math: I don't mind most of the mentioned functions because they are not virtual and the compiler will tell you if sth is missing. ^_~ But please do not remove the functions ConvertMathMLToMath(unsigned short) ConvertMathToMathType(unsigned short) ConvertMathTypeToMath(unsigned short) GetTokenChar(unsigned short, unsigned char) they are already part of a fix still to be implemented. If you want to get rid of them for the time being please only make them into comments. Sure, I'm not sure if I'm going to fix all (any?) of these myself, there's an awful lot of them across the various modules for one person to do all of them. Clearly sc with 409 unused methods would be the first place to start. (I previously did some callcatcher shrinkage to binfilter and sw which is why their counts are not as high) In case of continued interest I've also added binfilter: 247 methods http://people.redhat.com/caolanm/callcatcher/m201.binfilter.log and dbaccess: 99 methods http://people.redhat.com/caolanm/callcatcher/m201.dbaccess.log I probably should mention that the tool discards virtual methods on the basis that determining if virtuals are unused is very tricky. So all the listed methods are non-virtual. The problem arises in determining if a) some of the c-style symbols are used through e.g. dlopen-style stuff b) if the other methods are, like in this case, a work in progress c) or if the methods are used only under some platforms or debugging flags, in which case rather than remove them they just need to be protected with the same flags as the code in which they are invoked from. Which is a bit time consuming to figure out. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] SRC680_m201 777 unused methods nagmail
SRC680_m201: Detected unused methods for terminal build modules of sw/sc/sd/starmath on unxlngx6.pro 409 methods: http://people.redhat.com/caolanm/callcatcher/m201.sc.log first entry is ArgInput::GetArgSelection 234 methods: http://people.redhat.com/caolanm/callcatcher/m201.sd.log first entry is AccessibleSlideView::FocusHasChanged(unsigned short, unsigned short) 116 methods: http://people.redhat.com/caolanm/callcatcher/m201.sw.log first entry is AddressMultiLineEdit::Modified 18 methods: http://people.redhat.com/caolanm/callcatcher/m201.starmath.log first entry is ConvertMathMLToMath(unsigned short) please report any false positives to me C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] root?.dat files
What are those program/root3.dat root4.dat root5.dat files for in the installsets ? They contain just Base file in core0X package. Never include into patch. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] size: cppuhelper containers ... ~700k
On Wed, 2006-12-20 at 10:13 +0100, Stephan Bergmann wrote:
Caolan McNamara wrote:
On Tue, 2006-12-19 at 16:36 +, Michael Meeks wrote:
Hi there,
So - in my ongoing campaign to shrink memory usage, it seems that the
cppuhelper classes use the (uber-stupid) stl::hash_map code that insists
on allocating a staggering amount of memory for an empty hash (as
previously discussed).
Maybe it is worth jamming a TR1 alike unordered_map implementation
hash_map replacement with a more sensible initial allocation system into
o3l and convert to using that in one fell swoop ?
What is o3l? (Anyway, yes, replacing STLport's hash_map with something
more standard and future oriented looks like a good move to me---modulo
any potential compatibility issues, of course.)
Sorry, typo. I meant into the o3tl module which I assume expands to
OpenOffice.org Template Library, which looked like a natural place for
something like this.
But digging around a bit further it won't make much of a difference
really unless we implement our own better one because I see that
STLport5.1.0 has an an unordered_map implementation now, upgrading to
use that would make unordered_map available. But unordered_map still
backs onto the same hashtable that the STLport uses for hash_map and
both hash_map and unordered_map share the same default initial sizes of
100, and any explicit size setting for the hash_map will be downwardly
limited to the smallest prime allowed in hashtable.c
The good news though is that hdu's patch for reducing the smallest
allowed explicit initial size is now in stlport5
i.e.
# define __PRIME_LIST_BODY { \
7ul, 23ul, \
instead of
# define __PRIME_LIST_BODY { \
53ul, 97ul, 193ul, 389ul, 769ul, \
so maybe the least effort route after al is to go with hdu's two patches
to our stlport for the above upstreamed change and for the empty
hashtable optimization.
C.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] size: cppuhelper containers ... ~700k
On Tue, 2006-12-19 at 16:36 +, Michael Meeks wrote: Hi there, So - in my ongoing campaign to shrink memory usage, it seems that the cppuhelper classes use the (uber-stupid) stl::hash_map code that insists on allocating a staggering amount of memory for an empty hash (as previously discussed). Maybe it is worth jamming a TR1 alike unordered_map implementation hash_map replacement with a more sensible initial allocation system into o3l and convert to using that in one fell swoop ? C. (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Is there any Java in the source of OpenOffice? Kind thanks for your wonderful product.
On Mon, 2006-12-04 at 11:59 +, Joe Garvey wrote: I need to know in what programming language(s) Open Office is written, and whether there is much Java content? Joe Garvey, GARVEYDESIGN.COM [EMAIL PROTECTED] +353 87 962 5110 Overwhelming majority is in C++, http://wiki.services.openoffice.org/wiki/Java#OpenOffice.org_2.0_Functionality_depending_on_Java lists the minority of components written in java. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Possible exploit potential in openoffice
On Wed, 2006-10-25 at 14:53 +0200, Stephan Bergmann wrote: Caolan McNamara wrote: Also, we really should also add... .section.note.GNU-stack,,@progbits to the end of bridges/source/cpp_uno/gcc3_linux_intel/call.s similiar to the line at the end of bridges/source/cpp_uno/gcc3_linux_x86_64/call.s Yes. Can you file an issue? http://www.openoffice.org/issues/show_bug.cgi?id=70845 C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Valgrind automatic tests for accessability
On Thu, 2006-10-12 at 09:05 +0200, Thorsten Ziehm wrote: Hi Mathias, Mathias Bauer wrote: Code coverage is one thing (and it's only status quo!), code behavior another. Does just switching on a11y support in the configuration *without actually using it* really make the testing with the testtool impossible? How does it hurt us? It doesn't make the testing with TestTool impossible. But the Accessibility Code isn't touched at testing. Therefore I talked about the analysis of Code Coverage with the TestTool scripts. If it will be possible to check the Accessibility functionality with TestTool too, then the code coverage of all scripts will increase. But as I heard, this isn't possible without using the Accessibility Tools. Maybe something of interest here then might be dogtail which RedHat uses for app GUI testing. It uses the a11y interface to traverse the apps GUI elements, and so tests some a11y functionality as it goes by nature of how it works. http://people.redhat.com/zcerza/dogtail/ http://people.redhat.com/zcerza/dogtail/doc/apps/categories.html C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] freetype hinting
On Sun, 2006-09-24 at 16:46 +0200, Bernd Schubert wrote: Hi, I'm presently investigating why openoffice fonts look more blurry with freetype-2.2.1 than with freetype-2.1.10, see this thread http://lists.nongnu.org/archive/html/freetype/2006-09/msg00050.html I think finally I found the reason whats the problem: in vcl/source/glyphs/gcach_ftyp.cxx:857 ... May I ask why gcach_ftyp.cxx is trying to handle all this stuff itself and not just asking fontconfig? I mean, I see there is vcl/source/gdi/fontcfg.cxx, so somehow fontconfig is used. But why aren't its defaults used for hinting as well? Maybe you'd be interested in the use fontconfig hinting patch at issue 64508 which affects some of this. Though as well as the fontconfig defaults, there are also now cairo defaults which affect gtk2 apps, for that patch to additionally honour those settings see issue 59127 C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] valgrind work
On Thu, 2006-08-24 at 11:42 +0100, Caolan McNamara wrote: I see that there appears to be some valgrind work underway, at least in reporting valgrind warnings. Sort of relevant to this, glib has it's own memory allocating trickery just OOo does, and export G_SLICE=always-malloc apparently turns it off so G_SLICE=always-malloc valgrind ... might be a more suitable way to call valgrind to also pick up on problems with glib allocated objects used by OOo. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] valgrind work
I see that there appears to be some valgrind work underway, at least in reporting valgrind warnings. Can I suggest that accessibility be enabled for these valgrind tests. I highly suspect there are a gadzillion valgrind-findable bugs exposed with enabling a11y :-( C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [releases] OOo 2.0.4 status meeting
On Thu, 2006-08-24 at 13:26 +0200, Mathias Bauer wrote: Caolan McNamara wrote: On Tue, 2006-08-22 at 12:56 +0200, Martin Hollmichel wrote: We still have some stoppers open (68776, animated gifs, 68046, API problem) and cws warningfixes03 (build breakage), cws hro08, so that we target OOD680m3 for release candidate by the end of this week. Initial inactivity time (IIT) for patches is increased, the owner of the high scores will get a ping. http://eis.services.openoffice.org/patchreport/iit_index.html FWIW I'd like to mention two potential showstopping regressions (with patches to workaround attached) #i68822# crash on Input Mechanism commit in writer and QA thinks that this is a duplicate to issue 68522 that is integrated into m182 (and now OOD680m2) anyway. I compared the patch to the fix from Frank and I think that this is true, so no need to integrate this patch IMHO. Yup, it's the same problem, and all is under control on that front. #i68369# crash on shutdown under X I can't say anything about the content (maybe PL can). Do you have a real life scenario whith a crash? Until now it's only something discovered by Valgrind. Indeed, if it doesn't crash for anyone else then that's fine and I won't bang on about it for 2.0.4. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [releases] OOo 2.0.4 status meeting
On Tue, 2006-08-22 at 12:56 +0200, Martin Hollmichel wrote: We still have some stoppers open (68776, animated gifs, 68046, API problem) and cws warningfixes03 (build breakage), cws hro08, so that we target OOD680m3 for release candidate by the end of this week. Initial inactivity time (IIT) for patches is increased, the owner of the high scores will get a ping. http://eis.services.openoffice.org/patchreport/iit_index.html FWIW I'd like to mention two potential showstopping regressions (with patches to workaround attached) #i68822# crash on Input Mechanism commit in writer and #i68369# crash on shutdown under X C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Minimal Works .wps import filter?
On Sat, 2006-07-29 at 22:28 -0600, Andrew Ziem wrote: Hi, What would be the minimal acceptable function and code quality that OpenOffice.org would accept for a Microsoft Works import filter? Right now I have about 500 lines of spaghetti C++ that dumps the plain text to stdout for Works 4 (old, but seems to be the most popular on the Internet) and Works version 8 (aka 2005). Version 7 should probably work as is. However, Works 2000 (aka 5) looks somewhat different. I realize this code is not yet helpful, but I'm looking ahead. For the future, I'm considering creating a library with an API similar to libwpd, so the Works-OpenOffice.org integration should be easy (I hope). Eventually, the filter should process text styles, alignment, page size, etc., but at what point would the import filter be acceptable? If it was me, I'd say all main body text, and basic formatting, i.e. get inline formatted italic, bold, underline, fontname and fontsize working. Getting styles imported and supporting the above in those styles would be good too if possible initially, but afterwards if necessary. If that functions, then it would seem suitable quality to me for inclusion. And extend it feature by feature block afterwards. Do you know if the works file format documented anywhere ? Is it it's own file format, or is it some cut-down version of some other file format ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] gcc 4.X.Y ate my office suite
gcc 4.X.Y still has some casting oddities which has (yet again) bitten me, a test case for other gcc 4.X.Y distros and gcc tracking bug is available at... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28357 C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Issue 4695
On Wed, 2006-07-05 at 22:17 -0500, William Neil Hall wrote: Issue 4695 does not have a target version number asigned to it, and I have reason to want it fixed. I read the website and it said if you have a bug you would like to fix email this address... How do I go about getting this assigned to me so I can fix submit a fix to it? -Thanks For your first fix you should just go ahead and work on the problem, and when you have a solution simply attach your patch to the issue, it doesn't need to be reassigned to you to do that. The developer in charge of the module can then commit it for you once there's a solution. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] workspace handling
On Tue, 2006-07-04 at 04:52 +0200, Stefan Taxhet wrote: I'm a little worried about how long it's taking my workspaces to go anywhere Oops, they were still active? I found xalanupgrade and fpicker6 and moved those to the new area. Excellent, thanks for finding them :-) C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] workspace handling
I'm a little worried about how long it's taking my workspaces to go anywhere, and I'm wondering if this is normal both for external and internal workspaces, i.e. today is Jul 3 and I've 4 unintegrated workspaces which are out my hands. xalanupgrade ready for qa since May 5 = 59 days unchanged fpicker6 ready for qa since May 24 = 40 days unchanged targetedaot approved since Jun 12 = 21 days unchanged bfsixtyfour approved since Jun 15 = 18 days unchanged And interestingly, since some of those workspaces were created, I've just realized that according to http://ooomisc.services.openoffice.org/pub/OpenOffice.org/cws/upload/readme.txt the cws upload site has moved, and the original installsets for some of these workspaces have apparently disappeared in the meanwhile :-( C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Running parallel builds
On Fri, 2006-05-19 at 15:33 -0400, Chris H wrote: Hello, I would like to run a parallel build to see if I can cut down on build time a bit. My server is a Dual Xeon HT with 2 GB of ram. When I run dmake the CPU utilization is about 30%. When I run dmake -P2 it stays the same. Is there something else I need to do to kick off a parallel build or am I doing it right? Does parallel building make a significant difference in build times? I'd guess you did dmake -P2 in the top level directory ? The top level makefile.mk only really calls build.pl, try this cd instsetoo_native/util build --all -- -P2 that'll call dmake -P2 every time dmake would normally be called, additionally you can make build.pl attempt to build parallel modules at the same time, e.g. build --all -P2 or to go nuts, both together build --all -P2 -- -P2 Finally, export MAXPROCESS=2 is an alternative way to trigger dmakes to be -P2 so build --all -- -P2 and export MAXPROCESS=2 build --all are the same. parallel building is a sort of your mileage may vary kind of thing. Sometimes inter-module dependencies for build's -PX need fixing, and sometimes makefile.mk's for dmake's -PX need fixing, so I always build parallel, but with a check for failure and restart unparallel on trouble. That said, with OOC680_m2 I don't think there's any problems with parallel dmake makefile.mks, and only one module interdependency problem that I know of which your unlikely to hit. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] The Crash Reporter
On Wed, 2006-03-22 at 15:17 +, Gregor Hartmann wrote: Hi, Am 22.03.06, 12:21:58, schrieb Caolan McNamara [EMAIL PROTECTED] zum Thema Re: [dev] The Crash Reporter: Yeah, makes sense of course. In our own case RedHat keeps and provides debuginfo rpms of extracted debugging data, so theoretically I guess we would be able to use the same or similiar process to make sense of crash reporter data from our stripped builds. Is the stripped stacktrace - stacktrace with symbols code used by the Sun process freely available in any form ? The tool heavily relies on our infrastructure to track the checksums and the setup we have over here so it would make no sense to make it available publicly. But it should not be too hard to build some tooling around addr2line to get the same results. FWIW http://people.redhat.com/caolanm/ooocvs/ooomapstack is a simple little script which does what I want on our stacktraces and sticks the line numbers back in for me. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] The Crash Reporter
On Wed, 2006-03-22 at 11:12 +, Gregor Hartmann wrote: Its even worse. To be able to get also the sourcecode lines of the stacks sun keeps the original debug information for the binaries delivered. Sun then works on the 'enriched' stacks only. So a crash report which is sent in from a build form a non Sun source cannot be used at all since the debug information is missing. So such crash reports are always spam which has to be sorted out. So That's why “there are a few hoops to be jumped through if an outside developer want to enable the crash reporter.” Yeah, makes sense of course. In our own case RedHat keeps and provides debuginfo rpms of extracted debugging data, so theoretically I guess we would be able to use the same or similiar process to make sense of crash reporter data from our stripped builds. Is the stripped stacktrace - stacktrace with symbols code used by the Sun process freely available in any form ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Executable Memory
On Fri, 2006-03-17 at 10:17 +0100, Stephan Bergmann wrote: 3 Exploiting the fact that the executable memory in question is never freed, add a simple, special-purpose (executable) memory allocator to bridges/source/cpp_uno/shared. It would work similar to rtl_allocateMemory by using mmap (or equivalent), but would be much simpler since it would not have to keep track of a free list: if there is enough space left at the end of the last obtained mmap area, use that; otherwise, obtain a new mmap area. Pro: local change in C++ UNO bridges, no new interface in rtl/alloc.h needed, does not make too much memory executable. Con: can't think of one. Sure. It sounds the quickest and easiest fix. It's a real non-theoretical problem for OOo under SELinux enabled linux (e.g. Fedora) which has been biting us for a while. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Greek fonts on Linux OO.o
On Mon, 2006-03-13 at 00:35 +0200, Seeker wrote: From a quick search i didn't find the issue. I refer to the problem with greek fonts. When the user types something in Greek OO.o frequently takes the characters from a font which doesn't have the suitable characters with very very very ugly results. You can see the problem here: http://static.flickr.com/25/62583834_0436c1bfff_o.png Note how different 1 and 2 are. The first misses characters and even the ones which appear are very ugly. The ugly fonts appear even in OO.o's GUI. Does installing DejaVu fonts make any difference for you ? http://dejavu.sourceforge.net/ There aren't a lot of good greek-coverage (as opposed to fonts which include some greek characters for math-coverage purposes) But DejaVu apparently has some good coverage there. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] warnings01: status and how to proceed
On Wed, 2006-03-01 at 20:57 +0100, Thorsten Behrens wrote: Stephan Bergmann [EMAIL PROTECTED] writes: However, some people build OOo in such a way that they use system-supplied alternatives of those external projects, so that the patches will have no effect for them. That means that switching on warnings are errors can break such builds (although the official OOo builds would succeed). The relevant patch files, until now, are boost/boost-1.30.2.patch boost/spirit-1.6.1.patch icu/icu-2.6.patch neon/neon.patch python/Python-2.3.4.patch sablot/Sablot-0.52.patch stlport/STLport-4.0.patch stlport/STLport-4.5-0119.patch Add agg to the list. I guess that for e.g. next version of Fedora, I can go around getting the warnings free patches for this libraries into at least the distro versions of these modules so at least a --with-system on fedora fc5 would work with warnings as errors enabled, and I assume that other distros could do the same. The problem would be using --with-system-foo on existing releases :-( Have you already submitted the fix warnings patches for these libraries into their respective bug tracking systems, so that the next releases of those libraries themselves will include the warning fixes :-) ? But what about providing tinderbox slaves, dedicated to community CWS? This would be a good idea, especially is organized so that someone who wishes to create an install set for qaing a workspace can generate a Hamburg QA compatible workspace for various platforms by submitting a job to build it and auto move it to somewhere where it can be downloaded. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] compiled from tarball but cannot start
On Fri, 2006-02-03 at 13:11 +0100, Johannes Walther wrote: Hi, yesterday I downloaded the 2.0.1 (OOA680_m1) tarball with sources, set up the environment and started compilation. I used dmake from $SRC_ROOT and after much hours the end of the compile process was /usr/home/chris/coding/OO/OOA680_m1/instsetoo_native/util - No EPM: do no packaging at this stage Looks like everything compiled fine (congratulations), except that the installation/package creation stage was skipped, possible from --disable-epm passed to configure. If you (after setting up your environment) try this... cd /usr/home/chris/coding/OO/OOA680_m1/instsetoo_native/util export PKGFORMATSWITCH=-format rpm -simple /opt/openoffice.org2.0test dmake openoffice_en-US it should install directly to /opt/openoffice.org2.0test in theory otherwise I guess you could configure without --disable-epm and after resourcing your environment run build and see if that makes whatever is guessed as a suitable package for your distribution/OS. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] bug report about eps files insertion
On Tue, 2006-01-24 at 20:22 +0100, Nicolas Pourcelot wrote: Hi, eps files generated by matplotlib (a widely used python library) are not correctly handled by OpenOffice 1.1.x and 2.x. I join an example of such a file. These eps files are readable by all other programs I tested. The eps file probably doesn't have a preview image embedded in it. i.e. would look ok when finally printed to ps/printer but no preview shown when viewing/editing the document See http://www.openoffice.org/issues/show_bug.cgi?id=9290 This will hopefully be somewhat improved for 2.0.2 C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] gcj registration time error with gcc 4.1 workaround
I got a dread no mapping from java to c++ error on registering java
components with gcj. It seems to be this tiny little regression in gnu
classpath.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25389
A silly little probable workaround for jurt shown inline here.
Index: com/sun/star/lib/util/UrlToFileMapper.java
===
RCS file: /cvs/udk/jurt/com/sun/star/lib/util/UrlToFileMapper.java,v
retrieving revision 1.3
diff -u -p -u -r1.3 UrlToFileMapper.java
--- openoffice.org.orig/jurt/com/sun/star/lib/util/UrlToFileMapper.java
7 Sep 2005 19:05:37 - 1.3
+++ openoffice.org/jurt/com/sun/star/lib/util/UrlToFileMapper.java
13 Dec 2005 11:34:14 -
@@ -95,6 +95,14 @@ public class UrlToFileMapper {
// the URI constructor might throw
java.net.URISyntaxException (in
// Java 1.5, URL.toURI might be used instead).
String encodedUrl = encode(url.toString());
+
+
+String mytest = encodedUrl.substring(0, 6);
+if (mytest.equals(file:.)) {
+String ans = encodedUrl.substring(5,
encodedUrl.length());
+return new File(ans);
+}
+
try {
Object uri = uriConstructor.newInstance(
new Object[] { encodedUrl });
C.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] gcc bitfields and memory access. e.g. -mtune=pentium4
This is a nasty gotcha that caught me out recently, where a bitfield comparison to unsigned char would blow up OOo during a OutputDevice::DrawText, not every time, but over the course of a medium length OOo session almost guaranteed to occur. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25199 -mtune=pentiumpro is the default OOo gcc on ix86 build flag for OOo, and doesn't suffer from the problem, while e.g. -mtune=pentium4 which is the default for fedora 4 does. So it's not a serious general OOo problem, but one that's possibly worth knowing about. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
