Re: [Libreoffice] few queastions about building sal
On Aug 29, 2011, at 8:35 PM, Caolán McNamara wrote: On Mon, 2011-08-29 at 15:53 +0200, Stephan Bergmann wrote: On Aug 29, 2011, at 2:50 PM, Matúš Kukan wrote: rtl_hashfunc, rtl_hashentry_destroy and 5 more rtl_hashtable_* from rtl/source/locale.c Ah, I see. Yes, indeed, appears they have erroneously been added to sal.map once, and should not be removed for interface stability. There's no mention of them in the headers, I wonder what are the realistic chances that anything ever used those ? C. Zero. But it does not hurt that much to have them exported, does it? So I would just play it safe. YMMV. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] unnecessary build of obj/bootstrap.o?
On Aug 29, 2011, at 5:12 PM, Kevin Hunter wrote: In tracking down another issue, I've run across a number of object files that we appear to build but not use. Example: g++ -o sal/unxlngx6/obj/bootstrap.o [...] A few lines later in the build, we build this, with a few extra g++ arguments. This is the version that actually gets used elsewhere in the build: g++ -o sal/unxlngx6/slo/bootstrap.o [...] \ -fpic \ -DSHAREDLIB \ -D_DLL_ Question: what's the point of building the first one (if any)? Those files are built once to be included in a static library (via OBJFILES) and once to be included in a dynamic library (via SLOFILES). The static library was used to build some build-time tools, IIRC, but appears to be no longer needed. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Platform-specific OUTPATH variables
Sent from my iPhone On 30.08.2011, at 14:40, Eike Rathke o...@erack.de wrote: Hi Tor, On Tuesday, 2011-08-30 00:15:50 -0600, Tor Lillqvist wrote: Can't we at least get rid of the '350' subdirectory ? Yes please. The 350 should be 340 (isn't it?) for 3-4 branches, so different output hierarchies when switching branches is nice to have in order to not spoil already existing outputs. Maybe, once a build only generates output in that single directory. Until then, the point is rather moot, IMO. -Stephan___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] (was: Re: buglet in 1ec7b6a4 (?))
On Aug 31, 2011, at 3:55 AM, Kohei Yoshida wrote: On Mon, 2011-08-29 at 12:08 +0200, Stephan Bergmann wrote: http://cgit.freedesktop.org/libreoffice/core/commit/autogen.sh?id=3ea37ac7005c64f378756a5dbc3fbfbc3bf8b053 does not fix this for the one-argument case, however, due to an error introduced in http://cgit.freedesktop.org/libreoffice/core/commit/autogen.sh?id=c0b9fdfbbaa46e984dbe6ea9e7f5adc943b9f248. Attached patch would fix that. Thanks. Just pushed to master. BTW, I believe this is your first commit to LibreOffice I believe (aside from your numerous commits to the OOo code base that is)? Can I ask you to confirm that your patch is under LGPLv3+/MPL 1.1 ? Oops, good catch. Yes, this and all forthcoming contributions from me (until further notice) are under LGPLv3+/MPL 1.1. Thanks, -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] inconsistency between rtl::OString/rtl::OUString and optimization opportunities ?
On Aug 31, 2011, at 12:04 PM, Caolán McNamara wrote: rtl_string_new_WithLength/rtl_uString_new_WithLength create an rtl/String/rtl_uString of the given length, but set the full buffer contents to 0s[1] No idea whether specifying that the values of all characters are set to 0 was meant to be actually useful (and is exploited somewhere) or was misguided overeagerness. meanwhile I see that we have x_rtl_uString_new_WithLength in inc/i18nutil/x_rtl_ustring.h which is a non-zeroed out variant of rtl_uString_new_WithLength so there's an uninitialized buffer available to play with. We can assign ownership of the rtl_uString to an OUString with OUString( rtl_uString * str, __sal_NoAcquire ) and skip calling acquire, i.e. OUString has *two* methods to take ownership of a rtl_uString without calling acquire. the public OUString( rtl_uString * str, __sal_NoAcquire ) the private OUString( rtl_uString * value, DO_NOT_ACQUIRE * ) as well as the usual add-add-refcount version of OUString( rtl_uString * str ) While OString has only the private OString( rtl_String * value, DO_NOT_ACQUIRE * ) as well as the usual add-add-refcount version of OString( rtl_String * str ), so the same hack isn't available. No reason to not add a OString(…, __sal_NoAcquire) variant, too, I would say. I'm vaguely thinking of moving that i18nutil x_rtl stuff into comphelper/string or something, hard-coding its refcount argument to 0 or 1 and fixing up its uses to consistently use one or the other public OUString acquire/noacquire ctors and add a OString variant so that either of the belows is possible to skip copying buffers around the place. #if thinko-one rtl_String *pStr = foo_rtl_string_new_WithLength(nLen/*, refCount=0*/); //call acquire, refCount of 1, OString::dtor destroys buffer rtl::OString aRet(pStr); pStr-length = rStrm.Read(pStr-buffer, nLen); #else rtl_String *pStr = foo_rtl_string_new_WithLength(nLen/*, refCount=1*/); //don't call acquire, refCount stays 1, OString::dtor destroys buffer rtl::OString aRet(pStr, SAL_NO_ACQUIRE); pStr-length = rStrm.Read(pStr-buffer, nLen); #endif I would go with the second choice. foo_rtl_string_new_WithLength creates and returns a new resource that the caller is responsible of eventually releasing again, be it via an explicit rtl_string_release or via the SAL_NO_ACQUIRE trick. Also, that way its behavior is similar to plain rtl_string_new_WithLength, and adding the corresponding optimization for nLen=0 in the future would be straightforward. //if unlikely length != nLen make deep copy of string to release excess //mem, nobody seems to worry about excess for rtl::O[U]String buffers, //but much less opportunity to have a large chunk of unused //buffer there. C. [1] with a loop, I suppose its no real optimization there to use memset or rtl_allocateMemory for that case ? Wouldn't hurt to use memset instead, I'd say. Even if all compilers reduced the loop to something as efficient, using memset would still be shorter than that verbose loop. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] More numbering types: one, two, three, ...
On Sep 1, 2011, at 2:19 AM, Mohammad Elahi wrote:
Changed function lcl_formatPersianWord to be more generic, and added support
for some more numbering types:
English word: one, two, three, ...
English cardinal: first, second, third, ...
English cardinal semi-word: 1st, 2nd, 3rd, ...
Persian cardinal word.
I used C++ macros, but do not know whether libreoffice community
likes using it or not?
Any feedback is welcomed.
First, I think extending this from Persian to English already shows the biggest
flaw of this approach: Do you want to extend in in this way for all languages
supported by LibO? I would consider such extension to additional languages a
localization task, a task that typically only consists of translating string
resources. Here, however, someone doing localization would need to add new
constants to NumberingType.idl and would need to add code to
defaultnumberingprovider.cxx. That does not feel right.
That said, concentrating on details of the code:
- At least I do not like macros very much. But at least DEFINE_WORD_TABLE is
local to a single .cxx.
- In C++, no need for
typedef struct {…} NumberWordTable;
Instead, use the shorter
struct NumberWordTable {…};
- the second table is used for irregular cardinal numbers is not empty:
should probably read if not empty?
- In
sal_Unicode *(table1[2][8]);
the superfluous parentheses are IMO confusing, and the sal_Unicode data should
really be const, so rather
sal_Unicode const * table1[2][8];
- For the Persian characters (that cannot be given visibly in an ASCII-only
.cxx file, anyway) the practice of specifying sal_Unicode strings as sequences
of individual characters (a la {0x0635,0x062f,0}) appears acceptable. However,
for English strings, {'o','n','e',0} vs. one is hard to tolerate. Maybe all
the data should be specified as UTF-8 instead, using literal … strings (the
literal Persian UTF-16 characters like 0x0635 become a little harder to
maintain, having to encode them as UTF-8 like \xXX\xYY), and explicitly
converting to rtl::OUString when used.
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] New desktop integration modules
On Sep 1, 2011, at 5:32 AM, Timothy Pearson wrote: I have created a patch that adds Trinity Desktop Environment integration to LibreOffice, and would like to get it included in the upstream LibreOffice sources if you are interested. It is based on the old KDE3 integration module, but has been altered to work with the latest version of TDE. It does not damage or replace the existing KDE3 desktop integration modules, and can be turned on/off with a configure flag at compile time. This is an important feature to users of TDE, as the existing KDE3 integration module will not function properly within the latest releases of TDE. We are prepared to maintain and enhance the TDE integration module for the foreseeable future. The patch can be found here: http://git.trinitydesktop.org/viewgit/index.php?a=viewblobp=Trinity%20Desktop%20Environmenth=33a55305c99e0dc808b25eaba3f7373521eec3e1hb=HEADf=main/thirdparty/libreoffice/3.3.2/patches/libreoffice-trinity.diff If you need the patch in e different format, or have concerns about it, please don't hesitate to contact me! One detail that immediately caught my attention is that the connectivity/source/drivers/tdeab code is obviously based on old connectivity/source/drivers code that still uses active UNO component registration. This would need to be adapted. See http://wiki.services.openoffice.org/wiki/Passive_Component_Registration for the concepts, https://issues.apache.org/ooo/show_bug.cgi?id=113189 for the issue that implemented it, and http://cgit.freedesktop.org/libreoffice/core/commit/?id=9551bf5a1ee5c9275a26f8ec4021e0b7f5665176 for the changeset containing the relevant modifications to connectivity/source/drivers. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] More numbering types: one, two, three, ...
On Sep 1, 2011, at 11:00 AM, Mohammad Elahi wrote:
Here, however, someone doing localization would need to add new constants to
NumberingType.idl and would need to add code to defaultnumberingprovider.cxx.
That does not feel right.
OK, I'm just started to work with libreoffice code ;) Just searched for a
similar feature which
recently has been added, and used it as a templated to how to write code.
Please, Would you mind tell me what is right in this case? How should I write
code for localizing numbers
which best fits?
To be honest, I have no idea what the best approach would look like. Maybe
something like this: In the front end, have numbering types specified not by
a single NumberingType constant, but by a tuple of NumberingType constant and
language code (there should already be at least one such enumeration of
language codes in LibO), where the language code is only used by NumberingType
constants like CHARS_WORD, CHARS_CARDINAL_WORD, etc. In the back end, devise
and algorithm and a list of string resources that produces the desired output
for all the combinations of (a) numeric value to be formatted according to the
given (b) tuple of NumberingType constant and language code. Depending on what
special cases the various languages need, the algorithm and the corresponding
list of necessary string resources will grow over time, as more and more
languages are being taken care of. At runtime, the algorithm then obtains the
necessary strings for the given language like is done for all the other
localized strings in LibO.
- the second table is used for irregular cardinal numbers is not empty:
should probably read if not empty?
Sorry for typos
No need to be sorry. :-)
- For the Persian characters (that cannot be given visibly in an ASCII-only
.cxx file, anyway) the practice of specifying sal_Unicode strings as
sequences of individual characters (a la {0x0635,0x062f,0}) appears
acceptable. However, for English strings, {'o','n','e',0} vs. one is hard
to tolerate. Maybe all the data should be specified as UTF-8 instead, using
literal … strings (the literal Persian UTF-16 characters like 0x0635 become
a little harder to maintain, having to encode them as UTF-8 like \xXX\xYY),
and explicitly converting to rtl::OUString when used.
Thanks,
Yes, but I think as you said it is better to use UTF-8, one of my problems
was defining a two dimensional
array to hold strings with variable length, first I used
(sal_Unicode[]){0x0635, ...}, but a feedback from
community was It's not C++03 compatible, so used constant length arrays
which do not like them.
But by changing it to UTF-8, it even makes the persian strings more tolerable.
In the end, the best way to represent those strings will depend on how exactly,
if at all, this is extended to more languages than just Persian (see above).
(For example, if we should take the route I sketched above, those strings would
be stored externally from the C++ source file, anyway, and all this would
become moot.)
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Sep 1, 2011, at 12:30 PM, Tor Lillqvist wrote: The changes themself look sane, regarding the background Khaled gave and knowing part of his work from older days I didn't hesitate much to commit this :) OK, excellect! Khaled, if you want direct commit access, just ask (hmm, file a bug asking for that, is that still the correct procedure?) Yes, http://wiki.documentfoundation.org/Development/NewAccount (been there just myself right now…) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] More numbering types: one, two, three, ...
On Sep 1, 2011, at 1:01 PM, Eike Rathke wrote: On Thursday, 2011-09-01 09:35:09 +0200, Stephan Bergmann wrote: First, I think extending this from Persian to English already shows the biggest flaw of this approach: Do you want to extend in in this way for all languages supported by LibO? I would consider such extension to additional languages a localization task, a task that typically only consists of translating string resources. String resources wouldn't be sufficient as different locales have different rules for how to form a number string, especially when it comes to ordinals. Thats why I sketched that string resources plus algorithm (taking care of all the various language-specific details) thing further down in the thread. However, this looks more like spell-out than level numbering and as such misses the point of the numbering provider. If we wanted to implement spell-out I'd rather go for ICU's methods than implementing yet another home-grown solution. Sounds even better. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build break when generating RDBs
On Sep 1, 2011, at 5:33 PM, Peter Foley wrote:
On Thu, 1 Sep 2011, Eike Rathke wrote:
Hi Peter,
On Tuesday, 2011-08-30 14:36:01 -0400, Peter Foley wrote:
[ build ALL ] top level modules: i18npool
[ build ALL ] loaded modules: i18npool
[ build RDB ] i18npool_test_breakiterator
awk: cmd. line:1: $R/^\?xml version.*$R/ { next; } {
gsub($R/vnd.sun.star.expand:\$OOO_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$OOO_BASE_DIR,$0);
gsub($R/vnd.sun.star.expand:\$BRAND_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$BRAND_BASE_DIR,$0); print; }
awk: cmd. line:1:^ syntax error
awk: cmd. line:1: $R/^\?xml version.*$R/ { next; } {
gsub($R/vnd.sun.star.expand:\$OOO_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$OOO_BASE_DIR,$0);
gsub($R/vnd.sun.star.expand:\$BRAND_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$BRAND_BASE_DIR,$0); print; }
awk: cmd. line:1: ^ backslash not last character on line
make: ***
[/libreoffice/workdir/unxlngx6.pro/RdbTarget/i18npool_test_breakiterator.rdb]
Error 1
I'm getting the above build error which seems to be caused by $R being
added to the awk regex expression by gb_Helper_abbreviate_dirs.
Apparently you're the only one getting this error, so I wonder what may
be different on your system? I doubt this is a general
gb_Helper_abbreviate_dirs always inserts $R before / problem. Which
platform are you on? I presume winmingw, because that (and windows)
defines gb_Helper_abbreviate_dirs_native to something different than the
general gb_Helper_abbreviate_dirs:
I'm actually building libreoffice in a gentoo linux x64 chroot.
I don't know if the chroot is causing this problem or not.
awk is 4.0.0
make is 3.82
Let me know if you need any more info.
The path to the LibO sources within your chroot environment appears to be too
short (they are probably right in the root there, right?). Then,
gb_Helper_abbreviate_dirs will replace each occurrence of / with $R/ in the
command line. (gb_Helper_abbreviate_dirs is broken by design, but must of the
time this goes unnoticed.) Try moving the LibO sources further down in the
directory hierarchy.
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] fix basebmp symbol visibility (was: bug in vcl make files?)
On Sep 1, 2011, at 9:26 PM, Stephan Bergmann wrote: On Sep 1, 2011, at 3:47 PM, Matúš Kukan wrote: That's not about makefiles. debugDump() is not marked for exporting, you can do this in cxx file with SAL_DLLPUBLIC_EXPORT or in hxx files. But in hxx you need to use library specific macro defined as in http://opengrok.libreoffice.org/xref/core/basebmp/inc/basebmp/bitmapdevice.hxx#42 It's more complicated because of error in windows compilers, I think. I have pushed this one. ( http://cgit.freedesktop.org/libreoffice/core/commit/?id=e21822008dff0c618e8947d7343bc70d51d47ec3 ) You cannot do it that way -- it will not work on Windows. See http://wiki.services.openoffice.org/wiki/Symbol_Visibility for details (in short, you need the BASEBMP_DLLPUBLIC/BASEBMP_DLLIMPLEMENTATION stuff in the header file if you want to be able to link against the function on Windows). Will try to remember to prepare a proper patch tomorrow, unless someone beats me to it… Promised to write up a patch, so here it comes. (It cleans up basebmp visibility handling in accordance with http://wiki.services.openoffice.org/wiki/Symbol_Visibility.) HOWEVER: Due to an unfortunate chain of events, I was unable to actually try it out right now. So, Matúš (or whoever else), if you are willing to try it out, fix the inadvertent typo, and push it, that would be great. Thanks, -Stephan 0001-Export-basebmp-debugDump-so-it-can-be-called-in-vcl-.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: 3 commits - offapi/com offapi/UnoApi_offapi.mk oovbaapi/ooo oovbaapi/UnoApi_oovbaapi.mk solenv/gbuild udkapi/UnoApi_udkapi.mk
On Sep 2, 2011, at 11:58 AM, Matus Kukan wrote: offapi/UnoApi_offapi.mk| 7859 + offapi/com/sun/star/rendering/XMtfRenderer.idl |2 oovbaapi/UnoApi_oovbaapi.mk| 2087 +++--- oovbaapi/ooo/vba/excel/XControlObject.idl |2 oovbaapi/ooo/vba/excel/XGraphicObjects.idl |2 solenv/gbuild/UnoApiTarget.mk | 66 udkapi/UnoApi_udkapi.mk| 945 +-- 7 files changed, 5753 insertions(+), 5210 deletions(-) Re adding #include XInterface.idl, IIRC Jürgen once modified idlc so that it does not fail if XInterface is not included (esp. since when inheriting merely from XInterface you no longer need to write that down --- though the .idl files in question seem to mention XInterface explicitly). Anyway, what makes me wonder is how you stumbled over those --- while changing .idl processing to work in batches (i.e., might the problem be a regression)? -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: 3 commits - offapi/com offapi/UnoApi_offapi.mk oovbaapi/ooo oovbaapi/UnoApi_oovbaapi.mk solenv/gbuild udkapi/UnoApi_udkapi.mk
On Sep 2, 2011, at 3:36 PM, Matúš Kukan wrote: On 2 September 2011 14:29, Stephan Bergmann stephan.bergmann.second...@googlemail.com wrote: On Sep 2, 2011, at 11:58 AM, Matus Kukan wrote: offapi/UnoApi_offapi.mk| 7859 + offapi/com/sun/star/rendering/XMtfRenderer.idl |2 oovbaapi/UnoApi_oovbaapi.mk| 2087 +++--- oovbaapi/ooo/vba/excel/XControlObject.idl |2 oovbaapi/ooo/vba/excel/XGraphicObjects.idl |2 solenv/gbuild/UnoApiTarget.mk | 66 udkapi/UnoApi_udkapi.mk| 945 +-- 7 files changed, 5753 insertions(+), 5210 deletions(-) Re adding #include XInterface.idl, IIRC Jürgen once modified idlc so that it does not fail if XInterface is not included (esp. since when inheriting merely from XInterface you no longer need to write that down --- though the .idl files in question seem to mention XInterface explicitly). Anyway, what makes me wonder is how you stumbled over those --- while changing .idl processing to work in batches (i.e., might the problem be a regression)? Well, you can try to revert and build oovbaapi..(or offapi but that's slow) /home/ubuntu/git/libo/oovbaapi/ooo/vba/excel/XGraphicObjects.idl:62 [1:1] : error in lookup of symbol: 'com::sun::star::uno::XInterface' /home/ubuntu/git/libo/oovbaapi/ooo/vba/excel/XGraphicObjects.idl:74 [1:1] : error in lookup of symbol, expected interface is not defined and no forward exists: '::com::sun::star::uno::XInterface' in '/ooo/vba/excel/XGraphicObjects' /home/ubuntu/git/libo/solver/unxlngi6/bin/idlc: detected 2 errors/home/ubuntu/git/libo/solver/unxlngi6/bin/idlc Version 1.1 I have no idea why it's happening, I just got errors, so I tried do get rid of them and thought this is safe and all right. OK, never mind. Safe and all right to add those includes, anyway. Just wondered why this suddenly became necessary. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] map files: how to update? [was: cppu::OPropertySetHelper ABI backwards compatibility]
On Sep 2, 2011, at 5:13 PM, Lionel Elie Mamane wrote: - For the question of which symbols for OPropertySetHelper2 to list in the various map files, see http://udk.openoffice.org/common/man/apicppclasses.html (you probably need access to builds on the various platforms to find out the correct mangled names). It does not say to export the vtable; I assume the vtable obviously has to be exported. No, need not be exported (if none of the ctors and dtors are inline). It says: If the destructor of a class is declared virtual, declare the destructors of all its base classes virtual. (To have a dedicated place where RTTI for the base classes is generated, which is referenced by the RTTI for the derived class. Since in general you cannot control the ways a class is used, the best advice probably is to do this for each class that is intended to be subclassed.) Well, we cannot do that anymore, since that would break ABI on OPropertySetHelper2. Can we safely ignore this instruction here? Yes. Revised patch attached; if it is good to go (especially with respect to questions above), I'll commit (with a better commit message). gcc3.map in the latest patch (sent this morning): - Do not export vtable (see above). - Comment out the RTTI symbols (_ZTI, _ZTS), as they are already implicitly exported in GCC_3_0_0 section via some hackery. (This implies that any _ZTI and _ZTS symbols covered by the previous point are always exported with version GCC_3_0_0, which defeats the correct use of versioning for those symbols.) - Do not export the thunks (_ZThn), not needed externally. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build break when generating RDBs
On Sep 2, 2011, at 6:28 PM, Peter Foley wrote:
On Fri, 2 Sep 2011, Stephan Bergmann wrote:
On Sep 1, 2011, at 5:33 PM, Peter Foley wrote:
On Thu, 1 Sep 2011, Eike Rathke wrote:
Hi Peter,
On Tuesday, 2011-08-30 14:36:01 -0400, Peter Foley wrote:
[ build ALL ] top level modules: i18npool
[ build ALL ] loaded modules: i18npool
[ build RDB ] i18npool_test_breakiterator
awk: cmd. line:1: $R/^\?xml version.*$R/ { next; } {
gsub($R/vnd.sun.star.expand:\$OOO_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$OOO_BASE_DIR,$0);
gsub($R/vnd.sun.star.expand:\$BRAND_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$BRAND_BASE_DIR,$0); print; }
awk: cmd. line:1:^ syntax error
awk: cmd. line:1: $R/^\?xml version.*$R/ { next; } {
gsub($R/vnd.sun.star.expand:\$OOO_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$OOO_BASE_DIR,$0);
gsub($R/vnd.sun.star.expand:\$BRAND_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$BRAND_BASE_DIR,$0); print; }
awk: cmd. line:1: ^ backslash not last character on line
make: ***
[/libreoffice/workdir/unxlngx6.pro/RdbTarget/i18npool_test_breakiterator.rdb]
Error 1
I'm getting the above build error which seems to be caused by $R being
added to the awk regex expression by gb_Helper_abbreviate_dirs.
Apparently you're the only one getting this error, so I wonder what may
be different on your system? I doubt this is a general
gb_Helper_abbreviate_dirs always inserts $R before / problem. Which
platform are you on? I presume winmingw, because that (and windows)
defines gb_Helper_abbreviate_dirs_native to something different than the
general gb_Helper_abbreviate_dirs:
I'm actually building libreoffice in a gentoo linux x64 chroot.
I don't know if the chroot is causing this problem or not.
awk is 4.0.0
make is 3.82
Let me know if you need any more info.
The path to the LibO sources within your chroot environment appears to be
too short (they are probably right in the root there, right?). Then,
gb_Helper_abbreviate_dirs will replace each occurrence of / with $R/ in
the command line. (gb_Helper_abbreviate_dirs is broken by design, but must
of the time this goes unnoticed.) Try moving the LibO sources further down
in the directory hierarchy.
-Stephan
Moving the source tree one level down did indeed fix it.
Out of curiosity could you elaborate on why building libreoffice in
/libreoffice fails?
I would have thought that you built in /, not /libreoffice. Anyway, what
breaks is that if, say, $(REPODIR) is an empty string in
gb_Helper_abbreviate_dirs (solenv/gbuild/Helper.mk), then all occurrences of /
on the command line are replaced with $R/, even those occurrences that do not
denote filepaths, like the occurrences of / in the awk argument '/^\?xml…' in
solenv/gbuild/RdbTarget.mk.
-Stephan
Thanks,
Peter
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Honor --disable-strip in gbuild.
Unlike the old dmake build system, solenv/gbuild/platform/unxgcc.mk sets -Wl,--strip-all depending on --enable-symbols only, and ignores --disable-strip altogether. Attached patch fixes that. (To avoid confusion: I recently switched my git email address, but my contributions are still under the license documented at http://lists.freedesktop.org/archives/libreoffice/2011-August/017383.html.) -Stephan From 5b1199602807152777b149cc3c30105c2064baa5 Mon Sep 17 00:00:00 2001 From: Stephan Bergmann sberg...@redhat.com Date: Tue, 6 Sep 2011 09:39:07 +0200 Subject: [PATCH] Honor --disable-strip in gbuild. --- solenv/gbuild/gbuild.mk |6 ++ solenv/gbuild/platform/unxgcc.mk |8 +--- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/solenv/gbuild/gbuild.mk b/solenv/gbuild/gbuild.mk index 48bebeb..329eefa 100644 --- a/solenv/gbuild/gbuild.mk +++ b/solenv/gbuild/gbuild.mk @@ -87,6 +87,12 @@ else gb_SYMBOL := $(false) endif +ifeq ($(strip $(DISABLE_STRIP)$(disable_strip)),) +gb_STRIP := $(true) +else +gb_STRIP := $(false) +endif + gb_DEBUGLEVEL := 0 ifneq ($(strip $(DEBUG)$(debug)),) gb_DEBUGLEVEL := 1 diff --git a/solenv/gbuild/platform/unxgcc.mk b/solenv/gbuild/platform/unxgcc.mk index 4234c71..5c71bd4 100644 --- a/solenv/gbuild/platform/unxgcc.mk +++ b/solenv/gbuild/platform/unxgcc.mk @@ -163,9 +163,11 @@ gb_LinkTarget_LDFLAGS += \ endif ifneq ($(gb_SYMBOL),$(true)) -gb_LinkTarget_LDFLAGS += \ - -Wl,--strip-all \ - +ifeq ($(gb_STRIP),$(true)) +gb_LinkTarget_LDFLAGS += -Wl,--strip-all +else +gb_LinkTarget_LDFLAGS += -Wl,--strip-debug +endif endif ifneq ($(gb_DEBUGLEVEL),0) -- 1.7.6 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Honor --disable-strip in gbuild.
On 09/06/2011 09:58 AM, Norbert Thiebaud wrote: On Tue, Sep 6, 2011 at 2:51 AM, Stephan Bergmannsberg...@redhat.com wrote: Unlike the old dmake build system, solenv/gbuild/platform/unxgcc.mk sets -Wl,--strip-all depending on --enable-symbols only, and ignores --disable-strip altogether. Attached patch fixes that. doesn't that also apply to macosx.mk ? Only if gbuild would strip on Mac OS X (which it does not, and which is another issue). -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] frm::OInterfaceContainer::insertByIndex must not crash for null argument.
Found a regression from a recent Disable fake VBA events for the
old-style form controls commit that causes the forms/qa/unoapi check to
fail. Attached patch fixes it.
-Stephan
From 9bea29af5a3fd86031e28bb8b4ca3f445f3eca96 Mon Sep 17 00:00:00 2001
From: Stephan Bergmann sberg...@redhat.com
Date: Tue, 6 Sep 2011 10:58:50 +0200
Subject: [PATCH] frm::OInterfaceContainer::insertByIndex must not crash for
null argument.
Regression introduced with 4fae740db79d4e7cc97440e2bab8d1ef612d9b51;
caused forms/qa/unoapi check to fail.
---
forms/source/misc/InterfaceContainer.cxx | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/forms/source/misc/InterfaceContainer.cxx
b/forms/source/misc/InterfaceContainer.cxx
index af24414..ff5b9c7 100644
--- a/forms/source/misc/InterfaceContainer.cxx
+++ b/forms/source/misc/InterfaceContainer.cxx
@@ -827,14 +827,6 @@ void OInterfaceContainer::implInsert(sal_Int32 _nIndex,
const Reference XProper
sal_Bool _bEvents, ElementDescription* _pApprovalResult, sal_Bool _bFire )
throw( IllegalArgumentException )
{
const bool bHandleEvents = _bEvents m_xEventAttacher.is();
-bool bHandleVbaEvents = false;
-try
-{
-_rxElement-getPropertyValue(rtl::OUString(
RTL_CONSTASCII_USTRINGPARAM(GenerateVbaEvents) ) ) = bHandleVbaEvents;
-}
-catch( const Exception )
-{
-}
// SYNCHRONIZED -
::osl::ClearableMutexGuard aGuard( m_rMutex );
@@ -890,6 +882,14 @@ void OInterfaceContainer::implInsert(sal_Int32 _nIndex,
const Reference XProper
// - SYNCHRONIZED
// insert faked VBA events?
+bool bHandleVbaEvents = false;
+try
+{
+_rxElement-getPropertyValue(rtl::OUString(
RTL_CONSTASCII_USTRINGPARAM(GenerateVbaEvents) ) ) = bHandleVbaEvents;
+}
+catch( const Exception )
+{
+}
if ( bHandleVbaEvents )
{
Reference XEventAttacherManager xMgr (
pElementMetaData-xInterface, UNO_QUERY );
--
1.7.6
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] frm::OInterfaceContainer::insertByIndex must not crash for null argument.
On 09/06/2011 12:25 PM, Noel Power wrote: Hi Stephan, On 06/09/11 10:07, Stephan Bergmann wrote: Found a regression from a recent Disable fake VBA events for the old-style form controls commit that causes the forms/qa/unoapi check to fail. Attached patch fixes it. -Stephan thanks for fixing, ( I see Caolán pushed ) btw what exactly was null /me just doesn't see where/why moving the getPropertyValue makes a difference. The unoapi tests call insertByIndex with a null interface, approveNewElement called from OInterfaceContainer::implInsert checks for null and throws an exception, but your modification accessed _rxElement before it got passed to approveNewElement. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] map files: how to update? [was: cppu::OPropertySetHelper ABI backwards compatibility]
On 09/06/2011 06:39 PM, Lionel Elie Mamane wrote: On Mon, Sep 05, 2011 at 09:57:30AM +0200, Stephan Bergmann wrote: - For the question of which symbols for OPropertySetHelper2 to list in the various map files, see http://udk.openoffice.org/common/man/apicppclasses.html (you probably need access to builds on the various platforms to find out the correct mangled names). gcc3.map in the latest patch (sent this morning): - Do not export the thunks (_ZThn), not needed externally. They are exported for just about every other class in that file; that is then also a historical error? Noticed that too. Yes, either historical error or due to something being inline that should not be. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] fix for fdo#33960 cross reference to a list number, dot bug makes sw/qa/complex/writer fail
At least with recent git trunk builds, make subsequentcheck fails in sw with
1) checkCrossReferences(complex.writer.CheckCrossReferences)
org.junit.ComparisonFailure: set reference field format doesn't result in correct field
result expected: 1[.] but was: 1[]
at org.junit.Assert.assertEquals(Assert.java:123)
at
complex.writer.CheckCrossReferences.checkField(CheckCrossReferences.java:120)
at
complex.writer.CheckCrossReferences.checkCrossReferences(CheckCrossReferences.java:176)
This appears to be caused by the fix for
https://bugs.freedesktop.org/show_bug.cgi?id=33960 cross reference to
a list number, dot bug, which removes the trailing . from
SwNumRule::MakeRefNumString.
The question is, is the below patch (which makes that subsequentcheck
failure go away) right in adapting the failing test to the new code, or
does this failure actually uncover unwanted side effects of the new code
(I'm esp. unsure about changing A. 1. to A 1)?
diff --git a/sw/qa/complex/writer/CheckCrossReferences.java
b/sw/qa/complex/writer/CheckCrossReferences.j
index cc7fcb1..597a14f 100644
--- a/sw/qa/complex/writer/CheckCrossReferences.java
+++ b/sw/qa/complex/writer/CheckCrossReferences.java
@@ -145,9 +145,9 @@ public class CheckCrossReferences {
final String FldResult1 = *i*;
final String FldResult2 = +b+*i*;
final String FldResult3 = -1-+b+*i*;
-final String FldResult4 = 1.;
-final String FldResult5 = 1.;
-final String FldResult6 = A. 1.;
+final String FldResult4 = 1;
+final String FldResult5 = 1;
+final String FldResult6 = A 1;
// variables for current field
com.sun.star.text.XTextField xField = null;
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] build system patches
On 09/07/2011 03:14 AM, Norbert Thiebaud wrote: On Tue, Sep 6, 2011 at 5:32 PM, Peter Foleypefol...@verizon.net wrote: Hi, Here are some patches for various problems I encountered while building libreoffice. 0001-libcrnf.a is that a consequence of http://cgit.freedesktop.org/libreoffice/core/commit/?id=291b85778669b4e4e276faab22add9d0e80046df ? I would suspect so. That one apparently also broke my Mac OS X build, but I did not yet find time to look into it. (What fits somewhat nicely is that it shows up in a chroot build. My impression from the Mac OS X build failure logs was that building moz now inadvertently takes certain libraries from the system, instead of from (now) intended to be built in nss vs. (before) being built as part of building moz itself, and those libraries are not present, on Mac OS X nor in a chroot. Something like that.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] build system patches
On 09/07/2011 10:28 AM, Norbert Thiebaud wrote: On Wed, Sep 7, 2011 at 1:47 AM, Stephan Bergmannsberg...@redhat.com wrote: On 09/07/2011 03:14 AM, Norbert Thiebaud wrote: On Tue, Sep 6, 2011 at 5:32 PM, Peter Foleypefol...@verizon.netwrote: Hi, Here are some patches for various problems I encountered while building libreoffice. 0001-libcrnf.a is that a consequence of http://cgit.freedesktop.org/libreoffice/core/commit/?id=291b85778669b4e4e276faab22add9d0e80046df ? I would suspect so. That one apparently also broke my Mac OS X build, but I did not yet find time to look into it. (What fits somewhat nicely is that it shows up in a chroot build. My impression from the Mac OS X build failure logs was that building moz now inadvertently takes certain libraries from the system, instead of from (now) intended to be built in nss vs. (before) being built as part of building moz itself, and those libraries are not present, on Mac OS X nor in a chroot. Something like that.) humm.. and that would also explain the 0002- patch (well not the patch but the reason that motivated it) I think you are right, and maybe the commit above should be revisited in light of these... (I means instead of papering over the symptom :-) ) Yes, definitely dig in and try to understand the root cause, than fixing the symptoms. Putting kendy as the author of the above changeset on cc. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] map files: how to update? [was: cppu::OPropertySetHelper ABI backwards compatibility]
On 09/07/2011 12:14 PM, Lionel Elie Mamane wrote: On Mon, Sep 05, 2011 at 09:57:30AM +0200, Stephan Bergmann wrote: On Sep 2, 2011, at 5:13 PM, Lionel Elie Mamane wrote: I assume the vtable obviously has to be exported. No, need not be exported (if none of the ctors and dtors are inline). Ah, I had not declared the copy constructor and assignment operator well, which led to the vtable being necessary to export. That is fixed now. good Revised patch attached; if it is good to go (especially with respect to questions above), I'll commit (with a better commit message). gcc3.map in the latest patch (sent this morning): - Do not export the thunks (_ZThn), not needed externally. Well, the build fails if they are not exported. So for now, I export them. If the fact that they are needed comes from an error in the class design, please let me know what to do to fix that. Hm, had *thought* they were not really needed, and had run a small test case to verify, but it seems there are nevertheless cases where they *are* needed. If you have no inline functions left (neither implicit nor explicit ones, incl. default functions provided by the compiler), then poor class design cannot be the reason. -- Just export them, I would say. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build only xpcom in moz: not working
On 09/07/2011 12:36 PM, Lionel Elie Mamane wrote: In your commit 291b85778669b4e4e276faab22add9d0e80046df (Build our mozilla (module moz) against the nss we have built anyway.) [...] Doing make only in xpcom fails from a clean state (some files that are needed are not built), so I've completely reverted that hunk for now. Feel free to do whatever you meant by this hunk in a way that works :) see also thread around http://lists.freedesktop.org/archives/libreoffice/2011-September/017824.html -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
On 09/07/2011 04:37 PM, Eike Rathke wrote: Hi Regina, On Wednesday, 2011-09-07 15:04:47 +0200, Regina Henschel wrote: I see a lot of sal_uInt64 in the code. Is that supported for Windows? As far as I know at least the MSVC Express has only 4Byte long. Umm.. now that you mention.. sal/inc/sal/types.h has #if (_MSC_VER= 1000) typedef __int64 sal_Int64; typedef unsigned __int64 sal_uInt64; so what evaluates _MSC_VER to in MSVCE? Also noticing there #define SAL_CONST_UINT64(x) x##ui64 so the constant I introduced probably should use that. If MSVCE doesn't support 64bit values I might do some tricks using the double mantissa. But we use sal_[u]Int64 all over the code base, and the default case in sal/types.h (to typedef it to a struct of smaller ints) is long gone, so I would assume _MSC_VER=1000 really means any _MSC_VER here. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] cppcheck cleanliness: duplicate expression
On 09/08/2011 01:44 AM, Eike Rathke wrote: Hi Korrawit, On Wednesday, 2011-09-07 22:01:09 +0700, Korrawit Pruegsanusak wrote: Attached patch will clear the cppcheck warning for duplicate expression on both sides of ''. Yup, good catch! http://cgit.freedesktop.org/libreoffice/core/commit/?id=a58ed493e572fef2c503bd329e924bb062ba9c96 Thanks Eike Korrawit, Eike, did you check the context to verify that it should really read a.nChar1 == a.nChar2 instead of a.nChar1 == b.nChar1 in the second term of (a.nChar1 b.nChar1) || ((a.nChar1 == a.nChar2) (a.nChar2 b.nChar2)) ? Somehow, that expression still looks suspicious. (At least, it does not implement a lexicographical less-than relation. Not sure whether it should or not, however.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] cppcheck cleanliness: duplicate expression
On 09/08/2011 08:18 AM, Stephan Bergmann wrote: On 09/08/2011 01:44 AM, Eike Rathke wrote: Hi Korrawit, On Wednesday, 2011-09-07 22:01:09 +0700, Korrawit Pruegsanusak wrote: Attached patch will clear the cppcheck warning for duplicate expression on both sides of ''. Yup, good catch! http://cgit.freedesktop.org/libreoffice/core/commit/?id=a58ed493e572fef2c503bd329e924bb062ba9c96 Thanks Eike Korrawit, Eike, did you check the context to verify that it should really read a.nChar1 == a.nChar2 instead of a.nChar1 == b.nChar1 in the second term of (a.nChar1 b.nChar1) || ((a.nChar1 == a.nChar2) (a.nChar2 b.nChar2)) ? Somehow, that expression still looks suspicious. (At least, it does not implement a lexicographical less-than relation. Not sure whether it should or not, however.) Now actually looking at the context: Given that CmpKernData in vcl/source/gdi/outdev3.cxx is (only) used as an argument to std::sort, I'm pretty sure it must read (a.nChar1 == b.nChar1) to make that a true strict weak ordering, as required by std::sort. Pushed as http://cgit.freedesktop.org/libreoffice/core/commit/?id=8b7978c822b11c53b4bd40bb0829e3ec205f1359. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] configure.in monstrosity
On 09/08/2011 02:50 PM, Tomáš Chvátal wrote: I was editing the configure.in file in order to fix one tiny bug and found out it is horrible scarry place. It would be really nice if that huge file would be split into several separate parts per-use. So I would like to propose slow cleanup/splitting to have simple configure.ac with platform check, and then i would move each configure option and switches into per feature macros in m4/. This way we could easily overview all the options, and it would also improve the readability. What do you think about this? Sounds sane. Also, there are dependencies between some of the checks, forcing them into a specific order, which is rather brittle, anyway. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppcheck duplicate if expressions in bulmaper.cxx (sd part)
On 09/08/2011 10:47 PM, julien2412 wrote:
Here is the pb :
if( 0 )--- Found duplicate if expressions.
{
nFontID = EE_CHAR_FONTINFO_CJK;
nFontHeightID = EE_CHAR_FONTHEIGHT_CJK;
nWeightID = EE_CHAR_WEIGHT_CJK;
nPostureID = EE_CHAR_ITALIC_CJK;
}
else if( 0 )
{
nFontID = EE_CHAR_FONTINFO_CTL;
nFontHeightID = EE_CHAR_FONTHEIGHT_CTL;
nWeightID = EE_CHAR_WEIGHT_CTL;
nPostureID = EE_CHAR_ITALIC_CTL;
}
I checked the history, it's there since 16/11/2000 (commit
5dc708093d1ee179099abdcbf0c6f649b1c4deeb)
could anyone explain to me the purpose of this ? Just a typo ?
It's preceded by comment to be implemented if module supports CJK a
few lines above at sd/source/ui/func/bulmaper.cxx:73, so I would say its
something like commented-out code that still awaits implementation...
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: sal/inc
On 09/07/2011 02:56 PM, Bjoern Michaelsen wrote: sal/inc/sal/types.h | 16 1 file changed, 16 insertions(+) New commits: commit de290e726ed2aa5a4c007d61a7db1042c45d43db Author: Bjoern Michaelsenbjoern.michael...@canonical.com Date: Wed Sep 7 12:37:08 2011 +0200 introduce SAL_DEPRECATED macro Is it true that __declspec must go before the return type for MSC (i.e., that the return type must go within the SAL_DEPRECATED argument)? Then, SAL_DEPRECATED suffers from the multiple-argument template return type unpleasantness described at http://stackoverflow.com/questions/295120/c-mark-as-deprecated/295229#295229. :( -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Cppcheck defect when @ is present
On 09/11/2011 01:27 PM, Pierre-André Jacquod wrote: What's the best thing to do : - to keep objective C++ parts ? - to replace objective C++ by plain (with or without boost) C++ ? for me there are already too many languages and flavour of languages. I would stay with plain C++, not adding objective C++ on top In the Mac OS X specific code parts, we do need Objective C code, to interface the relevant Mac APIs. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Mi first very little patch
On 09/12/2011 01:03 AM, Lionel Elie Mamane wrote: On Sun, Sep 11, 2011 at 10:04:52PM +0200, CaStarCo wrote: I've created a second (very little too) patch to reduce the scope of a variable. --- a/sal/osl/w32/file_dirvol.cxx +++ b/sal/osl/w32/file_dirvol.cxx @@ -60,7 +60,6 @@ extern C BOOL TimeValueToFileTime(const TimeValue *cpTimeVal, FILETIME *pFTime Thank you for your contribution to LibreOffice, it is most welcome. Looking at that function in that file, it needs a more thorough cleanup, and maybe other functions in that file and/or in other files in the same directory; see http://msdn.microsoft.com/en-us/library/ms724284%28v=VS.85%29.aspx, in particular: [...] Also, the scope of localTime can be reduced even further, changing the line that assigns it into also declaring it, as in __int64 localTime = cpTimeVal-...; -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] From sal/cppunit.h to sal/precppunit.hxx
Hi all, With http://cgit.freedesktop.org/libreoffice/core/commit/?id=d996328cd5f46eeed2df0cbd510eda28e2f7cef9 come three changes for CppUnit based tests in the LibO code base: - The header sal/cppunit.h has been removed (and it was not used much). - There is a new header sal/precppunit.hxx that should be included in every file (.hxx or .cxx) that includes any cppunit/... headers. What it does at the moment is override CPPUNIT_PLUGIN_EXPORT (see next), but it might get extended in the future. This means that the first headers included into any file (.hxx or .cxx) should now follow the pattern [#include precompiled_XXX.hxx] #include sal/config.h [#include sal/precppunit.hxx] - The overridden CPPUNIT_PLUGIN_EXPORT exports the cppunitTestPlugIn function via symbol visibility, so there is no longer a need to export it via a map file. (For dmake-based code, that means use VISIBILITY_HIDDEN=TRUE and SHLnUSE_EXPORTS=name instead of SHLnVERSIONMAP=... This feature was also already available with the old sal/cppunit.h, but lots of places in the code still used map files. I changed this to exclusively use symbol visibility now.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH] convert xml2cmp to gbuild
On 09/12/2011 11:23 PM, Norbert Thiebaud wrote: On Mon, Sep 12, 2011 at 4:04 PM, Peter Foleypefol...@verizon.net wrote: Another gbuild conversion. Nice. Pushed, Thanks. It ~looks like this broke the latest Mac OSX gcc-4.0.1 (PPC) tinderbox build, see http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTERbrief-log=1315881022.32373. (Though I have no clue what went wrong; at least cannot easily reproduce on unxlngx6.pro.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH] convert xml2cmp to gbuild
On 09/13/2011 08:18 AM, Stephan Bergmann wrote: On 09/12/2011 11:23 PM, Norbert Thiebaud wrote: On Mon, Sep 12, 2011 at 4:04 PM, Peter Foleypefol...@verizon.net wrote: Another gbuild conversion. Nice. Pushed, Thanks. It ~looks like this broke the latest Mac OSX gcc-4.0.1 (PPC) tinderbox build, see http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTERbrief-log=1315881022.32373. (Though I have no clue what went wrong; at least cannot easily reproduce on unxlngx6.pro.) I think the problem is using static libraries. IIRC, on Mac OS X, if you link against two static libs -lA -lB, order is important, and if B need symbols from A (that the executable into which the two are linked does not already take from A), it won't find them. What could help in this specific case is to switch the order of x2c_support and x2c_xcd in xml2cmp/Executable_*.mk. (Will try that out on my Mac, but that can take a while. Another solution might be to use Mac OS X ld switches -all_load or -force_load.) In general, I think using static libraries to link individual objects into multiple dynamic libraries or executables will not work smoothly across all our platforms. (I experimented with that earlier this year, thinking that it might help write CppUnit tests that can access private symbols of to-be-tested dynamic libraries, but only got lost in problems.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] fix for fdo#33960 cross reference to a list number, dot bug makes sw/qa/complex/writer fail
On 09/07/2011 11:15 PM, Troy Rollo wrote: On Wednesday 07 September 2011, Stephan Bergmann wrote: Troy, will you come up with a fix that brings sw/source/core/doc/number.cxx and sw/qa/complex/writer/CheckCrossReferences.java in sync again? I won't be able to do that until mid November due to other commitments. Reopened https://bugs.freedesktop.org/show_bug.cgi?id=33960 cross reference to a list number, dot bug and disabled the failing tests as http://cgit.freedesktop.org/libreoffice/core/commit/?id=e849071acc91cafd05d52326e6a5cccf750836c1 fdo#33960#, fdo#35690#: Disabled failing checkCrossReferences tests for now. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build
On 09/13/2011 01:00 AM, Norbert Thiebaud wrote: On Mon, Sep 12, 2011 at 4:53 PM, Michael Stahlm...@openoffice.org wrote: On 12.09.2011 23:26, Peter Foley wrote: --- a/MathMLDTD/prj/build.lst +++ b/MathMLDTD/prj/build.lst @@ -1,3 +1,2 @@ -md MathMLDTD : solenv NULL -md MathMLDTD usr1- all md_mkout NULL -md MathMLDTD\prj get - all md_prj NULL +md MathMLDTD : NULL you remove the dependency on solenv; it seems that currently we don't have any module (except solenv of course, and testautomation which doesn't do anything) that does not directly or indirectly depend on solenv; i wonder why that is? is there perhaps some reason that modules must depend on solenv? isn't that for the basic setup of solver ? (mkdir od bin inc etc..) but I believe Deliver.mk do the mkdir by precaution anyways.. so that should no have any impact here.. But that might explain the strange tinderbox failure at http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTERfull-log=1315879214.25561, a missing 350minor.mk early one, where xml2cmp is one of the first three modules being built (in parallel). -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build
On 09/13/2011 11:18 AM, Michael Stahl wrote: On 13.09.2011 11:09, Stephan Bergmann wrote: On 09/13/2011 01:00 AM, Norbert Thiebaud wrote: On Mon, Sep 12, 2011 at 4:53 PM, Michael Stahlm...@openoffice.org wrote: On 12.09.2011 23:26, Peter Foley wrote: --- a/MathMLDTD/prj/build.lst +++ b/MathMLDTD/prj/build.lst @@ -1,3 +1,2 @@ -md MathMLDTD : solenv NULL -md MathMLDTD usr1- all md_mkout NULL -md MathMLDTD\prj get - all md_prj NULL +md MathMLDTD : NULL you remove the dependency on solenv; it seems that currently we don't have any module (except solenv of course, and testautomation which doesn't do anything) that does not directly or indirectly depend on solenv; i wonder why that is? is there perhaps some reason that modules must depend on solenv? isn't that for the basic setup of solver ? (mkdir od bin inc etc..) but I believe Deliver.mk do the mkdir by precaution anyways.. so that should no have any impact here.. But that might explain the strange tinderbox failure at b, a missing 350minor.mk early one, where xml2cmp is one of the first three modules being built (in parallel). -Stephan thanks for reminding me, 3X0minor.mk was the thing that i only vaguely remembered. apparently it's still necessary in converted modules because we start gmake indirectly via dmake. guess somebody should put back the solenv deps :) doing it right now -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH] convert xml2cmp to gbuild
On 09/13/2011 08:40 AM, Stephan Bergmann wrote: On 09/13/2011 08:18 AM, Stephan Bergmann wrote: On 09/12/2011 11:23 PM, Norbert Thiebaud wrote: On Mon, Sep 12, 2011 at 4:04 PM, Peter Foleypefol...@verizon.net wrote: Another gbuild conversion. Nice. Pushed, Thanks. It ~looks like this broke the latest Mac OSX gcc-4.0.1 (PPC) tinderbox build, see http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTERbrief-log=1315881022.32373. (Though I have no clue what went wrong; at least cannot easily reproduce on unxlngx6.pro.) I think the problem is using static libraries. IIRC, on Mac OS X, if you link against two static libs -lA -lB, order is important, and if B need symbols from A (that the executable into which the two are linked does not already take from A), it won't find them. What could help in this specific case is to switch the order of x2c_support and x2c_xcd in xml2cmp/Executable_*.mk. (Will try that out on my Mac, but that can take a while. Another solution might be to use Mac OS X ld switches -all_load or -force_load.) Hm, can't reproduce the problem on my Mac OS X 10.6 box. Strange. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build
On 09/13/2011 11:20 AM, Stephan Bergmann wrote: On 09/13/2011 11:18 AM, Michael Stahl wrote: guess somebody should put back the solenv deps :) doing it right now http://cgit.freedesktop.org/libreoffice/core/commit/?id=9f78448b9423d0b33d8ef372dc67a1903b31 -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] From sal/cppunit.h to sal/precppunit.hxx
On 09/13/2011 11:50 AM, Lubos Lunak wrote: On Monday 12 of September 2011, Stephan Bergmann wrote: Hi all, With http://cgit.freedesktop.org/libreoffice/core/commit/?id=d996328cd5f46eeed2 df0cbd510eda28e2f7cef9 come three changes for CppUnit based tests in the LibO code base: Please update http://wiki.documentfoundation.org/Development/Unit_Tests to match the current status. done ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Linux plumbers 2011: large application startup slidedeck
On 09/14/2011 10:31 AM, Caolán McNamara wrote: Taras Glek's slidedeck about firefox, etc. startup performance http://people.mozilla.com/~tglek/lpc2011/ Some goodies. On the relatively low-hanging fruit side of things... [...] b) fadvise(WILLNEED) before dlopen ? http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-04/msg01396.html http://sourceware.org/bugzilla/show_bug.cgi?id=11431 https://bugzilla.mozilla.org/show_bug.cgi?id=554421 Covered by our pagein hackery, so given the apparent reluctance to add advise to ld.so, we will have to keep it around for now... -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Linux plumbers 2011: large application startup slidedeck
On 09/14/2011 11:48 AM, Caolán McNamara wrote: On Wed, 2011-09-14 at 11:17 +0200, Stephan Bergmann wrote: On 09/14/2011 10:31 AM, Caolán McNamara wrote: Taras Glek's slidedeck about firefox, etc. startup performance http://people.mozilla.com/~tglek/lpc2011/ Some goodies. On the relatively low-hanging fruit side of things... [...] b) fadvise(WILLNEED) before dlopen ? http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-04/msg01396.html http://sourceware.org/bugzilla/show_bug.cgi?id=11431 https://bugzilla.mozilla.org/show_bug.cgi?id=554421 Covered by our pagein hackery, so given the apparent reluctance to add advise to ld.so, we will have to keep it around for now... Though the pagein list was created once, and isn't really reviewed regularly ? There was definitely a period of a few months a year or two ago when the pagein list contained libraries which had been removed, so are we confident that the list that's there at the moment make sense ? Guess no (not well maintained). So, sure, a more generic approach would be better, not the least from a maintenance viewpoint. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] duplicateif in vcl/source/gdi/outdev3.cxx
On 09/14/2011 08:47 PM, julien2412 wrote: Since I don't know the impact I prefer proposing a review. Of course, if you're really sure of you Eike (:-) ), I can commit and push right away on master http://nabble.documentfoundation.org/file/n3336763/patch_outdev3.txt patch_outdev3.txt Looking at the code, I am pretty sure the first use of nMatchType should be nSearchType instead. That is, the code should check whether nSearchType and nMatchType have differing settings of OTHERSTYLE and then pessimize nTestMatch by 10,000. Pushed now as http://cgit.freedesktop.org/libreoffice/core/commit/?id=b6cccb9e77111254932ebcf96f883aab04cb3f56. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] gbuildized xml2cmp breaks Windows (was: Tinderbox failure, last success: 2011-09-13 20:44:55)
On 09/15/2011 09:11 AM, Stephan Bergmann wrote: http://cgit.freedesktop.org/libreoffice/core/commit/?id=e728feaeebae96df5566bdb6d5f0458983d843ad On Windows, xml2cmp depends on uwinapi from sal. should probably fix the below problem. Turns out that that fix (making xml2cmp depend on sal) introduced a circular dependency (as sal already depends on xml2cmp). The problem is that before gbuildization, xml2cmp was careful not to link against uwinapi (via UWINAPILIB=$(0) in xml2cmp/util/makefile.mk); this needs to be re-implemented in gbuild. -Stephan On 09/15/2011 08:47 AM, ke...@suse.cz wrote: Hi folks, One of you broke the build of LibreOffice with your commit :-( Please commit and push a fix ASAP! Full log available at http://tinderbox.libreoffice.org/MASTER/status.html Tinderbox info: Box name: Windows XP SP3 Machine: CYGWIN_NT-5.1 steve 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin Configured with: --disable-directx --disable-mozilla --without-junit --disable-binfilter --with-ant-home=/home/kendy/apache-ant-1.8.1 Commits since the last success: core 45589f1 gbuildize automation 6c8a7e0 pass -s flag to custom target's make process a3c3d70 be silent c79e42d be silent c40f634 work silently for make -s 37356b7 allow to specify additional deps for zip target 0510c98 WaE: declaration of 'index' shadows a global declaration b2d9db4 WaE: declaration of 'i' shadows a previous local 30bf29f WaE: declaration of 'j' shadows a previous local 7a7f10e forgot another csv file 4fe0797 add formats test for xls and xlsx 2b75f59 improve calc's format unit test 032fca6 deliver libcrmf.a 0c113d8 Fix of localised template name problems in Impress part 1 b6cccb9 Fix nSearchType vs. nMatchType typo and simplify resulting code. fb1e454 Don't always set refresh flag on export. This is a bad hack. 2f65414 Check the source range when refreshing, and abort refresh if invalid. 932ee04 Introduced CHECK_PARALLELISM (and poshed the code up). a75cb23 default shortcut for .uno:SearchDialog should be Ctrl+H 27dcdb1 New unit test case for testing SHEETS function result. dd482fd do not try to read from an iterator which we just deleted from the container e26ea36 Revert Revert i#118224: kill O(n^2) complexity of unique bookmark name creation 9015c60 Do the same when calling ScDocument::InsertTabs(). 892f8b5 fdo#35965: Mark all formula cells dirty when appending a new sheet. b7998b6 No need to bark about G_SLICE on stderr. 188696a don't crash b7912ec don't quote ???x??? 0a97ece merge srvdepy functions into xml2cmp and simplify xml2cmp gbuild 8578e3c Related: fdo#40599 add a initial basic test for deleting graphics c046147 Folded smoketestdoc back into smoketestoo_native; no need to have it separated. 05a6605 Revert i#118224: kill O(n^2) complexity of unique bookmark name creation 387620b Removed solenv/bin/subsequenttests, moved its (improved) content directly into Makefile.in. 109ca35 Added more missing dependencies on solenv back into build.lsts. 333648c added twofold affix+compound to hunspell, as the official fixed https://sourceforge.net/tracker/index.php?func=detailaid=3288562group_id=143754atid=756395 6caaa5e default to -r on gbuild for performance (assumed esp. on make 3.82) 79dc19f ByteString-rtl::OStringBuffer 98ae11b pointless foo 33aa323 callcatcher: remove unused code 4a3db11 ImplUpdateStringFromUniString is now dangling 1cd1e4a use read_uInt8s_AsOString here 84db141 forgot the csv file for number formats 61732a8 add unit test for formated cells b6d3f5c ScCompiler::IsDBRange compares upper case strings ba361f9 add database unit test 32ca2cb Updated csv_parser from orcus. 689bde9 Some cppcheck cleaning dictionaries help The error is: build failed - error is:: log for /cygdrive/c/libo/xml2cmp/prj cd .. make -s -r -j1 make -s -r deliverlog [ info ALL ] LinkTarget Library/uwinapi.lib not defined: Assuming headers to be there! [ info ALL ] LinkTarget Library/advapi32.lib not defined: Assuming headers to be there! [ build CXX ] xml2cmp/source/xcd/main [ build CXX ] xml2cmp/source/support/cmdline [ build CXX ] xml2cmp/source/support/heap [ build CXX ] xml2cmp/source/support/sistr [ build CXX ] xml2cmp/source/support/syshelp [ build CXX ] xml2cmp/source/support/badcast [ build CXX ] xml2cmp/source/xcd/cr_html [ build CXX ] xml2cmp/source/xcd/cr_index -- [ build CXX ] xml2cmp/source/xcd/cr_metho [ build CXX ] xml2cmp/source/xcd/filebuff [ build CXX ] xml2cmp/source/xcd/parse [ build CXX ] xml2cmp/source/xcd/xmlelem [ build CXX ] xml2cmp/source/xcd/xmltree [ build CXX ] xml2cmp/source/xcd/dependy [ build DEP ] LNK:Executable/xml2cmp.exe [ build DEP ] LNK:Executable/xml2cmp.exe [ build DEP ] LNK:Executable/xml2cmp.exe [ build LNK ] Executable/xml2cmp.exe Microsoft (R) Incremental Linker Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. c:/libo/workdir/wntmsci12.pro/CxxObject/xml2cmp/source/xcd/main.o c:/libo/workdir/wntmsci12.pro/CxxObject/xml2cmp/source/support
Re: [Libreoffice] Bug in XclImpOutlineBuffer::MakeScOutline ?
On 09/15/2011 12:42 AM, julien2412 wrote: I'm trying to open a quite big xls file (sorry, I'm allowed to publish it). Here are the 4 types of error in logs : [...] Error: UniString::SearchAndReplaceAllAscii() - pAsciiStr include characters 127 From File /home/maryline/compile-libreoffice/libo/tools/source/string/strascii.cxx at Line 628 After some research to confirm first thought, some characters in the file have an ascii code 127 and LO doesn't like. Ok why not. Error: UniString::SearchAscii() - pAsciiStr include characters 127 From File /home/maryline/compile-libreoffice/libo/tools/source/string/strascii.cxx at Line 566 not same line in the file but same error as above But even if those complaints are about characters that actually originated in the xls file (instead of characters coming statically from the source code itself, a la some RTL_CONSTASCII_USTRINGPARAM(non-ASCII-here) mistake), it is a mistake that the code thinks it should treat them as ASCII. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
On 09/15/2011 11:37 AM, Michael Stahl wrote: i think somebody once told me that the last remaining functions are only required on Windows 2000, and if we raised the baseline to Windows XP then it would be unnecessary. any idea if that is true? No, looks like snprintf etc. from uwinapi are still needed on recent Windows, as Windows' _snprintf etc. are not standards conformant (see http://stackoverflow.com/questions/1270387/are-snprintf-and-friends-safe-to-use), and there still appear to be no standards conformant true snprintf etc. in the Windows API. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
On 09/15/2011 11:13 AM, Tor Lillqvist wrote:
OK, clearly the time now has come to get rid of uwinapi completely.
Our uwinapi.dll only contains four functions nowadays: snprintf,
snwprintf, vsnprintf and vsnwprintf. We should move those to sal or
something. And for those pesky binary extensions that might want an
ABI stable uwinapi.dll, let's just keep around one from 3.3 or 3.2
times and include it in the installer.
But instead of moving those functions to, say, sal, why not keep them in
a library called uwinapi.dll? And do the clean-up of not including that
library implicitly in every linker call on Windows (i.e., remove it from
gb_STDLIBS and old STD{LIB,SHL}{GUI,CUI}MT), but explicitly in only
those that actually use it.
(A drawback of moving those functions to sal is that it could easily
lead us into a similar situation in the future as we have today. If,
for example, Windows one day will make conforming versions of those
functions available and we would like to remove them from our code base,
external code more-or-less accidentally binding against the versions
from sal might give us a hard time removing them again.)
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
On 09/15/2011 12:36 PM, Tor Lillqvist wrote: Patches welcome. Sounds doable (if I find access to a Windows box). -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
On 09/15/2011 02:57 PM, Fridrich Strba wrote:
Stefan,
On Thu, 2011-09-15 at 12:10 +0200, Stephan Bergmann wrote:
But instead of moving those functions to, say, sal, why not keep them in
a library called uwinapi.dll? And do the clean-up of not including that
library implicitly in every linker call on Windows (i.e., remove it from
gb_STDLIBS and old STD{LIB,SHL}{GUI,CUI}MT), but explicitly in only
those that actually use it.
I would even contend to detect the code that uses those functions and
see whether they cannot be fixed in the code itself. The problem now is
that if there are extensions out there that are linking with uwinapi.dll
(and there is actually one that we know about), they are for sure not
linking with the uwinapi.dll that comes with LO 3.4.x, but with
something from 3.3.x. The ABI of this library changed (maybe by mistake)
between 3.3.x and 3.4.x release cycles.
Do you know in what way it changed?
My suggestion would be -- for windows builds -- not to link with
uwinapi.dll at all and detect the use of the snprintf functions and
check whether they actually need to be compliant in that particular use
and if yes, do some magic around them. For instance, in libwpd I do
this:
http://libwpd.git.sourceforge.net/git/gitweb.cgi?p=libwpd/libwpd;a=blob;f=src/lib/WPXString.cpp;h=b9da3124fe47641ec446cadb284379215d7aaa8a;hb=HEAD#l136
This would have the merit of not linking with uwinapi.dll anymore and
not to distribute any headers/import libraries for it in our SDK, so
that extension-writers can little-by-little move out of it.
In the SDK, I would not distribute anything for it, anyway. This should
really be something private (which is in line with ure/source/README
flagging it as private).
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuild question
On 09/17/2011 06:19 AM, Norbert Thiebaud wrote: On Fri, Sep 16, 2011 at 7:07 PM, Peter Foleypefol...@verizon.net wrote: I'm working on converting soltools to gbuild but I've come across a problem. soltools/testhxx/makefile.mk echos the commandline to compile a cxx file to a temporary file and then runs it through a perl script. What I need is a way to get the command line used to compile a file with out actually executing it. With dmake this seems to be accomplished with CAPTURE_COMMAND but I haven't been able to find equivalent funcionality in gbuild. A pointer would be appreciated. Peter, The first question you should ask youself is: is this thing actually used somewhere [...] Apparently the answer is.. no. testhxx was invented at the time we made the code warning free, and started with cleaning up the headers. It allowed to compile just a given header, with all the command line arguments of a normal compiler call. That said, it has probably not been used lately, probably rotted, and if we ever feel a need for it again, we could create a new one from scratch in the context of the new build system. So, the old one can probably be removed now. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debian gcc or LO bug
On 09/18/2011 11:23 PM, julien2412 wrote: Hello, On LO-dev IRC, i met someone with this pb /home/luc/git/core/vcl/unx/gtk/a11y/atkutil.cxx:322:60: error: call of overloaded ‘insert(com::sun::star::uno::Referencecom::sun::star::accessibility::XAccessibleEventBroadcaster)’ is ambiguous detail logs : [ build CXX ] vcl/unx/gtk/a11y/atkutil R=/home/luc/git S=$R/core O=$S/solver/unxlngx6.pro W=$S/workdir/unxlngx6.pro mkdir -p $W/CxxObject/vcl/unx/gtk/a11y/ $W/Dep/CxxObject/vcl/unx/gtk/a11y/ ccache g++ -DCPPU_ENV=gcc3 -DCUI -DENABLE_GRAPHITE -DENABLE_GTK -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -DGCC -DGXX_INCLUDE_PATH=/usr/include/c++/4.6 -DHAVE_GCC_VISIBILITY_FEATURE -DLINUX -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DPRODUCT -DPRODUCT_FULL -DSOLAR_JAVA -DSUPD=350 -DUNIX - DUNX -DVCL -DX86_64 -D_PTHREADS -D_REENTRANT -DVCLPLUG_GTK_IMPLEMENTATION -DVERSION=\350m1\ -Wall -Wendif-labels -Wextra -Wshadow -Woverloaded-virtual -Wno-non-virtual-dtor -fPIC -fmessage-length=0 -fno-common -pipe -fvisibility=hidden -fvisibility-inlines-hidden -std=c++0x -Wno-deprecated-declarations -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -O2 -c $S/vcl/unx/gtk/a11y/atkutil.cxx -o $W/CxxObject/vcl/unx/gtk/a11y/atkutil.o -MMD -MT $W/ CxxObject/vcl/unx/gtk/a11y/atkutil.o -MP -MF $W/Dep/CxxObject/vcl/unx/gtk/a11y/atkutil.d -I$S/vcl/unx/gtk/a11y/ -I$O/inc/stl -I$O/inc/external -I$O/inc -I$S/solenv/unxlngx6/inc -I$S/solenv/inc -I$S/res -I$S/solenv/inc/Xp31 -I/usr/lib/jvm/java-6-openjdk-amd64/include -I/usr/lib/jvm/java-6-openjdk-amd64/include/linux -I/usr/lib/jvm/java-6-openjdk-amd64/include/native_threads/include -I$S/vcl/inc -I$S/vcl/inc/pch -I$S/solenv/inc -I$O/inc -I$O/inc/offapi -I$O/ inc/udkapi -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/cairo -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include /home/luc/git/core/vcl/unx/gtk/a11y/atkutil.cxx: In member function ‘void DocumentFocusListener::attachRecursive(const com::sun::star::uno::Referencecom::sun::star::accessibility::XAccessible, const com::sun::star::uno::Referencecom::sun::star::accessibility::XAccessibleContext, const com::sun::star::uno::Referencecom::sun::star::accessibility::XAccessibleStateSet)’: /home/luc/git/core/vcl/unx/gtk/a11y/atkutil.cxx:322:60: error: call of overloaded ‘insert(com::sun::star::uno::Referencecom::sun::star::accessibility::XAccessibleEventBroadcaster)’ is ambiguous /home/luc/git/core/vcl/unx/gtk/a11y/atkutil.cxx:322:60: note: candidates are: /usr/include/c++/4.6/bits/stl_set.h:407:7: note: std::pairtypename std::_Rb_tree_Key, _Key, std::_Identity_Key, _Compare, typename _Alloc::rebind_Key::other::const_iterator, bool std::set_Key, _Compare, _Alloc::insert(const value_type) [with _Key = com::sun::star::uno::Referencecom::sun::star::uno::XInterface, _Compare = std::lesslt;com::sun::star::uno::Referencelt;com::sun::star::uno::XInterfacegt; , _Alloc = std::allocatorcom::sun::star::uno:: Referencecom::sun::star::uno::XInterface , typename std::_Rb_tree_Key, _Key, std::_Identity_Key, _Compare, typename _Alloc::rebind_Key::other::const_iterator = std::_Rb_tree_const_iteratorlt;com::sun::star::uno::Referencelt;com::sun::star::uno::XInterfacegt; , std::set_Key, _Compare, _Alloc::value_type = com::sun::star::uno::Referencecom::sun::star::uno::XInterface] /usr/include/c++/4.6/bits/stl_set.h:416:7: note: std::pairtypename std::_Rb_tree_Key, _Key, std::_Identity_Key, _Compare, typename _Alloc::rebind_Key::other::const_iterator, bool std::set_Key, _Compare, _Alloc::insert(std::set_Key, _Compare, _Alloc::value_type) [with _Key = com::sun::star::uno::Referencecom::sun::star::uno::XInterface, _Compare = std::lesslt;com::sun::star::uno::Referencelt;com::sun::star::uno::XInterfacegt; , _Alloc = std:: allocatorlt;com::sun::star::uno::Referencelt;com::sun::star::uno::XInterfacegt; , typename std::_Rb_tree_Key, _Key, std::_Identity_Key, _Compare, typename _Alloc::rebind_Key::other::const_iterator = std::_Rb_tree_const_iteratorlt;com::sun::star::uno::Referencelt;com::sun::star::uno::XInterfacegt; , std::set_Key, _Compare, _Alloc::value_type = com::sun::star::uno::Referencecom::sun::star::uno::XInterface] The value_type rvalue reference in the second alterntive indicates that the given GCC and standard library already support C++11 rvalue references and move semantics. I am not sure whether it is indeed the case per the Standard wording, but this apparently lets at least claim the given GCC implementation that the given LibO code is ambiguous: From ReferenceXBroadcaster to insert(ReferenceXInterfaceconst), there always has been a conversion route via ReferenceXBroadcaster::operator ReferenceXInterfaceconst(). I assume the given GCC thinks that there is an additional, longer route, from
Re: [Libreoffice] Remove NULL checks from delete
On 09/19/2011 08:58 PM, Thomas Arnhold wrote:
I've recently seen some changes, which removed unnecessary NULL checks
for delete commands with the form:
- if (pTextPContext)
- delete pTextPContext;
+ delete pTextPContext;
Codebase is full with these. I've attached a little perl script which
should solve this conversion. I've attached a sample for the vcl dir.
Any objections?
By the way, using the below regexps (best run in a C locale) should find
even more instances, and should avoid false positives of the form if
(foo) delete bar; or (unlikely) #if (foo) \n delete foo;:
foreach (@ARGV) {
my $file = $_;
open(FH, $file);
my $data = ;
while (FH) { $data .= $_; }
close(FH);
while ($data =~ /((?!#)\s*\bif\s*\(\s*(\w+)\s*\)\s*delete\s+\2\s*;)/g) {
print found $1\n;
}
while ($data =~
/((?!#)\s*\bif\s*\(\s*(\w+)\s*\)\s*{\s*delete\s+\2\s*;\s*})/g) {
print found $1\n;
}
}
(The outer parentheses are only there for print found $1\n to work
-- no idea how Perl makes available the complete match without that
hack... The leading (?!#)\s* should really read (?!#\s*), but
then Perl complains that Variable length lookbehind [is] not implemented.)
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: Branch 'libreoffice-3-4' - solenv/gbuild
Björn,
What good is that backport to 3.4? For one, the fix turns out to not
work yet (as executables already built using gbuild but only used during
the build itself use a NONEBIN token in solenv/gbuild/platform/*.mk
instead of the NONE token used in solenv/inc/*.mk, so that
macosx-change-install-names.pl complains and fails). For another, are
there any executables in 3.4 that are built using gbuild but are not
only used during the build itself (i.e., for which the missing call to
macosx-change-install-names.pl actually matters)?
-Stephan
On 09/19/2011 11:06 PM, Bjoern Michaelsen wrote:
solenv/gbuild/platform/macosx.mk |2 ++
1 file changed, 2 insertions(+)
New commits:
commit a87a8ee5a1919f6f6b4b35668456c03bdd499c85
Author: Stephan Bergmannsberg...@redhat.com
Date: Mon Sep 19 21:39:46 2011 +0200
Call macosx-change-install-names on executables in gbuild, too.
Signed-off-by: Bjoern Michaelsenbjoern.michael...@canonical.com
diff --git a/solenv/gbuild/platform/macosx.mk b/solenv/gbuild/platform/macosx.mk
index 2def0c9..ff7 100755
--- a/solenv/gbuild/platform/macosx.mk
+++ b/solenv/gbuild/platform/macosx.mk
@@ -274,6 +274,8 @@ $(call gb_Helper_abbreviate_dirs,\
$(foreach lib,$(LINKED_STATIC_LIBS),$(call
gb_StaticLibrary_get_target,$(lib))) \
-o $(1) \
`cat $${DYLIB_FILE}` \
+ $(if $(filter Executable,$(TARGETTYPE)),\
+ $(PERL) $(SOLARENV)/bin/macosx-change-install-names.pl Executable
$(LAYER) $(1)) \
$(if $(filter Library CppunitTest,$(TARGETTYPE)),\
$(PERL) $(SOLARENV)/bin/macosx-change-install-names.pl Library $(LAYER)
$(1) \
ln -sf $(1) $(patsubst %.dylib,%.jnilib,$(1))) \
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Proposal: slowcheck -- a new gbuild toplevel target
On 09/19/2011 09:18 PM, Bjoern Michaelsen wrote: we now have a good systematic set of test targets with unitcheck, subsequentcheck and check on master(*). However, we now have so many unittests (which is good) that running each and everyone on every build slows down the development cycle esp. in sc -- just because they taking unittesting serious. Now we: a) dont want developers to be punished for writing unittests with slow turnarounds (they might stop writing them) b) dont want people to disable all in-build unittests to be run on every compile (because it is far too easy to forget to run them again once before pushing then) so I am proposing introducing a new target in the build system called slowunitcheck. Those are tests that are technically unittests (need no full install), but considered to slow/longrunning to be run on every build. Instead those are run along the subsequenttests when running make check (or alone by running make slowunitcheck). Opinions? I'm somewhat undecided. While there may be a pragmatic need to exclude from constantly building those unit tests that are too slow, offering a framework for that might make people choose the easy way out, instead of putting work into their slow unit tests to make them fast. (I do not know what makes those sc unit tests slow, so I do not know whether lack-of-trying-to-improve applies here. Just a general concern. And I do know that we already have a framework for fucked up and slow subsequenttests, but I would like to get rid of that over time, replacing them with true unit tests.) In general, people may want to consult the literature on what to do about slow unit tests, e.g., the section on Slow Tests (p. 253ff) in Gerard Meszaros' xUnit Test Patterns: Refactoring Test Code (A-W, 2007). -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO Custom properties
On 09/20/2011 10:11 AM, swagat sharma wrote: I have generated a deb package of libreoffice using epm. --enable-epm and with-package-format = deb Now the package generated is installed by default in /opt directory. How can I modify it to install in /usr/lib/ ? Which variable to change/set? Any ideas? Should be DefaultDestPath in scp2/source/ooo/installation_ooo.scp. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Undoing basis/brand split in 3.5
As recently announced on #libreoffice-dev, I consider undoing the basis/brand layer split. Historically, this was introduced at Sun to make it possible for various products (plain OpenOffice.org, Brasilian BrOffice re-branding, Sun's proprietary StarOffice, ...) to share code that is only built, packaged (into platform specific package formats like rpm, deb), and quality-checked once. With LibO today, there is no real need for that split any longer, so it only complicates our code base. I would undo it in incremental steps directly on master (unless I hit temporary problems that cannot be worked around easily and that force me on a branch of my own). One consequence would be that the 3.5 package and file system layout would differ rather substantially from the 3.4 one (so that, e.g., using some form of delta packages to upgrade from 3.4 to 3.5 would not be a good idea, if anybody wanted to do something like that anyway). (There is also a URE/rest split, which I will not touch for now. At least Debian seems to be interested in having a stand alone URE on top of which sits a LibO alongside potentially more apps.) So, if you see any issue with this, please make yourself heard. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Suspicious warning fixes (was: [Libreoffice-commits] .: 4 commits - chart2/source cui/source desktop/test solenv/bin solenv/gdb solenv/inc)
Regina, The below two commits fix warnings from code changed through a recent commit by you, and in both cases I am a little unsure whether my fix is good (see inline below). On 09/20/2011 08:51 PM, Stephan Bergmann wrote: chart2/source/view/main/ShapeFactory.cxx |1 cui/source/tabpages/tpline.cxx |4 [...] New commits: commit ae8102f1e38c4da840f8343bbbd628f1c660c132 Author: Stephan Bergmannsberg...@redhat.com Date: Tue Sep 20 20:13:02 2011 +0200 Removed pPageView made unused by previous changeset 3e5edf6c. diff --git a/cui/source/tabpages/tpline.cxx b/cui/source/tabpages/tpline.cxx index b6825b9..ac170a2 100644 --- a/cui/source/tabpages/tpline.cxx +++ b/cui/source/tabpages/tpline.cxx @@ -898,7 +898,7 @@ void SvxLineTabPage::Reset( const SfxItemSet rAttrs ) pModel-InsertPage( pPage, 0 ); SdrView* pView = new SdrView( pModel,aVDev ); pView-hideMarkHandles(); -SdrPageView* pPageView = pView-ShowSdrPage(pPage); +pView-ShowSdrPage(pPage); SdrObject *pObj=NULL; long nSymTmp=nSymType; if(pSymbolList) @@ -1545,7 +1545,7 @@ IMPL_LINK( SvxLineTabPage, MenuCreateHdl_Impl, MenuButton *, pButton ) // 3D View SdrView* pView = new SdrView( pModel,aVDev ); pView-hideMarkHandles(); -SdrPageView* pPageView = pView-ShowSdrPage(pPage); +pView-ShowSdrPage(pPage); I assume those ShowSdrPage calls have side effects, so should indeed be left in, right? PopupMenu* pPopup = new PopupMenu; String aEmptyStr; commit 122b729a5a974179265b6d7a8c1c92199262b76a Author: Stephan Bergmannsberg...@redhat.com Date: Tue Sep 20 20:06:39 2011 +0200 Removed unused fMaxSize introduced by previous changeset 3e5edf6c. diff --git a/chart2/source/view/main/ShapeFactory.cxx b/chart2/source/view/main/ShapeFactory.cxx index dc06eba..c2626ca 100644 --- a/chart2/source/view/main/ShapeFactory.cxx +++ b/chart2/source/view/main/ShapeFactory.cxx @@ -1293,7 +1293,6 @@ drawing::PolyPolygonShape3D createPolyPolygon_Symbol( const drawing::Position3D const double fWidthH = rSize.DirectionX/2.0; //fWidthH stands for Half Width const double fHeightH = rSize.DirectionY/2.0; //fHeightH stands for Half Height -double fMaxSize = fHeightH fWidthH ? fHeightH : fWidthH; //assumes non negative fMaxSize was freshly introduced but not used -- was it a mistake to add it, or is the mistake rather that the place that should use it is missing? const sal_Int32 nQuarterCount = 35; // points inside a quadrant, used in case circle sal_Int32 nPointCount = 4; //all arrow symbols only need 4 points -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] License for my patches
On 09/21/2011 09:37 AM, Samphan Raruenrom wrote: All my patches to LibreOffice project are under LGPLv3+/MPL1.1 dual license and future versions of the licenses. Please don't forget to update http://wiki.documentfoundation.org/Development/Developers accordingly. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] clean rebuilds needed
My recent commit to start undoing the basis/brand split, http://cgit.freedesktop.org/libreoffice/core/commit/?id=a66f9903bba9dc7eeff6683ebddcd34d4ad70068 makes it necessary to do clean rebuilds on non-Windows, as the RPATHs of all the moved libs have changed. Sorry for the late notification. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] --enable-werror
Just a friendly reminder that all developers should use --enable-werror all the time. It helps yourself (you find potential errors early), your fellow developers (they don't need to fix your warnings for you), and our users (via a more stable product). (Different compilers tend to catch slightly different sets of warnings, so it does happen that a developer misses some...) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW 3-4] fdo#39510 crash on closing document with footnotes
On 09/25/2011 01:48 PM, Mathias Bauer wrote: The differentiation between hard and soft refererences would require a solid understanding of the relationships of all objects. With this understanding you could most probably fix the existing code without refcounting also: a weak reference always could be replaced by a callback function that tells possible consumers of an object that this object is going to die (and so manually sets the pointer to Null), a pattern that can be found in OOo's code in other places (e.g. SfxBroadcaster or SwNotify objects). But of course using refcounting here would make the code clearer. And another advantage of weak refs over notifications is that the former tend to behave correctly in multi-threaded scenarios while the latter tend to misbehave. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Easy Hack String replacement: SearchAndReplace
On 09/26/2011 01:30 AM, Neil Leathers wrote: I was looking into the Easy Hacks: Removal/Replacement of the String/UniString/ByteString with OUString/OString once and for all and ran into needing to translate a SearchAndReplaceAscii. Before launching into this set I wanted to confirm that instead of moving the SearchAndReplace functions to OUString and OString they should be moved to OUStringBuffer and OStringBuffer? No, it would probably be better placed at OUString (where it returns a new OUString instance, leaving the original intact) than at OUStringBuffer (where it modifies this instance). The reason is that putting it at OUStringBuffer would typically only pay off for repeated calls to SearchAndReplace or SearchAndReplaceAll, but such repeated calls are typically also subtly broken. (Imagine code that shall replace in str1 all occurrences of %foo% with str2 and all occurrences of %bar% with str3; str1.SearchAndReplaceAll(%foo%, str2); str1.SearchAndReplaceAll(%bar%, str3); is in general broken -- consider, e.g., the case where str2 is %bar%.) IIRC, there should be a thread on this in the interface-discuss or interface-announce mailing lists at openoffice.org. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] comprehensive binfilter tests?
With the apparently somewhat semi-automatic code clean-up/removal in binfilter (removing dead code, noticing compiler warnings about thus newly unused variables, thus removing more dead code, ...), I wonder whether this does not introduce regressions. Do we have some comprehensive test suite for binfilter? -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --enable-werror
On 09/26/2011 11:22 AM, Michael Meeks wrote: Hi Stephan, On Mon, 2011-09-26 at 08:41 +0200, Stephan Bergmann wrote: Just a friendly reminder that all developers should use --enable-werror all the time. This is a nice idea of course :-) but some platforms spew errors constantly beyond the control of the developer. IMHO it is best to leave this to people that are truly neurotic, and (of course) to try to not generate new warnings. You mean, you let http://cgit.freedesktop.org/libreoffice/core/commit/?id=0b24bd7a6ec714c74795cf417e35bd036303f3b9 hide a WaE... should be fixed properly when the issue is understood through just because you think you can live without this helpful --enable-werror stuff? Hm. It helps yourself (you find potential errors early), your fellow developers (they don't need to fix your warnings for you), and our users (via a more stable product). Sure - it'd be ideal; anyhow - help much appreciate on my favorite warning (of which I have several (tens?) of thousand when compiling): In file included from /data/opt/libreoffice/core/sw/source/core/doc/docfly.cxx:66:0: /data/opt/libreoffice/core/sw/source/core/inc/UndoAttribute.hxx:209:38: warning: 'auto_ptr' is deprecated (declared at /usr/include/c ++/4.5/backward/auto_ptr.h:86) Caolán already addressed that, didn't he? -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Compilation error in svx undefined reference to `XPropertyList::operator delete(void*)'
On 09/26/2011 10:58 AM, Michael Meeks wrote: On Sun, 2011-09-25 at 01:40 -0700, julien2412 wrote: /home/maryline/compile-libreoffice/libo/workdir/unxlngi6/CxxObject/svx/source/tbxctrls/fillctrl.o: In function `~XBitmapList': /home/maryline/compile-libreoffice/libo/svx/inc/svx/xtable.hxx:469: undefined reference to `XPropertyList::operator delete(void*)' /home/maryline/compile-libreoffice/libo/svx/inc/svx/xtable.hxx:469: undefined reference to `XPropertyList::operator delete(void*)' Riight - that is odd / annoying. The idea here is (by hiding new / delete) that we force people to use the static factory function and thus not shoot the ref-counting in the foot :-) as a quick hack around just removing those operators would work, and sorry to break it for you ... If the only way to create XBitmapList instances is via an (XBitmapList member) factory function, you do not need (and should remove again) private new/delete -- private ctor/dtor suffice. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] comprehensive binfilter tests?
On 09/26/2011 11:45 AM, Michael Meeks wrote: On Mon, 2011-09-26 at 10:23 +0200, Stephan Bergmann wrote: With the apparently somewhat semi-automatic code clean-up/removal in binfilter (removing dead code, noticing compiler warnings about thus newly unused variables, thus removing more dead code, ...), I wonder whether this does not introduce regressions. Probably it does; all code change has that potential :-) but this should -never- stop us doing it. Arguably code that has the highest rate of change coupled with people working on and caring about it also has the best quality, certainly after a few minor point releases. The LibreOffice approach has been to encourage people to change the code, and fix any knock-on problems later. True, some parts of the code are horribly fragile - but this is a great way of identifying and hardening / fixing those pieces. The OpenOffice approach of discouraging code change was IMHO a short-sighted fast-track to obscurity, discouraging the volunteer developers crucial to progress from contributing. Micheal, I do not agree with what you write above (at least not in its IMO exaggerated form), but I think its also irrelevant for this thread. My concern here is with code that is changed semi-automatically and rather aggressively, with probably hardly anybody checking that the results are still working as intended. So the chance of regressions remaining undetected for quite a while is IMO higher here than for other typical code changes. (And the cost of analysing the regressions, if they are eventually found, will also be rather high, given the aggressive pruning of allegedly dead code in the meantime). Do we have some comprehensive test suite for binfilter? No. Having said that, we don't have a -comprehensive- test suite for other, more useful code that people are actively using day by day; say the ODF import / export support ;-) or the Microsoft binary / OOXML filters, all of which are also under active development. I imagine that something useful for testing binfilter's import (we killed export) may be quite simple - particularly since the style / content of the ODF it produces is expected to never change again :-) Potentially we could have a during-build unit-test modelled on the sc/ filters-test that hooked the XML out of the binfilter filter directly [without going through a nasty re-save-as-ODF that'd introduce regular constant change] that would be robust, cause ~no false positives and be rather helpful. At least the extra confidence might help accelerate the rate of change and boldness with which it is made there. Is that what you were thinking ? :-) I wasn't thinking anything in particular, just wanted to make sure there is not some good regression test mechanism hidden somewhere that would come in handy here and of which I was not yet aware. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] subsequenttest hang ...
On 09/26/2011 08:24 PM, Michael Meeks wrote: On Mon, 2011-09-26 at 17:33 +0200, Stephan Bergmann wrote: A timed wait is no solution here. (Timeouts in this kind of code pose at least two problems. For one, they prevent a human from coming back to a hung make check after a while, only to find out they no longer get a clue where it hang, as the build has unhelpfully been forced to move forward. That is of course possible; however in this case the build would simply fail with an assertion at this exact point. In general, that is probably better than hanging indefinitely, which can wedge tinderboxes, and give the impression the build is continuing when it has hung. Tinderboxes need to handle non-terminating builds, anyway (think a non-terminating, say, idlc), so no need to address non-terminating tests specifically for them. The real solution, instead, is to not only wait on the Result object, but also on the OfficeConnection. Fixed as Looks like an improvement to me, thanks for that. I wonder why we only see this now, surely smoketests have died in mid-flow before ? Not sure. Maybe it was indeed always the case that cppunittester would hang should soffice.bin crash while in the BASIC smoke test code. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --enable-werror
On 09/26/2011 01:15 PM, Marc-André Laverdière wrote: I tried doing that, but it seems that my autogen flags made it so that I was compiling some module unknown to me that was in 'build warning land'. Unless we don't have modules living in such countries anymore, I won't want to enable that option. I see this flag as an aspirational goal let us fix all that stuff so that we can -one day- compile everything that way We were there already, and I think we still are there (at least on Linux with recent GCC, maybe it decayed on Windows). I personally am against anything that makes it harder for a n00b like me to get something done. The learning curve is not-so-easy so lets not make it worse. For just compiling the sources, the default of --disable-werror is hence the way to go. For actually making changes to the code, and especially doing so as a newbie -- what's wrong with the help offered by those compiler warnings? (Given they are caused by your changes, not by code that was already dirty with warnings before you touched it -- which brings me back to the point that all developers should use --enable-werror all the time, to keep the master clean.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] clean rebuilds needed
On 09/26/2011 07:00 PM, Bjoern Michaelsen wrote: The concept of dependencies only get you so far -- the rest is better left to caching (aka ccache). I think its *file based* dependencies that's the problem here -- they are simply not at the right level of granularity. (Then again, I'm not sure there's at all a working theory of making arbitrary changes to your source tree and then rebuilding everything that needs to be rebuilt while only rebuilding as little as possible what would not necessarily need to be rebuilt.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] clean rebuilds needed
On 09/26/2011 10:01 PM, Bjoern Michaelsen wrote: On Mon, 26 Sep 2011 21:33:03 +0200 Stephan Bergmannsberg...@redhat.com wrote: I think its *file based* dependencies that's the problem here -- they are simply not at the right level of granularity. (Then again, I'm not sure there's at all a working theory of making arbitrary changes to your source tree and then rebuilding everything that needs to be rebuilt while only rebuilding as little as possible what would not necessarily need to be rebuilt.) No need for such theory, as for all practical proposes, there is ccache doing exactly that (although with a bit of addition IO). As for finer granularity: With the practical reality of C/C++ with preprocessing, context sensitive syntax and commandline switches to influence the compile result there is little hope for such a thing existing _and_ be reasonably fast (read: orders of magnitude faster than just frigging compiling it). there is ccache doing exactly that: but not everything is being built by the C/C++ compilers... finer granularity: I did not mean finer granularity within C/C++ files (so that a changed header does not necessarily cause rebuild of every file including it), but rather within the makefiles themselves (so that a change to one recipe in one makefile would not cause everything to be rebuilt if we had targets depend on the makefiles their recipes come from): -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] comprehensive binfilter tests?
On 09/26/2011 09:58 PM, Michael Meeks wrote: (And the cost of analysing the regressions, if they are eventually found, will also be rather high, given the aggressive pruning of allegedly dead code in the meantime). Surely git bisect is pretty impervious to the size or number of changes ? I have no experience how useful git bisect would actually be here, given the core/binfilter repo split. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppunittester hang when LC_ALL/LANG set
On 09/27/2011 12:47 AM, Miklos Vajna wrote: I just updated my master build on my notebook after about two weeks and the build hanged in sal when I did *not* unset LANG/LC_ALL. First I bisected it: [...] Does this ring any bell? I tried to revert the commit, but it's a large one, and I could not easily resolve conflicts in sal/textenc/textenc.cxx. So in short: $ echo $LANG $LC_ALL hu_HU hu_HU ^ This hangs, but after an 'unset LANG LC_ALL' the build continues fine. Yes, I can reproduce this here -- will provide a fix. Sorry for the trouble. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] subsequenttest hang ...
On 09/26/2011 11:23 PM, Norbert Thiebaud wrote: So... my Linux tinderbox hanged again in make check... after only 3 green iterations... I have not noticed for 7 hours, nor anyone else apparently... Would that be http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTERfull-log=1317053012.10270? Unfortunately, there is no information about the hanging build left, so it is impossible to tell what the problem was here. Did you already experience builds hung in make check earlier? I was not aware of that. What would be helpful in such a case would be an overview of running processes, together with stacks from the suspects (cppunittester, soffice.bin). so clearly running make check is not ready for prime time. I'm turning that off on my box for now. So, looks like I need to set up my own tinderbox? Hm. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppunittester hang when LC_ALL/LANG set
On 09/27/2011 08:20 AM, Stephan Bergmann wrote: On 09/27/2011 12:47 AM, Miklos Vajna wrote: I just updated my master build on my notebook after about two weeks and the build hanged in sal when I did *not* unset LANG/LC_ALL. First I bisected it: [...] Does this ring any bell? I tried to revert the commit, but it's a large one, and I could not easily resolve conflicts in sal/textenc/textenc.cxx. So in short: $ echo $LANG $LC_ALL hu_HU hu_HU ^ This hangs, but after an 'unset LANG LC_ALL' the build continues fine. Yes, I can reproduce this here -- will provide a fix. Sorry for the trouble. http://cgit.freedesktop.org/libreoffice/core/commit/?id=193715bbf0e59256fd8da7ebd8dc5eb937615281 FullTextEncodingDataSingleton must not call itself recursively. should fix this. (For Windows, the fix is still only a TODO: FIXME dummy. I will address that once I have a working Windows build environment to do the development in.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --enable-werror
On 09/27/2011 10:33 AM, Michael Meeks wrote: On Tue, 2011-09-27 at 10:06 +0530, Marc-André Laverdière wrote: When I tried using this flag, I ended up not being able to _build_ at all. And that wasn't even due to my own mistake, only some module I know nothing at all is breaking the build. Sure sure, so - I think Stephan has a point - that we ought to find some way of enabling this for some set of people that can cope with it. I suspect a good heuristic would be to have an 'auto' mode for the flag that checks if you have git push access and if so enables -Werror, so that old-hands get it automatically, and newbies don't suffer. No need to go creative here, IMO. With a default --disable-werror, I *hope* it should suffice to just remind developers that they should --enable-werror (the same way we should remind them to --enable-dbgutil and to run make check). -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] per-library types headers ...
On 09/27/2011 01:24 PM, Noel Grandin wrote: (1) Nice pragma trick for making this problem show up at compile time: http://stackoverflow.com/questions/74326/how-should-i-detect-unnecessary-include-files-in-a-large-c-project/109890#109890 This would flag double includes that are there for good encapsulation, like when a header contains an inline function definition using rtl::OUString (so header #inlcude rtl/ustring.hxx), and that header is included in a cxx that also contains a function definition using rtl::OUString (so cxx too #include rtl/ustring.hxx). (2) There is a tool based on clang that can detect unused includes: http://code.google.com/p/include-what-you-use/ Cool, thanks for the pointer. Always thought about doing something like this, but never came around... -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] per-library types headers ...
On 09/27/2011 10:55 AM, Michael Meeks wrote:
I'm still a tad annoyed by our compile times, and was wondering - has a
footypes.hxx header approach been tried in the past. This would add a
near complete set of forward declarations of classes, templates, etc.
necessary to use that library.
I suspect (at the moment) that people tend to simply include the header
that creates whatever definition they care about in their headers
chaining them together into bulky masses of pulled in headers, rather
than whacking things like:
namespace com { namespace sun { namespace star { namespace uno {
class Any;
class Exception;
template typename class Reference;
template typename class Sequence;
class XInterface;
} } } }
namespace rtl { class OUString; }
into their headers to cut such chains (and who can blame them - that
seems much more readable). Though of course the base Reference class is
prolly something that we should have ~everywhere - with fwd. decls for
the interface classes themselves.
Potentially, by switching to lazily including just the svxtypes.hxx (or
whatever) header ~everywhere, we could have a smaller, quicker to parse
code-base (pwrt. no in-lines that get actually compiled) as well as a
rather more bearable dependency tree.
Did anyone research this sort of thing in the past ?
Sometimes forward declarations suffice, sometimes the true definition is
needed, so I guess you would end up in each header with a mix of
footypes.hxx plus a list of whatever, and that list would start to grow
again quite quickly (and hardly ever shrink during maintenance).
So, I'm more in favour of tools like those that Noel pointed out, that
can be run once every while over the code base to find unnecessary
includes (could actually become an easy hack then). Should be
interesting to look into such tools, whether they work fine for our code
base...
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --enable-werror
On 09/26/2011 08:41 AM, Stephan Bergmann wrote: Just a friendly reminder that all developers should use --enable-werror all the time. I wasn't aware that this might come across negatively, arrogantly, dictatorial, or something like that. Hope I didn't put off too many people. I had sincerely assumed that this topic was uncontroversial. Boy was I wrong... ;-) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Removal of rtl::O[U]String[Buffer]::operator sal_{char|Unicode} const *()
Hi all,
As has recently been discussed on #libreoffice-dev, its probably a good
idea to remove the rather unhelpful conversion operators
rtl::OString::operator sal_Char const * ()
rtl::OStringBuffer::operator sal_Char const * ()
rtl::OUString::operator sal_Unicode const * ()
rtl::OUStringBuffer::operator sal_Unicode const * ()
(The reason why this came up on IRC this time was that the expression
aStr = aStr + cSep with aStr of type rtl::OString and cSep of type
sal_Char had a rather non-intuitive meaning, implicitly converting aStr
into a sal_Char const *, adding the integral value of cSep to that
pointer, and then converting that modified sal_Char const * back into an
rtl::OString via the rtl::OString(sal_Char const *) constructor.)
The change will be source-code incompatible, but that is probably
acceptable:
- The change is ABI compatible (involving only inline C++ functions).
- The ~only legitimate use case for those conversion operators was in
indexing expressions like aStr[n]. To continue those expressions to
work, appropriate operator [](sal_Int) member functions will be added to
the four classes.
- All other uses of the conversion operators should use the getStr()
member functions. (Also note that there might be cases where
translation between, say, rtl::OString and char const * via naive
application of rtl::OString::getStr() is not appropriate as it
potentially looses information, when the given rtl::OString instance
contains NUL characters. Having the calls to getStr explicitly in the
code helps auditing in this case.)
My plan is as follows:
- I just pushed
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6671fa81db0ecea4ada005bb79f55f08fb440ad4
Removed uses of rtl::O[U]String[Buffer]::operator sal_{char|Unicode}
const *(). and
http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=34c2ec87db4b6962ded661157056c58163e39821
Removed uses of rtl::O[U]String[Buffer]::operator sal_{char|Unicode}
const *(). That clears the current master of all dubious (i.e.,
non-[]) uses of the conversion operators for a Linux x86_64
--enable-binfilter --enable-dbgutil make check build.
- A few more builds (e.g., Windows, Mac OS X) should be done with the
below patch to ensure that as many dubious uses in
platform-/configuration-switch-specific code as possible have been
fixed. If someone wants to give me a hand here, that would be great.
- The attached no-string-conversion.patch will remove the conversion
operators and introduce the operator [] replacements. It can be
committed to master once the above step is done, in the 3.5 time frame.
(If anybody has objections to this, esp. as it nominally breaks
backwards compatibility at the source level, raise your hands.)
-Stephan
diff --git a/sal/inc/rtl/strbuf.hxx b/sal/inc/rtl/strbuf.hxx
index 63ae448..e485e7d 100644
--- a/sal/inc/rtl/strbuf.hxx
+++ b/sal/inc/rtl/strbuf.hxx
@@ -287,12 +287,18 @@ public:
/**
Return a null terminated character array.
*/
-operatorconst sal_Char *() const { return pData-buffer; }
+const sal_Char* getStr() const { return pData-buffer; }
/**
-Return a null terminated character array.
- */
-const sal_Char* getStr() const { return pData-buffer; }
+ Access to individual characters.
+
+ @param index must be non-negative and less than length.
+
+ @return the character at the given index.
+
+ @since LibreOffice 3.5
+*/
+sal_Char operator [](sal_Int32 index) const { return getStr()[index]; }
/**
Return a OString instance reflecting the current content
diff --git a/sal/inc/rtl/string.hxx b/sal/inc/rtl/string.hxx
index 96ca406..22de6dd 100644
--- a/sal/inc/rtl/string.hxx
+++ b/sal/inc/rtl/string.hxx
@@ -251,19 +251,6 @@ public:
/**
Returns a pointer to the characters of this string.
- pThe returned pointer is not guaranteed to point to a null-terminated
- byte string. Note that this string object may contain embedded null
- characters, which will thus also be embedded in the returned byte
- string./p
-
- @return a pointer to a (not necessarily null-terminated) byte string
- representing the characters of this string object.
-*/
-operator const sal_Char *() const SAL_THROW(()) { return pData-buffer; }
-
-/**
- Returns a pointer to the characters of this string.
-
pThe returned pointer is guaranteed to point to a null-terminated byte
string. But note that this string object may contain embedded null
characters, which will thus also be embedded in the returned
@@ -275,6 +262,17 @@ public:
const sal_Char * getStr() const SAL_THROW(()) { return pData-buffer; }
/**
+ Access to individual characters.
+
+ @param index must be non-negative and less than length.
+
+ @return the character at the given index.
+
+ @since LibreOffice 3.5
+*/
+sal_Char operator
Re: [Libreoffice] Removal of rtl::O[U]String[Buffer]::operator sal_{char|Unicode} const *()
On 09/27/2011 09:07 PM, Caolán McNamara wrote: On Tue, 2011-09-27 at 21:00 +0200, Stephan Bergmann wrote: introduce the operator [] replacements. Any reason, we make operator[] const ?, i.e. unassignable. plenty of code out there using operator[] to get a given index, and setCharAt to set it, which is kind of clumsy. Ah right, the rtl::O[U]StringBuffer functions should be adapted accordingly. (Note that my commits just broke various tinderboxes due to some GCCs apparently complaining about alleged ambiguities in a+=b when a is a tools String and b an rtl::OUString; fixing it right now.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Removal of rtl::O[U]String[Buffer]::operator sal_{char|Unicode} const *()
On 09/27/2011 09:21 PM, Stephan Bergmann wrote: (Note that my commits just broke various tinderboxes due to some GCCs apparently complaining about alleged ambiguities in a+=b when a is a tools String and b an rtl::OUString; fixing it right now.) Hopefully fixed now with http://cgit.freedesktop.org/libreoffice/core/commit/?id=5c0b18ed99e30c604c77caa86e4551a4403e5c91 Work around ambiguity introduced by previous rtl::O[U]String[Buffer] related clean up. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] subsequenttest hang ...
On 09/28/2011 02:01 AM, Norbert Thiebaud wrote: (1) it occurred to me that this French expression may not translate well. a surveiller comme du lait sur le feux means to keep close and attentive watch... milk being notorious -- when it start boiling -- for quickly overflowing the pot. That metaphor doesn't fit here, as the hanging build is not boiling the tinderbox up, rather cooling it down... ;-) But I do get your point. Hope we get the tests into good enough shape soon (maybe its really only forms/qa/unoapi that causes trouble; will run that in a loop here to see if I can reproduce anything debuggable...) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] unit-test / code sharing ...
On 09/28/2011 11:27 AM, Caolán McNamara wrote: On Wed, 2011-09-28 at 09:46 +0100, Michael Meeks wrote: Reading the various cppunit tests we have and the code cut/paste going on gives some concern. We need a place to share most of this really bootstrap UNO heavy lifting and the various other bits of common magic that go on there, presumably a CppUnit::TestFixture sub-class - where quite that belongs, I don't know - perhaps vcl would be a good place. Yeah, test would be fine probably. The intent was to merge the common code back together once the various filter tests in different modules flushed out the required flags and magic, but I didn't get around to it. Yes, test was intended for such stuff -- but we need to make sure not to introduce circular dependencies. (The conceptual level of that module is still somewhat undecided.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] unit-test / code sharing ...
On 09/28/2011 10:46 AM, Michael Meeks wrote:
Incidentally, while trying to get some StarBasic / VBA unit tests
working with Moggi, it seemed that some of our hangs were down to
dialogs showing up that were simply not visible, and spinning the
mainloop waiting for a response.
static void aBasicErrorFunc( const StringrErr, const StringrAction )
{
rtl::OStringBuffer aErr( Unexpected dialog: );
aErr.append( rtl::OUStringToOString( rAction, RTL_TEXTENCODING_ASCII_US )
);
aErr.append( Error: );
aErr.append( rtl::OUStringToOString( rErr, RTL_TEXTENCODING_ASCII_US ) );
CPPUNIT_ASSERT_MESSAGE( aErr.getStr(), false);
}
void FiltersTest::setUp()
{
ErrorHandler::RegisterDisplay( aBasicErrorFunc );
}
Solves that rather pleasantly, with the added bonus that it might help
improve the accuracy / helpfulness our basic error reporting over time.
I suspect we should do this for all unit-tests above tools, and the
head-less smoketest too.
But isn't it the way that all dialogs are implicitly cancelled in
headless mode, anyway?
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] New Config Variable in Impress
On 09/28/2011 11:00 PM, Rob Snelders wrote: I'm looking into bug fdo#35973. But I have trouble finding out how I can add config-variables for Impress. Can anybody give me any pointers? The configuration data is in module officecfg. There you have schema (.xcs) files describing the static layout of the data tree (think of it as a hierarchy of structs and lists, with data types like bool and string and integer at the leaves) and data (.xcu) files describing the actual values (if they need to be preset). For a new impress flag, say, you would need to add to officecfg/registry/schema/org/openoffice/Office/Impress.xcs. The corresponding XML schema is described at officecfg/registry/component-schema.dtd. (When you modify anything in module officecfg, you also need to rebuild module postprocess, as there various small .xcs/.xcu files are packed together into larger .xcd files. Impress.xcs ends up in a main.xcd, see postprocess/packregistry/makefile.mk.) Accessing the configuration data at runtime is done via the configmgr UNO services (although there are---rather unnecessary---layers of abstraction above those UNO services themselves in the code base, which the application code typically uses instead.) Let me know if you have any further questions (I'm sberg at #libreoffice-dev, if you prefer IRC). -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] need help with feature/gbuild
On 09/29/2011 01:04 AM, Matúš Kukan wrote: I have recreated feature/gbuild branch. I'm gbuildizing sal, salhelper, cppu and cppuhelper there. It's almost done but there are few problems. In odk I'm getting: check cpp docu: + ERROR: ../../unxlngi6.pro/bin/odkcommon/docs/cpp/ref/names/cppu/AccessControl is missing It's because I have added visibility macro as: class CPPUHELPER_DLLPUBLIC AccessControl The problem is also when CPPUHELPER_DLLPUBLIC expands to empty string . For now I use --disable-odk but unless we want to remove odk something has to be done with that and maybe someone knows what. Looks like yet another shortcoming of that silly autodoc tool; probably it can't parse class CPPUHELPER_DLLPUBLIC AccessControl correctly. One more reason to switch to Doxygen or similar soon (expecting that to be mature enough to cope with such macro uses). [...] And another problem is with libraries with version (libuno_sal.so.3, ..) That's probably only for linux? Not only Linux, but also at least Mac OS X and Solaris use this naming scheme of a suffixed .3. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 14 files in libreoffice git source flagged as trojans
On 09/29/2011 10:52 PM, Billy Charlton wrote: After the clone completed, MS Security Essentials popped up with nine severe trojans and exploits. The affected files are .doc, .rtf, and .wmf -- which would be the places that Windows viruses and trojans would indeed hide. I have no way of knowing if these are legit or not, but figured someone on this list who does Windows dev would want to know. This has been discussed recently, see the thread around http://lists.freedesktop.org/archives/libreoffice/2011-September/018749.html True Trojans or false positives ? -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] MinGW cross-compilation: Runs!
On 09/29/2011 11:18 PM, Jan Holesovsky wrote: Based on Tor's, Fridrich's, and others great work, I was able to get the MinGW cross-compilation to state that it not only builds, but even runs! :-) The good thing about all this is that with this, you do not need a Windows machine at all to be able to produce LibreOffice Windows executable. Just to clarify: Those MinGW based builds are binary incompatible with the traditional, MSVC based Windows builds (i.e., C++ extensions compiled for the traditional builds will not work). But great work indeed! -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppunit test and smoketest failures
On 10/02/2011 08:49 PM, Peter Foley wrote:
:
LD_LIBRARY_PATH=/root/libreoffice/smoketestoo_native/unxlngx6.pro/lib:/root/libreoffice/solver/unxlngx6.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
/root/libreoffice/solver/unxlngx6.pro/bin/cppunit/cppunittester \
-env:UNO_SERVICES=file:///root/libreoffice/solver/unxlngx6.pro/xml/ure/services.rdb
\
-env:UNO_TYPES=file:///root/libreoffice/solver/unxlngx6.pro/bin/types.rdb \
-env:arg-soffice=path:/root/libreoffice/solver/unxlngx6.pro/installation/opt/program/soffice
-env:arg-user=./unxlngx6.pro/misc/smoketest/user \
-env:arg-env=LD_LIBRARY_PATH${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}
-env:arg-testarg.smoketest.doc=./unxlngx6.pro/bin/smoketestdoc.sxw --protector \
/root/libreoffice/solver/unxlngx6.pro/lib/unoexceptionprotector.so \
unoexceptionprotector ./unxlngx6.pro/lib/libsmoketest.so
officeconnection.cxx:142:Assertion
Test name: N12_GLOBAL__N_14TestE::test
setUp() failed
- equality assertion failed
- Expected: 2
- Actual : 0
officeconnection.cxx:171:Assertion
Test name: N12_GLOBAL__N_14TestE::test
tearDown() failed
- equality assertion failed
- Expected: 0
- Actual : 77
Failures !!!
Run: 1 Failure total: 2 Failures: 2 Errors: 0
This indicates that soffice.bin crashed during start up. You can try
two things to find out more:
- Try to start soffice manually from
/root/libreoffice/solver/unxlngx6.pro/installation/opt/program/soffice
(best in a clean shell, no Env.Host.sh sourced) and see whether it
fails, too.
- Enable crash dumps (in bash, ulimit -c unlimited) and see whether some
core or core.* is generated, and look into that.
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ExternalLib.mk rpath gotchas
On 10/03/2011 12:45 PM, Caolán McNamara wrote: A better solution might be to put a stock libtool into our tree, patch it to smuggle the correct gb_LinkTarget__RPATHS entry into the link line, and then always copy our patched libtool over preexisting libtools when we unpack external tarballs in our build ? Sounds good to me. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Replace (Byte)String with O(U)String in sw
On 10/03/2011 04:48 PM, Chr. Rossmanith wrote: One improvement suggested by Norbert on IRC: using OUString instead of ::rtl::OUString. What is the preferred syntax using ::rtl::OUString at the beginning of the file and OUString throughout the remaining source code or ::rtl::OUString everywhere in the source code. I would stick with a pattern that does use a namespace prefix (i.e., rtl::OUString rather than OUString). Even if it is slightly longer, it helps avoid ambiguities should one of the #included headers in the future drag in another entity with the same plain name (probably unlikely for OUString, but it does happen, cf. rtl::Reference vs. com::sun::star::uno::Reference; another measure against this is to explicitly using rtl::OUString; instead of the more general using namespace rtl;). The initial :: in ::rtl::OUString is probably not really worth it, more noise than of practical value. But there's a lot of personal taste involved... -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC handles, a quibble
On 10/04/2011 06:27 PM, Terrence Enger wrote: (*) In the hope of attracting critical feedback (but constructive, of course: this is after all LibreOffice grin /), I sprinkled the code liberally with questions and comments. Most conspicuously, - I cite the X/Open reference manual. I have not seen any comparable citation in LO code. Perhaps the citation does not belong in the code at all. - I express my own doubts about that manual. This is a more personal expression than anything I have noticed elsewhere in the code. Does it belong? I would consider such comments fully appropriate in the code base. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: stoc/source
On 10/04/2011 07:11 PM, Kevin Hunter wrote: At 9:33am -0400 Mon, 03 Oct 2011, Tor Lillqvist wrote: stoc/source/inspect/introspection.cxx | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) New commits: commit 9e6d06a871b366cc72f9a23ab45080b66a47f144 Making my way through a backlog of commits ... it seems to me that it doesn't matter why the for-loop was used in the first place, because now it's not clean code, and the function could be made that much better. I don't know much about the Reference or XIdlClass data types, but this patch at least compiles on my machine, and I claim removes ambiguity while remaining true to the came-before logic. It also removes the overhead of recursion, as I don't think this algorithm needs it. Hi Kevin, Thanks a lot for the patch. I think the real intent always was to actually look through all the returned getSuperclasses(), and the error that superclasses past the first one are effectively ignored has never been noticed. (getSuperclasses() returning a sequence of length greater than one only happens for multiple-inheritance interface types, which are relatively rare. And the isDerivedFrom in question is probably also not called that much.) I will look into this tomorrow. (I had this oddity on my list for a while now, anyway.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] .: stoc/source
On 10/04/2011 11:01 PM, Kevin Hunter wrote: At 4:15pm -0400 Tue, 04 Oct 2011, Stephan Bergmann wrote: Thanks a lot for the patch. I think the real intent always was to actually look through all the returned getSuperclasses(), and the error that superclasses past the first one are effectively ignored has never been noticed. Excellent. Was wondering, but don't yet know LO well enough to make such declarations. Well, modulo any errors on my part, the logic I sent in patch 1 should be the same as what was originally there, but I hope easier to read/see for comparison/fixing. Here is a second patch that compiles, /should/ respond to what you just confirmed was the original intent, but is untested. (It was a random drive by patching.) Specifically, I suppose it's obvious that this now changes the semantics of it actually used to do. If you know how to test it ... Yes, that's how I would have done it, too. Pushed now, thanks again. (I assume you already stated somewhere what license your contributions are under, even though that's not explicitly listed at http://wiki.documentfoundation.org/Development/Developers.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Removal of rtl::O[U]String[Buffer]::operator sal_{char|Unicode} const *()
On 09/27/2011 09:00 PM, Stephan Bergmann wrote:
Hi all,
As has recently been discussed on #libreoffice-dev, its probably a good
idea to remove the rather unhelpful conversion operators
rtl::OString::operator sal_Char const * ()
rtl::OStringBuffer::operator sal_Char const * ()
rtl::OUString::operator sal_Unicode const * ()
rtl::OUStringBuffer::operator sal_Unicode const * ()
(The reason why this came up on IRC this time was that the expression
aStr = aStr + cSep with aStr of type rtl::OString and cSep of type
sal_Char had a rather non-intuitive meaning, implicitly converting aStr
into a sal_Char const *, adding the integral value of cSep to that
pointer, and then converting that modified sal_Char const * back into an
rtl::OString via the rtl::OString(sal_Char const *) constructor.)
The change will be source-code incompatible, but that is probably
acceptable:
- The change is ABI compatible (involving only inline C++ functions).
- The ~only legitimate use case for those conversion operators was in
indexing expressions like aStr[n]. To continue those expressions to
work, appropriate operator [](sal_Int) member functions will be added to
the four classes.
- All other uses of the conversion operators should use the getStr()
member functions. (Also note that there might be cases where translation
between, say, rtl::OString and char const * via naive application of
rtl::OString::getStr() is not appropriate as it potentially looses
information, when the given rtl::OString instance contains NUL
characters. Having the calls to getStr explicitly in the code helps
auditing in this case.)
My plan is as follows:
- I just pushed
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6671fa81db0ecea4ada005bb79f55f08fb440ad4
Removed uses of rtl::O[U]String[Buffer]::operator sal_{char|Unicode}
const *(). and
http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=34c2ec87db4b6962ded661157056c58163e39821
Removed uses of rtl::O[U]String[Buffer]::operator sal_{char|Unicode}
const *(). That clears the current master of all dubious (i.e., non-[])
uses of the conversion operators for a Linux x86_64 --enable-binfilter
--enable-dbgutil make check build.
- A few more builds (e.g., Windows, Mac OS X) should be done with the
below patch to ensure that as many dubious uses in
platform-/configuration-switch-specific code as possible have been
fixed. If someone wants to give me a hand here, that would be great.
Decided to push
http://cgit.freedesktop.org/libreoffice/core/commit/?id=112bdf84d684590e042725c7173e059b4afa2f83
Removed dangerous rtl::O[U]String[Buffer]::operator sal_{char,Unicode}
const *. now, even though I didn't manage to get a Windows build yet
(and it looks like that will still take a while...).
So, if you build on Windows and experience a breaker due to this commit,
please be so kind and fix it (or discuss it here).
Thanks,
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] .: stoc/source
On 10/05/2011 09:13 AM, Kevin Hunter wrote: At 2:58am -0400 Wed, 05 Oct 2011, Stephan Bergmann wrote: On 10/04/2011 11:01 PM, Kevin Hunter wrote: Here is a second patch that compiles, /should/ respond to what you just confirmed was the original intent, but is untested. (It was a random drive by patching.) Specifically, I suppose it's obvious that this now changes the semantics of it actually used to do. If you know how to test it ... Yes, that's how I would have done it, too. Pushed now, thanks again. (I assume you already stated somewhere what license your contributions are under, even though that's not explicitly listed at http://wiki.documentfoundation.org/Development/Developers.) Incidentally, do we have a set of tests for this? I wouldn't know where to begin. This was truly a drive-by reading of a commit and surrounding code. Unfortunately, there's no good unit tests for this code. Blame it on me for taking the all too easy road out and committing the fix without doing the boring ^H^H^H joyful work of adding a test for it first. That said, people wanting to write unit tests for the introspection stuff would be more than welcome! There's definitely things to unearth there... -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Replace WW8Bytes with ww::bytes
On 10/05/2011 10:11 PM, Michael Stahl wrote:
On 05.10.2011 22:02, Maciej Rumianowski wrote:
Dnia 2011-10-05, śro o godzinie 17:35 +0200, Lubos Lunak pisze:
On Wednesday 05 of October 2011, Jan Holesovsky wrote:
That would allow you to convert the pO-GetData() to something like
po-data(), instead of(*pO)[0] (and similar) used on many places...
That same would be allowed by
class bytes : public std::vectorsal_uInt8
{
public:
const sal_uInt8* data() const { returnfront(); }
...
So if it is desired solution I can modify Patches?
why not just use po-front() directly instead, that's nicer than
(*po)[0] and no need to introduce a class just for this IMHO.
v[0] has become something of a standard idiom, I'd say. So, personal
taste mostly.
Btw, v[0] (as well as v.front()) are only valid if !v.empty() -- but
(without checking it in detail right now) I guess the patch already
takes account of that, Maciej?
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
