[PATCH] remove unused code
Hi there,
another patch removing unused code. Actually I need an advice this time. Is
method oox::core::XmlFilterBase::getChartConverter() really unused / unwanted?
As it's used in Shape::finalizeXShape (oox/source/drawingml/shape.cxx). So feel
free to drop it if it's not valid.
Btw can we really rely on the tool which generates unusedcode.easy?
Regards,
Petr
>From 94f6485cdfd7e87af6c432708c16aed061a8c2cb Mon Sep 17 00:00:00 2001
From: Petr Vorel
Date: Thu, 8 Mar 2012 16:11:03 +0100
Subject: [PATCH] remove unused code
---
oox/inc/oox/core/xmlfilterbase.hxx|4
oox/inc/oox/ppt/dgmimport.hxx |1 -
oox/inc/oox/ppt/dgmlayout.hxx |1 -
oox/inc/oox/ppt/pptimport.hxx |1 -
oox/inc/oox/xls/excelfilter.hxx |1 -
oox/source/core/xmlfilterbase.cxx |5 -
oox/source/drawingml/shape.cxx|2 --
oox/source/ppt/dgmimport.cxx |5 -
oox/source/ppt/dgmlayout.cxx |5 -
oox/source/ppt/pptimport.cxx |5 -
oox/source/shape/ShapeFilterBase.cxx |5 -
oox/source/shape/ShapeFilterBase.hxx |2 --
oox/source/xls/excelfilter.cxx|5 -
sc/source/filter/excel/xestream.cxx |6 --
sc/source/filter/inc/xestream.hxx |1 -
sd/source/filter/eppt/epptooxml.hxx |1 -
sw/source/filter/ww8/docxexportfilter.hxx |1 -
unusedcode.easy |1 -
18 files changed, 0 insertions(+), 52 deletions(-)
diff --git a/oox/inc/oox/core/xmlfilterbase.hxx b/oox/inc/oox/core/xmlfilterbase.hxx
index 0e015da..09c76ee 100644
--- a/oox/inc/oox/core/xmlfilterbase.hxx
+++ b/oox/inc/oox/core/xmlfilterbase.hxx
@@ -95,10 +95,6 @@ public:
/** Has to be implemented by each filter to return the collection of VML shapes. */
virtual ::oox::vml::Drawing* getVmlDrawing() = 0;
-/** Has to be implemented by each filter, returns a filter-specific chart
-converter object, that should be global per imported document. */
-virtual ::oox::drawingml::chart::ChartConverter* getChartConverter() = 0;
-
/** Has to be implemented by each filter to return the table style list. */
virtual const ::oox::drawingml::table::TableStyleListPtr getTableStyles() = 0;
diff --git a/oox/inc/oox/ppt/dgmimport.hxx b/oox/inc/oox/ppt/dgmimport.hxx
index 74f8020..99332a8 100644
--- a/oox/inc/oox/ppt/dgmimport.hxx
+++ b/oox/inc/oox/ppt/dgmimport.hxx
@@ -57,7 +57,6 @@ public:
virtual const oox::drawingml::table::TableStyleListPtr getTableStyles();
virtual oox::vml::Drawing* getVmlDrawing();
-virtual oox::drawingml::chart::ChartConverter* getChartConverter();
private:
virtual ::rtl::OUString implGetImplementationName() const;
diff --git a/oox/inc/oox/ppt/dgmlayout.hxx b/oox/inc/oox/ppt/dgmlayout.hxx
index 35c0857..a263eed 100644
--- a/oox/inc/oox/ppt/dgmlayout.hxx
+++ b/oox/inc/oox/ppt/dgmlayout.hxx
@@ -57,7 +57,6 @@ public:
virtual const oox::drawingml::table::TableStyleListPtr getTableStyles();
virtual ::oox::vml::Drawing* getVmlDrawing();
-virtual ::oox::drawingml::chart::ChartConverter* getChartConverter();
private:
virtual ::rtl::OUString implGetImplementationName() const;
diff --git a/oox/inc/oox/ppt/pptimport.hxx b/oox/inc/oox/ppt/pptimport.hxx
index 79df421..ddb67a4 100644
--- a/oox/inc/oox/ppt/pptimport.hxx
+++ b/oox/inc/oox/ppt/pptimport.hxx
@@ -57,7 +57,6 @@ public:
virtual const ::oox::drawingml::Theme* getCurrentTheme() const;
virtual ::oox::vml::Drawing* getVmlDrawing();
virtual const oox::drawingml::table::TableStyleListPtr getTableStyles();
-virtual ::oox::drawingml::chart::ChartConverter* getChartConverter();
voidsetActualSlidePersist( SlidePersistPtr pActualSlidePersist ){ mpActualSlidePersist = pActualSlidePersist; };
std::map< rtl::OUString, oox::drawingml::ThemePtr >&getThemes(){ return maThemes; };
diff --git a/oox/inc/oox/xls/excelfilter.hxx b/oox/inc/oox/xls/excelfilter.hxx
index c15b6cc..8585dc2 100644
--- a/oox/inc/oox/xls/excelfilter.hxx
+++ b/oox/inc/oox/xls/excelfilter.hxx
@@ -71,7 +71,6 @@ public:
virtual const ::oox::drawingml::Theme* getCurrentTheme() const;
virtual ::oox::vml::Drawing* getVmlDrawing();
virtual const ::oox::drawingml::table::TableStyleListPtr getTableStyles();
-virtual ::oox::drawingml::chart::ChartConverter* getChartConverter();
virtual sal_Bool SAL_CALL filter( const ::com::sun::star::uno::Sequence< ::com::sun::star::beans::PropertyValue >& rDescriptor ) throw( ::com::sun::star::uno::RuntimeException );
diff --git a/oox/source/core/xmlfilterbase.cxx b/oox/source/core/xmlfilterbase.cxx
index f5868bf..f1aebdd 100644
--- a/oox/source/core/xmlfilterbase.cxx
+++ b/oox/source/core/xmlfilterbase.cxx
@@ -672,11 +672,6 @@ XmlFilterBase& XmlFilterBase::exportDocumentProperties( Reference< XDocumen
[patch] convert tools/table usage to std::set in svtools module
Hi License statement already on file. Regards, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html 0001-Convert-tools-table-usage-to-std-set.patch Description: application/mbox ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: [PUSHED][PATCH]fdo45671 writer par. bg color simplified code for split button
>> In Excel, the default background colour seems to >>be yellow, so let's do something similar here – I don't like yellow >>per se, but Excel users are probably used to yellow, so no need to >>break the functionality for them. >>So, I'd propose to use either "Yellow" or "Chart 3" as the default. I did some thinking (some, not a lot) on this matter. It seems that the default colour for font and line colour buttons is black and for background buttons (highlight excepted) is transparent. That does not look usefull to me, is these are bound to be the default colours of font, line, background anyway. Isn't it a better idea to set the default colours as a contrastong colour (eg COL_RED for font/line and COL_YELLOW for background) so that users can 'mark' sections without choosing a colour? Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[ANN] LibreOffice 3.5.1 RC2 available
Dear Community, The Document Foundation is happy to announce the second release candidate of LibreOffice 3.5.1. The upcoming 3.5.1 will be the first in a series of frequent bugfix releases on our feature-packed 3.5 code line. Please be aware that LibreOffice 3.5.1 RC2 is not ready for production use, you should continue to use LibreOffice 3.4.5 or 3.5.0 for that. The release is available for Windows, Linux and Mac OS X from our QA builds download page at http://www.libreoffice.org/download/pre-releases/ A note for Windows users: this Release Candidate will uninstall your current stable build and replace it. If you do not wish this to happen but still would like to test, you should follow the instructions for installing in parallel: http://wiki.documentfoundation.org/Installing_in_parallel Should you find bugs, please report them to the FreeDesktop Bugzilla: https://bugs.freedesktop.org A good way to assess the RC2 quality is to run some specific manual tests on it, our TCM wiki page has more details: http://wiki.documentfoundation.org/QA/Testing/Regression_Tests#Full_Regression_Test (and the announcement mail: http://lists.freedesktop.org/archives/libreoffice/2011-December/022464.html) For other ways to get involved with this exciting project - you can e.g. contribute code: https://www.libreoffice.org/get-involved/developers/ translate LibreOffice to your language: http://wiki.documentfoundation.org/Translation_for_3.5 or help with funding our operations: http://challenge.documentfoundation.org/ A list of known issues with 3.5.1 RC2 is available from our wiki: http://wiki.documentfoundation.org/Releases/3.5.1/RC2 Please find the list of changes against LibreOffice 3.5.0 here: http://download.documentfoundation.org/libreoffice/src/bugfixes-libreoffice-3-5-1-release-3.5.1.2.log Let us close again with a BIG Thank You! to all of you having contributed to the LibreOffice project - this release would not have been possible without your help. Yours, The Document Foundation Board of Directors pgpYF1jVm5cCk.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bugfix and improvement for autogen.sh
Hey,
I was doing some compiling yesterday, and noticed that "autogen.sh
--help" clobbers your autogen.lastrun.
My original thought was to change the code to fix the bug, but then I
had an idea - make "--help" more useful.
Thus, my idea is to add this to autogen.sh:
my $pos = 0;
for my $arg (@ARGV) {
if ($arg eq '--help') {
system ("./help.sh " . $ARGV[$pos+1]);
exit;
}
$pos++;
}
and also add the attached help.sh file.
Basically, it shows a short description for "autogen.sh --help", with
a link to the wiki page and general overview. but you can also do
"autogen.sh --help full" for everything, and "autogen.sh --help speed"
for specific instructions about speed boosting. We can add additional
sections to help.sh if we wanted to - perhaps notes re cgywin or other
helpful docs.
If no one has any objections, I'll push to master.
Cheers,
Josh
help.sh
Description: Bourne shell script
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW] fix for fdo#47105, use the new anonymous db name
Hey, [1] fixes that Range contains column labels is not enabled for anonymous db data. The check still used the old string for anonymous db data. The patch is simple and safe and therefore I think we should include it into 3-5. Please also consider to add the following commits that fix some more problems around the anonymous db data: http://cgit.freedesktop.org/libreoffice/core/commit/?id=59dcb5918dbcb93173afcd5bc4f3b01fa7bef1ee http://cgit.freedesktop.org/libreoffice/core/commit/?id=66fbd3a48ac5608eeb45629b9d285790cfcefff6 http://cgit.freedesktop.org/libreoffice/core/commit/?id=ecdc626d91d723c9861345008d6563b118a92a7a The new string for anonymous db data is not localized and should be used only in calc core. I hope that I now removed all references to this string in the GUI. Regards, Markus [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=259839dcb9ee74c3a24bbec12de4ec92b56ad62e ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW] fdo#47102, set the edit field visible when switching to formula input in conditional format dlg
Forgot the link. 2012/3/9 Markus Mohrhard : > Hey, > > [1] fixes fdo#47102. We need to reset the edit line visible because it > might have been set hidden. > > Patch is simple and safe and therefore I think we can include it into 3-5. > > Regards, > Markus [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=f361431f944abd9e12fad80f4880fa111214ff06 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW] fdo#47102, set the edit field visible when switching to formula input in conditional format dlg
Hey, [1] fixes fdo#47102. We need to reset the edit line visible because it might have been set hidden. Patch is simple and safe and therefore I think we can include it into 3-5. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GSoC & error during make
Hi, > this is a known problem when using make 3.81 and is fixed on master now: > http://cgit.freedesktop.org/libreoffice/core/commit/?id=294b86e3dbbdb9b136cb17a51687f4e2762711cf In the commit message for revision 294b86e3dbbd Michael Stahl wrote: > This is all quite ugly and should be reverted once support for make 3.81 is > dropped. What is the time-frame of this happening? I'm guessing when 3.83 is released, meaning LibO won't have a dependency on a _single_ (known to be slow) version of make? Okay so looking at the make website, I expect 3.83 will come out in 2014, so is it more likely that support will be dropped when a number of distros have updated? Cheers, Josh ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Weird undefined symbol: Reference::operator Reference const&() const
> IIRC, this is a known issue with the compiler provided by Apple (can't find > any issue ID right now, though). Let me just add that switching to clang helped... --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: OpenOffice Addon Plugin on Eclipse
On Thu, 2012-03-08 at 23:18 +0400, libreoffice...@gmail.com wrote: > It works , but it is very old and NetBeans plugin is much better . As I said, I only have 24 hours a day... feel free to improve it and submit patches. -- Cedric ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Patch for Easy Hack 45033
On Mon, 2012-02-13 at 22:15 +0100, Rob Snelders wrote: > Hi, > > Are you sure this is the correct file? When I open the file I only see > OpenOffice and StarOffice entries. Maybe someone else can check what > he/she sees. Yeah it seems to still consist of OOo and StarOffice entries. Italio could you have another go at this. i.e. attaching a biblio.odb which has LibreOffice entries in it. I'd like to get this low-hanging fruit out of the way. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW] fix for fdo#46825, crash copying a chart
On 03/08/2012 10:06 AM, Stephan Bergmann wrote: On 03/03/2012 01:08 AM, Markus Mohrhard wrote: [1] fixes a crash when you copy a chart in the document. The problem is that you should not create a uno::Sequence with new because the uno::Sequence copy c'tor is creating a flat copy. This will later result in a double delete. I think the patch is quite save and fixes a crash and therefore should be included into at least 3-5 and if still possible in 3-5-1. Regards, Markus [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=8f2d3c47ad40039a842fa09d98137155dcfdfe9e While changing from a pointer-to-Sequence member to a plain Sequence member is probably a good choice, anyway (as Sequence itself is nothing more than a pointer to the underlying uno_Sequence data structure), I do not see how the original code was actually wrong: The Sequence copy ctor increases the shared _pSequence->nRefCount, while delete, via Sequence dtor, uno_type_destructData, _destructData, and idestructSequence decrements nRefCount again, and destroys the shared uno_Sequence only when the ref count has dropped to zero. The real issue was the SchXMLCell assignment operator (which has become a non-issue with the fix, of course, making the compiler-generated one behave correctly now). Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: OpenOffice Addon Plugin on Eclipse
Thanks Cedric, It works , but it is very old and NetBeans plugin is much better . Nick On 3/8/2012 6:18 PM, Cedric Bosdonnat wrote: On Thu, 2012-03-08 at 18:14 +0400, libreoffice...@gmail.com wrote: Dear Admins, Is there any Interoffice / Open Office AddOn Plugin on Eclipse for development? (we have found plugin for Netbeans http://plugins.netbeans.org/plugin/2320/openoffice-org-api-plugin this does not work on new version of LO, because of the changes in SDK ) Please have a look at the ooeclipse project. http://www.ohloh.net/p/ooeclipse I haven't found time to work on it recently, but it should help you. Of course feel free to help the development if you wish some features / bug fixes there. -- Cedric ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#46728: EDITING: soffice.bin crashed with SIGSEGV in Window::GetCursor()
Hi!
Error is in svx/source/sdr/overlay/overlaymanagerbuffered.cxx
386: Window& rWindow = static_cast< Window& >(rmOutputDevice);
387: Cursor* pCursor = rWindow.GetCursor();
Maybe something is with the timing of instructions because there are two lines
which are exactly the same, and there works everything:
240: Window& rWindow = static_cast< Window& >(rmOutputDevice);
241: Cursor* pCursor = rWindow.GetCursor();
So defining rWindow in a wider scope (outside of if(bTargetIsWindow){...} line
238) - and using that same rWindow in subsequent occurrences - seems to solve
the problem, at least it makes it less frequent.
PS.: rWindow is of type Window, which has a member named mpWindowImpl. This is
not present in OutputDevice class which is the base class of Window. What value
will be assigned to mpWindowImpl in rWindow after Window& rWindow =
static_cast< Window& >(rmOutputDevice);
Szabolcs
From b887ce90a1f654a4472425fcefc73af8a52395ee Mon Sep 17 00:00:00 2001
From: Szabolcs Dezsi
Date: Thu, 8 Mar 2012 19:32:51 +0100
Subject: [PATCH] Fixes crash in Window::GetCursor()
---
svx/source/sdr/overlay/overlaymanagerbuffered.cxx |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/svx/source/sdr/overlay/overlaymanagerbuffered.cxx b/svx/source/sdr/overlay/overlaymanagerbuffered.cxx
index 1a0016f..eb117f7 100644
--- a/svx/source/sdr/overlay/overlaymanagerbuffered.cxx
+++ b/svx/source/sdr/overlay/overlaymanagerbuffered.cxx
@@ -233,11 +233,11 @@ namespace sdr
// prepare cursor handling
const bool bTargetIsWindow(OUTDEV_WINDOW == rmOutputDevice.GetOutDevType());
bool bCursorWasEnabled(false);
+Window& rWindow = static_cast< Window& >(rmOutputDevice);
// #i80730# switch off VCL cursor during overlay refresh
if(bTargetIsWindow)
{
-Window& rWindow = static_cast< Window& >(rmOutputDevice);
Cursor* pCursor = rWindow.GetCursor();
if(pCursor && pCursor->IsVisible())
@@ -354,8 +354,6 @@ namespace sdr
// To get the update, the windows in question are updated manulally here.
if(bTargetIsWindow)
{
-Window& rWindow = static_cast< Window& >(rmOutputDevice);
-
if(rWindow.IsChildTransparentModeEnabled() && rWindow.GetChildCount())
{
const Rectangle aRegionRectanglePixel(
@@ -383,7 +381,6 @@ namespace sdr
// #i80730# restore visibility of VCL cursor
if(bCursorWasEnabled)
{
-Window& rWindow = static_cast< Window& >(rmOutputDevice);
Cursor* pCursor = rWindow.GetCursor();
if(pCursor)
--
1.7.7
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: MinGW-Port: Problems with UnoUrlResolver
> > In case someone is interested I will supply a short example (Qt/MinGW > > based) how to start an LO with an empty "sheet of paper" out of a small > > program. I don't want to pollute the list, therefore tell me a > > (central) address where to send the files to. > > Sounds really useful - we should license it with some hyper-liberal > license too so people are happy to cut/paste it. BSD or somesuch. I agree - since I learned my part of LO programming that way, too, I feel I should return something useful to the community ;-) > > How large is that ? It sounds like a good thing to have in > odk/examples/cpp - perhaps 'qt-mingw-demo' or something ? hopefully the > source is not too big ? the other samples are ~20k or so. Unpacked something like 15k - but I still want to write a little README since someone really has to be very careful with regards to the whole environment. But once the environment is set up, the whole thing seems to work rather stable. So probably tomorrow I will have written the missing "manual"; should I send the tarball to you? > > Really glad you got things working :-) So am I - but (maybe you already have realized it) I ran into the next problem working with TextTables ;-) Thanks, Helmar ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: MinGW-Port: Problems with UnoUrlResolver
Hi Helmar, On Thu, 2012-03-08 at 17:25 +0100, Helmar Spangenberg wrote: > finally I could solve the problem. Great news ! :-) > UNO_PATH=L:\blabla\libreoffice3.5\program > URE_MORE_TYPES=file:///L:/blabla/libreoffice3.5/program/types/offapi.rdb > > Now I even can use the MinGW-UNO with an off-the-shell (MSVC) installation of > LO :-) Wonderful. > In case someone is interested I will supply a short example (Qt/MinGW based) > how to start an LO with an empty "sheet of paper" out of a small program. I > don't want to pollute the list, therefore tell me a (central) address where > to > send the files to. Sounds really useful - we should license it with some hyper-liberal license too so people are happy to cut/paste it. BSD or somesuch. How large is that ? It sounds like a good thing to have in odk/examples/cpp - perhaps 'qt-mingw-demo' or something ? hopefully the source is not too big ? the other samples are ~20k or so. Really glad you got things working :-) All the best, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED][REVIEW -3-5] Fix dialog controls size and position in the file preperties dialog
On Mon, 2012-03-05 at 21:02 +, Michael Meeks wrote: > This fixes the layout of the dialog so we don't truncate translations: > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=21d85dabe5d780571ad8ca39c8e6d30be90a0bf4 > > I'd love to have it reviewed & cherry-picked to -3-5 :-) Pushed to 3-5, i.e. will be 3.5.2 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Excessive exception size cost ...
Hi guys, On Wed, 2012-02-29 at 16:29 +, Michael Meeks wrote: > So - I did some more analysis, and re-compiled all of LibreOffice both > with and without the attached patch - analysing all 287 shared libraries > we get: So - because of the expert skepticism of my estimate of where the wasteage is: ie. exception unwind tables, I re-ran my relocstats.pl tool (which I've checked in here): http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/scripts/ over the code both with and without those extra bad_alloc exceptions we spit out on every string allocation (which are used to do nothing more useful than abort ;-). Here are the numbers from: $ relocstat.pl --data-profile *.so # in program/ Section size breakdown # with no string exceptions code74126kb - 45% exceptions 46003kb - 28% data20913kb - 13% linking 15432kb - 9.3% data relocs 8462kb - 5.1% ... Total: 170285850 bytes Section size breakdown # with string exceptions thrown everywhere code75233kb - 44% exceptions 48131kb - 28% data20913kb - 12% linking 15445kb - 9.1% data relocs 8462kb - 5% ... Total: 173612058 bytes So - there is the 1.9% size saving ~3.3Mb saved (which is a lower bound - we can do better by being more complete). Perhaps what is more frightening, is the sheer weight of the exception information: we have fourty-eight (48) Mb of exception unwind information vs. 75Mb of code; that is cf. http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/scripts/relocstat.pl#n547 from just two section types: .gcc_except_table and .eh_frame. It appears that for every 10 bytes of .text (ie. code) we create 6+ bytes of exception unwind information. Given that we then that in (100 - epsilon)% of the generated cases don't do anything at all useful with the results beyond the crash handler, this seems rather a high cost to pay. It is also a markedly higher proportion than mozilla: Section size breakdown code15923kb - 60% exceptions 4870kb - 18% data3226kb - 12% data relocs 1682kb - 6.3% linking 460kb - 1.7% ... This is compiled with openSUSE 12.1's default: gcc 4.6.2, and operating on stripped binaries. We can also see that of the two potential causes of bloat removal of not doing this: a) not in-lining: if (error_return) throw ::std::bad_alloc(); vs. b) not generating huge unwind tables for methods doing pure string operations The win breaks down thus: code change: -1107kb exception change -2128kb So 2/3rds of the reduction is simply shrinking the unwind tables. While it shouldn't affect the ultimate numbers, I am using the --enable-merged-libs feature here (as is obvious from the autogen.lastrun I posted). So - there we are: exceptions hurt, they hurt really a lot size-wise, and they provide us with very little real value since we just abort when they are thrown in ~all cases. Alternatively, perhaps they are truly a productivity tool - they certainly let us generate more bytes of output more quickly ;-) Feedback appreciated, my relocstat.pl tool is untouched for several years, possibly it is not adding up right - please do check it out. ATB, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW][3-5] fdo#46923 possibly dodgy use of invalid iterators in sc inputhdl.cxx
On Thu, 2012-03-08 at 11:36 -0500, Kohei Yoshida wrote: > But I did that refactoring for master only. The 3.5 code has > something completely different (and even less safe); it uses a single > integer member nAutoPos to handle both formula and column positions. crap, should have checked the branch first, yeah can't be that. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Problems to access table columns via UNO interface
Hello list,
I have difficulties to access table columns (and rows) via the UNO interface.
I have no problems to create a table, but I am not able to manipulate the
properties of the columns.
Basically my code can be nailed down to
Reference docServices (rDocument, UNO_QUERY_THROW);
Reference tabelle(docServices->
createInstance(OUString::createFromAscii("com.sun.star.text.TextTable")),
UNO_QUERY_THROW);
tabelle->initialize(2, 5);
Reference tcols (tabelle->getColumns(), UNO_SET_THROW);
Any pval;
pval <<= tcols->getByIndex(2);
Reference s_properties(pval, UNO_QUERY_THROW);
Some debugging showed that the method getByIndex returns an Any with a pointer
to 0. Since in my case "tcols" seems to be initiated correctly
(tcols->getCount() returns 5 as expected, and tcols->hasElements() returns
true),
can someone please tell me what is wrong in my code!
I am using LO-3.5 as distributed from www.libreoffice.org; I observe this
behavior under SuSE Linux 12.1 (64bit).
Thanks in advance,
Helmar
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW][3-5] fdo#46923 possibly dodgy use of invalid iterators in sc inputhdl.cxx
On Thu, Mar 8, 2012 at 11:14 AM, Caolán McNamara wrote: > So, for https://bugs.freedesktop.org/show_bug.cgi?id=46923 under Linux > with debugging stl iterators I can see "use of invalid iterator" stl > errors with miAutoPosColumn which is a plausible reason for the reported > crash. > > miAutoPosFormula is used to point into the std::set pFormulaData and > miAutoPosColumn is used to point into the std::set pColumnData > > I reckon the safest thing to do is to initialize those to the end of > their respective containers when the containers are initially allocated, > i.e. > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=a3f1614c606629196ca71dc22dab3343b060dced Your fix looks good. Thanks for catching it. It was the result of me switching from an integer based quasi iterators to the real STL iterators. But I did that refactoring for master only. The 3.5 code has something completely different (and even less safe); it uses a single integer member nAutoPos to handle both formula and column positions. So, I have my doubt that the invalid use of iterator you saw on master applies to the 3.5 branch. Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
minutes of ESC call ...
* Present: + Eike, Stephan, Norbert, Michael, Andras, Rainer, David, Caolan, Petr, Markus, Cedric, Kendy, Fridrich * Completed Action items + Add GSOC tasks to the wiki: + l/strace-alike for UNO (Stephan) + switched for two other better uno related tasks + wrapper for MS compiler for autotools usage (Norbert) + table styles (Cedric) + calc filters performance improvements (Kohei & Markus) + refactor god objects (Bjoern) + Publisher importer + one other (Fridrich) + add specific writer / layout unit test task (Cedric / Michael S.) + dropped for now * Pending Action Items + [still pending] extract 64bit build hardware from firewall (Kendy / Admins) + rename VCL API to make it GetBeamerFoo & fix (Michael) + [ongoing] respond in the gerrit bug fdo#44498 with some rational (Bjoern) + call today on the topic + Add GSOC tasks to the wiki: https://wiki.documentfoundation.org/Development/Gsoc/Ideas + multi-user / telepathy / co-editing (Eike) + fwd. Eike Svante's proposal (Thorsen) + layout / toolkit conversion task (Caolan) + add graphical conditional formatting task (Kohei) + bunch of ideas / slide-show re-work etc. (Thorsten) + better template translation (Andras) + take updated ESC composition to the board (Thorsten) * Action Items review * Release Engineering update (Petr) + 3.5.1rc2 up-loaded, and trickling out to mirrors + no blockers we know of (out mid next week) + 3.4.6rc1 - is being up-loaded + needs pushing to mirrors + hope we won't need rc2 since it's a final release + ie. should be back on schedule + thanks for all the fixes & reviews ! * gerrit update (Norbert) + got it up & running, going nicely, could run the same workflow as today, still at the beginning. + still working on it * GSOC update (Cedric) + deadline for beautiful tasks is tomorrow ! * QA update (Rainer) + Bjoern stablishing a QA call every two weeks, call tomorrow + goal - to learn more about / co-ordinate QA activities + report after the call * getting quite a lot of most-annoying bugs nominated (Petr) + are we accepting rather less annoying bugs ? + hard to judge, any bug is annoying - are they comparitively much more annoying ? - or is the reporter better at nominating + concern wrt. too easy to nominate most annoying (Rainer) + hard to get an overview + how many 'really' most annoying + lots of little annoyances, hard to see if they affect many users. + gained 8 fixed 4 in the last week (eg.) + does it loose the function if there are too many ? + monitor for next week (Rainer, Petr) * cost and usefulness of exceptions (Michael) + still pending analysis ... AA: + post results shortly (Michael) + concerns wrt. maintainability vs. code-size (Stephan) + brought lots of code into exception-land (Caolan) + need to post for compiler guys + consider the costs in more detail & need review. * regression analysis (Caolan) + good number of regressions are in RTF + new, better implementation there, exchanging a bus-load of horrible, twisty bugs with shiny new regressions. + with the hope that new code is easier to fix + also a number of DOCX regression + windows only - hard to collect trace + an intermittent iterator incrementing crash * 3.5 most annoying bugs ... + 56 (of 153) open vs.: 52/145, 49/140, 44/132, 41/124, 32/104, 28/93, 21/76, 23/71 37% 36% 35%,33%,33%,30%,30%, 28%, 32% + https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1 * 3.5 bugs tagged with 'regression' + 116(+7) bugs open of 379(+20) total * Componentcount net * + Writer - 51 (+4) + LibreOffice - 12 (+2) + Spreadsheet - 10 (+3) + Presentation - 10 (+0) + Drawing - 9 (-1) + Database - 6 (+0) + Basic- 3 (+0) + https://bugs.freedesktop.org/buglist.cgi?keywords=regression%2C%20&keywords_type=allwords&resolution=---&query_format=advanced&product=LibreOffice&list_id=36764 -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.
Bug 45522: Crash when copying table between Writer and other LibreOffice programs
Hi! https://bugs.freedesktop.org/show_bug.cgi?id=45522 There's an attached odt file with a table in it. Copying the table to other LO programs (Calc, etc) causes LO to crash. After inspection I realized that the problem is in sw/source/core/table/swtable.cxx There is a struct definition in that file SwTableCellInfo::Impl with a void setTable(const SwTable * pTable) method. Error is in if (m_pTabFrm->IsFollow()) line. m_pTabFrm = SwIterator::FirstElement(*pFrmFmt); Problem is that SwIterator::FirstElement(*pFrmFmt); can return with NULL, so asking for ->IsFollow() can cause errors. After adding a check ( if ( m_pTabFrm ) ), crash is gone, although copying the table is still buggy. In the pasted table the whole layout is gone. All the data are in the first column in Calc and only the upper part of the table is copied in Draw and Impress. If I copy the table without the cell containing 'Wind Class', than it's ok, so that cell somehow ruins the copy mechanism. Someone has any idea why? Szabolcs ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 45563 - incorrect IMPORT of Zotero RTF, regression
On Thu, Mar 08, 2012 at 02:31:51PM +0100, "Chr. Rossmanith" wrote: > master has import problems with RTF docs with DOS line ends. If I > change line ends with dos2unix to Unix line ends the problem is > solved. Any hints where I might start debugging? Hi Christina, Look in writerfilter/source/rtftok/rtftokenizer.cxx. Ideally dos line endings are ignored in RTFTokenizer::resolveParse(), search for 0x0d. HTH, Miklos ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW 3-5] fdo#46832 fix uno bootstrapping
external .NET ( and possibly c++ ) client(s) are failing on 3.5. This is due to missing embedded manifest info in dll(s) built with gbuild resulting in failure to properly load VC90 runtime. Please see http://cgit.freedesktop.org/libreoffice/core/commit/?id=c3d806be7d30a437607d924a4d33f13fe20dd1ba thanks, Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW][3-5] fdo#46923 possibly dodgy use of invalid iterators in sc inputhdl.cxx
So, for https://bugs.freedesktop.org/show_bug.cgi?id=46923 under Linux with debugging stl iterators I can see "use of invalid iterator" stl errors with miAutoPosColumn which is a plausible reason for the reported crash. miAutoPosFormula is used to point into the std::set pFormulaData and miAutoPosColumn is used to point into the std::set pColumnData I reckon the safest thing to do is to initialize those to the end of their respective containers when the containers are initially allocated, i.e. http://cgit.freedesktop.org/libreoffice/core/commit/?id=a3f1614c606629196ca71dc22dab3343b060dced C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[ANN] LibreOffice 3.4.6 RC1 test builds available
Hi *, for 3.4.6 RC1, we're now uploading builds 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-3-4/ 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 vs. 3.4.5 is available here http://dev-builds.libreoffice.org/pre-releases-3-4/src/bugfixes-libreoffice-3-4-6-release-3.4.6.1.log It would be nice to verify they're really fixed in the build. Thanks a lot for your help, Fridrich, using (as always) the words of wise Thorsten ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW][3.5]fdo#46531, spell checking display fun
On Thu, 2012-03-08 at 14:32 +, Caolán McNamara wrote: > Nah, I recall some more of the details now. The virtual methods that > are a problem are those of SpellDialogChildWindow. Your patch call Ah - hideous :-) so we'd want to expose that late init via the abstract dialog factory, and ... I'll just leave it as it is now - man-trap intact and hope :-) Thanks ! Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Checking string allocations (was Re: String literals, ASCII vs UTF-8)
On 03/05/2012 04:29 PM, Michael Meeks wrote:
On Fri, 2012-03-02 at 17:16 +, Caolán McNamara wrote:
Yeah, back the O[UString contents with direct new/delete calls in a real
implementation body instead of current thin header-only wrapper around
the C-API which backs onto rtl_allocateMemory/rtl_freeMemory.
I'm really rather convinced that we shouldn't be piling up huge amounts
of exception unwind information, and crippling our optimiser by
What's "we" and "our" here? This looks to me like trying to fight a
given (LO is implemented in C++; C++ makes use of exceptions -- just
look at the standard library). Stop worrying and learn to love the
bomb. ;)
terrifying it with lots of things that never really happen. At the most
banal level, I suspect that:
struct Empty { int unused; };
Empty *p = new Empty();
delete p;
can't legitimately be optimised away if we have a throwing constructor,
Where does a "throwing constructor" come into play here? Do you mean a
throwing operator new? (If that is global operator new, it cannot be
optimized away, without complete program analysis anyway, as global
operator new/delete can be overridden by client code.)
but of course I can dig out some compiler people who know what they're
on about here.
Consistently calling std::abort() somewhere rather than waiting for a
SEGV sounds fine, though preferably not in-lined into many tens if not
hundreds of thousands of duplicate compare/branch/call-function sides at
every object construction.
Again, the thousands of duplicates typically fold into a single instance
per .so, so not that much excess space-wise.
Compared with that sort of waste, using the CPU's beautiful, efficient,
built-in exception handling mechanism that requires zero code, and no
unwind table ;-) *((int *)NULL) = 42; makes some sense.
Only if you do not want to react to the exception.
I don't find the explanation that most C++ object allocation wastes
space left and right a great argument for doing yet more wastage :-)
Not sure what you mean here.
Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW][3.5]fdo#46531, spell checking display fun
On Tue, 2012-02-28 at 14:13 +, Michael Meeks wrote: > On Tue, 2012-02-28 at 12:26 +, Caolán McNamara wrote: > > Dialog is fragile and tricky :-( > > So - given that the dialog was moved to cui, is not public, and has > only one constructor in the factory method - would something like the > appended clean that up rather pleasantly ? > Nah, I recall some more of the details now. The virtual methods that are a problem are those of SpellDialogChildWindow. Your patch call LateInit inside CreateSvxSpellDialog, but the problem is that the SpellDialogChildWindow::SpellDialogChildWindow ctor http://opengrok.libreoffice.org/xref/core/svx/source/dialog/SpellDialogChildWindow.cxx#47 is what is calling CreateSvxSpellDialog, so a LateInit there still tries to call virtual methods on an in-construction object, e.g. the IsGrammarChecking and HasAutoCorrection calls. Its only after a SpellDialogChildWindow, or the things that inherit from it, i.e. SwSpellDialogChildWindow, is itself finished construction that calling virtual methods on it from inside a SvxSpellDialog is safe. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: OpenOffice Addon Plugin on Eclipse
On Thu, 2012-03-08 at 18:14 +0400, libreoffice...@gmail.com wrote: > Dear Admins, > > Is there any Interoffice / Open Office AddOn Plugin on Eclipse for > development? > (we have found plugin for Netbeans > http://plugins.netbeans.org/plugin/2320/openoffice-org-api-plugin this > does not work on new version of LO, because of the changes in SDK ) Please have a look at the ooeclipse project. http://www.ohloh.net/p/ooeclipse I haven't found time to work on it recently, but it should help you. Of course feel free to help the development if you wish some features / bug fixes there. -- Cedric ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
OpenOffice Addon Plugin on Eclipse
Dear Admins, Is there any Interoffice / Open Office AddOn Plugin on Eclipse for development? (we have found plugin for Netbeans http://plugins.netbeans.org/plugin/2320/openoffice-org-api-plugin this does not work on new version of LO, because of the changes in SDK ) Nick ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [PUSHED] Convert from tools/table.hxx to std::map in SvxMacroTableDtor class in SVL module
Thanks, pushed. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED][PATCH] fdo#46939: Crash after trying to rename autotext entry
On Wed, 2012-03-07 at 04:20 +0100, Dézsi Szabolcs wrote: > > xRoot->renameElement ( aOldStreamName, aNewStreamName ); > > It can be seen a few lines later, that xBlkRoot is handled the same way, > catching a container::ElementExistException, but doing nothing in the catch > block. Yeah, that logic suggests that if we catch in one place, we should catch in the other, so PUSHED. Though I see the reason an exception is thrown is because the oldname and the newname are the same, i.e. the rename doesn't make sense, it already has that name. So I stuck the offending block inside the existing new != old test. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [PUSHED] fdo#43424: LO Crashes while Comparing an Empty Document with Another Document
Thanks, applied, pushed to master. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Convert from tools/table.hxx to std::map in SvxMacroTableDtor class in SVL module
Hi License statement already on file. Regards, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html 0001-Convert-from-tools-table.hxx-to-std-map-in-SvxMacroT.patch Description: application/mbox ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#43424: LO Crashes while Comparing an Empty Document with Another Document
Hi!
There was a call for GetLine( nInsPos-1 ); with nInsPos == 0 so it wanted to
return aLines[ nLine ]; where nLine == -1.
(vector< CompareLine* > aLines;)
Files: sw/source/core/doc/doccomp.cxx (in SwCompareData::ShowDelete)
Szabolcs
From 0d726dc30eb85745eab8b83c710b57df99ee17e0 Mon Sep 17 00:00:00 2001
From: Szabolcs Dezsi
Date: Thu, 8 Mar 2012 14:52:14 +0100
Subject: [PATCH] Comparing empty document with attached one crashes LO
---
sw/source/core/doc/doccomp.cxx | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/sw/source/core/doc/doccomp.cxx b/sw/source/core/doc/doccomp.cxx
index 80c77c4..11c43f3 100644
--- a/sw/source/core/doc/doccomp.cxx
+++ b/sw/source/core/doc/doccomp.cxx
@@ -1536,14 +1536,17 @@ void SwCompareData::ShowDelete( const CompareData& rData, sal_uLong nStt,
((SwCompareLine*)rData.GetLine( nEnd-1 ))->GetEndNode(), 1 );
sal_uInt16 nOffset = 0;
-const CompareLine* pLine;
-if( GetLineCount() == nInsPos )
+const CompareLine* pLine = 0;
+if( nInsPos >= 1 )
{
-pLine = GetLine( nInsPos-1 );
-nOffset = 1;
+if( GetLineCount() == nInsPos )
+{
+pLine = GetLine( nInsPos-1 );
+nOffset = 1;
+}
+else
+pLine = GetLine( nInsPos );
}
-else
-pLine = GetLine( nInsPos );
const SwNode* pLineNd;
if( pLine )
--
1.7.7
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [OBSOLETE] fdo#40686: Opening the attached file crashes LibreOffice - FILEOPEN
Thanks, but sorry, already handled by Caolán in c0db5469d9bb289075914e60ced856698a6ae249. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#40686: Opening the attached file crashes LibreOffice - FILEOPEN
Hi! With this small modification files attached here loads correctly. I'm ignoring values which are outside the specification range (1-31680). Szabolcs From 4a17bf3d26fdf75cb504daa41364eeb7fe970e88 Mon Sep 17 00:00:00 2001 From: Szabolcs Dezsi Date: Thu, 8 Mar 2012 14:30:48 +0100 Subject: [PATCH] Opening certain .doc files crashes LO --- sw/source/filter/ww8/ww8par6.cxx |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/sw/source/filter/ww8/ww8par6.cxx b/sw/source/filter/ww8/ww8par6.cxx index 2ca90194..7de87dd 100644 --- a/sw/source/filter/ww8/ww8par6.cxx +++ b/sw/source/filter/ww8/ww8par6.cxx @@ -306,7 +306,8 @@ void SwWW8ImplReader::SetDocumentGrid(SwFrmFmt &rFmt, const wwSection &rSection) } aGrid.SetBaseWidth( writer_cast(nCharWidth)); -aGrid.SetLines(writer_cast(nTextareaHeight/nLinePitch)); +if( nLinePitch >= 1 && nLinePitch <= 31680 ) +aGrid.SetLines(writer_cast(nTextareaHeight/nLinePitch)); aGrid.SetBaseHeight(writer_cast(nLinePitch)); sal_Int32 nRubyHeight = 0; -- 1.7.7 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bug 45563 - incorrect IMPORT of Zotero RTF, regression
Hi, master has import problems with RTF docs with DOS line ends. If I change line ends with dos2unix to Unix line ends the problem is solved. Any hints where I might start debugging? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Question about Bug 40686: Opening the attached file crashes LibreOffice - FILEOPEN
On Thu, 2012-03-08 at 12:35 +0100, Dézsi Szabolcs wrote: > Adding a simple if( nLinePitch != 0 ) before the line seems to solve > the problem, documents load with it. > > Question: should I use this solution (if it's a solution) or this > causes other issues somewhere else? That nLinePitch comes from "sprmSDyaLinePitch", e.g. http://msdn.microsoft.com/en-us/library/dd923455%28v=office.12%29.aspx so "value MUST be greater than or equal to 1, and MUST be less than or equal to 31680" is apparently the valid range for that value, so yeah, ignoring it outside of that range seems the sane thing to do. http://cgit.freedesktop.org/libreoffice/core/commit/?id=c0db5469d9bb289075914e60ced856698a6ae249 C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW 3-5] fdo#46508 use ISCHECKFORPRODUCTUPDATES property for online update
2012/3/8 Matúš Kukan : > On 6 March 2012 21:59, Andras Timar wrote: >> I pushed the fix to master, and a similar patch for libreoffice-3-5 >> branch is attached. >> http://cgit.freedesktop.org/libreoffice/core/commit/?id=5ce699f0c82d5bfd629c22be0747bbe3b851a9fd > > I fixed MacOSX-Intel_1-built_no-moz_on_10.6.8's --enable-epm build with: > http://cgit.freedesktop.org/libreoffice/core/commit/?id=0138d85a6f9cb33a943d43e715fd2a34edb6011d > I think. > Maybe something similar is needed for attached patch now pushed in 3-5 branch > ? You are right, thanks! I pushed a similar fix to 3-5 branch. Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: performance enhancements for cygwin make
> as Norbert says I think you may end up with path problems. Converting between Cygwin and Windows format pathnames is one simple Cygwin library call, cygwin_conv_path() declared in . > Incidentally, there is a remake.c (touch_file) method there already, Weird that it opens the file, reads a byte and writes it back... What's wrong with utimes() (in the case of an already existing file)? (Yeah, I guess it isn't equally portable.) But at least in our private fork, for Windows we definitely should just use SetFileTimeW() on Windows, perhaps utimes() on Unix, and if that fails because of non-existent file, then fall back to the portable code that uses O_CREAT. > prolly more likely to go up-stream like that. I expect the biggest hurdle to upstreaming will be "so where are the unit test additions/changes to check that your changes work and don't break anything" and "where is the documentation patch" ;) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: build break, master, windows7-64bit, in tail_build PDFITest
Hi
This seems to be fixed now.
I did a git status and it looks like git "forgot" to delete some
leftover files, so I deleted them myself and the problem went away.
Regards, Noel.
On 2012-03-08 14:25, Markus Mohrhard wrote:
Hello Noel,
2012/3/7 Noel Grandin:
[ 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
Can you try again with at least backporting [1] ? This should give
some more details if the the test is failing.
Regards,
Markus
[1]
http://cgit.freedesktop.org/libreoffice/core/commit/?id=ccfbb8647503e9e2531c4fc1fb03354a82401e3d
Disclaimer: http://www.peralex.com/disclaimer.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: performance enhancements for cygwin make
Hi Noel, On Thu, 2012-03-08 at 11:11 +0200, Noel Grandin wrote: > yeah, I'm working on the version from the dev-tools/make-3.82-gbuild > repository Nice :-) > > properly beside the 'call touch as an inline' thing does not need to > > be windows specific. > > I've coded 2 variants, one general purpose and one specific to windows. > Because > (a) on Windows, I can implement "touch" using exactly one system call, Heh - systemcalls are ~free compared to forking I think - as Norbert says I think you may end up with path problems. > (b) and because it's practice for some of the other optimisations I'd > like to do :-) Fun :-) > True, which is why I coded the general purpose variant (largely borrowed > from GNU touch) Incidentally, there is a remake.c (touch_file) method there already, I guess if we split the innards of that out and re-used them then we'd at least have this working for all the super-odd operating systems that make supports: AIX, Amiga etc. ;-) prolly more likely to go up-stream like that. I'm encouraged by Tor's 'file' find as well I guess. All the best, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: build break, master, windows7-64bit, in tail_build PDFITest
Hello Noel,
2012/3/7 Noel Grandin :
> [ 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
>
Can you try again with at least backporting [1] ? This should give
some more details if the the test is failing.
Regards,
Markus
[1]
http://cgit.freedesktop.org/libreoffice/core/commit/?id=ccfbb8647503e9e2531c4fc1fb03354a82401e3d
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [PUSHED] fdo45682 split button for writer line colour
Thanks, pushed to master. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW 3-5] fdo#46508 use ISCHECKFORPRODUCTUPDATES property for online update
On 6 March 2012 21:59, Andras Timar wrote: > I pushed the fix to master, and a similar patch for libreoffice-3-5 > branch is attached. > http://cgit.freedesktop.org/libreoffice/core/commit/?id=5ce699f0c82d5bfd629c22be0747bbe3b851a9fd I fixed MacOSX-Intel_1-built_no-moz_on_10.6.8's --enable-epm build with: http://cgit.freedesktop.org/libreoffice/core/commit/?id=0138d85a6f9cb33a943d43e715fd2a34edb6011d I think. Maybe something similar is needed for attached patch now pushed in 3-5 branch ? Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED 3-5] fdo#46508 use ISCHECKFORPRODUCTUPDATES property for online update
2012/3/8 Michael Meeks : >> Windows in a corporate environment. It can be done easily from the >> command line with the REMOVE=gm_o_Onlineupdate option, however, it >> would be better to use the ISCHECKFORPRODUCTUPDATES variable, because >> sysadmins are more familiar with that. > > It looks as if we already set that in our install anyway - right ? > Yes, default value of ISCHECKFORPRODUCTUPDATES is 1, and gm_o_Onlineupdate feature is installed by default. Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH]fdo45682 split button for writer line colour
Attached a simple patch which converts the old button for line colour in the table tool bar to a split button. Winfried 0001-fdo-45682-split-button-for-writer-table-line-color.patch Description: 0001-fdo-45682-split-button-for-writer-table-line-color.patch ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PUSHED 3-5] fdo#46508 use ISCHECKFORPRODUCTUPDATES property for online update
On Tue, 2012-03-06 at 21:59 +0100, Andras Timar wrote: > In some scenarios it is desirable to disable Online Update feature. It > can be done interactively but I'm thinking of silent install on Looks good to me :-) > Windows in a corporate environment. It can be done easily from the > command line with the REMOVE=gm_o_Onlineupdate option, however, it > would be better to use the ISCHECKFORPRODUCTUPDATES variable, because > sysadmins are more familiar with that. It looks as if we already set that in our install anyway - right ? > I pushed the fix to master, and a similar patch for libreoffice-3-5 > branch is attached. Pushed to -3-5 Thanks ! Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Positioning vcl Controls
Hi Andrew, On 2012-03-07 at 12:28 +, Andrew Higginson wrote: > 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 If you don't need any dynamic layouting, use the .src file; that way, the transition to... > However I also saw in the slides from FOSDEM that some work is being > done to make laying out easier, with Boxes and Grids. ...this will be easier when it hits master. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
sal/config.h build error ...
On Wed, 2012-03-07 at 02:17 +0900, Takeshi Abe wrote: > >> [ build CXX ] sal/qa/rtl/strings/test_strings_replace.cxx > >> /home/noel/libo/sal/qa/rtl/math/test-rtl-math.cxx:29:24: fatal error: > >> sal/config.h: No such file or directory > > I have stumbled on the same error. > > Interestingly even `make sal.clean` failed like: The rumour is that manually removing your solver/ works around this :-) I must say, I'm a bit concerned that our 'make clean' is becoming sufficiently complicated that it no longer effectively cleans ;-) [ same problem for cross-compiling that it removes only one of host / build ]. Do we need a 'make really_clean' that removes the solver, workdir etc. ? :-) All the best, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [PUSHED] Convert tools/table.hxx usage to std::map in tools module
Thanks, pushed to master. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PUSHED][3-5] disarm bogus unoapi XPropertySet test
On Wed, 2012-03-07 at 11:24 +0100, Michael Stahl wrote: > 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 Ooh - a nasty randomness that causes some build to fail and others to succeed ? :-) > evidence to back the hypothesis that unoapi tests are completely > braindamaged. Lol ;-) > so i've decided to disable the check that the value of the property is > actually different after calling setPropertyValue: No doubt sberg will have some thoughts when he gets back from vacation. > http://cgit.freedesktop.org/libreoffice/core/commit/?id=73867da36960adf8b79ff34c7094c63aa5a05940 > > please somebody review and apply it to libreoffice-3-5 as well. Pushed, thanks ! :-) Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Convert tools/table.hxx usage to std::map in tools module
Hi License statement already on file. Regards, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html 0001-Convert-tools-table.hxx-to-std-map.patch Description: application/mbox ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Question about Bug 40686: Opening the attached file crashes LibreOffice - FILEOPEN
Hi! Here's the bug's page: https://bugs.freedesktop.org/show_bug.cgi?id=40686 It seems that a division by zero occurs on line 310 in ww8par6.cxx: aGrid.SetLines(writer_cast(nTextareaHeight/nLinePitch)); nLinePitch is 0 here. This causes some doc files to crash LO. Adding a simple if( nLinePitch != 0 ) before the line seems to solve the problem, documents load with it. Question: should I use this solution (if it's a solution) or this causes other issues somewhere else? Szabolcs ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GSoC & error during make
On 8 March 2012 12:05, Michael Stahl wrote: > please pull again and then do "rm -rf solver workdir" to remove the > broken stuff (or a top-level make clean). Maybe removing solver/* could be enough ? You can save time with that. If not, remove also workdir/* > Matus promises to test future build system changes that add new pattern > rules on all supported make versions before pushing :) Yes :), sorry for this, I did not know there could be such differences. Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GSoC & error during make
On 08/03/12 00:00, Mariana Marasoiu wrote: > 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 this is a known problem when using make 3.81 and is fixed on master now: http://cgit.freedesktop.org/libreoffice/core/commit/?id=294b86e3dbbdb9b136cb17a51687f4e2762711cf please pull again and then do "rm -rf solver workdir" to remove the broken stuff (or a top-level make clean). Matus promises to test future build system changes that add new pattern rules on all supported make versions before pushing :) > And for sal module, there are lots of C++ errors and warnings and also > "No such file or directory" errors. that problem had the same cause. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [PUSHED] fix bug in previous patch in converting SwBookmarkNodeTable to multimap
Thanks, pushed to master. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: [PUSHED][PATCH]fdo45671 writer par. bg color simplified code for split button
Astron wrote (08-03-2012 11:22) > >>To the uninitiated, this behaviour might seem very confusing (exactly > >>as it did to Ivan). In Excel, the default background colour seems to > >>be yellow, so let's do something similar here – I don't like yellow > >>per se, but Excel users are probably used to yellow, so no need to > >>break the functionality for them. > >>So, I'd propose to use either "Yellow" or "Chart 3" as the default. > > Just let me know which initial colour you prefer and I will try to > > implement it :) > > In the interest of consistency and contrast... the best is probably to > use "Yellow." Whilst working on the next button I encountered buttons like table background colour in writer. These are not (yet) split button, but have a grey bitmap as default, with COL_TRANSPARENT as default colour. Apart from writer highlight colour, all background colour buttons I have seen so far in LibreOffice, have COL_TRANSPARENT as default, with a gray bitmap. I do not want to be irreverent, but does this not require some extra thought and/or advise from ux (I think that is where the user side of LibreOffice is discussed, but it could be something else)? Or could we consider using a checquered (gray/white) bitmap, like used in GIMP for transparent? Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Q: Is [collaboration] of some interest? [yes!]
Hi Riccardo, On Wed, 2012-03-07 at 15:39 +0100, Riccardo Bernardini wrote: > 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). No - this is a great place to do this. > 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. Wonderful - there is already some similar work underway that Eike is looking into, it would be great to have you work with him. > The project is about providing LibreOffice with a "Google Docs-like" > simultaneous editing capability, but with some improvements and a > bazaar (or git) flavor. Ok - so, in the model I'm recommending, the git flavour would be something orthogonal. > 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"). Right, > 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). Ok - so, (I hope) our focus first would be the on-line co-editing, and then use/fall-back to (and improve) the document merging / comparison functionality to do on-line/off-line merges. > 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. Sure. > 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? There is work underway, to bootstrap this via instant messaging, and particularly the Telepathy framework - it would be great to make that more public / visible and get more hands onto playing with it. Eike - do you have something that could go into a feature branch ? :-) > 2. Has the LibreOffice community some interest in this idea? If it > has, this would give us a stronger motivation. Yes - of course, we're here to help guide you towards a design that is complementary to what we're doing, fits well with the code-base, and other people etc. :-) And to some degree I'm here to try to support others to help them do cool things with the code-base, of which this is clearly one. > 3. Do you have some general suggestions for us? Especially about > interfacing the rest of the developers. So - first, talk to Eike (preferably CC'ing the list here). Second - here is what I was trying to persuade Eike was a sensible way of doing it (which he's prolly detected as insane already ;-). Please bear in mind we're starting with calc here ... Here are my thoughts: * It doesn't matter what you do to the document, as long as everyone's document does the same thing. * Thus - whatever protocol you use, it needs to enforce hard ordering, such that edits 'A1', 'B1', 'A2' 'C1' end up in the same order for A, B, and C regardless of latency / topology etc. * Jabber provides this guarentee :-) and a beautiful way of bootstrapping communication from an existing communication tool: telepathy/empathy/IM * Those edits need to do -exactly- the same thing, ie. we'd want the same major version of LibreOffice at each end. ** But ** - and here is where the work starts * We need to ensure that all edits to the document are not applied immediately, but described and dispatched to the Jabber server, and only the events returned are applied. * This means we need a -clean- Controller <-> Model split which we currently don't have ;-) -although- some things are really quite pleasant, eg. dialogs often tend not to be instant apply, and to collect up their changes into abstract SfxItemSets (PropertyBags to you and me) so with work we can tease out the controller perhaps. * And of course, some thinking of good ways of managing cursor locations, and transmitting other
Re: [PUSHED][PATCH]fdo45671 writer par. bg color simplified code for split button
Hi Winfried, On 7 March 2012 07:54, Winfried Donkers wrote: > Astron wrote (06-03-2012 17:44) >>> That is expected behaviour to me. The startup background colur is >>> transparent (hence the gray bitmap in the button). > >>To the uninitiated, this behaviour might seem very confusing (exactly >>as it did to Ivan). In Excel, the default background colour seems to >>be yellow, so let's do something similar here – I don't like yellow >>per se, but Excel users are probably used to yellow, so no need to >>break the functionality for them. >>So, I'd propose to use either "Yellow" or "Chart 3" as the default. > > I simply -and without further thought- copied the initial setting of > the old style button, which was transparent and which shows as gray > (see colour palette). I have no problem in changing the initial > colour to yellow (as with writer highlight colour), but once you > select transparent colour from the palette, the button shows gray > again... Okay. > Just let me know which initial colour you prefer and I will try to > implement it :) In the interest of consistency and contrast... the best is probably to use "Yellow." Astron. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fix bug in previous patch in converting SwBookmarkNodeTable to multimap
Hi Fix bug in my previous patch, spotted by Ivan. Regards, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html 0001-Fix-bug-in-commit-ad9960ffeb25f31ce4b1f819f909f1eb9a.patch Description: application/mbox ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GSoC & error during make
On Thu, Mar 8, 2012 at 3:31 AM, Michael Meeks wrote: > > On Thu, 2012-03-08 at 01:00 +0200, Mariana Marasoiu wrote: >> Okay, bad news... I still couldn't build LibreOffice :(. > > :-) sorry for the trouble. One of the best ways to get a working build > is to use IRC, and appear in the #libreoffice-dev on irc.freenode.net > and get some interactive help (it may be quicker), we're quite friendly > there & tend not to bite (at least newbies :-) I strongly recommend http://workaround.org/getting-help-on-irc if you are not familiar with IRC... that will help you to have an even nicer experience :-) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: performance enhancements for cygwin make
On Thu, Mar 8, 2012 at 3:11 AM, Noel Grandin wrote: > > > On 2012-03-08 10:59, Norbert Thiebaud wrote: >> >> the gmake we use is a cygwin-gmake not a WINDOW32 gmake so to build it on >> cygwin > > yeah, I'm working on the version from the dev-tools/make-3.82-gbuild > repository > > >> ./configure make should be enough and autotools should detect cygwin > > It's detecting gcc and compiling a normal version fine, but it's not > compiling the stuff behind the WINDOWS32 #define > Maybe I should be using a different #define, something like > #ifdef WINDOWS32 || __CYGWIN__ no because the path you'd get under cygwin is unlikely to be supported by a native WIN32 call. but then, it is hard to comment on abstract... post the patches, maybe I get a better idea of what you mean Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GSoC & error during make
On Thu, 2012-03-08 at 01:00 +0200, Mariana Marasoiu wrote: > Okay, bad news... I still couldn't build LibreOffice :(. :-) sorry for the trouble. One of the best ways to get a working build is to use IRC, and appear in the #libreoffice-dev on irc.freenode.net and get some interactive help (it may be quicker), we're quite friendly there & tend not to bite (at least newbies :-) HTH, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo #46446: add python gdb helpers for osl::FileBase
On Wed, 2012-03-07 at 22:43 +0100, Catalin Iacob wrote: > Sample output for the pretty printer: Looks really lovely ! thanks for that :-) Good work, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: performance enhancements for cygwin make
On 2012-03-08 10:59, Norbert Thiebaud wrote: the gmake we use is a cygwin-gmake not a WINDOW32 gmake so to build it on cygwin yeah, I'm working on the version from the dev-tools/make-3.82-gbuild repository ./configure make should be enough and autotools should detect cygwin It's detecting gcc and compiling a normal version fine, but it's not compiling the stuff behind the WINDOWS32 #define Maybe I should be using a different #define, something like #ifdef WINDOWS32 || __CYGWIN__ properly beside the 'call touch as an inline' thing does not need to be windows specific. I've coded 2 variants, one general purpose and one specific to windows. Because (a) on Windows, I can implement "touch" using exactly one system call, (b) and because it's practice for some of the other optimisations I'd like to do :-) granted that on linux it won't probably not translate into big gain, it should not hurt either... True, which is why I coded the general purpose variant (largely borrowed from GNU touch) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: performance enhancements for cygwin make
On Thu, 2012-03-08 at 09:52 +0200, Noel Grandin wrote: > I'm having a bash at this - mostly I copied and simplified the > corresponding code from the GNU touch utility. ooh - exciting ! :-) thanks for that, I'll hold fire on filing the easy hack on that. Hopefully you're working on the version from our git repo that is at least sanely revision controlled, fast local diffs etc. :-) > Anybody have any ideas? I think the consensus is right - that you should write them for unix as well, although the win is smaller there it will be at least something I guess. Looking forward to your patches ! :-) Thanks ! Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW] fix for fdo#46825, crash copying a chart
On 03/03/2012 01:08 AM, Markus Mohrhard wrote: [1] fixes a crash when you copy a chart in the document. The problem is that you should not create a uno::Sequence with new because the uno::Sequence copy c'tor is creating a flat copy. This will later result in a double delete. I think the patch is quite save and fixes a crash and therefore should be included into at least 3-5 and if still possible in 3-5-1. Regards, Markus [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=8f2d3c47ad40039a842fa09d98137155dcfdfe9e While changing from a pointer-to-Sequence member to a plain Sequence member is probably a good choice, anyway (as Sequence itself is nothing more than a pointer to the underlying uno_Sequence data structure), I do not see how the original code was actually wrong: The Sequence copy ctor increases the shared _pSequence->nRefCount, while delete, via Sequence dtor, uno_type_destructData, _destructData, and idestructSequence decrements nRefCount again, and destroys the shared uno_Sequence only when the ref count has dropped to zero. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: performance enhancements for cygwin make
On 08/03/12 08:52, Noel Grandin wrote: > 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. we use cygwin make, which is to say make believes it runs on UNIX, and does not use the Windows stuff. you are welcome to try to build LO with a native Windows make, but you should not expect it to work. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: performance enhancements for cygwin make
On Thu, Mar 8, 2012 at 2:37 AM, Noel Grandin wrote: > > > On 2012-03-08 10:19, Jesús Corrius wrote: >> >> There are already many native ports of the GNU tools for Windows. > > I know - I'm working on Meeks' suggestions for improving the performance of > gmake on Windows. > > >> You can try adding -DWINDOWS32 to CFLAGS. > > That part I know, but which file do I edit to make that happen when building > using gcc/make under cygwin. the gmake we use is a cygwin-gmake not a WINDOW32 gmake so to build it on cygwin ./configure make should be enough and autotools should detect cygwin properly beside the 'call touch as an inline' thing does not need to be windows specific. granted that on linux it won't probably not translate into big gain, it should not hurt either... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [OBSOLETE] Don't use Makefile Emacs mode and tabs for Python files
Whoa, why did we have that Mode: makefile-gmake in .py files, one wonders. Anyway, all those Emacs mode lines seem to have been fixed already my Michael Stahl, do you need to pull? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [PUSHED] fdo #46446: add python gdb helpers for osl::FileBase
Thanks, pushed to master. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: performance enhancements for cygwin make
On 2012-03-08 10:19, Jesús Corrius wrote: There are already many native ports of the GNU tools for Windows. I know - I'm working on Meeks' suggestions for improving the performance of gmake on Windows. You can try adding -DWINDOWS32 to CFLAGS. That part I know, but which file do I edit to make that happen when building using gcc/make under cygwin. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: performance enhancements for cygwin make
> I'm having a bash at this - mostly I copied and simplified the corresponding > code from the GNU touch utility. There are already many native ports of the GNU tools for Windows. For example: http://gnuwin32.sourceforge.net/packages/coreutils.htm I used these ones to compile linux code using a Visual Studio project and they worked well. > 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. You can try adding -DWINDOWS32 to CFLAGS. -- Jesús Corrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
