[Libreoffice] signed/unsigned comparison (was: [PATCH] Replace SvULongs with vector and code clean up part 1)
On Aug 6, 2011, at 3:32 PM, Maciej Rumianowski wrote:
I was working on SvULongs in libs-core and I decided to split my work in
several Patches.
With this patch comes some questions:
@@ -228,9 +229,9 @@ private:
String aValStr;
double nValNum;
sal_Bool bUndoAddList;
-SvULongs aAddList;
-SvULongs aDelList;
-SvULongs aCurEntryList;
+std::vectorsal_uInt32 aAddList;
+std::vectorsal_uInt32 aDelList;
+std::vectorsal_uInt32 aCurEntryList;
[…]
@@ -1325,7 +1288,7 @@ String SvxNumberFormatShell::GetComment4Entry(short
nEntry)
if(nEntry 0)
return String();
-if(nEntryaCurEntryList.Count())
+if(nEntry (short)aCurEntryList.size())
{
5. Should short type be replaced with sal_Int16 or more appropriate type?
Some C++ compilers warn about comparisons like (x y) where x is an rvalue of
a signed integral type and y is an rvalue of an unsigned integral type. And,
in general, they are right in doing so: Assume that x is an rvalue -1 of type
int and y is some rvalue of type unsigned int. Usual arithmetic conversion
causes the int -1 to be converted to unsigned int. Undefined behavior,
hard-disk erased. Oops.
However, if the programmer can prove that x is always non-negative in the above
comparison, there is usually an easy solution to that problem:
First, assert the programmer's knowledge that x is indeed non-negative. In the
original code, that would be
OSL_ASSERT(nEntry = 0);
(Which might or might not be considered overkill in this specific case, given
the if(nEntry 0) branch just above the code in question.)
Next, cast x (of signed integral type T) to an unsigned integral type that is
known to be able to represent all the non-negative values of T. (In general,
with current C++ implementations, that can be tricky if all you know about T is
that it is some typedef.) But in the original code T is known to be short (and
whether that is a good choice is an entirely different question), so that code
could be changed to
if (sal::static_int_cast unsigned short (nEntry) aCurEntryList.size())
Note the use of sal::static_int_cast instead of static_cast---the former was
introduced to make it simpler to find all places that need to be adapted should
the type of nEntry ever be changed---and is declared and documented in
sal/types.h. (And never use a C-style cast in C++ code.) Note also that it
would also work to cast to a larger type than unsigned short, like unsigned int
or unsigned long int.
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [ANNOUNCE] libreoffice-3.3.4.2 tag skipped (3.3.4-rc2)
Hi, no changes have been committed into the libreoffice-3-3-4 branch. The code is exactly the same as for the tag libreoffice-3.3.4.1 (3.3.4-rc1). Hence it does not make sense to do the libreoffice-3.3.4.2 tag and 3.3.4-rc2 build. If no blocker is found, 3.3.4-rc1 will be marked as final on August 17, 2011. See also the schedule at http://wiki.documentfoundation.org/ReleasePlan#3.3_release and release criteria at http://wiki.documentfoundation.org/Release_Criteria ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Suggestion and patch for Confirmation of save format dialog
On Tue, 2011-08-09 at 09:15 +0930, Josh Heidenreich wrote: HI, For a long time I have been annoyed at the Are you sure you want to save as a .DOC message, as I find the buttons confusing. I have made some changes, with the button to show the format name. Screenshots: http://thejosh.info/libreoffice/export_format1.png http://thejosh.info/libreoffice/export_format2.png I have coded a patch, although it's against the old repos. Attach the patch anyway :-). I think the whole existing dialog was a complete fail. Never liked the wording Keep, seeing as the dialog also appears on first save of a new file, i.e. new document-save as .doc, and you get Keep MS format, which feels odd to me. Use/Save might be better. Maybe put Save as 'X' anyway into the current keep button, with save in 'Y' instead as the alternative save as ODF. I know I typically skip all explanatory text and go right to the buttons, only reading the text if I need to. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Suggestion and patch for Confirmation of save format dialog
Forwarding this to the ux-advise list, a better forum I think for discussion about such changes Noel On 09/08/11 00:45, Josh Heidenreich wrote: HI, For a long time I have been annoyed at the Are you sure you want to save as a .DOC message, as I find the buttons confusing. I have made some changes, with the button to show the format name. Screenshots: http://thejosh.info/libreoffice/export_format1.png http://thejosh.info/libreoffice/export_format2.png I have coded a patch, although it's against the old repos. Josh ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [BUG] dbaccess/xmlfilter.cxx
On 08/08/11 19:16, Jenei Gábor wrote: Hello, I found out that on make -sr debug=true dbglevel=2 dbaccess did not compile successfully, the problem is with xmlfilter.cxx, it uses OStringBuffer, but there is no include to use it, so cxx says: OStringBuffer is not a member of rtl namespace I did the include, and the build works fine, I must notice that it only appears in debug version making, as the code is behind a DBGLEVEL1 macro. I send the patch to fix it in the attachement, please add it to all the sources. Gabor Jenei looks ok to me ( no build to check yet ) I will commit it later for you. Have you already confirmed patch license e.g. LGPLv3+/MPL-Licence for this and any other patches you sent? thanks Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] build problems with cppunit (windows)
On Mon, 2011-08-08 at 23:39 +0400, Dmitry. A. Ashkadov wrote: I tried build LO from 'core' repository on Windows 7. The result is the same error. Modules 'cppunit' and 'xml2cmp' wasn't built due to the same unresolved external symbol. We tried to build devel. version of LO, but the define «_DEBUG» is not really set. ((( cppunit and xml2cmp build for me on Windows 7 without problem, so a) what autogen/configure flags are you using b) what compiler are you using C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] build error in tail_build
Hi *, Building LibreOffice now and then. Currently to look at some functions / dig a bit in the code. Low level experience. Working on Ubuntu. Previous successful build was from July 6 Yesterday I did a ./g pull -r on the master. (Didn't do any special action for the one-git transition, since I thought that is not needed for me). There were a few internal build errors that could be passed by following the typical advise as: rm -Rf /home/cono/src/git/libo/odk/unxlngi6.pro # optional module 'clean' /bin/bash cd /home/cono/src/git/libo source ./Env.Host.sh cd odk build and again make Now I get a build errror in tail_build: [ build LNK ] CppunitTest/libtest_sd_uimpress.so R=/home/cono/src/git S=$R/libo O=$S/solver/350/unxlngi6.pro W=$S/workdir/unxlngi6.pro mkdir -p $W/LinkTarget/CppunitTest/ g++ -shared -Wl,-z,noexecstack -Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$S/solenv/unxlngi6/lib -L$O/lib -L$S/solenv/unxlngi6/lib -L/usr/lib/i386-linux-gnu -Wl,--hash-style=gnu -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions -Wl,--strip-all $W/CxxObject/sd/qa/unit/uimpress.o `cat $W/LinkTarget/Library/libsdlo.so.objectlist` -Wl,--start-group -Wl,--end-group -lcppunit -lavmedialo -lbasegfxlo -lcanvastoolslo -lcomphelpgcc3 -lcppcanvaslo -luno_cppu -luno_cppuhelpergcc3 -ldrawinglayerlo -leditenglo -li18nisolang1gcc3 -luno_sal -luno_salhelpergcc3 -lsblo -lsfxlo -lsotlo -lsvllo -lsvtlo -lsvxcorelo -lsvxlo -ltklo -ltllo -lucbhelper4gcc3 -lutllo -lvcllo -lxolo -o $W/LinkTarget/CppunitTest/libtest_sd_uimpress.so cat: /home/cono/src/git/libo/workdir/unxlngi6.pro/LinkTarget/Library/libsdlo.so.objectlist: Bestand of map bestaat niet /home/cono/src/git/libo/workdir/unxlngi6.pro/CxxObject/sd/qa/unit/uimpress.o: In function `(anonymous namespace)::Test::setUp()': uimpress.cxx:(.text+0x143): undefined reference to `SdDrawDocument::SdDrawDocument(DocumentType, SfxObjectShell*)' /home/cono/src/git/libo/workdir/unxlngi6.pro/CxxObject/sd/qa/unit/uimpress.o: In function `(anonymous namespace)::Test::testCustomShow()': uimpress.cxx:(.text+0x30e): undefined reference to `SdDrawDocument::GetCustomShowList(unsigned char)' /home/cono/src/git/libo/workdir/unxlngi6.pro/CxxObject/sd/qa/unit/uimpress.o: In function `CppUnit::ConcretTestFixtureFactory(anonymous namespace)::Test::makeFixture()': uimpress.cxx:(.text+0xc07): undefined reference to `SdDLL::Init()' collect2: ld returned 1 exit status make: *** [/home/cono/src/git/libo/workdir/unxlngi6.pro/LinkTarget/CppunitTest/libtest_sd_uimpress.so] Fout 1 Advice? Thanks, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Rainer Bielefeld libreoff...@bielefeldundbuss.de changed: What|Removed |Added Depends on||39919 --- Comment #183 from Rainer Bielefeld libreoff...@bielefeldundbuss.de 2011-08-09 03:31:22 PDT --- Nominate Bug 39919 - CRASH when insert particular SVG picture from file. This one alone might not be a typical most annoying one, but we have lots or SVG crash, does not open, result is unusable problems, it would be great if we could get SVG into focus for a while. Or may be this would b better for Bug 37361 LibreOffice 3.5 most annoying bugs? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] two assertions raised and a failed database query
On Mon, 2011-08-08 at 15:11 -0400, Terrence Enger wrote: But unless the inbound conversion has always been wrong for everybody. Yeah, that's what I'm wondering. Could it have been always wrong. i.e. this is a SQL_C_TYPE_TIMESTAMP as per http://msdn.microsoft.com/en-us/library/ms714556%28v=vs.85%29.aspx The bug is number 110236 Error: operator delete mismatch http://openoffice.org/bugzilla/show_bug.cgi?id=110236. Ah yah, I see, yeah, that seems perfectly reasonable alright. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build error in tail_build
On Tue, Aug 9, 2011 at 5:31 AM, Cor Nouws oo...@nouenoff.nl wrote: Hi *, Building LibreOffice now and then. Currently to look at some functions / dig a bit in the code. Low level experience. Working on Ubuntu. Previous successful build was from July 6 Yesterday I did a ./g pull -r on the master. (Didn't do any special action for the one-git transition, since I thought that is not needed for me). So you are still pulling 'master' from last friday... since the master you pulled is froozen read-only in bootstrap,artwork,base,calc, etc what made you think that 'it was not needed for you' ? Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fix for fdo#34768 - no update preview
On 06/08/11 18:46, Péter Rabi wrote: Hi all, I wrote a simple patch for resolving the following bug: https://bugs.freedesktop.org/show_bug.cgi?id=34768 (the patch is attached therein) When selecting a template in dialogue Load Slide Design in Impress, the preview didn't get updated. I linked the already existing event handler and called it also when selecting a region. I would like to ask to apply the patch not only on master, but also on branches -3-3 and -3-4, as the changes are hazard-free IMHO. looks good to me, will commit to 3.4, 3.3 is closed afaik Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] fix for fdo#34768 - no update preview
On 09/08/11 12:06, Noel Power wrote: On 06/08/11 18:46, Péter Rabi wrote: Hi all, I wrote a simple patch for resolving the following bug: https://bugs.freedesktop.org/show_bug.cgi?id=34768 (the patch is attached therein) When selecting a template in dialogue Load Slide Design in Impress, the preview didn't get updated. I linked the already existing event handler and called it also when selecting a region. I would like to ask to apply the patch not only on master, but also on branches -3-3 and -3-4, as the changes are hazard-free IMHO. looks good to me, will commit to 3.4, 3.3 is closed afaik pushed to 3.4 ( will commit to master once I have a build later ) I think I have seen you have previously state your patches are under LGPLv3+/MPL1.1, if not can you confirm ? nice patch, thanks again Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build error in tail_build
Norbert Thiebaud wrote (09-08-11 12:42) So you are still pulling 'master' from last friday... since the master you pulled is froozen read-only in bootstrap,artwork,base,calc, etc Hmm :-( what made you think that 'it was not needed for you' ? Combination of various, such as: - lack of experience - Only pointer I found on http://wiki.documentfoundation.org/Development/One_Git_Conversion was the onegit.sh, found in contrib/dev-tools which I did not have - the fact that pull did not give an error - I saw some remark on commit rights in combination with another command - ... But hey, better then summing up more reasons: what command(s) do I use to move to the new master? Thanks, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build problems with cppunit (windows)
09.08.2011 14:28, Caolán McNamara пишет: On Mon, 2011-08-08 at 23:39 +0400, Dmitry. A. Ashkadov wrote: I tried build LO from 'core' repository on Windows 7. The result is the same error. Modules 'cppunit' and 'xml2cmp' wasn't built due to the same unresolved external symbol. We tried to build devel. version of LO, but the define «_DEBUG» is not really set. ((( cppunit and xml2cmp build for me on Windows 7 without problem, so a) what autogen/configure flags are you using b) what compiler are you using C. I use compiler from MSVS 2008. Options are: ./autogen.sh --with-num-cpus=1 --with-max-jobs=1 --with-lang=en-US ru --with-ant-home=/cygdrive/c/ant --without-junit --enable-dbgutil --disable-epm --disable-binfilter --disable-mozilla --disable-build-mozilla --disable-activex --disable-directx --disable-atl --disable-odk without --enable-dbgutil there is no such problem. -- Best Regards, Dmitry attachment: dmitry_ashkadov.vcf___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build error in tail_build
Cor Nouws wrote: ... But hey, better then summing up more reasons: what command(s) do I use to move to the new master? ...___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Hello, I don't think there's a script for this. Just create your local repo from scratch by following this url : http://wiki.documentfoundation.org/Development/Native_Build (this page has been updated). You could save your autogen.lastrun if you want to preserve the options you usually passed for the compilation. Then after the autogen.sh part, copy the backup in your repo and rerun autogen.sh before running the compilation with make. Hope I forgot nothing or misunderstood anything :-) Julien. PS : make fetches dictionnary and help repositories by default -- View this message in context: http://nabble.documentfoundation.org/build-error-in-tail-build-tp3238515p3238689.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Problem with dev-install on windows
Hello! I built LO (branch libreoffice-3-4-2) on Windows without options «--enable-dbgutil», but it cannot be installed to local directory using «make dev-install» ERROR: ERROR: Could not create parent directory C:/office/instsetoo_native/util/cygdrive/c/office/instsetoo_native/ -- Best Regards, Dmitry attachment: dmitry_ashkadov.vcf___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] fix for fdo#34768 - no update preview
Hi Noel, all, pushed to 3.4 ( will commit to master once I have a build later ) I think I have seen you have previously state your patches are under LGPLv3+/MPL1.1, if not can you confirm ? Yes, I affirm I'm contributing my patches under license LGPLv3+/MPL1.1. The above is in accordance with my earlier patches, too. (I used to denote this piece of information in the commit message.) Best regards, Péter ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build error in tail_build
julien2412 wrote (09-08-11 14:04) I don't think there's a script for this. Just create your local repo from scratch by following this url : http://wiki.documentfoundation.org/Development/Native_Build (this page has been updated). Ah, thanks. I only looked at the 'get your first build' part lately. Any thing I need to do to prevent mixing with the current local master, or could I just delete that with smthng as ./g -f master -D ? (inspired by the page Development#Using_Git_for_LibreOffice_development) Currently I have both the old master and libreoffice-3-4-0 You could save your autogen.lastrun if you want to preserve the options you usually passed for the compilation. Then after the autogen.sh part, copy the backup in your repo and rerun autogen.sh before running the compilation with make. Hope I forgot nothing or misunderstood anything :-) Julien. PS : make fetches dictionnary and help repositories by default Thanks, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Suggestion and patch for Confirmation of save format dialog
Forwarding this to the ux-advise list, a better forum I think for discussion about such changes I can get a few of the UI designers at work (who are also LO users) to take a look as well. I like Caolán's suggested wording though. Attach the patch anyway :-). Also, what is the easiest way to submit a patch, as my code is currently stuck in the old repositories. Josh ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build error in tail_build
On Tue, Aug 9, 2011 at 6:43 AM, Cor Nouws oo...@nouenoff.nl wrote: Norbert Thiebaud wrote (09-08-11 12:42) So you are still pulling 'master' from last friday... since the master you pulled is froozen read-only in bootstrap,artwork,base,calc, etc Hmm :-( what made you think that 'it was not needed for you' ? Combination of various, such as: - lack of experience - Only pointer I found on http://wiki.documentfoundation.org/Development/One_Git_Conversion was the onegit.sh, found in contrib/dev-tools which I did not have ohh! I see. No, you were not supposed to run that script :-) The page above, describe the process used to convert/consolidate the repositories. the result is that bootstrap is now replaced by core and the only repository left are core, binfilter, help, dictionaries and translations. so, all you need to do is git clone git://anongit.freedesktop.org/libreoffice/core to clone the brand new 'core' repo and then autogen/make as usual in that core repository. make will clone any other repository if needed (it will always clone help, and dictionaries, binfilter and translations will be cloned depending on autogen options) any patch you had pending in your previous repositories, need to be re-applied in the new one. (no, fetch/merge between the two are not possible, since they share no common ancestor) Note that the new repo had all the tab/spaces anomalies cleaned-up, so when re-applying patches you may have issues. git apply has options to mitigate these issues ( --withespace=fix , --ignore-whitespaces I strongly suggest reading man git-apply for theses) Norbert PS: as a reminder this apply only to master and future release branch out of master (3.5 and after). the 3.3.x and 3.4.x maintenance remain on the old repositories, and will remain there. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build error in tail_build
On Tue, Aug 9, 2011 at 7:24 AM, Cor Nouws oo...@nouenoff.nl wrote: julien2412 wrote (09-08-11 14:04) I don't think there's a script for this. Just create your local repo from scratch by following this url : http://wiki.documentfoundation.org/Development/Native_Build (this page has been updated). Ah, thanks. I only looked at the 'get your first build' part lately. Any thing I need to do to prevent mixing with the current local master, old and new are in completely separate git... you need to get a brand new git repository, by cloning core. this will not 'update' you existing bootstrap setup any work pending you had in the old repository (and that was not committed before last friday, will remain there and will not be in the nre core repository unless you manually apply patches yourself to transfer the work from the old to the new. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] ODT Viewer
Hi there, To achieve a high acceptance of the LibreOffice and Open Document Formats against M$-Office formats, I suggest to develop a lightweight Viewer for ODFs specially ODT format. Using it, people can be encouraged to send ODT files as their email attachments to the others and inform them to grab the viewer from the libreoffice.org . This is so easier than suggesting the email partner to get and install the big LibreOffice package (300MB+ ?!) to see contents of a single file! Cheers, Majid Tajamolian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Suggestion and patch for Confirmation of save format dialog
On Tue, 2011-08-09 at 22:04 +0930, Josh Heidenreich wrote: Also, what is the easiest way to submit a patch, as my code is currently stuck in the old repositories. http://wiki.documentfoundation.org/Development/Patch_Handling_Guideline#How_to_submit_a_patch Even though you've still got old repos, if you commit your patch locally and use git format-patch the output still generally applies (with --ignore-whitespace anyway) against the new ones as I found when bringing a pile across. And if not some manual massaging at the applying end of the patch will still work. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] signed/unsigned comparison
Hi Stephan,
On Tuesday, 2011-08-09 09:05:49 +0200, Stephan Bergmann wrote:
On Aug 6, 2011, at 3:32 PM, Maciej Rumianowski wrote:
@@ -1325,7 +1288,7 @@ String SvxNumberFormatShell::GetComment4Entry(short
nEntry)
if(nEntry 0)
return String();
-if(nEntryaCurEntryList.Count())
+if(nEntry (short)aCurEntryList.size())
{
5. Should short type be replaced with sal_Int16 or more appropriate type?
Some C++ compilers warn about comparisons like (x y) where x is an rvalue
of a signed integral type and y is an rvalue of an unsigned integral type.
The actual code committed has
if( static_castsize_t(nEntry) aCurEntryList.size())
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
pgpefRkPZ2bpi.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#37319: don't write invalid references to odf files
Hi Markus,
On Tuesday, 2011-08-09 05:04:35 +0200, Markus Mohrhard wrote:
this patch removes entries like #REF! A1:A3 for named ranges when the sheet
referenced by the named range is no longer there.
I didn't check lately, is the current compiler's ODFF grammar able to
read a [#REF!] properly?
@@ -3808,7 +3816,18 @@ void ScXMLExport::WriteNamedExpressions(const
com::sun::star::uno::Reference co
}
else
{
-AddAttribute(XML_NAMESPACE_TABLE, XML_EXPRESSION,
sOUTempContent);
+ScRange aRange;
+if (pNamedRange-GetErrCode() ||
!pNamedRange-IsValidReference(aRange))
Sure that on any error of pNamedRange-GetErrCode() a [#REF!] should be
written? This look dubious to me.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
pgpLQaN2Qp8Ym.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] signed/unsigned comparison (was: [PATCH] Replace SvULongs with vector and code clean up part 1)
On Tuesday 09 of August 2011, Stephan Bergmann wrote:
On Aug 6, 2011, at 3:32 PM, Maciej Rumianowski wrote:
@@ -1325,7 +1288,7 @@ String
SvxNumberFormatShell::GetComment4Entry(short nEntry) if(nEntry 0)
return String();
-if(nEntryaCurEntryList.Count())
+if(nEntry (short)aCurEntryList.size())
{
5. Should short type be replaced with sal_Int16 or more appropriate type?
Some C++ compilers warn about comparisons like (x y) where x is an rvalue
of a signed integral type and y is an rvalue of an unsigned integral type.
And, in general, they are right in doing so: Assume that x is an rvalue -1
of type int and y is some rvalue of type unsigned int. Usual arithmetic
conversion causes the int -1 to be converted to unsigned int. Undefined
behavior, hard-disk erased. Oops.
Correct.
However, if the programmer can prove that x is always non-negative in the
above comparison, there is usually an easy solution to that problem:
[skipped a description of the typical OOo style of using a sledge hammer to
punch in a nail that's anything but easy and can potentially cause almost as
much trouble as it solves]
Actually a much better solution to the problem is to realize that 'unsigned'
belongs together with other legacy stuff and is just not worth it, perhaps
except for bitfields (which are kind of legacy stuff these days as well).
If the extra bit of value is really needed, then it's usually much better to
go for a larger type (as 'unsigned' does not mean it has any magic range
checks included), otherwise just going with plain 'int' simply does the job.
Too bad usage of STL drags in these problems, but that's not a problem that
couldn't be solved. Certainly much easier than having code cluttered with
checks and casts that serve no real purpose.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODT Viewer
Majid Tajamolian wrote: To achieve a high acceptance of the LibreOffice and Open Document Formats against M$-Office formats, I suggest to develop a lightweight Viewer for ODFs specially ODT format. This has already been discussed quite extensively a couple months ago: http://www.mail-archive.com/discuss@documentfoundation.org/msg07101.html If you have something new to add, it's more likely that it will get noticed on that list, rather than on this (pure development) one, where ideas not supported by code prototypes are less likely to be taken into consideration. Regards, Andrea. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Problem with dev-install on windows
Hi Dmitry, On 2011-08-09 at 16:07 +0400, Dmitry. A. Ashkadov wrote: I built LO (branch libreoffice-3-4-2) on Windows without options «--enable-dbgutil», but it cannot be installed to local directory using «make dev-install» ERROR: ERROR: Could not create parent directory C:/office/instsetoo_native/util/cygdrive/c/office/instsetoo_native/ make dev-install is not really working on Windows. I tried to get it to do something useful some time ago, but haven't finished that. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] signed/unsigned comparison (was: [PATCH] Replace SvULongs with vector and code clean up part 1)
On Tuesday 09 of August 2011, Stephan Bergmann wrote:
On Aug 9, 2011, at 3:02 PM, Lubos Lunak wrote:
Too bad usage of STL drags in these problems, but that's not a problem
that couldn't be solved.
How?
namespace lostd // or just no namespace at all, any other 'list' class is
unlikely
{
template ...
class list : public ::std::list ...
{
...
int size() const { return ::std::list ... ::size(); } // plus possibly
checks here, but somehow doubt there are many cases, if any, where one would
have a list with more than 2E9 items
...
};
This class is technically still also std::list, so it should be a drop-in
replacement for all cases. And IMO a much nicer solution than
people randomly adding casts all over the codebase.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Bug 39561 (XHTML export filter)
On 04/08/11 16:14, Christophe Strobbe wrote: Hi, Attached is a patch for Bug 39561 Use svg:title, not svg:desc for XHTML img alt attribute [accessibility] https://bugs.freedesktop.org/show_bug.cgi?id=39561. I am new to Git and LibreOffice development and generated this patch with git diff ... (I couldn't figure out how to use format-patch). the patch looks fine, but I am not at all sure about which attribute should be mapped into the 'alt' tag, to me the description seems like a better fit ( a more verbose image replacement is better ? ), otoh it would seem that the html xhtml filters should be consistent. I've committed the patch to master in any case, thanks for the patch btw, can you confirm patch is LGPLv3+/MPL1.1, Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] rectangle in drawing toolbar
Hi all, with http://cgit.freedesktop.org/libreoffice/impress/commit/?h=libreoffice-3-4id=d31b6292b14546ac7b04b4f483b70f68b56412e6 the single rectangle in the drawing toolbar was changed from classical rectangle to custom shape rectangle. In addition the part Corner Radius in the positionsize dialog is enabled, but should not be. But I don't know where this was introduced. Now there are the issues 39907, 36796 and 36822. I propose to rethink the changes. Perhaps the default design of the drawing toolbar should be discussed in UX? Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] mysqlc chicken-and-egg bootstrap
On 05/08/11 10:23, Lionel Elie Mamane wrote: Hi, When doing a fresh bootstrap clone and ./autogen.sh '--enable-ext-mysql-connector' '--with-system-mysql' configure complains that the directory mysqlc does not exist and errors out. But that directory will be created by make fetch _after_ configure is finished running, so I'd suggest the attached patch. Else, one has to do: ./autogen.sh make fetch ./autogen.sh '--enable-ext-mysql-connector' '--with-system-mysql' you are using downloaded source tar-balls ? but anyhow seems like a useless check, pushed to master Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Bug 39561 (XHTML export filter)
On 09/08/11 16:26, Noel Power wrote: On 04/08/11 16:14, Christophe Strobbe wrote: Hi, Attached is a patch for Bug 39561 Use svg:title, not svg:desc for XHTML img alt attribute [accessibility] https://bugs.freedesktop.org/show_bug.cgi?id=39561. I am new to Git and LibreOffice development and generated this patch with git diff ... (I couldn't figure out how to use format-patch). the patch looks fine, but I am not at all sure about which attribute should be mapped into the 'alt' tag, to me the description seems like a better fit ( a more verbose image replacement is better ? ), otoh it would seem that the html xhtml filters should be consistent. I've committed the patch to master in any case, thanks for the patch btw, can you confirm patch is LGPLv3+/MPL1.1, Noel changed subject ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Bug 39561 (XHTML export filter)
Hi, At 17:26 9-8-2011, Noel Power wrote: On 04/08/11 16:14, Christophe Strobbe wrote: Hi, Attached is a patch for Bug 39561 Use svg:title, not svg:desc for XHTML img alt attribute [accessibility] https://bugs.freedesktop.org/show_bug.cgi?id=39561. I am new to Git and LibreOffice development and generated this patch with git diff ... (I couldn't figure out how to use format-patch). the patch looks fine, but I am not at all sure about which attribute should be mapped into the 'alt' tag, to me the description seems like a better fit ( a more verbose image replacement is better ? ), svg:title should definitely be mapped to the alt attribute (based on my understanding of XHTML, ODF and SVG, and on 10 years of RD in accessibility). The user should be able to decide whether or not to get a long description after getting the short description. A long description is not required for every image. otoh it would seem that the html xhtml filters should be consistent. I've committed the patch to master in any case, thanks for the patch btw, can you confirm patch is LGPLv3+/MPL1.1, I confirm that I make this patch available under LGPLv3+/MPL1.1. By the way, I could not find the full process for fixing and closing bugs on http://www.libreoffice.org/get-involved/developers/ or http://wiki.documentfoundation.org/Development. I missed: * any mention of the need to confirm that you submit your patch under LGPLv3+/MPL1.1 (and that you can make a blanket statement like the one by Lionel Elie Mamane two days ago http://lists.freedesktop.org/archives/libreoffice/2011-August/016134.html; * Who closes the reported bug and when (presumably only after it has been committed). (Ah, I just noticed Noel closed the bug.) Who should I contact to update the Wikipage? Best regards, Christophe -- Christophe Strobbe K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on Document Architectures Kasteelpark Arenberg 10 bus 2442 B-3001 Leuven-Heverlee BELGIUM tel: +32 16 32 85 51 http://www.docarch.be/ Twitter: @RabelaisA11y --- Open source for accessibility: results from the AEGIS project www.aegis-project.eu --- Please don't invite me to Facebook, Quechup or other social networks. You may have agreed to their privacy policy, but I haven't. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Calc] Feature Request - charts : error bars + broken axes
Hi Patrick, On 2011-08-08 at 10:45 +0200, Patrick Gerin wrote: In case this list is not the best suited for the present request, please, let me know the address to that I should better use. The best mailing list for the discussing feature requests is probably disc...@documentfoundation.org . This mailing list is for code contributions, and discussions about the actual code. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Eclipse CDT IDE LibreOffice, hints tips needed
On Sat, 2011-07-30 at 00:46 +0200, Thorsten Behrens wrote: Olivier Hallot wrote: Can a charitable soul tell me if using Eclipse CDT (or netbeans) for LibreOffice hacking does make sense? I keep crashing both IDE's upon defining ~/git/libo/ as project, looks like it is too big for the vanilla IDEs (java out of heap space , bla bla bla). What fun, still those pesky IDEs seem unsuitable for any project of real-world size. Reportedly, adding only e.g. sw works, though. ;) even sw isn't that interesting for the indexing is way too slow... However it's probably much more interesting with gmake than with the old build system. Still plain text editor like Vim or Emacs combined with idutils or ctags is the way to go. -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] signed/unsigned comparison (was: [PATCH] Replace SvULongs with vector and code clean up part 1)
On Aug 9, 2011, at 5:15 PM, Lubos Lunak wrote:
On Tuesday 09 of August 2011, Stephan Bergmann wrote:
On Aug 9, 2011, at 3:02 PM, Lubos Lunak wrote:
Too bad usage of STL drags in these problems, but that's not a problem
that couldn't be solved.
How?
namespace lostd // or just no namespace at all, any other 'list' class is
unlikely
{
template ...
class list : public ::std::list ...
{
...
int size() const { return ::std::list ... ::size(); } // plus possibly
checks here, but somehow doubt there are many cases, if any, where one would
have a list with more than 2E9 items
...
};
This class is technically still also std::list, so it should be a drop-in
replacement for all cases. And IMO a much nicer solution than
people randomly adding casts all over the codebase.
Technically, lostd::list is no longer a container, as it violates the
requirement that the return type of size() is size_type. (And if you redefine
size_type as int, as you should do anyway in the above sketch, it violates the
requirement that size_type is an unsigned integral type.) Really, I would not
try to outsmart the specification---even if the specification is far from
beautiful.
From my experience, I consider the problem of randomly added casts as not
that severe, anyway. The best fix for the code in question would probably be
if indexing types like the type of nEntry were std::size_t to begin with.
Then, explicit casts would probably only be needed at the interfaces to
external representations (like file formats)---places where explicit range
checks are typically already needed, anyway.
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Custom Animation not working
swagat sharma wrote: I rercently built 3.5 codebase, cloned 2 weeks back. I'm surprised to see that custom animation is not working. It was working fine in previous production releases, like 3.3.2, and 3.4.0 Is there anyone else who can confirm? No, works here. If this persists in a fresh build, please file a bug with more info (platform, exact config etc). Let's keep this list free of detailed bug discussions (unless code is involved). Cheers, -- Thorsten pgpoDB9nHGBc3.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix building bridge with -mavx
Hi Caolan, On 2011-08-08 at 12:06 +0100, Caolán McNamara wrote: Libreoffice bridge code won't compile on new CPUs which add -mavx to cxxflags with --march=native. As first idea for the fix is actual ban for the -mavx cxxflag by adding -nomavx. I'm curious, in what way does the implicit -mavx cause the build to fail? I wonder how far we'd get rebasing the bridges on on libffi ? There's a fair bit of overlap. Hard to say - I've re-used the libffi implementation of the small struct handling in the x86-64 bridge, but did not go any further; might be doable, but for sure not trivial :-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] .vimrc to compile source from within Vim
Hi, I took the wiki's Vim tip to build a module from within Vim and enhanced it to compile the current source file (and only that) in both, dmake and gbuild modules. If the current file is a Makefile, the entire module is built using make. If the current file is build.lst, the entire module is built using build. Should work (can't test at the moment due to a dying graphics adapter) also with a detached gvim where sourcing the environment is needed first. Attached. Enjoy Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Call appropriate makeprg with Ctrl+K map C-K :call Make()CR if $SOLARENV == Normal makeprg, not in LibreOffice/OpenOffice.org environment function Make() make endfun else The root of the directory where we stop going further up, excluding. For example, if /libo/core is the tree's root, the root of that is /libo let s:dir_root = fnamemodify( $SRC_ROOT, :h ) function DirLimit( dir ) return a:dir == s:dir_root endfunction function GetDotPath() let l:dir = . while !DirLimit( l:dir ) !filereadable( l:dir . /Makefile ) !filereadable( l:dir . /prj/build.lst ) let l:dir .= /.. endwhile if DirLimit( l:dir ) let l:dir = . else get rid of first ./ The loop above could be changed to make this unnecessary, but as is it is identical to the one in GetModuleRoot() let l:dir = substitute( dir, \./, , ) endif return l:dir endfunction function GetModuleRoot() let l:mods = :p:h let l:dir = expand( % . l:mods ) while !DirLimit( l:dir ) !filereadable( l:dir . /Makefile ) !filereadable( l:dir . /prj/build.lst ) let l:mods .= :h let l:dir = expand( % . l:mods ) endwhile if DirLimit( l:dir ) let l:dir = expand( %:p:h ) endif return l:dir endfunction function Make() cd into current file's directory before obtaining module's root let l:my_local_path = expand(%:h) if (l:my_local_path == ) let l:my_local_path = . endif exec 'lcd ' . l:my_local_path if has(gui_running) Source environment for detached gvim. Use ENV.$INPATH instead of Env.Host.sh when building for more than one platform and ln -s Env.Host.sh ENV.$INPATH or something similar. let l:mymake = source $SRC_ROOT/Env.Host.sh else let l:mymake = endif let l:jobs = 1 define how many jobs you want with make let l:module = GetModuleRoot() Define the make tool, order is significant as a Makefile exists in the project's root returned as module if none exists in the module. if expand( %:t ) == Makefile If the current file is a Makefile, gbuild the entire module. exec 'lcd ' . l:module let l:mymake .= make -sr -j . l:jobs . wall=true debug=true elseif expand( %:t ) == build.lst If the current file is a build.lst, dmake the entire module. let l:mymake .= build.pl wall=true debug=true -P2 -- -P3 elseif filereadable( makefile.mk ) let l:mymake .= dmake wall=true debug=true . GetDotPath() . /$INPATH/slo/%:t:r.obj elseif filereadable( l:module . /Makefile ) exec 'lcd ' . l:module Pass target as full path constructed of now relative part. let l:mymake .= make -sr -j . l:jobs . wall=true debug=true $WORKDIR/CxxObject/ . fnamemodify( l:module, :t ) . /%:.:h/%:t:r.o else let l:mymake .= build.pl wall=true debug=true -P2 -- -P3 endif let makeprg = l:mymake make endfunction endif pgpxrN5OCoZQl.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] .vimrc to compile source from within Vim
Hi, On Tuesday, 2011-08-09 18:23:37 +0200, Eike Rathke wrote: to compile the current source file (and only that) Hmm.. actually make continues to build if there there are more sources to compile, even if the target was given. How to make it stop after the specified target? Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpjaLEksLvQQ.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] mysqlc chicken-and-egg bootstrap
On Tue, Aug 09, 2011 at 04:37:51PM +0100, Noel Power wrote: On 05/08/11 10:23, Lionel Elie Mamane wrote: When doing a fresh bootstrap clone and ./autogen.sh '--enable-ext-mysql-connector' '--with-system-mysql' configure complains that the directory mysqlc does not exist and errors out. But that directory will be created by make fetch _after_ configure is finished running, so I'd suggest the attached patch. Else, one has to do: ./autogen.sh make fetch ./autogen.sh '--enable-ext-mysql-connector' '--with-system-mysql' you are using downloaded source tar-balls ? No, git clone of bootstrap repository. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build error in tail_build
Norbert Thiebaud wrote (09-08-11 14:36) ohh! I see. No, you were not supposed to run that script :-) That is what I expected, but had the idea to look for some pointers. Anyhow: better ask advise right away the next time. so, all you need to do is git clone git://anongit.freedesktop.org/libreoffice/core git complains that libo exists and is not empty. Hence my question: any smart way to - get rid of the old master repro + - conserve the (sharing) libreoffice 3-4-0 clone ? Thanks, PS: as a reminder this apply only to master and future release branch out of master (3.5 and after). the 3.3.x and 3.4.x maintenance remain on the old repositories, and will remain there. -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Java debugging
Hello, Could someone help me? I would like to fix a bug with LO Base wizards, I found the java source of the wizard,and even I got how to debug it from OpenOffice instructions: here http://cedric.bosdonnat.free.fr/wordpress/?p=57 and here http://wiki.services.openoffice.org/wiki/Java_and_OpenOffice.org Eclipse runs well, it stops at my breakpoint, and even I can see som variables, actually all the global and static variables, but local variables are not shown,and even if I directly enter the name eclipse can't resolve it. Does any of you have experiences with java components debugging? It would be nice to use it from Eclipse. thank you: Gabor ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ccache support
On Mon, 2011-08-08 at 11:40 +0200, Christian Lohmaier wrote: Hi Lubos, (snip) Not true either. Default ccache size is 1GB, and that is enough when you focus on one branch. (a build uses less than 500MB) Just a note about what I have observed, for anybody who happens to care. I have configured LO with options --disable-mozilla --enable-symbols --enable-dbgutil --enable-crashdump --disable-build-mozilla --without-junit and completed my first build of LO using ccache up to the step `make`. Cache statistics look like ... cache directory /home/terry/.ccache cache hit (direct) 6158 cache hit (preprocessed) 37 cache miss 11986 called for link 563 multiple source files 3 compile failed 212 preprocessor error34 bad compiler arguments60 unsupported source language 15 autoconf compile/link611 unsupported compiler option 1426 no input file 1309 files in cache 30789 cache size 4.1 Gbytes max cache size 10.0 Gbytes This makes me really glad that I set a max cache size larger than the default 1 GB, For comparison, after I had completed several non-product builds of OpenOffice, my cache statistics looked like ... cache directory /media/2ced347d-3cdc-49f5-956d-099d36784957/terry/OOo_hacking/SRC_DIR_ccache cache hit (direct) 0 cache hit (preprocessed) 15499 cache miss 14993 called for link 1192 multiple source files 9 compile failed91 preprocessor error24 unsupported source language 186 autoconf compile/link666 no input file450 files in cache 29986 cache size 1.5 Gbytes max files 10 max cache size 10.0 Gbytes I do not remember turning on cache compression back then, but that could well explain the big difference in cache size. Cheers, Terry. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ccache support
On Tue, Aug 9, 2011 at 1:58 PM, Terrence Enger ten...@iseries-guru.com wrote: On Mon, 2011-08-08 at 11:40 +0200, Christian Lohmaier wrote: Hi Lubos, (snip) Not true either. Default ccache size is 1GB, and that is enough when you focus on one branch. (a build uses less than 500MB) Just a note about what I have observed, for anybody who happens to care. Since we are sharing data point, here is ccache -s for the MacOSX tinderbox: cache directory /Volumes/ccache_ramdisk cache hit (direct) 5595178 cache hit (preprocessed) 217622 cache miss362720 called for link 297911 multiple source files 1281 compile failed 98681 preprocessor error 49165 couldn't find the compiler 5 bad compiler arguments 21278 unsupported source language 4445 autoconf compile/link 420383 unsupported compiler option 689280 no input file 89750 files in cache 59804 cache size 2.0 Gbytes max cache size 2.3 Gbytes ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Suggestion and patch for Confirmation of save format dialog
Hi Noel, Josh, all! @ Noel: Thanks for forwarding! @ Josh: UI designers at work being LibO users? We should definitively meet on the Design Team list ;-) Am Dienstag, den 09.08.2011, 10:31 +0100 schrieb Noel Power: Forwarding this to the ux-advise list, a better forum I think for discussion about such changes Noel On 09/08/11 00:45, Josh Heidenreich wrote: For a long time I have been annoyed at the Are you sure you want to save as a .DOC message, as I find the buttons confusing. True, true - I think this issue came up each year twice during the OOo times. As far as I know, there have been numerous attempts to fix the understandability of the buttons ... First, thanks a lot for taking care about that. Although I think the dialog needs a bit more tweaking, it is a step towards the (very) right direction. I have made some changes, with the button to show the format name. Screenshots: http://thejosh.info/libreoffice/export_format1.png http://thejosh.info/libreoffice/export_format2.png I have coded a patch, although it's against the old repos. As far as I can see, nothing changed but the button layout and their caption. Right? Unfortunately, I think that: * the (possible) length of the button text, and ... * the stacked button layout (which is never used in LibO that way) will eat up the improved understandability of your change. So, what do we have to fill the buttons when exporting (if we want to get back the usual layout)? I assume there are: * the file format description Microsoft Word 97/2000/XP/2003 format * the file format extension .doc Is there something else available within the code/data, e.g. only Microsoft Word format? Is there something we can do to limit the length of the buttons? Given the file formats we have, I think 20 characters containing whole words should be sufficient (e.g. for Microsoft PowerPoint) to cover all major use cases (in English, needs some refinement). Some other things being strange: * I assume that the message Do you want to save the document in this format anyway? refers to some older Yes/No buttons. We may update that as well. * People might not know what ODF refers to. Usually they see odt or odc ... if they see that. -- trying to make it the LibreOffice default file format * The latest ODF file format is nice, but something for experts - especially since the user may wonder where to set the latest ODF file format in this dialog. * The position of the file format description makes the text hard to read - moving it to the end. This leads to ... (non-native English speaker brainstorming) ... == The document may contain formatting or content that cannot be saved in the currently selected file format Microsoft Word 97/2000/XP/2003. Use the default ODF file format and be sure that the document is saved correctly. [Use Microsoft Word Format] [Use Default ODF Format] -- [x] Ask when not saving in ODF format == Is this something which could be turned into reality (=code)? What do you think? Interestingly, the dialog does not provide any further help ... strange. Wondering whether we should ping the documentation team. That said, the most helpful thing (but most difficult) ist to tell people what will be missing exactly in terms of content, features or formatting when exporting documents. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ccache support
Hi *, On Tue, Aug 9, 2011 at 8:58 PM, Terrence Enger ten...@iseries-guru.com wrote: On Mon, 2011-08-08 at 11:40 +0200, Christian Lohmaier wrote: Not true either. Default ccache size is 1GB, and that is enough when you focus on one branch. (a build uses less than 500MB) Just a note about what I have observed, for anybody who happens to care. cache directory /home/terry/.ccache cache hit (direct) 6158 cache hit (preprocessed) 37 cache miss 11986 [...] files in cache 30789 cache size 4.1 Gbytes max cache size 10.0 Gbytes This makes me really glad that I set a max cache size larger than the default 1 GB, So you showed some irrelevant numbers, at least for the current topic. Your cache is filled with other stuff already, not with just the files from one single build. And of course ccache will happily use whatever size is available before it starts to expire old files. But yes, If you build with debug symbols, you need larger cache size. The 500MB for a build was referring to product builds, without any debugging options. For comparison, after I had completed several non-product builds of OpenOffice, my cache statistics looked like ... cache directory /media/2ced347d-3cdc-49f5-956d-099d36784957/terry/OOo_hacking/SRC_DIR_ccache cache hit (direct) 0 cache hit (preprocessed) 15499 cache miss 14993 That is a rather bad hit ratio - something between 5:1 and 10:1 when building often would be what I expect. 1:1 is when you build versions that did have lots of changes in between. And no direct hits? Did you disable it? Norbert's ratio is of course when you build multiple times a day, so might not be that representative either :-) But you see that the cache-size doesn't need to be big to get hits. When you stay on one branch, then the files that didn't match won't match in future, so no need to keep them around, they can be expired. When you switch back and forth in history and between different branches, you should consider using different cache-directories (when you build the other branches seldomly compared to your main tree), or use a bigger size (if the other branch gets build regularly, and thus the files in the cache are touched and thus not considered candidates for expiry). max files 10 Any reason why you set a limit on the number of files? ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ccache support
actually the more interesting numbers are: --disable-ccache make clean time make ccache -C --enable-ccache make clean time make make clean time make Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] mysqlc chicken-and-egg bootstrap
On 09/08/11 17:56, Lionel Elie Mamane wrote: On Tue, Aug 09, 2011 at 04:37:51PM +0100, Noel Power wrote: you are using downloaded source tar-balls ? No, git clone of bootstrap repository. ah ok, anyway, with the new core git this is no longer a problem and the test makes even less sense Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#37319: don't write invalid references to odf files
Hello Eike, Kohei, 2011/8/9 Kohei Yoshida kohei.yosh...@gmail.com On Tue, 2011-08-09 at 05:04 +0200, Markus Mohrhard wrote: Hello, this patch removes entries like #REF! A1:A3 for named ranges when the sheet referenced by the named range is no longer there. I implemented Regina's first suggestion because I don't see a way to implement the other version with our current formula api. All in all this should be quite a save fix since I only added checks that the ScTokenArray contains no error and that the reference is valid. So..., I feel a bit uneasy modifying this for 3.4. First of all, there is a likelihood that the said invalid formula syntax may be affecting other areas where the formula expressions are written, and fixing just for the export of named expressions may not fix the core cause. True. I'll have a look at some other problems too. Also, as Eike hinted, modifying the export code would also affect our ability to import the expression that we generate. We need to check that, and if need be, fix it there as well. The import works quite well. It shows #Ref! as reference which should be quite fine. In addition to that, even after fixing the import to adopt to the new grammar rule, we'll need to be able to import the old, invalid syntax since there are documents out there that contain expressions written that way. I did not change the import filter. This feature is already implemented because [#Ref!] seems to be a valid expression whereas the old expression was not. Given all this, I would feel a little more comfortable nailing this on master the right way, and *then* see if the change is safe enough to be backported to the 3.4 branch. No problem with this. I'll push it to master with some other clean-up soon. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] .vimrc to compile source from within Vim
Hi Eike, On Tue, 9 Aug 2011 18:23:37 +0200 Eike Rathke o...@erack.de wrote: I took the wiki's Vim tip to build a module from within Vim and enhanced it to compile the current source file (and only that) in both, dmake and gbuild modules. If the current file is a Makefile, the entire module is built using make. If the current file is build.lst, the entire module is built using build. Should work (can't test at the moment due to a dying graphics adapter) also with a detached gvim where sourcing the environment is needed first. Attached. http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/ is a cozy place for these. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] .vimrc to compile source from within Vim
Hi Eike, On Tue, 9 Aug 2011 18:50:12 +0200 Eike Rathke o...@erack.de wrote: Hmm.. actually make continues to build if there there are more sources to compile, even if the target was given. How to make it stop after the specified target? for gbuild-based modules I could image that happening with the changes made in gnumake4, because: Makefile = Library depfile - Object depfile - Object compilation = inherent depend by include statement - depends on so make would try to remake the Library depfile as per: http://www.gnu.org/software/make/manual/make.html#Remaking-Makefiles I am just guessing here (to lazy for builds on my vacation), but does make gb_FULLDEPS= (setting gb_FULLDEPS to empty) help? Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Does anyone use 'source_config' files for build.pl ???
I am trying to put build.pl on a died... is this source_config business used by anyone or is that one of these 'hamburg-only' kind of thing ? Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Does anyone use 'source_config' files for build.pl ???
On Tue, 9 Aug 2011 19:44:50 -0500 Norbert Thiebaud nthieb...@gmail.com wrote: I am trying to put build.pl on a died... is this source_config business used by anyone or is that one of these 'hamburg-only' kind of thing ? No and neither should it. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] Fix incorrect import of multi-range data source in chart
I'd like to backport the attached patch to the 3-4 branch.
Without this patch, import of charts in Excel documents fail when the
data series consist of multiple cell ranges, which is common in complex
chart objects. The failure happens only in locales where the function
and range separator is ',' (Tools - Options - Calc - Formula -
Separators - Function), which is default in the English locales and
others.
I've attached a very small example document to demonstrate the failed
chart import, which is amazingly smaller than the patch itself when
compressed. ;-)
Anyway, review and sign-off very much appreciated.
Kohei
--
Kohei Yoshida, LibreOffice hacker, Calc
kohei.yosh...@suse.com
From 0e83658f97696e498ebbc616056fe1a4089ce321 Mon Sep 17 00:00:00 2001
From: Kohei Yoshida kohei.yosh...@suse.com
Date: Tue, 9 Aug 2011 15:49:15 -0400
Subject: [PATCH] Correctly import from Excel charts with multiple ranges.
This was fixed in i#107275, but the fix only worked in locales
where the range/argument separator was ';' (e.g. German locale).
This is the correct fix that works in all locales regardless of
the separator.
---
sc/inc/reftokenhelper.hxx |2 +-
sc/source/core/tool/reftokenhelper.cxx|4 +-
sc/source/filter/xml/XMLTableShapeResizer.cxx |5 ++-
sc/source/ui/unoobj/chart2uno.cxx | 38 +
4 files changed, 33 insertions(+), 16 deletions(-)
diff --git a/sc/inc/reftokenhelper.hxx b/sc/inc/reftokenhelper.hxx
index 8451a16..3566fd7 100644
--- a/sc/inc/reftokenhelper.hxx
+++ b/sc/inc/reftokenhelper.hxx
@@ -55,7 +55,7 @@ public:
*/
static void compileRangeRepresentation(
::std::vectorScTokenRef rRefTokens, const ::rtl::OUString rRangeStr, ScDocument* pDoc,
-::formula::FormulaGrammar::Grammar eGrammar = ::formula::FormulaGrammar::GRAM_ENGLISH);
+const sal_Unicode cSep, ::formula::FormulaGrammar::Grammar eGrammar);
static bool getRangeFromToken(ScRange rRange, const ScTokenRef pToken, bool bExternal = false);
diff --git a/sc/source/core/tool/reftokenhelper.cxx b/sc/source/core/tool/reftokenhelper.cxx
index e77f130..fb54280 100644
--- a/sc/source/core/tool/reftokenhelper.cxx
+++ b/sc/source/core/tool/reftokenhelper.cxx
@@ -47,9 +47,9 @@ using ::std::auto_ptr;
using ::rtl::OUString;
void ScRefTokenHelper::compileRangeRepresentation(
-vectorScTokenRef rRefTokens, const OUString rRangeStr, ScDocument* pDoc, FormulaGrammar::Grammar eGrammar)
+vectorScTokenRef rRefTokens, const OUString rRangeStr, ScDocument* pDoc,
+const sal_Unicode cSep, FormulaGrammar::Grammar eGrammar)
{
-const sal_Unicode cSep = ScCompiler::GetNativeSymbol(ocSep).GetChar(0);
const sal_Unicode cQuote = '\'';
// #i107275# ignore parentheses
diff --git a/sc/source/filter/xml/XMLTableShapeResizer.cxx b/sc/source/filter/xml/XMLTableShapeResizer.cxx
index e0425c0..6d61b80 100644
--- a/sc/source/filter/xml/XMLTableShapeResizer.cxx
+++ b/sc/source/filter/xml/XMLTableShapeResizer.cxx
@@ -35,6 +35,7 @@
#include chartlis.hxx
#include XMLConverter.hxx
#include rangeutl.hxx
+#include compiler.hxx
#include reftokenhelper.hxx
#include tools/debug.hxx
#include com/sun/star/sheet/XSpreadsheetDocument.hpp
@@ -94,7 +95,9 @@ void ScMyOLEFixer::CreateChartListener(ScDocument* pDoc,
return;
auto_ptr vectorScTokenRef pRefTokens(new vectorScTokenRef);
-ScRefTokenHelper::compileRangeRepresentation(*pRefTokens, aRangeStr, pDoc);
+const sal_Unicode cSep = ScCompiler::GetNativeSymbol(ocSep).GetChar(0);
+ScRefTokenHelper::compileRangeRepresentation(
+*pRefTokens, aRangeStr, pDoc, cSep, formula::FormulaGrammar::GRAM_ENGLISH);
if (!pRefTokens-empty())
{
ScChartListener* pCL(new ScChartListener(rName, pDoc, pRefTokens.release()));
diff --git a/sc/source/ui/unoobj/chart2uno.cxx b/sc/source/ui/unoobj/chart2uno.cxx
index 32fc54a..8c43501 100644
--- a/sc/source/ui/unoobj/chart2uno.cxx
+++ b/sc/source/ui/unoobj/chart2uno.cxx
@@ -1043,7 +1043,9 @@ void ScChart2DataProvider::Notify( SfxBroadcaster /*rBC*/, const SfxHint rHint
}
vectorScTokenRef aTokens;
-ScRefTokenHelper::compileRangeRepresentation(aTokens, aRangeRepresentation, m_pDocument, m_pDocument-GetGrammar());
+const sal_Unicode cSep = ScCompiler::GetNativeSymbol(ocSep).GetChar(0);
+ScRefTokenHelper::compileRangeRepresentation(
+aTokens, aRangeRepresentation, m_pDocument, cSep, m_pDocument-GetGrammar());
return !aTokens.empty();
}
@@ -1419,7 +1421,9 @@ ScChart2DataProvider::createDataSource(
}
vectorScTokenRef aRefTokens;
-ScRefTokenHelper::compileRangeRepresentation(aRefTokens, aRangeRepresentation, m_pDocument, m_pDocument-GetGrammar());
+const sal_Unicode cSep = ScCompiler::GetNativeSymbol(ocSep).GetChar(0);
+ScRefTokenHelper::compileRangeRepresentation(
+aRefTokens, aRangeRepresentation, m_pDocument, cSep, m_pDocument-GetGrammar());
if
Re: [Libreoffice] ccache support
On Tue, 2011-08-09 at 21:33 +0200, Christian Lohmaier wrote: Hi *, On Tue, Aug 9, 2011 at 8:58 PM, Terrence Enger ten...@iseries-guru.com wrote: On Mon, 2011-08-08 at 11:40 +0200, Christian Lohmaier wrote: Not true either. Default ccache size is 1GB, and that is enough when you focus on one branch. (a build uses less than 500MB) Just a note about what I have observed, for anybody who happens to care. cache directory /home/terry/.ccache cache hit (direct) 6158 cache hit (preprocessed) 37 cache miss 11986 [...] files in cache 30789 cache size 4.1 Gbytes max cache size 10.0 Gbytes This makes me really glad that I set a max cache size larger than the default 1 GB, So you showed some irrelevant numbers, at least for the current topic. Your cache is filled with other stuff already, not with just the files from one single build. And of course ccache will happily use whatever size is available before it starts to expire old files. Actually, my cache was empty when I started just after midnight ... cache directory /home/terry/.ccache cache hit (direct) 0 cache hit (preprocessed) 0 cache miss 0 files in cache 0 cache size 0 Kbytes max cache size 1.0 Gbytes Then I increased the maximum size. But yes, If you build with debug symbols, you need larger cache size. The 500MB for a build was referring to product builds, without any debugging options. For comparison, after I had completed several non-product builds of OpenOffice, my cache statistics looked like ... cache directory /media/2ced347d-3cdc-49f5-956d-099d36784957/terry/OOo_hacking/SRC_DIR_ccache cache hit (direct) 0 cache hit (preprocessed) 15499 cache miss 14993 That is a rather bad hit ratio - something between 5:1 and 10:1 when building often would be what I expect. 1:1 is when you build versions that did have lots of changes in between. And no direct hits? Did you disable it? This is from last year. I suspect the numbers result from two builds, the first giving almost all misses and second giving almost all hits. I dunno about direct hits. Direct hits may be a feature newer than the ccache I was running then. (snip) max files 10 Any reason why you set a limit on the number of files? No, I think ccache did that all on its own. OTOH, the man page says there is no default value for --max-files. The output from `script` does not contain the string max-files. Sigh. Terry. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Does anyone use 'source_config' files for build.pl ???
I am trying to put build.pl on a diet... Great! I have started twice at the same task but then always got scared by how much of it (and of the Perl modules it uses) can be killed, and thought, what the heck, gbuild is coming anyway;) deliver.pl also contains a fair amount of whatI assume is Hamburg-only -related code. For instance the common_build and COMMON_DEST things. Or what? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Please run an instrumented LO for me (patch included)
In the iOS porting effort one problematic thing is the dynamic code generation used in the C++/UNO bridge. Some experimentation would indicate, however, that in normal use of LO very few kinds of snippets are actually generated, so it would be trivial to just pre-generate a sufficient static set of assembly source code snippets using a short shell script or whatever. (Especially as for iOS there won't be any Java, Python, or binary extension support, or support of Basic macros in documents, so the set of potentially generated code snippets is fixed a priori, even if it might be tedious to exactly find out the whole set.) (It is the App Store rules that as far as I understand prevent the support for arbitrary scripts loaded from the outside in any app, including Basic code in documents. As for dynamic code generation, I don't know if the OS prevents it (mprotect() etc), or whether this too is just an enforced rule. Anyway, my goal for the iOS porting effort is that the code could potentially be used in an app distributed on the App Store. I am not interested in the jailbreaking scene.) So, I would want some empirical data... Could you please add logging output code as below to the codeSnippet() function in the cpp2uno part of the C++/UNO bridge for your platform, and run some representative use cases of LO without using any extensions or macros in documents, but otherwise with complex things going on, sort the stderr output dropping duplicates (sort -u), and post as a followup, thanks. Below is diff for MacOSX (which I know compiles and works), and x86-64 Linux (which I don't have time right now to test (leaving on a short trip with the family in an hour), but it should be trivial to fix in case there is a typo)... Cheers, --tml diff --git a/bridges/source/cpp_uno/gcc3_macosx_intel/cpp2uno.cxx b/bridges/source/cpp_uno/gcc3_macosx_intel/cpp2uno.cxx index 2ceb0bb..6a26bd3 100644 --- a/bridges/source/cpp_uno/gcc3_macosx_intel/cpp2uno.cxx +++ b/bridges/source/cpp_uno/gcc3_macosx_intel/cpp2uno.cxx @@ -438,6 +438,17 @@ unsigned char * codeSnippet( = ((unsigned char *) exec) - p - sizeof (sal_Int32); p += sizeof (sal_Int32); OSL_ASSERT(p - code = codeSnippetSize); +fprintf(stderr, +== codeSnippet to %s, functionIndex=%d%s, vtableOffset=%d\n, +(exec == privateSnippetExecutorGeneral ? General : + (exec == privateSnippetExecutorVoid ? Void : + (exec == privateSnippetExecutorHyper ? Hyper : + (exec == privateSnippetExecutorFloat ? Float : +(exec == privateSnippetExecutorDouble ? Double : + (exec == privateSnippetExecutorClass ? Class : + ???)), +(functionIndex ~0x8000), (functionIndex 0x8000) ? |0x8000:, vtableOffset); +fflush(stderr); return code + codeSnippetSize; } diff --git a/bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx b/bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx index c9b5185..c8d45a7 100644 --- a/bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx +++ b/bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx @@ -434,6 +434,11 @@ unsigned char * codeSnippet( unsigned char * code, // jmpq *%r11 *reinterpret_castsal_uInt32 *( code + 20 ) = 0x00e3ff49; +fprintf(stderr, +== codeSnippet to privateSnippetExecutor, functionIndex=%d%s, vtableOffset=%d\n, +nFunctionIndex), (bHasHiddenParam) ? |0x8000:, nVtableOffset); +fflush(stderr); + return code + codeSnippetSize; } ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Does anyone use 'source_config' files for build.pl ???
ok so I pushed a fist stab at it... (removed 600 line or so) If that cause trouble to someone, you'll know how to blame :-) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#37319: don't write invalid references to odf files
On Tue, 2011-08-09 at 22:56 +0200, Markus Mohrhard wrote: Given all this, I would feel a little more comfortable nailing this on master the right way, and *then* see if the change is safe enough to be backported to the 3.4 branch. No problem with this. I'll push it to master with some other clean-up soon. Sorry, I wasn't clear. I meant to say that it's wrong to replace the whole formula expression with #REF! when only one of the references is invalid. And that's what Eike was questioning too. I'll give you an example. Create a new document, and define a named range such as MyTest : $Sheet1.$A$1+$Sheet2.$A$1 Enter in A2 =MyTest and you'll get 0 as the result of the calculation. Now, delete Sheet2. You'll get error in A2, but when you check the definition of MyTest, you'll see $Sheet1.$A$1+$#REF!.$A$2 When you save this document at this point, what gets saved is table:expression=[$Sheet1.$A$1]+[$#REF!.$A$2] The bug reported in fdo#37391 says that as of ODF 1.2 you must write table:expression=[$Sheet1.$A$1]+[#REF!] when one of sheet, column and row gets invalidated. Since this expression is generated directly from ScCompiler, it's likely affecting other areas where the formula expressions are generated from ScCompiler on export. And the right fix probably needs to be made inside the formula compiler code too. Regards, Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
