Re: partial build not show module name on error
Hello all, On Sat, Feb 11, 2012 at 16:51, Korrawit Pruegsanusak wrote: > If a partial build results in an error, the error message doesn't > contain the module name [snip] Should be fixed with http://cgit.freedesktop.org/libreoffice/core/commit/?id=27164d22884d27009057d13a86578419c100e2e2 Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] convert table.hxx use in editeng/source/editeng/editdoc.hxx
Ping?
On 2012-02-10 11:42, Noel Grandin wrote:
Hi
Convert tools/table.hxx usage in editeng/source/editeng/editdoc.hxx
to boost::ptr_map
Contributed under LGPLv3+ / MPL 1.1 or later.
(And my license statement is on file in the wiki)
Regards, Noel Grandin
Disclaimer: http://www.peralex.com/disclaimer.html
diff --git a/editeng/source/editeng/editattr.hxx
b/editeng/source/editeng/editattr.hxx
index 8e82084..19632c0 100644
--- a/editeng/source/editeng/editattr.hxx
+++ b/editeng/source/editeng/editattr.hxx
@@ -30,9 +30,9 @@
#define _EDITATTR_HXX
#include
+#include
class SvxFont;
-class SvxFontItem;
class SvxWeightItem;
class SvxPostureItem;
class SvxShadowedItem;
diff --git a/editeng/source/editeng/editdoc.cxx
b/editeng/source/editeng/editdoc.cxx
index 0161eaa0..53e293d 100644
--- a/editeng/source/editeng/editdoc.cxx
+++ b/editeng/source/editeng/editdoc.cxx
@@ -2169,33 +2169,36 @@ bool CharAttribList::DbgCheckAttribs() const
}
#endif
-SvxFontTable::SvxFontTable()
+sal_uLong SvxFontTable::GetId( const SvxFontItem& rFontItem ) const
{
+for(FontItemMap::const_iterator it = maFontItemMap.begin(); it !=
maFontItemMap.end(); ++it)
+{
+if ( *it->second == rFontItem )
+return it->first;
+}
+DBG_WARNING( "Font not found: GetId()" );
+return 0;
}
-SvxFontTable::~SvxFontTable()
+void SvxFontTable::Insert( sal_uLong nIdx, SvxFontItem *pFontItem)
{
-SvxFontItem* pItem = First();
-while( pItem )
-{
-delete pItem;
-pItem = Next();
-}
+maFontItemMap.insert( nIdx, pFontItem );
}
-sal_uLong SvxFontTable::GetId( const SvxFontItem& rFontItem )
+int SvxFontTable::Count() const
{
-SvxFontItem* pItem = First();
-while ( pItem )
-{
-if ( *pItem == rFontItem )
-return GetCurKey();
-pItem = Next();
-}
-DBG_WARNING( "Font not found: GetId()" );
-return 0;
+return maFontItemMap.size();
}
+SvxFontItem* SvxFontTable::Get( sal_uLong nIdx )
+{
+FontItemMap::iterator it = maFontItemMap.find( nIdx );
+if (it == maFontItemMap.end() )
+return NULL;
+return it->second;
+}
+
+
SvxColorList::SvxColorList()
{
}
diff --git a/editeng/source/editeng/editdoc.hxx
b/editeng/source/editeng/editdoc.hxx
index 2b35c3e..6a14fdf 100644
--- a/editeng/source/editeng/editdoc.hxx
+++ b/editeng/source/editeng/editdoc.hxx
@@ -39,8 +39,8 @@
#include
#include
#include
-
#include
+#include "boost/ptr_container/ptr_map.hpp"
class ImpEditEngine;
class SvxTabStop;
@@ -141,15 +141,20 @@ SV_DECL_PTRARR( ContentInfoArray, ContentAttribsInfoPtr,
1 )
// --
// class SvxFontTable
// --
-DECLARE_TABLE( DummyFontTable, SvxFontItem* )
-class SvxFontTable : public DummyFontTable
+class SvxFontTable
{
+private:
+typedef boost::ptr_map FontItemMap;
+FontItemMap maFontItemMap;
public:
-SvxFontTable();
-~SvxFontTable();
+SvxFontTable() {}
+~SvxFontTable() {}
-sal_uLong GetId( const SvxFontItem& rFont );
+sal_uLongGetId( const SvxFontItem& rFont ) const;
+void Insert( sal_uLong nIdx, SvxFontItem *pFontItem );
+int Count() const;
+SvxFontItem* Get( sal_uLong nIdx );
};
// --
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
build break, master, windows7, something to do with tools/string.hxx
Hi Getting compile errors on Windows7 64-bit building master, using VisualStudio2008. Regards, Noel Grandin c:/LibreOffice/libo/sw/source/filter/ww8/ww8par3.cxx(2186) : error C2679: binary '=' : no operator found which takes a right-hand operand of type 'const char *' (or there is no acceptable conversion) C:/LibreOffice/libo/solver/wntmsci12.pro/inc\tools/string.hxx(146): could be 'void String::operator =(int)' C:/LibreOffice/libo/solver/wntmsci12.pro/inc\tools/string.hxx(200): or 'String &String::operator =(const String &)' C:/LibreOffice/libo/solver/wntmsci12.pro/inc\tools/string.hxx(202): or 'String &String::operator =(const rtl::OUString &)' C:/LibreOffice/libo/solver/wntmsci12.pro/inc\tools/string.hxx(204): or 'String &String::operator =(const sal_Unicode *)' C:/LibreOffice/libo/solver/wntmsci12.pro/inc\tools/string.hxx(206): or 'String &String::operator =(sal_Unicode)' C:/LibreOffice/libo/solver/wntmsci12.pro/inc\tools/string.hxx(208): or 'String &String::operator =(char)' while trying to match the argument list '(String, const char *)' Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: build break, master, windows7, something to do with tools/string.hxx
Fixed by 7fd4640469ce0cc3211a38393c7f25bd2deecd87 --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [OBSOLETE] convert table.hxx use in editeng/source/editeng/editdoc.hxx
That patch doesn't apply at all any more; the affected code has already been changed completely by your own commit a0cd57b926830e8798a5019b30776e94dd97c8a1 !? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [OBSOLETE] convert table.hxx use in editeng/source/editeng/editdoc.hxx
Oh, my bad, so sorry. On 2012-03-07 11:07, Tor Lillqvist wrote: That patch doesn't apply at all any more; the affected code has already been changed completely by your own commit a0cd57b926830e8798a5019b30776e94dd97c8a1 !? --tml Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: build break, master, windows7, something to do with tools/string.hxx
thanks On 2012-03-07 11:03, Tor Lillqvist wrote: Fixed by 7fd4640469ce0cc3211a38393c7f25bd2deecd87 --tml Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Base hangs when trying to close it
Michael Meeks-2 wrote > >> "make check" failed before I git update (and so didn't retrieve yet your >> commit which includes a possible fix). > :-) so - I didn't commit the patch I sent you, I'd love some testing / > feedback though. > Hi Michael, Sorry, I thought http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b2cb23c429e1be1099008473770c634ce96c969 was your commit, my mistake. Michael Stahl created a tracker here : https://bugs.freedesktop.org/show_bug.cgi?id=47021. Now we'll be able to keep on the investigation on bugzilla as you had suggested. Thank you both of you ! Julien. -- View this message in context: http://nabble.documentfoundation.org/Base-hangs-when-trying-to-close-it-tp3798832p3806247.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
[ANN] LibreOffice 3.5.1 RC2 pre-available
Hi *, for the upcoming new version 3.5.1, the RC2 builds now start to be available on pre-releases. This build is slated to be second release candidate build on the way towards 3.5.1, please refer to our release plan timings here: http://wiki.documentfoundation.org/ReleasePlan#3.5_release Builds are now being uploaded to a public (but non-mirrored - so don't spread news too widely!) place, as soon as they're available. Grab them here: http://dev-builds.libreoffice.org/pre-releases/ If you've a bit of time, please give them a try & report *critical* bugs not yet in bugzilla here, so we can incorporate them into the release notes. Please note that it takes approximately 24 hours to populate the mirrors, so that's about the time we have to collect feedback. The list of fixed bugs relative to 3.5.1-rc2 is here: http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-5-1-release-3.5.1.2.log So playing with the areas touched there also greatly appreciated - and validation that those bugs are really fixed. Thanks a lot for your help, Fridrich (following words copyrighted by Thorsten) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Promoting RCs on Facebook
Hi, as already written to the marketing list: Can the maintainer of https://www.facebook.com/libreoffice.org please raise his hand? I've seen again that the folder http://dev-builds.libreoffice.org/pre-releases/ has been mentioned there to promote testing. This is not very useful as this is a single machine to carry the load. It is better to wait for the mirror network, which makes the test-builds available at http://download.documentfoundation.org/libreoffice/testing/ Thank you. Volker -- Volker Merschmann Member of The Document Foundation http://www.documentfoundation.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW][3-5] disarm bogus unoapi XPropertySet test
On 06/03/12 13:38, julien2412 wrote: > see full error log at > /home/julien/compile-libreoffice/libo/workdir/unxlngx6/JunitTest/sw_unoapi/done.log > http://nabble.documentfoundation.org/file/n3803458/done.log.zip done.log.zip your log says that the XPropertySet test for an SwXTextSection failed: > * State for sw.SwXTextSection::com::sun::star::beans::XPropertySet ** > [sw.SwXTextSection::com::sun::star::beans::XPropertySet::setPropertyValue()] > is testcode: [setPropertyValue()] - PASSED.FAILED specifically setting this property: > LOG> setting property 'LinkRegion' failed looking at my log file for this test, the properties are tested in a completely different order, and setting the LinkRegion doesn't fail for me; thus i conclude that this unoapi test framework tests properties in a random order and expects that to actually work, which is yet more evidence to back the hypothesis that unoapi tests are completely braindamaged. so i've decided to disable the check that the value of the property is actually different after calling setPropertyValue: http://cgit.freedesktop.org/libreoffice/core/commit/?id=73867da36960adf8b79ff34c7094c63aa5a05940 please somebody review and apply it to libreoffice-3-5 as well. > Of course, it's a different thing. > > Now : > - should I file a bug for initial problem (or is too late because you patch > fixes it) ? i've filed fdo#47021 since the patch doesnt fix it :) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Relicensing of my contributions
To whom it might concern : All of my past and future contributions to LibreOffice may be licensed under the MPL/LGPLv3+ dual license, including the go-ooo code. Best regards, -- Éric Bischoff Strasbourg, France ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW][3-5] Re: Two Python 2.x regressions in LibreOffice 3.5.1RC1
On 04/03/12 00:45, David Bolen wrote: > I've run into two regressions (from 3.4.5) when using LibreOffice > 3.5.1RC1 with the internal Python interpreter (though I believe it will > affect any Python 2.x user), both apparently unintended consequences of > an earlier Python 3 compatibility commit. hi David, thanks for bringing these regressions to this list; in my experience usually QA people aren't very fond of looking at API issues. > Specifically: > > 1. (Bug 46926) Switching to a rich comparison function for wrapped >object comparisons was incomplete, and essentially disabled >comparisons silently. For existing code, comparisons that used to be >true will simply always be false. http://cgit.freedesktop.org/libreoffice/core/commit/?id=387389b644b91808fdee74846b2d855382f48ed7 > 2. (Bug 46859) Changes to support Python 3's "str" type being unicode >broke some of the class wrapping in uno.py under Python 2, so you can >no longer set (or even dereference) Char values without generating an >exception in Python 2. (Bug 46859) http://cgit.freedesktop.org/libreoffice/core/commit/?id=4634cbc237239da771e0f6a81f78171ecec726ba > I expect that there will be others such as myself, for which 3.5.1 will > be the first 3.5 release used with Python, so if there's any way to > consider these issues for inclusion before 3.5.1 final I think it would > be useful. If nothing else, the rich comparison fix is very modest and > not fixable by an end user. unfortunately it's probably too late for 3.5.1 now, but 3.5.2 is just some weeks away. > The uno.py case is trickier since I haven't yet proposed a full solution > that retains Python 3 compatibility, though it does seem that as > distributed, the wrapper should be compatible with the internal > interpreter and the larger Python 2.x base in preference to 3. But at > the least, this is more easily fixable by an end user if necessary. we have figured out a way that should work both in Python 2 and 3 (see the comments in the bug). > I'm new to LibreOffice development, so I apologize if this note is a > misuse of this list, with respect to referencing existing bug reports. oh, and it is great that you have patches for the bugs, and it would be a good idea to mention that in the mail :) thanks for finding these bugs and fixing them. could you please confirm that you contribute the patches under MPL/LGPLv3+ license? the best way is to send a blanket mail to this list with the license for all your past and future contributions to LO, add yourself to this wiki page and add a link to that mail in the wiki page: http://wiki.documentfoundation.org/Development/Developers regards, michael PS: please somebody review the above 2 commits and backport to libreoffice-3-5. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
build break, master, windows7-64bit, in tail_build PDFITest
[ build LNK ] CppunitTest/itest_sfx2_metadatable.lib
c:/LibreOffice/libo/sdext/source/pdfimport/test/tests.cxx(113) : error :
Assertion
Test name: `anonymous namespace'::PDFITest::testXPDFParser
assertion failed
- Expression: m_aPageSize.Width == 79400 && m_aPageSize.Height == 59500
- A4 page size (in 100th of points)
c:/LibreOffice/libo/sdext/source/pdfimport/test/tests.cxx(614) : error :
Assertion
Test name: `anonymous namespace'::PDFITest::testOdfWriterExport
assertion failed
- Expression: aAdaptor.odfConvert(
getURLFromSrc("/sdext/source/pdfimport/test/
testinput.pdf"), new OutputWrap(aAbsURL), NULL )
- Exporting to ODF
c:/LibreOffice/libo/sdext/source/pdfimport/test/tests.cxx(598) : error :
Assertion
Test name: `anonymous namespace'::PDFITest::testOdfDrawExport
assertion failed
- Expression: aAdaptor.odfConvert(
getURLFromSrc("/sdext/source/pdfimport/test/
testinput.pdf"), new OutputWrap(aAbsURL), NULL )
- Exporting to ODF
Disclaimer: http://www.peralex.com/disclaimer.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GNU make version
On 07/03/12 03:22, Norbert Thiebaud wrote: > iow. the whole thing about 3.82 is slow is unfounded. Stock 3.82 _is_ > slow because there was a bug that has been found and patched, even > up-streamed by michael IIRC... and that was almost a year ago now... of course i meant stock 3.82 is slow, because that's what you get by default if you don't know that the LO project has its own patched make. but good to know that there is a fix for the problem. > I was amongst those that resisted the notion of having our own gnu > make forcibly bootstrapped in the build process, like we have dmake > now... > I do not object to a --build-make or something like that in > configure.in to automate the building of our own gmake... at least > until the situation settle upstream > _but_ any such version we optionally build from configure _must_ be > straight-up compatible with upstream. we cannot afford to start having > Makefile that > _require_ a custom gnu-make to build. yes. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
CMake (Re: GNU make version)
On Wednesday 07 of March 2012, David Tardon wrote: > On Wed, Mar 07, 2012 at 01:28:05AM +0100, Mat M wrote: > > Hello > > > > Could someone point to archive on choosing gnumake ? > > I am surprised cmake was not elected, since the C means > > cross-platform, and that is one basic of LO. > > Sigh, life would not be complete without enthusiasts telling us we > should switch to cmake (or Qt) every few months. So, please, go read > http://wiki.services.openoffice.org/wiki/Build_System_Analysis for the > basics and > http://openoffice.2283327.n4.nabble.com/New-build-system-td2928559.html > for more questions and answers. That comparison appears to be seriously biased towards gbuild (referred to as 'GNU Make' in the document). I'm not build system expert, but judging from my CMake experience in KDE, the information and conclusions for CMake are either outdated or just plain wrong (given the document dating to the time when KDE SC 4.4 had been released, thus CMake having been used for more than 2 years by that time, I assume it's the the latter). In particular: - recursive make - CMake uses recursive make calls, but it appears the depth is always at most 3, and technically it's just one toplevel make calling make for each subtarget. I can also not see any of the recursive make problems with CMake, with the possible exception of performance. Specifically, doing make -j40 in kde-workspace/kwin really results in up to 40 jobs running at the same time, and dependencies are handled correctly. See also http://www.cmake.org/Wiki/CMake_FAQ#Other_Questions . - starting from a dedicated directory - this is an utter nonsense, CMake allows very modular building. There are even a number of KDE applications (or even plugins) that normally build as a part of a larger whole, but not only each sub-part can be built, but the sub-directory can be put in a tarball and built separately that way, if done properly. Possibly whoever created the document considered CMake's ability to use a large number of small CMakeLists.txt files to be a problem, when it's in fact an advantage. It is also worth noting that gbuild does require starting from dedicated directories. - no migration path - we right now build with two independent build systems, dmake and gbuild, so I don't see why CMake wouldn't be usable the same way. This is probably a result of the incorrect 'dedicated directory' assumption above. In practice CMake should build fine inside a different build system (that's just running 'make' there, right?) as well as the other way around (http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:ExternalProject , which can go as far as even downloading and configuring the external project first). - explicit custom target dependencies - KDE uses a large number of custom source files (such as .kcfg files containing configuration options from which .cpp/.h files for handling them easily are generated) and they're built by simply using the right macro and mentioning the name there. Probably whoever wrote the comparison did not realize CMake has macros too. All in all, with the possible exception of performance problems due to invoking make more than once, about which I can't say reasonably certainly either way, the evaluation of CMake in that document appears to be completely flawed. Also, note that gbuild does not have a number of deficiencies listed, probably because they either were not known by the time or were not deemed important, such as lacking any usable documentation or the inability to detect even the most blatant developer mistakes like typos. Not that I expect people now suddenly jump with joy and start converting to CMake (as much I'm tempted to try it out for real, I think there are more important problems than having a homebrewn build system that seems to work good enough), but even handwritting Makefile files could have probably won such "fair" comparison. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Bug 37361 depends on bug 35669, which changed state. Bug 35669 Summary: Incorrect cross-references to illustrations and equations in master documents https://bugs.freedesktop.org/show_bug.cgi?id=35669 What|Old Value |New Value Resolution|FIXED | Status|RESOLVED|REOPENED -- 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: CMake (Re: GNU make version)
Speaking as someone who likes CMake You may well be right, but right now the cost of switching the build system on such a large project is simply prohibitive. On 2012-03-07 13:57, Lubos Lunak wrote: On Wednesday 07 of March 2012, David Tardon wrote: On Wed, Mar 07, 2012 at 01:28:05AM +0100, Mat M wrote: Hello Could someone point to archive on choosing gnumake ? I am surprised cmake was not elected, since the C means cross-platform, and that is one basic of LO. Sigh, life would not be complete without enthusiasts telling us we should switch to cmake (or Qt) every few months. So, please, go read http://wiki.services.openoffice.org/wiki/Build_System_Analysis for the basics and http://openoffice.2283327.n4.nabble.com/New-build-system-td2928559.html for more questions and answers. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: CMake (Re: GNU make version)
Hi, On Wed, Mar 07, 2012 at 12:57:11PM +0100, Lubos Lunak wrote: > I'm not build system expert, but judging from my CMake experience in KDE, > [...] If you want to start a discussion about the build system to use, you are two years too late. Two years ago, gnu make was the best candidate and in many ways it still is. If there is no pressing reason to use CMake now that is worth the migration costs (which is in manyears, if you include all the disruptions it causes along the way) there is no point in discussing this. I wont tear apart your points on CMake, which are ignoring the specifics of OOo at that time -- most importantly three-layer office(*), for that reason. If you have a simple patch that magically replaces gbuild with CMake everywhere and on all platforms without any major disruptions _and_ has a unique selling point over GNU make, we can come back on this. If not, any further discussion on this is wasting everyones time. Lets just finish this migration and kill of dmake and build.pl instead. Best, Bjoern (*) And trust me, CMake was tested back then. But it just proved the 'breaking your toolchain since 1985'-mem like everything else. Its 'added-value' was none for us as we would have to work around the default assumptions didnt match ours. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Positioning vcl Controls
Hi, I am working on the about dialog and because the changes are quite large, I am pretty much doing the positioning of all controls in the dialog from scratch. So I wanted to ask what is the best way to do this as I can see two main ways: * Positioning them using MAP_APPFONT() and the Pos attribute in the .src file or * Doing it dynamically in the cxx file with SetPos However I also saw in the slides from FOSDEM that some work is being done to make laying out easier, with Boxes and Grids. So yeah, any advice you can give with regards to the best/accepted way to position the controls would be much appreciated :) -- Andrew Higginson ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Promoting RCs on Facebook
Hi, 2012/3/7 Volker Merschmann : > Can the maintainer of https://www.facebook.com/libreoffice.org please > raise his hand? > > I've seen again that the folder > http://dev-builds.libreoffice.org/pre-releases/ has been mentioned > there to promote testing. > This is not very useful as this is a single machine to carry the load. > It is better to wait for the mirror network, which makes the > test-builds available at > http://download.documentfoundation.org/libreoffice/testing/ > In the meantime I have found the names of the maintainers: Gerard Jensen, Don Crowley, Nikola Yanev I do not know any of them and they are not linked from the FB-page. Can anybody help? Volker -- Volker Merschmann Member of The Document Foundation http://www.documentfoundation.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: CMake (Re: GNU make version)
On 07/03/12 12:57, Lubos Lunak wrote: > On Wednesday 07 of March 2012, David Tardon wrote: >> On Wed, Mar 07, 2012 at 01:28:05AM +0100, Mat M wrote: >>> Hello >>> >>> Could someone point to archive on choosing gnumake ? >>> I am surprised cmake was not elected, since the C means >>> cross-platform, and that is one basic of LO. indeed, and AFAIK most of the platforms are supported by CMake by way of the (GNU) make backend. what was your point again? oh, GNU stands for GNU's not UNIX, but we actually found that GNU make also works on UNIX as well :) >> Sigh, life would not be complete without enthusiasts telling us we >> should switch to cmake (or Qt) every few months. So, please, go read >> http://wiki.services.openoffice.org/wiki/Build_System_Analysis for the >> basics and >> http://openoffice.2283327.n4.nabble.com/New-build-system-td2928559.html >> for more questions and answers. > > That comparison appears to be seriously biased towards gbuild (referred to > as 'GNU Make' in the document). > > I'm not build system expert, but judging from my CMake experience in KDE, > the > information and conclusions for CMake are either outdated or just plain wrong > (given the document dating to the time when KDE SC 4.4 had been released, > thus CMake having been used for more than 2 years by that time, I assume it's > the the latter). In particular: most of the people doing the comparison weren't build system experts either, they just had a list of requirements that the current dmake/build.pl system could not fulfill. then they sought input from build system experts on the tools@ooo mailing list, and the CMake maintainer actually showed up there to discuss things. > - recursive make - CMake uses recursive make calls, but it appears the depth > is always at most 3, and technically it's just one toplevel make calling make > for each subtarget. I can also not see any of the recursive make problems > with CMake, with the possible exception of performance. Specifically, doing > make -j40 in kde-workspace/kwin really results in up to 40 jobs running at > the same time, and dependencies are handled correctly. See also > http://www.cmake.org/Wiki/CMake_FAQ#Other_Questions . "with the possible exception of performance" was the main appeal of non-recursive make for us. > - starting from a dedicated directory - this is an utter nonsense, CMake > allows very modular building. There are even a number of KDE applications (or > even plugins) that normally build as a part of a larger whole, but not only > each sub-part can be built, but the sub-directory can be put in a tarball and > built separately that way, if done properly. Possibly whoever created the > document considered CMake's ability to use a large number of small > CMakeLists.txt files to be a problem, when it's in fact an advantage. It is > also worth noting that gbuild does require starting from dedicated > directories. sorry i don't have time to understand this point right now :) > - no migration path - we right now build with two independent build systems, > dmake and gbuild, so I don't see why CMake wouldn't be usable the same way. > This is probably a result of the incorrect 'dedicated directory' assumption > above. In practice CMake should build fine inside a different build system > (that's just running 'make' there, right?) as well as the other way around > (http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:ExternalProject , > which can go as far as even downloading and configuring the external project > first). actually i think i asked the CMake maintainer once (who posted on tools@ooo) whether CMake allowed for having one mode to build a single module, and another mode to build whole OOo; iirc i didn't get a satisfactory answer. > - explicit custom target dependencies - KDE uses a large number of custom > source files (such as .kcfg files containing configuration options from > which .cpp/.h files for handling them easily are generated) and they're built > by simply using the right macro and mentioning the name there. Probably > whoever wrote the comparison did not realize CMake has macros too. that had been pointed out at the time, but really, what's the difference between having to write lots of custom targets in CMake vs. GNU make? the only problem could be that CMake (being at a higher level of abstraction) doesn't offer something that some of our crazy custom stuff would need, but that is just speculation. > All in all, with the possible exception of performance problems due to > invoking make more than once, about which I can't say reasonably certainly > either way, the evaluation of CMake in that document appears to be completely > flawed. it would be great if we had had people with a lot of CMake experience 2 years ago to point out mis-understandings, but alas, they didn't contribute to the discussion back then. > Also, note that gbuild does not have a number of deficiencies listed, > p
[REVIEW] fix for fdo#46336, we should export all row styles
Hey, [1] fixes that we don't export all row styles which is an information loss and produces problems with graphic layer objects. This should not cause any performance impact or a increase in the size of the document since they are moved into one entry for all repeated rows. I think it is a safe fix and should be put into 3-5 but please correct the bug number in the commit message before you push. Regards, Markus [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5ef8396744966b9bd648bc0d1cb654db8c250be ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Rainer Bielefeld changed: What|Removed |Added Depends on||47052 --- Comment #220 from Rainer Bielefeld 2012-03-07 06:32:30 PST --- Add "Bug 47052 - Recovery fails because no access to AppData Temp folder", data loss -- 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
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Rainer Bielefeld changed: What|Removed |Added Depends on||43882 --- Comment #221 from Rainer Bielefeld 2012-03-07 06:34:20 PST --- Add "Bug 43882 - EDITING: CRASH when undo copy paste". It's rather a chin-up to get the crash, but we can't know whether there are other more simple ways to crash LibO because of this bug. -- 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
Q: Is this project of some interest?
Dear all, I believe this is the right list for this message. If it is not, please point me to the right list (and accept my apologizes). For several reasons (let me skip them), at my University we are thinking about starting a project involving ODF and we would like to know if there is already something similar to what we would like to produce and it the LibreOffice community could have some interest in it. The project is about providing LibreOffice with a "Google Docs-like" simultaneous editing capability, but with some improvements and a bazaar (or git) flavor. In our vision, each user has control about a "section" of the text (for simplicity, we are aiming mainly to text documents) and every changes made to the document are propagated to all the users currently on-line (with an experience similar to "Google Docs"). The difference with Google Docs is that the document is not in some fuzzy "cloud," but on the user's disk and the user can edit it while off-line, encrypt it, ... If the user does some changes while off-line, the other copies will receive the updates as soon as the user returns on-line. Different copies will exchange updates in a peer-to-peer fashion, without the need of a centralized repository (the bazaar/git flavor). This feature is my "personal itch" since I would actually use to write "many-hands" documents together with colleagues. Moreover, it would be an important feature of LibreOffice, not shared by other editing solutions. We are aware that there are many technical issues. For some issues we have solutions, for others we are still "combing our ideas." However, before going beyond the "idea combing" stage, I would like to ask the following questions: 1. Are you aware if this type of capability is already available (I do not think so) or currently developed? 2. Has the LibreOffice community some interest in this idea? If it has, this would give us a stronger motivation. 3. Do you have some general suggestions for us? Especially about interfacing the rest of the developers. Thank you for any help you can give us. Regards, Riccardo ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[ANNOUNCE] libreoffice-3.4.6.1 tag created (3.4.6-rc1)
Hi, there have been created the libreoffice-3.4.6.1 tag for 3.4.6-rc1 release. The corresponding official builds will be available within next few days. See the attached list of changes against 3.4.5-final. Now, you might switch your current 3-4 source tree to it using: ./g fetch --tags ./g checkout -b tag-libreoffice-3.4.6.1 libreoffice-3.4.6.1 Linux distro packages might find source tarballs at http://dev-builds.libreoffice.org/pre-releases-3-4/src/ They will be available from the official page together with the builds. See also the schedule at http://wiki.documentfoundation.org/ReleasePlan#3.4_release and release criteria at http://wiki.documentfoundation.org/Release_Criteria Best Regards, Petr + base + don't replace NULLs given by the database by type-default values (fdo#44813) [Lionel Elie Mamane] + fix VIEWING: Crash when page preview after (data sources) (fdo#44040) [Julien Nabet] + make the refresh query filter NULL-safe (fdo#44813) [Lionel Elie Mamane] + missing icons in Index Design dialog (fdo#38435) [Andras Timar] + calc + cast from BorderLine to BorderLine2 is not valid (fdo#39117) [Eike Rathke] + compile defined names that had unresolveds during load (fdo#40378) [Eike Rathke] + fix stop abusing regular string token for XML import (fdo#40590) [Eike Rathke] + fixed chart listener registration during ODS import. (fdo#39118) [Kohei Yoshida] + in INDIRECT() make a non-existing sheet produce an error again (fdo#36109) [Eike Rathke] + resolved Calc export to HTML with graphics failed (fdo#45032) [Eike Rathke] + resolved border width lost in ODF import (fdo#38595) [Eike Rathke] + resolved crash in ScMatrix::GetDimensons() from ScInterpreter (rhbz#783556) [Eike Rathke] + resolves crash on saving a file (fdo#43725) [Eike Rathke] + return early on error in ScInterpreter::GetDBParam, (fdo#2) [Markus Mohrhard] + sc: ODF export: cell styles: (fdo#45450) [Michael Stahl] + sc: fix setting borders (fdo#45115) [Michael Stahl] + components + align dictionary address with DICT_REPO_URL in instsetoo_native/util/openoffice.lst (fdo#44178) [Lior Kaplan] + default conversion of sequences is now again SAFEARRAY of VARIANTs #fdo46165 (i#117010) [Joachim Lingner] + fix crash in XML Form Document. (fdo#40261) [Jan Holesovsky] + fix crash when parsing XML signatures (fdo#39657) [Michael Stahl] + hidden radio button should also gets unset (fdo#43399) [Lionel Elie Mamane] + revert "Fix " (bnc#653688) [Thorsten Behrens] + revert "fix handling of SAFEARRAY(s) returned as variant in olebridge " (fdo#38441) [Noel Power] + filters + fix rotation of shapes in imported MS documents (fdo#43193) [Ivan Timofeev] + handle imported picture attribute from MSO Dialog ( ) (fdo#45995) [Noel Power] + help + don't ignore empty TableCell Element, also check if it's a header (fdo#42924) [Korrawit Pruegsanusak] + impress + do not create an empty slide when printing handouts (fdo#31966) [Ivan Timofeev] + libs-core + connectivity: fix crash on DISTINCT: (fdo#43479) [Michael Stahl] + country code 'IN' is not in use for these locales (fdo#45107, fdo#44208) [Andras Timar] + fix (fdo#44065) [Julien Nabet] + fix crash using instances dialog of dataform navigator (fdo#44816) [Noel Power] + fix crash when loading an invalid .fodt. (fdo#42771) [Jan Holesovsky] + fix hyphenation attributes: (fdo#44082) [Michael Stahl] + fix stop abusing regular string token for XML import (fdo#40590) [Eike Rathke] + impress210: disconnect and reconnect to table style on change model in SdrTableObjImpl (i#117319) [Christian Lippka ORACLE] + ODF export: fix draw:fit-to-size (fdo#45534) [Michael Stahl] + ODF export: fix layout grid invalid ODF (fdo#44073) [Michael Stahl] + ODF export: frames: invalid "min-width" (fdo#45449) [Michael Stahl] + resolved BorderLine with only InnerWidth set does not work (fdo#42784) [Eike Rathke] + restore special DATE handling code for SbxValue::Compute (fdo#44385) [Noel Power] + svxBorderLine::GuessLinesWidths: (fdo#38542) [Michael Stahl] + libs-gui + fix support for embedded images for basic Dialogs ( ) (fdo#45992) [Noel Power] + fix unfortunate name alias mixups with DejaVu fonts (fdo#44078) [Caolán McNamara] + resolved use proper Indian Rupee currency symbol U+20B9 (rhbz#794679) [Eike Rathke] + writer + cleaning up the tabs too early can cause loops (fdo#45908) [Cédric Bosdonnat] + fix hilariously stupid stack guards: (fdo#38745) [Michael Stahl] + fix sw.SwXViewSettings::com::sun::star::text::ViewSettings (fdo#35661) [Bjoern Michaelsen] + fix yet more layout crashes in ~SwRootFrm: (i#101776, fdo#39510) [Michael Stahl] + fixed crasher in dialog destructor (fdo#38515) [Cédric Bosdonnat] + force calculating layout before Activate to avoid crashes and loops (fdo#40438) [Cédric Bosdonnat] + fs34b: (patch provided by mathias.ba.
[ANNOUNCE] Branch libreoffice-3-4-6 created
Hi all, there have been created the libreoffice-3-4-6 branch. It will be used for fine tuning of the 3.4.6 release. The following rules apply: + preferably just translation or blocker fixes + only cherry-picking from libreoffice-3-5 branch + 2 additional reviews needed; 2nd reviewer pushes + no regular merges back to anything LibreOffice 3.4.6 is supposed to be the last 3.4.x bugfix release. All activities are moving to 3.5.x bug fix releases and further LO major releases. It means that it does not make much sense to nominate fixes for libreoffice-3-4 branch any longer. http://wiki.documentfoundation.org/ReleasePlan http://wiki.documentfoundation.org/Development/Branches Now, if you want to switch your clone to the branch, please do: ./g pull -r ./g checkout -b libreoffice-3-4-6 origin/libreoffice-3-4-6 Hopefully it will work for you :-) Most probably, you will also want to do (if you haven't done it yet): git config --global push.default tracking When you do git push with this, git will push only the branch you are on; e.g. libreoffice-3-5-1 when you have switched to it. This will save you some git shouting at you. Happy hacking, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
OString string literals ctor
Hello,
attached is a patch that removes the need to use the
RTL_CONSTASCII_STRINGPARAM macro with OString, similar to the patch from
the 'Obsoleting RTL_CONSTASCII_USTRINGPARAM' thread.
The difference here is that OString has a const char* ctor, which causes some
complications:
- having const char* and const char(&)[N] overloads always prefers the first
one for string literals, which AFAICS should be of the latter type. Trying to
go for const char*(&) does not work e.g. with something explicitly cast to
const char*. The solution I've found is to use a template and use SFINAE
(Substitution failure is not an error) idiom to in practice limit the
template arguments to only char* and const char*. Using the template makes
the compiler consider the const char(&)[N] ctor first. I'm not entirely sure
why this is so, but the problem and solution are consistently the same with
gcc, clang and msvc.
- embedded \0's strike again, RTL_CONSTASCII_* macros include them in the
string, the OString const char* ctor does not. There's no perfect solution,
I've decided to make the string literal ctor include \0's as well, given it's
mostly meant as a replacement for RTL_CONSTASCII_*, moreover if the \0 is
explicitly present in the literal, pressumably it's there for a reason. This
is not backwards compatible for the OString( "\0" ) case, but such code has
been up to now pointless anyway, so I do not see a problem with this. This
required also fixing unittests which tried to use this for whatever reason.
I've checked that I can make a rebuild without this introducing any
compilation warnings or errors.
I'd like to also point out to people doing changes like
- foo == OString( RTL_CONSTASCII_STRINGPARAM( "bar" ))
+ foo.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( "bar" ))
that this will be soon obsolete by these changes and easily replaced by plain
foo == "bar"
(Do we have an Easy Hack asking for the above, so that I change it? I
couldn't find one.)
--
Lubos Lunak
l.lu...@suse.cz
From 95c308df724bc9f7cf42e0e10627bace2c331d37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?=
Date: Tue, 6 Mar 2012 10:44:52 +0100
Subject: [PATCH 1/3] rtl_uString_newFromLiteral() for string literals
Drop the recently introduced rtl_uString_newFromAscii_WithLength()
and replace it with this one. The name fits better and it'll be also
a distinct function that specifically includes embedded \0's
(because that's what OUString supports and if a string literal
explicitly includes it, it makes sense to copy it as such).
---
sal/inc/rtl/ustring.h |9 +++--
sal/inc/rtl/ustring.hxx|4 +-
.../rtl/strings/test_oustring_stringliterals.cxx |7
sal/rtl/source/ustring.cxx | 37 +---
sal/util/sal.map |2 +-
5 files changed, 47 insertions(+), 12 deletions(-)
diff --git a/sal/inc/rtl/ustring.h b/sal/inc/rtl/ustring.h
index 80703f8..e432d2c 100644
--- a/sal/inc/rtl/ustring.h
+++ b/sal/inc/rtl/ustring.h
@@ -1243,14 +1243,15 @@ SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromStr_WithLength(
SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromAscii(
rtl_uString ** newStr, const sal_Char * value ) SAL_THROW_EXTERN_C();
-/** Allocate a new string that contains a copy of a character array.
+/** Allocate a new string that contains a copy of a string literal.
-This is equivalent to rtl_uString_newFromAscii(), except that
-length of the character array is explicitly passed to the function.
+This is similar to rtl_uString_newFromAscii(), except that
+length of the string literal is explicitly passed to the function,
+and embedded \0's are included in the string.
@since 3.6
*/
-SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromAscii_WithLength(
+SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromLiteral(
rtl_uString ** newStr, const sal_Char * value, sal_Int32 len ) SAL_THROW_EXTERN_C();
/** Allocate a new string from an array of Unicode code points.
diff --git a/sal/inc/rtl/ustring.hxx b/sal/inc/rtl/ustring.hxx
index 151e0a2..bb22619 100644
--- a/sal/inc/rtl/ustring.hxx
+++ b/sal/inc/rtl/ustring.hxx
@@ -184,7 +184,7 @@ public:
OUString( const char (&literal)[ N ] )
{
pData = 0;
-rtl_uString_newFromAscii_WithLength( &pData, literal, N - 1 );
+rtl_uString_newFromLiteral( &pData, literal, N - 1 );
if (pData == 0) {
#if defined EXCEPTIONS_OFF
SAL_WARN("sal", "std::bad_alloc but EXCEPTIONS_OFF");
@@ -338,7 +338,7 @@ public:
template< int N >
OUString& operator=( const char (&literal)[ N ] )
{
-rtl_uString_newFromAscii_WithLength( &pData, literal, N - 1 );
+rtl_uString_newFromLiteral( &pData, literal, N - 1 );
if (pData == 0) {
#if defined EXCEPTIONS_OFF
SAL_WARN("sal", "std::bad_alloc but EXCEPTIONS_OFF");
diff --git
Re: [Libreoffice-commits] .: Makefile
On 27 February 2012 09:28, Norbert Thiebaud wrote: >> @@ -342,12 +342,15 @@ ifneq ($(filter-out clean distclean,$(MAKECMDGOALS)),) >> # restart since autogen can have changed >> # config_host.k which is included in this >> # Makefile >> -Makefile: config_host.mk >> +Makefile: $(SRCDIR)/config_host.mk > > why did you have to add $SRCDIR here ? > Makefile has to be run in the top dir... and if not the dependencies below > would not be found (config_host.mk.in for > instance) >> +autogen.lastrun: >> + @true I also don't understand how could autogen.lastrun not exist when config_host.mk is already required and both are created by autogen.sh ? Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH]fdo45671 fix for no transparent colour in calc cell background
As mentioned before, in communication with Ivan and Astron, I have
attached a fix for the split button for cell background colour. It is now
possible again to set the background colour to transparent.
Also I fixed an inconsistency for calc font colour, which does not
influence the behaviour as far I can see, but which is now consistent
with the other split buttons.
On to the next button to be split in two :-)
Winfried
From b7cf81b7aee3aa297ef29c033b20a492eb6c8d5e Mon Sep 17 00:00:00 2001
From: Winfried Donkers
Date: Wed, 7 Mar 2012 17:39:03 +0100
Subject: [PATCH] fdo#45671 fix for transparent colour split button
---
sc/source/ui/view/formatsh.cxx |9 +
svx/source/tbxctrls/tbcontrl.cxx |4
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/sc/source/ui/view/formatsh.cxx b/sc/source/ui/view/formatsh.cxx
index 61522d6..dc75138 100644
--- a/sc/source/ui/view/formatsh.cxx
+++ b/sc/source/ui/view/formatsh.cxx
@@ -1435,6 +1435,15 @@ void ScFormatShell::ExecuteAttr( SfxRequest& rReq )
pTabViewShell->ExecuteCellFormatDlg( rReq, TP_FONT ); // wenn ToolBar vertikal
break;
+case SID_BACKGROUND_COLOR:
+{
+SvxBrushItem aBrushItem( (const SvxBrushItem&)
+ pTabViewShell->GetSelectionPattern()->GetItem( ATTR_BACKGROUND ) );
+aBrushItem.SetColor( COL_TRANSPARENT );
+pTabViewShell->ApplyAttr( aBrushItem );
+}
+break;
+
case SID_ATTR_ALIGN_LINEBREAK: // ohne Parameter als Toggle
{
const ScPatternAttr* pAttrs = pTabViewShell->GetSelectionPattern();
diff --git a/svx/source/tbxctrls/tbcontrl.cxx b/svx/source/tbxctrls/tbcontrl.cxx
index 2a20d4a..cdc447f 100644
--- a/svx/source/tbxctrls/tbcontrl.cxx
+++ b/svx/source/tbxctrls/tbcontrl.cxx
@@ -2250,6 +2250,10 @@ SvxColorExtToolBoxControl::SvxColorExtToolBoxControl(
switch( nSlotId )
{
case SID_ATTR_CHAR_COLOR:
+addStatusListener( OUString( RTL_CONSTASCII_USTRINGPARAM( ".uno:Color" )));
+nMode = TBX_UPDATER_MODE_CHAR_COLOR_NEW;
+break;
+
case SID_ATTR_CHAR_COLOR2:
addStatusListener( OUString( RTL_CONSTASCII_USTRINGPARAM( ".uno:CharColorExt" )));
nMode = TBX_UPDATER_MODE_CHAR_COLOR_NEW;
--
1.7.7
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Linux-x86 not uploading to dev-builds ?
http://dev-builds.libreoffice.org/daily/Linux-x86_10-Release_Configuration/ -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GSoC & error during make
On Tue, Mar 6, 2012 at 3:17 AM, Norbert Thiebaud wrote: > On Mon, Mar 5, 2012 at 6:20 PM, Mariana Marasoiu > wrote: >>> On Sun, Mar 4, 2012 at 7:08 PM, Mariana Marasoiu --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development internal build errors: ERROR: error 65280 occurred while making /home/mariana/Working/git/libo/helpcontent2/source/auxiliary it seems that the error is inside 'helpcontent2', please re-run build inside this module to isolate the error and/or test your fix: --- /bin/bash cd /home/mariana/Working/git/libo source ./Env.Host.sh cd helpcontent2 rm -Rf /home/mariana/Working/git/libo/helpcontent2/unxlngi6.pro # optional module 'clean' build >>> >>> What version are you trying to build ? this message seems to indicate >>> something more than a month old >> >> Well, I am trying to build the master branch of the git repo. > > The thing is that message above, especially the part about 'source > ./Env.Host.sh does not exist in master since February 5th (see > solenv/bin/build.pl) > >>Today I made a simple git pull to get the latest changes, and then ran >> make again, but with the same result. > > the problem may be that you dd a git pull and not a ./g pull -r ? > I did yesterday a ./g pull -r but it didn't fix the build. Afterwards, I tried a make clean & make, which ended with the same result. I followed Korrawit's instructions and realised that the branch I was trying to build wasn't the master, but libreoffice-3-5. So I switched to master, did ./g pull -r and now it's building once again. Lets hope this time works :D > In any case... > you mentionned > > http://wiki.documentfoundation.org/Development/How_to_build > > I supposed you read > http://wiki.documentfoundation.org/Development/How_to_build#The_Build_Failed..._What_can_I_do.C2.A0.3F > > and particularely the part: > " > [...] > ERROR: error 65280 occurred while making /lo/libo/connectivity/source/cpool > > it seems that the error is inside 'connectivity', please re-run build > inside this module to isolate the error and/or test your fix: > --- > [...] > make: *** [all] Error 1 > > First things: do not post that on the mailing list. The only useful > information in all this is that the module 'connectivity' could not be > built for some yet unknown reason. > [..] > " To my shame, I skipped the part where it said I shouldn't be posting that on the list. I'm sorry about that and next time I'l make sure I'll read more carefully the documentation before posting. Thanks for pointing it out! ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW] fix for fdo#46336, we should export all row styles
On Wed, Mar 7, 2012 at 9:31 AM, Markus Mohrhard wrote: > [1] fixes that we don't export all row styles which is an information > loss and produces problems with graphic layer objects. This should not > cause any performance impact or a increase in the size of the document > since they are moved into one entry for all repeated rows. > > I think it is a safe fix and should be put into 3-5 but please correct > the bug number in the commit message before you push. > > Regards, > Markus > > [1] > http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5ef8396744966b9bd648bc0d1cb654db8c250be Yup, I like the new code as it's much simpler & makes sense. I've also verified that it fixes the problem for fdo#46336. Pushed to the 3-5 branch with my sign-off. Kohei P.S. the original commit appears to have the wrong bug number. I fixed that in the commit message for the 3-5 branch. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEWED][PUSHED 3-5] fix for fdo#46336, we should export all row styles
Setting proper tags. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Q: Is this project of some interest?
On Wed, Mar 7, 2012 at 8:39 AM, Riccardo Bernardini wrote: > > This feature is my "personal itch" since I would actually use to write that is usually the best motivation to achieve anything in opensource :-) > "many-hands" documents together with colleagues. Moreover, it would be > an important feature of LibreOffice, not shared by other editing > solutions. > [...] > > 1. Are you aware if this type of capability is already available (I > do not think so) or currently developed? Not that I'm aware of... but I've recall seeing some discussion of people on the ML itching a similar topic (i.e how to store document in a git-friendly manner, altough IIRc that was not for 'sharing per say, but simply for the change-tradcking aspect) > 2. Has the LibreOffice community some interest in this idea? If it > has, this would give us a stronger motivation. The 'LibreOffice community', just like most, rarely has a single mind. But in the end the question is not 'are you for it', but 'is there a showstopper that would make you against it' > 3. Do you have some general suggestions for us? Especially about > interfacing the rest of the developers. My suggestion woud be: do as you would for any open source community: show-up, do some work, get yourself known for your work Lead by example to attract people that will find your itch something they are interested i... and code is much more convincing than talk. Engage on this ML, on IRC, read the relevant part of the Wiki, get familiar with the build process by doing some easy hacks... The Dev Community is pretty welcoming to new dev of any level and skill. On a higher level, smaller incremental changes are easier to get in than big-bad dump. so try to break-down you itch in manage-ably small feature, preferably that do not break things :-) and get them in one at the time... or instance working on improving, if need be, the 'uncompressed/flat' odf format... then saving directly in a git repo (with commit and all), then managing git conflict-resolution, then managing push/pull... (this is just an example based on your description.. I have no idea what the real technical/functional hurdle are...) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] .: Makefile
On Wed, Mar 7, 2012 at 10:16 AM, Matúš Kukan wrote: > On 27 February 2012 09:28, Norbert Thiebaud wrote: >>> @@ -342,12 +342,15 @@ ifneq ($(filter-out clean distclean,$(MAKECMDGOALS)),) >>> # restart since autogen can have changed >>> # config_host.k which is included in this >>> # Makefile >>> -Makefile: config_host.mk >>> +Makefile: $(SRCDIR)/config_host.mk >> >> why did you have to add $SRCDIR here ? >> Makefile has to be run in the top dir... and if not the dependencies below >> would not be found (config_host.mk.in for >> instance) > >>> +autogen.lastrun: >>> + @true > > I also don't understand how could autogen.lastrun not exist when > config_host.mk is already required and both are created by autogen.sh ? The only scenarii I can think of are: make jsut after clone without autogen first make disclean without autogen afterward in both case, a user error I think... we could add a $(error in case config_host.mk is not there to tell more clearly to the user that he is being silly. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Q: Is this project of some interest?
You could take a look at the code that Abiword has. They have a feature to do this by Bonjour/Avahi, Jabber and proper collaboration servers. 2012/3/7 Norbert Thiebaud > On Wed, Mar 7, 2012 at 8:39 AM, Riccardo Bernardini > wrote: > > > > This feature is my "personal itch" since I would actually use to write > > that is usually the best motivation to achieve anything in opensource :-) > > > "many-hands" documents together with colleagues. Moreover, it would be > > an important feature of LibreOffice, not shared by other editing > > solutions. > > > [...] > > > > 1. Are you aware if this type of capability is already available (I > > do not think so) or currently developed? > > Not that I'm aware of... but I've recall seeing some discussion of > people on the ML itching a similar topic (i.e how to store document in > a git-friendly manner, altough IIRc that was not for 'sharing per say, > but simply for the change-tradcking aspect) > > > 2. Has the LibreOffice community some interest in this idea? If it > > has, this would give us a stronger motivation. > > The 'LibreOffice community', just like most, rarely has a single mind. > But in the end the question is not 'are you for it', but 'is there a > showstopper that would make you against it' > > > 3. Do you have some general suggestions for us? Especially about > > interfacing the rest of the developers. > > My suggestion woud be: do as you would for any open source community: > show-up, do some work, get yourself known for your work > Lead by example to attract people that will find your itch something > they are interested i... and code is much more convincing than talk. > Engage on this ML, on IRC, read the relevant part of the Wiki, get > familiar with the build process by doing some easy hacks... > The Dev Community is pretty welcoming to new dev of any level and skill. > > On a higher level, smaller incremental changes are easier to get in > than big-bad dump. so try to break-down you itch in manage-ably small > feature, preferably that do not break things :-) and get them in one > at the time... or instance working on improving, if need be, the > 'uncompressed/flat' odf format... then saving directly in a git repo > (with commit and all), then managing git conflict-resolution, then > managing push/pull... (this is just an example based on your > description.. I have no idea what the real technical/functional hurdle > are...) > > Norbert > ___ > 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-commits] .: Makefile
On Wed, Mar 7, 2012 at 10:16 AM, Matúš Kukan wrote: > On 27 February 2012 09:28, Norbert Thiebaud wrote: >>> @@ -342,12 +342,15 @@ ifneq ($(filter-out clean distclean,$(MAKECMDGOALS)),) >>> # restart since autogen can have changed >>> # config_host.k which is included in this >>> # Makefile >>> -Makefile: config_host.mk >>> +Makefile: $(SRCDIR)/config_host.mk >> >> why did you have to add $SRCDIR here ? >> Makefile has to be run in the top dir... and if not the dependencies below >> would not be found (config_host.mk.in for >> instance) Good question... Perter ? why did you do that change, what issue were you trying to fix ? > >>> +autogen.lastrun: >>> + @true > > I also don't understand how could autogen.lastrun not exist when > config_host.mk is already required and both are created by autogen.sh ? > > Matus > ___ > 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
[PATCH] Remove unused code
This patch removes unused code as listed in unusedcode.easy
From 7b4e4199bdf631796f69813e60c296b0a0561e0c Mon Sep 17 00:00:00 2001
From: Santiago Martinez
Date: Wed, 7 Mar 2012 20:32:25 +0100
Subject: [PATCH] Remove unused code
---
connectivity/inc/connectivity/dbcharset.hxx |1 -
connectivity/source/commontools/dbcharset.cxx |6 --
unusedcode.easy |1 -
3 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/connectivity/inc/connectivity/dbcharset.hxx b/connectivity/inc/connectivity/dbcharset.hxx
index 60c96fb..cb13fcd 100644
--- a/connectivity/inc/connectivity/dbcharset.hxx
+++ b/connectivity/inc/connectivity/dbcharset.hxx
@@ -116,7 +116,6 @@ namespace dbtools
::rtl::OUString getIanaName() const { return m_aIanaName; }
protected:
-CharsetIteratorDerefHelper();
CharsetIteratorDerefHelper( const rtl_TextEncoding _eEncoding, const ::rtl::OUString& _rIanaName );
};
diff --git a/connectivity/source/commontools/dbcharset.cxx b/connectivity/source/commontools/dbcharset.cxx
index 87b78c4..45729df 100644
--- a/connectivity/source/commontools/dbcharset.cxx
+++ b/connectivity/source/commontools/dbcharset.cxx
@@ -154,12 +154,6 @@ namespace dbtools
{
}
-//-
-CharsetIteratorDerefHelper::CharsetIteratorDerefHelper()
-:m_eEncoding(RTL_TEXTENCODING_DONTKNOW)
-{
-}
-
//=
//= OCharsetMap::CharsetIterator
//=
diff --git a/unusedcode.easy b/unusedcode.easy
index 80eff11..9e16d5f 100755
--- a/unusedcode.easy
+++ b/unusedcode.easy
@@ -875,7 +875,6 @@ cppcanvas::internal::(anonymous namespace)::TransparencyGroupAction::Transparenc
cppcanvas::internal::ImplSprite::ImplSprite(com::sun::star::uno::Reference const&, com::sun::star::uno::Reference const&, boost::shared_ptr const&)
cppcanvas::internal::ImplText::ImplText(boost::shared_ptr const&, rtl::OUString const&)
dbaui::getKeyColumns(com::sun::star::uno::Reference const&, int)
-dbtools::CharsetIteratorDerefHelper::CharsetIteratorDerefHelper()
dbtools::DBTypeConversion::toINT64(com::sun::star::util::DateTime const&)
dbtools::SQLExceptionInfo::SQLExceptionInfo(com::sun::star::sdb::SQLErrorEvent const&)
dbtools::SQLExceptionIteratorHelper::SQLExceptionIteratorHelper(com::sun::star::sdb::SQLContext const&)
--
1.7.7.6
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Remove unused code in vbahelper
This patch removes unused code as listed in unusedcode.eas
From 4299bf917c9ac0c02dd5aecc8b40e09e775136f6 Mon Sep 17 00:00:00 2001
From: Santiago Martinez
Date: Wed, 7 Mar 2012 20:54:46 +0100
Subject: [PATCH] Remove unused code in vbahelper
---
unusedcode.easy |4
vbahelper/inc/vbahelper/vbahelper.hxx|4
vbahelper/source/vbahelper/vbahelper.cxx | 14 --
3 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/unusedcode.easy b/unusedcode.easy
index 9e16d5f..255ef66 100755
--- a/unusedcode.easy
+++ b/unusedcode.easy
@@ -907,10 +907,6 @@ nullcanvas::SpriteCanvasHelper::opaqueUpdate(basegfx::B2DConnectedRanges::ConnectedComponents const&)
o3tltests::cow_wrapper_client2::queryUnmodified() const
o3tltests::cow_wrapper_client3::queryUnmodified() const
-ooo::vba::Millimeter::get()
-ooo::vba::Millimeter::getInPoints()
-ooo::vba::Millimeter::set(double)
-ooo::vba::Millimeter::setInHundredthsOfOneMillimeter(double)
ooo::vba::createVBAUnoAPIService(SfxObjectShell*, char const*)
ooo::vba::excel::getViewFrame(com::sun::star::uno::Reference const&)
ooo::vba::excel::isInPrintPreview(SfxViewFrame*)
diff --git a/vbahelper/inc/vbahelper/vbahelper.hxx b/vbahelper/inc/vbahelper/vbahelper.hxx
index 00dfe58..190243c 100644
--- a/vbahelper/inc/vbahelper/vbahelper.hxx
+++ b/vbahelper/inc/vbahelper/vbahelper.hxx
@@ -147,12 +147,8 @@ public:
Millimeter(double mm);
-void set(double mm);
void setInPoints(double points) ;
-void setInHundredthsOfOneMillimeter(double hmm);
-double get();
double getInHundredthsOfOneMillimeter();
-double getInPoints();
static sal_Int32 getInHundredthsOfOneMillimeter(double points);
static double getInPoints(int _hmm);
};
diff --git a/vbahelper/source/vbahelper/vbahelper.cxx b/vbahelper/source/vbahelper/vbahelper.cxx
index f99077d..70fe850 100644
--- a/vbahelper/source/vbahelper/vbahelper.cxx
+++ b/vbahelper/source/vbahelper/vbahelper.cxx
@@ -1179,29 +1179,15 @@ Millimeter::Millimeter():m_nMillimeter(0) {}
Millimeter::Millimeter(double mm):m_nMillimeter(mm) {}
-void Millimeter::set(double mm) { m_nMillimeter = mm; }
void Millimeter::setInPoints(double points)
{
m_nMillimeter = points * factor / 100.0;
}
-void Millimeter::setInHundredthsOfOneMillimeter(double hmm)
-{
-m_nMillimeter = hmm / 100;
-}
-
-double Millimeter::get()
-{
-return m_nMillimeter;
-}
double Millimeter::getInHundredthsOfOneMillimeter()
{
return m_nMillimeter * 100;
}
-double Millimeter::getInPoints()
-{
-return m_nMillimeter / factor * 100.0;
-}
sal_Int32 Millimeter::getInHundredthsOfOneMillimeter(double points)
{
--
1.7.7.6
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Alex Thurgood changed: What|Removed |Added Depends on||47068 -- 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
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 --- Comment #222 from Alex Thurgood 2012-03-07 12:36:36 PST --- Adding 47068, nasty crash in Report Builder when moving a graphical object over a text field. Alex -- 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
[PATCH] Remove unused code(2)
This patch removes unused code as listed in unusedcode.easy
From 19f0c3ee363967fdd01601d640aff69c705b0303 Mon Sep 17 00:00:00 2001
From: Santiago Martinez
Date: Wed, 7 Mar 2012 21:32:29 +0100
Subject: [PATCH] Remove unused code in vbahelper
---
unusedcode.easy |3 ---
vbahelper/inc/vbahelper/vbahelper.hxx|7 ---
vbahelper/source/vbahelper/vbahelper.cxx | 17 -
3 files changed, 0 insertions(+), 27 deletions(-)
diff --git a/unusedcode.easy b/unusedcode.easy
index 255ef66..381d978 100755
--- a/unusedcode.easy
+++ b/unusedcode.easy
@@ -907,11 +907,8 @@ nullcanvas::SpriteCanvasHelper::opaqueUpdate(basegfx::B2DConnectedRanges::ConnectedComponents const&)
o3tltests::cow_wrapper_client2::queryUnmodified() const
o3tltests::cow_wrapper_client3::queryUnmodified() const
-ooo::vba::createVBAUnoAPIService(SfxObjectShell*, char const*)
ooo::vba::excel::getViewFrame(com::sun::star::uno::Reference const&)
ooo::vba::excel::isInPrintPreview(SfxViewFrame*)
-ooo::vba::extractBoolFromAny(com::sun::star::uno::Any const&, bool)
-ooo::vba::extractIntFromAny(com::sun::star::uno::Any const&, int)
oox::AttributeConversion::decodeHyperHex(rtl::OUString const&)
oox::AttributeConversion::decodeUnsignedHex(rtl::OUString const&)
oox::ContainerHelper::insertByIndex(com::sun::star::uno::Reference const&, int, com::sun::star::uno::Any const&)
diff --git a/vbahelper/inc/vbahelper/vbahelper.hxx b/vbahelper/inc/vbahelper/vbahelper.hxx
index 190243c..9a3da3c 100644
--- a/vbahelper/inc/vbahelper/vbahelper.hxx
+++ b/vbahelper/inc/vbahelper/vbahelper.hxx
@@ -75,7 +75,6 @@ namespace ooo
VBAHELPER_DLLPUBLIC css::uno::Reference< XHelperInterface > getVBADocument( const css::uno::Reference< css::frame::XModel >& xModel );
VBAHELPER_DLLPUBLIC css::uno::Reference< XHelperInterface > getUnoDocModule( const String& aModName, SfxObjectShell* pShell );
VBAHELPER_DLLPUBLIC SfxObjectShell* getSfxObjShell( const css::uno::Reference< css::frame::XModel >& xModel ) throw ( css::uno::RuntimeException);
-VBAHELPER_DLLPUBLIC css::uno::Reference< css::uno::XInterface > createVBAUnoAPIService( SfxObjectShell* pShell, const sal_Char* _pAsciiName ) throw (css::uno::RuntimeException);
css::uno::Reference< css::frame::XModel > getCurrentDoc( const rtl::OUString& sKey ) throw (css::uno::RuntimeException);
VBAHELPER_DLLPUBLIC css::uno::Reference< css::frame::XModel > getThisExcelDoc( const css::uno::Reference< css::uno::XComponentContext >& xContext ) throw (css::uno::RuntimeException);
@@ -103,16 +102,10 @@ namespace ooo
/** Extracts a 32-bit integer value from the passed Any, which may contain an integer or floating-point value.
Throws, if the Any is empty or contains an incompatible type. */
VBAHELPER_DLLPUBLIC sal_Int32 extractIntFromAny( const css::uno::Any& rAny ) throw (css::uno::RuntimeException);
-/** Extracts a 32-bit integer value from the passed Any, which may contain an integer or floating-point value.
-Returns nDefault, if rAny is empty. Throws, if the Any contains an incompatible type. */
-VBAHELPER_DLLPUBLIC sal_Int32 extractIntFromAny( const css::uno::Any& rAny, sal_Int32 nDefault ) throw (css::uno::RuntimeException);
/** Extracts a boolean value from the passed Any, which may contain a Boolean or an integer or floating-point value.
Throws, if the Any is empty or contains an incompatible type. */
VBAHELPER_DLLPUBLIC bool extractBoolFromAny( const css::uno::Any& rAny ) throw (css::uno::RuntimeException);
-/** Extracts a boolean value from the passed Any, which may contain a Boolean or an integer or floating-point value.
-Returns bDefault, if rAny is empty. Throws, if the Any contains an incompatible type. */
-VBAHELPER_DLLPUBLIC bool extractBoolFromAny( const css::uno::Any& rAny, bool bDefault ) throw (css::uno::RuntimeException);
/** Extracts a string from the passed Any, which may contain a Boolean, a value, or a string.
Throws, if the Any is empty or contains an incompatible type. */
diff --git a/vbahelper/source/vbahelper/vbahelper.cxx b/vbahelper/source/vbahelper/vbahelper.cxx
index 70fe850..03525baf 100644
--- a/vbahelper/source/vbahelper/vbahelper.cxx
+++ b/vbahelper/source/vbahelper/vbahelper.cxx
@@ -97,13 +97,6 @@ namespace vba
namespace { const double factor = 2540.0 / 72.0; }
-css::uno::Reference< css::uno::XInterface > createVBAUnoAPIService( SfxObjectShell* pShell, const sal_Char* _pAsciiName ) throw (css::uno::RuntimeException)
-{
-OSL_PRECOND( pShell, "createVBAUnoAPIService: no shell!" );
-::rtl::OUString sVarName( ::rtl::OUString::createFromAscii( _pAsciiName ) );
-return getVBAServiceFactory( pShell )->createInstance( sVarName );
-}
-
// helper method to determine if the view ( calc ) is in print-preview mode
bool isInPrintPreview( SfxViewFrame* pView )
{
[PATCH] Remove unused code(3)
This patch removes unused code as listed in unusedcode.easy
From 5ad94b05322b615da580027ed99e8a4e7ca68a51 Mon Sep 17 00:00:00 2001
From: Santiago Martinez
Date: Wed, 7 Mar 2012 21:46:11 +0100
Subject: [PATCH] Remove unused code as listed in unusedcode.easy
---
sc/source/ui/vba/excelvbahelper.cxx | 22 --
sc/source/ui/vba/excelvbahelper.hxx |1 -
unusedcode.easy |2 --
3 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/sc/source/ui/vba/excelvbahelper.cxx b/sc/source/ui/vba/excelvbahelper.cxx
index 7ee13b2..3d80796 100644
--- a/sc/source/ui/vba/excelvbahelper.cxx
+++ b/sc/source/ui/vba/excelvbahelper.cxx
@@ -139,19 +139,6 @@ void implSetZoom( const uno::Reference< frame::XModel >& xModel, sal_Int16 nZoom
pViewSh->GetViewData()->SetZoom( aFract, aFract, nTabs );
pViewSh->RefreshZoom();
}
-bool isInPrintPreview( SfxViewFrame* pView )
-{
-sal_uInt16 nViewNo = SID_VIEWSHELL1 - SID_VIEWSHELL0;
-if ( pView->GetObjectShell()->GetFactory().GetViewFactoryCount() >
-nViewNo && !pView->GetObjectShell()->IsInPlaceActive() )
-{
-SfxViewFactory &rViewFactory =
-pView->GetObjectShell()->GetFactory().GetViewFactory(nViewNo);
-if ( pView->GetCurViewId() == rViewFactory.GetOrdinal() )
-return true;
-}
-return false;
-}
const ::rtl::OUString REPLACE_CELLS_WARNING( RTL_CONSTASCII_USTRINGPARAM( "ReplaceCellsWarning"));
@@ -321,15 +308,6 @@ getCurrentBestViewShell( const uno::Reference< uno::XComponentContext >& xConte
return getBestViewShell( xModel );
}
-SfxViewFrame*
-getViewFrame( const uno::Reference< frame::XModel >& xModel )
-{
-ScTabViewShell* pViewShell = getBestViewShell( xModel );
-if ( pViewShell )
-return pViewShell->GetViewFrame();
-return NULL;
-}
-
sal_Bool IsR1C1ReferFormat( ScDocument* pDoc, const rtl::OUString& sRangeStr )
{
ScRangeList aCellRanges;
diff --git a/sc/source/ui/vba/excelvbahelper.hxx b/sc/source/ui/vba/excelvbahelper.hxx
index 85031ad..53f44c9 100644
--- a/sc/source/ui/vba/excelvbahelper.hxx
+++ b/sc/source/ui/vba/excelvbahelper.hxx
@@ -59,7 +59,6 @@ bool implnCopyRange( const css::uno::Reference< css::frame::XModel>& xModel, con
ScTabViewShell* getBestViewShell( const css::uno::Reference< css::frame::XModel>& xModel ) ;
ScDocShell* getDocShell( const css::uno::Reference< css::frame::XModel>& xModel ) ;
ScTabViewShell* getCurrentBestViewShell( const css::uno::Reference< css::uno::XComponentContext >& xContext );
-SfxViewFrame* getViewFrame( const css::uno::Reference< css::frame::XModel >& xModel );
sal_Bool IsR1C1ReferFormat( ScDocument* pDoc, const ::rtl::OUString& sRangeStr );
formula::FormulaGrammar::Grammar GetFormulaGrammar( ScDocument* pDoc, const ScAddress& sAddress, const css::uno::Any& aFormula );
diff --git a/unusedcode.easy b/unusedcode.easy
index 381d978..58a4e92 100755
--- a/unusedcode.easy
+++ b/unusedcode.easy
@@ -907,8 +907,6 @@ nullcanvas::SpriteCanvasHelper::opaqueUpdate(basegfx::B2DConnectedRanges::ConnectedComponents const&)
o3tltests::cow_wrapper_client2::queryUnmodified() const
o3tltests::cow_wrapper_client3::queryUnmodified() const
-ooo::vba::excel::getViewFrame(com::sun::star::uno::Reference const&)
-ooo::vba::excel::isInPrintPreview(SfxViewFrame*)
oox::AttributeConversion::decodeHyperHex(rtl::OUString const&)
oox::AttributeConversion::decodeUnsignedHex(rtl::OUString const&)
oox::ContainerHelper::insertByIndex(com::sun::star::uno::Reference const&, int, com::sun::star::uno::Any const&)
--
1.7.7.6
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Bug 37361 depends on bug 45637, which changed state. Bug 45637 Summary: EDITING: copy and paste text from Writer to Calc performs wrong (regression since 3.4) https://bugs.freedesktop.org/show_bug.cgi?id=45637 What|Old Value |New Value Resolution||DUPLICATE Status|NEW |RESOLVED -- 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
[Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 34184, which changed state. Bug 34184 Summary: [Task]: Make E-mail MAILMERGE usable https://bugs.freedesktop.org/show_bug.cgi?id=34184 What|Old Value |New Value Resolution||FIXED Status|REOPENED|RESOLVED -- 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
[PATCH] fdo #46446: add python gdb helpers for osl::FileBase
Sample output for the pretty printer:
$1 = directory: "file:///home/catalin/libreoffice/a_dir"
$2 = file: "file:///home/catalin/libreoffice/s1.ods"
$3 = link: "file:///home/catalin/libreoffice/link.patch" ->
"file:///home/catalin/libreoffice/patches/0001-Fix-cppcheck-possible-null-dereference-in-ScMyCellIn.patch"
$4 = fifo: "file:///home/catalin/libreoffice/some_fifo"
$5 = directory:
$6 = link: ->
"file:///home/catalin/libreoffice/patches/0001-Fix-cppcheck-possible-null-dereference-in-ScMyCellIn.patch"
$5 is a directory but osl_FileStatus_Mask_FileURL was not set when
retrieving it so the file url is invalid
Similarly, for $6 osl_FileStatus_Mask_FileURL is not set but
osl_FileStatus_Mask_FileURL is therefore the link target is valid and
can be printed
From 3f11d4862254238ee39fcc64ef53e8d12e431cd5 Mon Sep 17 00:00:00 2001
From: Catalin Iacob
Date: Wed, 29 Feb 2012 22:25:13 +0100
Subject: [PATCH] fdo #46446: add python gdb helpers for osl::FileBase
---
solenv/gdb/libreoffice/sal.py | 65 +
1 file changed, 65 insertions(+)
diff --git a/solenv/gdb/libreoffice/sal.py b/solenv/gdb/libreoffice/sal.py
index df87ed5..56a9752 100644
--- a/solenv/gdb/libreoffice/sal.py
+++ b/solenv/gdb/libreoffice/sal.py
@@ -26,6 +26,7 @@
# instead of those above.
import gdb
+import gdb.types
from libreoffice.util import printing
from libreoffice.util.string import StringPrinterHelper
@@ -90,6 +91,69 @@ class RtlReferencePrinter(object):
else:
return "empty %s" % self.typename
+class OslFileStatusPrinter(object):
+'''Prints oslFileStatus'''
+
+def __init__(self, typename, val):
+self.val = val
+
+def to_string(self):
+osl_file_type = gdb.lookup_type('oslFileType').strip_typedefs()
+fields_to_enum_val = gdb.types.make_enum_dict(osl_file_type)
+
+etype = self.field_val_if_valid('eType')
+if etype is not None:
+pretty_etype = '' # in case it's not one of the fields
+
+for field_name, field_val in fields_to_enum_val.iteritems():
+if etype == field_val:
+pretty_etype = self.pretty_file_type(field_name)
+else:
+pretty_etype = ''
+
+file_url = self.field_val_if_valid('ustrFileURL')
+if file_url is not None:
+pretty_file_url = str(file_url.dereference())
+else:
+pretty_file_url = ''
+
+pretty_file_status = pretty_etype + ': ' + pretty_file_url
+
+# for links append the link target if valid
+if etype == fields_to_enum_val['osl_File_Type_Link']:
+link_target = self.field_val_if_valid('ustrLinkTargetURL')
+if link_target is None:
+pretty_link_target = ''
+else:
+pretty_link_target = str(link_target.dereference())
+
+pretty_file_status += ' -> ' + pretty_link_target
+
+return pretty_file_status
+
+def pretty_file_type(self, file_type_name):
+if file_type_name != 'osl_File_Type_Regular':
+return file_type_name.replace('osl_File_Type_', '').lower()
+else:
+return 'file' # regular is not very descriptive, file is better
+
+def field_val_if_valid(self, field):
+mask_for_field = {'eType': 0x0001,
+ 'uAttributes': 0x0002,
+ 'aCreationTime': 0x0010,
+ 'aAccessTime': 0x0020,
+ 'aModifyTime': 0x0040,
+ 'uFileSize': 0x0080,
+ 'ustrFileName': 0x0100,
+ 'ustrFileURL': 0x0200,
+ 'ustrLinkTargetURL': 0x0400}
+
+valid_fields = self.val['uValidFields']
+if valid_fields & mask_for_field[field]:
+return self.val[field]
+else:
+return None
+
printer = None
def build_pretty_printers():
@@ -109,6 +173,7 @@ def build_pretty_printers():
# other stuff
printer.add('rtl::Reference', RtlReferencePrinter)
+printer.add('_oslFileStatus', OslFileStatusPrinter)
return printer
--
1.7.9.2
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Don't use Makefile Emacs mode and tabs for Python files
I was wondering why Emacs inserts tabs instead of spaces when changing sal.py. See attached patch for the reason :-) From d9e2eec409178263456574db015652497c9475ce Mon Sep 17 00:00:00 2001 From: Catalin Iacob Date: Wed, 7 Mar 2012 23:01:05 +0100 Subject: [PATCH] Don't use Makefile Emacs mode and tabs for Python files --- solenv/gdb/libreoffice/__init__.py |1 - solenv/gdb/libreoffice/cppu.py |1 - solenv/gdb/libreoffice/sal.py|1 - solenv/gdb/libreoffice/svl.py|1 - solenv/gdb/libreoffice/sw.py |1 - solenv/gdb/libreoffice/tl.py |1 - solenv/gdb/libreoffice/util/__init__.py |1 - solenv/gdb/libreoffice/util/compatibility.py |1 - solenv/gdb/libreoffice/util/printing.py |1 - solenv/gdb/libreoffice/util/string.py|1 - solenv/gdb/libreoffice/util/uno.py |1 - 11 files changed, 11 deletions(-) diff --git a/solenv/gdb/libreoffice/__init__.py b/solenv/gdb/libreoffice/__init__.py index a3b4f4b..ebc9e6f 100644 --- a/solenv/gdb/libreoffice/__init__.py +++ b/solenv/gdb/libreoffice/__init__.py @@ -1,4 +1,3 @@ -# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # Version: MPL 1.1 / GPLv3+ / LGPLv3+ # # The contents of this file are subject to the Mozilla Public License Version diff --git a/solenv/gdb/libreoffice/cppu.py b/solenv/gdb/libreoffice/cppu.py index 3403251..bac13e7 100644 --- a/solenv/gdb/libreoffice/cppu.py +++ b/solenv/gdb/libreoffice/cppu.py @@ -1,4 +1,3 @@ -# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # Version: MPL 1.1 / GPLv3+ / LGPLv3+ # # The contents of this file are subject to the Mozilla Public License Version diff --git a/solenv/gdb/libreoffice/sal.py b/solenv/gdb/libreoffice/sal.py index df87ed5..8f295e5 100644 --- a/solenv/gdb/libreoffice/sal.py +++ b/solenv/gdb/libreoffice/sal.py @@ -1,4 +1,3 @@ -# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # Version: MPL 1.1 / GPLv3+ / LGPLv3+ # # The contents of this file are subject to the Mozilla Public License Version diff --git a/solenv/gdb/libreoffice/svl.py b/solenv/gdb/libreoffice/svl.py index 57d60d9..2286886 100644 --- a/solenv/gdb/libreoffice/svl.py +++ b/solenv/gdb/libreoffice/svl.py @@ -1,4 +1,3 @@ -# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # Version: MPL 1.1 / GPLv3+ / LGPLv3+ # # The contents of this file are subject to the Mozilla Public License Version diff --git a/solenv/gdb/libreoffice/sw.py b/solenv/gdb/libreoffice/sw.py index 8325bfa..1c4415c 100644 --- a/solenv/gdb/libreoffice/sw.py +++ b/solenv/gdb/libreoffice/sw.py @@ -1,4 +1,3 @@ -# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # Version: MPL 1.1 / GPLv3+ / LGPLv3+ # # The contents of this file are subject to the Mozilla Public License Version diff --git a/solenv/gdb/libreoffice/tl.py b/solenv/gdb/libreoffice/tl.py index 4f944f0..c7d56a5 100644 --- a/solenv/gdb/libreoffice/tl.py +++ b/solenv/gdb/libreoffice/tl.py @@ -1,4 +1,3 @@ -# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # Version: MPL 1.1 / GPLv3+ / LGPLv3+ # # The contents of this file are subject to the Mozilla Public License Version diff --git a/solenv/gdb/libreoffice/util/__init__.py b/solenv/gdb/libreoffice/util/__init__.py index a3b4f4b..ebc9e6f 100644 --- a/solenv/gdb/libreoffice/util/__init__.py +++ b/solenv/gdb/libreoffice/util/__init__.py @@ -1,4 +1,3 @@ -# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # Version: MPL 1.1 / GPLv3+ / LGPLv3+ # # The contents of this file are subject to the Mozilla Public License Version diff --git a/solenv/gdb/libreoffice/util/compatibility.py b/solenv/gdb/libreoffice/util/compatibility.py index 3419fa9..403b384 100644 --- a/solenv/gdb/libreoffice/util/compatibility.py +++ b/solenv/gdb/libreoffice/util/compatibility.py @@ -1,4 +1,3 @@ -# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # Version: MPL 1.1 / GPLv3+ / LGPLv3+ # # The contents of this file are subject to the Mozilla Public License Version diff --git a/solenv/gdb/libreoffice/util/printing.py b/solenv/gdb/libreoffice/util/printing.py index a315603..4fe5241 100644 --- a/solenv/gdb/libreoffice/util/printing.py +++ b/solenv/gdb/libreoffice/util/printing.py @@ -1,4 +1,3 @@ -# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # Version: MPL 1.1 / GPLv3+ / LGPLv3+ # # The contents of this file are subject to the Mozilla Public License Version diff --git a/solenv/gdb/libreoffice/util/string.py b/solenv/gdb/libreoffice/util/string.py index e85999a..fb62989 100644 --- a/solenv/gdb/libreoffice/util/string.py +++ b/solenv/gdb/libreoffice/util/string.py @@ -1,4 +1,3 @@ -# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*- # Version: MPL 1.1 / GPLv3+ / LGPLv3+ # # The contents of this file are subject to the Mozilla Public License Version diff --git a/solenv/gdb/libreoffice/
Re: GSoC & error during make
On Wed, Mar 7, 2012 at 7:17 PM, Mariana Marasoiu wrote: > > I did yesterday a ./g pull -r but it didn't fix the build. Afterwards, > I tried a make clean & make, which ended with the same result. > > I followed Korrawit's instructions and realised that the branch I was > trying to build wasn't the master, but libreoffice-3-5. So I switched > to master, did ./g pull -r and now it's building once again. Lets hope > this time works :D > Okay, bad news... I still couldn't build LibreOffice :(. It fails in two modules: officecfg and sal. I tried building them separately, with a make clean before that, but I still get errors... This is what I get for officecfg: cd officecfg && make -j 1 -rs gb_PARTIALBUILD=T [ build XCS ] officecfg/registry/schema/org/openoffice/Setup.xcs /home/mariana/Working/git/libo/solver/unxlngi6.pro/xml/processing/schema_val.xsl:1: parser error : Document is empty ^ /home/mariana/Working/git/libo/solver/unxlngi6.pro/xml/processing/schema_val.xsl:1: parser error : Start tag expected, '<' not found ^ cannot parse /home/mariana/Working/git/libo/solver/unxlngi6.pro/xml/processing/schema_val.xsl make[1]: *** [/home/mariana/Working/git/libo/workdir/unxlngi6.pro/XcsTarget/officecfg/registry/schema/org/openoffice/Setup.xcs] Error 4 make: *** [officecfg] Error 2 And for sal module, there are lots of C++ errors and warnings and also "No such file or directory" errors. If I should post the output, tell me and I'll put it in a pastebin. Thanks, Mariana Mărășoiu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: CMake (Re: GNU make version)
Good evening! So I can't let my mailbox for the day without you stiffing it with mails :-) I will answer -almpost- all mails because I liked the discussions and some need my right of reply. Le Wed, 07 Mar 2012 14:03:16 +0100, Michael Stahl a écrit: On 07/03/12 12:57, Lubos Lunak wrote: On Wednesday 07 of March 2012, David Tardon wrote: On Wed, Mar 07, 2012 at 01:28:05AM +0100, Mat M wrote: Hello Could someone point to archive on choosing gnumake ? I am surprised cmake was not elected, since the C means cross-platform, and that is one basic of LO. indeed, and AFAIK most of the platforms are supported by CMake by way of the (GNU) make backend. what was your point again? oh, GNU stands for GNU's not UNIX, but we actually found that GNU make also works on UNIX as well :) Funny, my first insight was more about Microsoft OSes... Sigh, life would not be complete without enthusiasts telling us we should switch to cmake (or Qt) every few months. So, please, go read http://wiki.services.openoffice.org/wiki/Build_System_Analysis for the basics and http://openoffice.2283327.n4.nabble.com/New-build-system-td2928559.html for more questions and answers. Thank you for providing the links I asked for. It seems OOo still a reference to understand what's up now. My second sentence was not to troll and/or rant (So you should not sigh ;)). I just wanted to expose my gut feelings about Cmake, and also had the "having more Windows devs" rant in mind; I didn't talked about: - Cmake roughly seems more active than gnu make. Not that it is a pledge of quality, but fixing might be easier. - Cmake also allows to build under Visual Studio (Don't feel obliged to answer ;)) I will dive into links to understand. That comparison appears to be seriously biased towards gbuild (referred to as 'GNU Make' in the document). I'm not build system expert, but judging from my CMake experience in KDE, the information and conclusions for CMake are either outdated or just plain wrong (given the document dating to the time when KDE SC 4.4 had been released, thus CMake having been used for more than 2 years by that time, I assume it's the the latter). In particular: most of the people doing the comparison weren't build system experts either, they just had a list of requirements that the current dmake/build.pl system could not fulfill. then they sought input from build system experts on the tools@ooo mailing list, and the CMake maintainer actually showed up there to discuss things. [...] So I have now a fresh view of what happened 2 years ago :) TY Le Wed, 07 Mar 2012 13:28:09 +0100, Bjoern Michaelsen a écrit: Lets just finish this migration and kill of dmake and build.pl instead. I totally agree Best regards to you all enthusiasts Mat M ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GSoC & error during make
On Wed, Mar 7, 2012 at 5:00 PM, Mariana Marasoiu wrote: > On Wed, Mar 7, 2012 at 7:17 PM, Mariana Marasoiu > wrote: >> >> I did yesterday a ./g pull -r but it didn't fix the build. Afterwards, >> I tried a make clean & make, which ended with the same result. What command, exactly, did you use to switch back to the master btanch ? iow: what is the output of ./g branch Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GSoC & error during make
Hi, Just to piggyback this thread, because I am having build errors on master too. > Okay, bad news... I still couldn't build LibreOffice :(. > It fails in two modules: officecfg and sal. I tried building them > separately, with a make clean before that, but I still get errors... I am having errors in sal too. > And for sal module, there are lots of C++ errors and warnings and also > "No such file or directory" errors. > If I should post the output, tell me and I'll put it in a pastebin. These too. It appears if I do a top-level "make clean && make", I get one set of errors (syntax errors in the code), and if I do a make sal.clean && make sal, I get directory errors instead. This is all on the latest master (b43fe402154fae9bf1e2201d9b1a049cbcaf63ef). Errors from "make clean && make": /home/josh/git/libo/sal/qa/rtl/math/test-rtl-math.cxx:29:24: error: sal/config.h: No such file or directory /home/josh/git/libo/sal/qa/rtl/math/test-rtl-math.cxx:30:30: error: sal/precppunit.hxx: No such file or directory /home/josh/git/libo/sal/qa/rtl/math/test-rtl-math.cxx:36:24: error: rtl/math.hxx: No such file or directory Errors from "make sal.clean", done straight after: rm: cannot remove `/home/josh/git/libo/solver/unxlngx6.pro/inc/osl/armarch.h': Is a directory rm: cannot remove `/home/josh/git/libo/solver/unxlngx6.pro/inc/osl/conditn.h': Is a directory rm: cannot remove `/home/josh/git/libo/solver/unxlngx6.pro/inc/osl/conditn.hxx': Is a directory Took a look over cgit, for somethis which might be it, is: http://cgit.freedesktop.org/libreoffice/core/commit/sal?id=cb83035cd248348c0301a765dfe80c8d95859b4a to blame? Cheers, Josh ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GSoC & error during make
On Wed, Mar 7, 2012 at 9:24 PM, Josh Heidenreich wrote: > Hi, > > Just to piggyback this thread, because I am having build errors on master too. > >> Okay, bad news... I still couldn't build LibreOffice :(. >> It fails in two modules: officecfg and sal. I tried building them >> separately, with a make clean before that, but I still get errors... > > I am having errors in sal too. > >> And for sal module, there are lots of C++ errors and warnings and also >> "No such file or directory" errors. >> If I should post the output, tell me and I'll put it in a pastebin. > > These too. It appears if I do a top-level "make clean && make", I get > one set of errors (syntax errors in the code), and if I do a make > sal.clean && make sal, I get directory errors instead. > > This is all on the latest master (b43fe402154fae9bf1e2201d9b1a049cbcaf63ef). > > Errors from "make clean && make": > > /home/josh/git/libo/sal/qa/rtl/math/test-rtl-math.cxx:29:24: error: > sal/config.h: No such file or directory > /home/josh/git/libo/sal/qa/rtl/math/test-rtl-math.cxx:30:30: error: > sal/precppunit.hxx: No such file or directory > /home/josh/git/libo/sal/qa/rtl/math/test-rtl-math.cxx:36:24: error: > rtl/math.hxx: No such file or directory > > Errors from "make sal.clean", done straight after: > > rm: cannot remove > `/home/josh/git/libo/solver/unxlngx6.pro/inc/osl/armarch.h': Is a > directory > rm: cannot remove > `/home/josh/git/libo/solver/unxlngx6.pro/inc/osl/conditn.h': Is a > directory > rm: cannot remove > `/home/josh/git/libo/solver/unxlngx6.pro/inc/osl/conditn.hxx': Is a > directory > > Took a look over cgit, for somethis which might be it, is: > http://cgit.freedesktop.org/libreoffice/core/commit/sal?id=cb83035cd248348c0301a765dfe80c8d95859b4a > to blame? that is gnu-make 3.81 related one work around is to clone git://anongit.freedesktop.org/libreoffice/contrib/dev-tools and to ./configure | make in the make-3.82-gbuild directory and then copy the generate make binary in that directory to /opt/lo/bin/. the ./autogen.sh lo again and make clean + make (note: autogen will automatically pick-up make from /opt/lo/bin if present) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GSoC & error during make
On Wed, Mar 7, 2012 at 9:38 PM, Norbert Thiebaud wrote: > > then ./autogen.sh lo again and make clean + make > (note: autogen will automatically pick-up make from /opt/lo/bin if present) > if make clean cause trouble do: cp autogen.lastrun autogen.lastrun.saved && make distclean && cp autogen.lastrun.saved autogen.lastrun && ./autogen.sh then make ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Pushed] [PATCH] Remove unused code in vbahelper
Pushed. On 03/08/2012 01:27 AM, Santiago Martinez wrote: > This patch removes unused code as listed in unusedcode.eas > > > > ___ > 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: [Pushed] [PATCH] Remove unused code
Pushed. On 03/08/2012 01:05 AM, Santiago Martinez wrote: > This patch removes unused code as listed in unusedcode.easy > > > > > ___ > 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: [Pushed] [PATCH] Remove unused code(3)
Pushed. On 03/08/2012 02:19 AM, Santiago Martinez wrote: > This patch removes unused code as listed in unusedcode.easy > > > > ___ > 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: [Pushed] [PATCH] Remove unused code(2)
Pushed. On 03/08/2012 02:07 AM, Santiago Martinez wrote: > This patch removes unused code as listed in unusedcode.easy > > > > ___ > 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
performance enhancements for cygwin make
Hi I'm having a bash at this - mostly I copied and simplified the corresponding code from the GNU touch utility. But I want to add windows32-specific enhancements, and I'm struggling to figure out how to build gmake with the WINDOWS32 define turned on, so it compiles the windows-specific stuff. I'm building under cygwin with gcc. Anybody have any ideas? Thanks, Noel Grandin On 2012-03-06 17:13, Michael Meeks wrote: couldn't we add "touch", "mkdir" and "cp" functions to Make? Implementing those should be fairly trivial. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
