Re: Excessive exception size cost ...

[Noel Grandin]

Just some interesting numbers for this debate.

Doing some rough analysis on master:

[1] total number of throw calls 108381

[2] total no. of catch blocks 3984
 re-throws the same exception  319
 throws different exception433
 calls generic handler1134
 ignores exceptions   1121
 others977


Footnotes

[1] git grep throw | wc -l

[2] find . -name *.cxx | xargs grep -A 5 -h "catch ("
and then a small java program


Disclaimer: http://www.peralex.com/disclaimer.html


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Bibliography DB and DBaseIII files [was: Patch for Easy Hack 45033]

[Lionel Elie Mamane]

On Fri, Mar 09, 2012 at 03:15:10PM +, Caolán McNamara wrote:

> Aha, now I understand the problem. Looking a bit closer, our biblio.odb
> *doesn't* embed the database inside the .odb, this is one of the .odbs
> which point to an external data source/sink. In this case it points to
> ~/.libreoffice/3/user/database/biblio/biblio.db[f|t] so whenever anyone
> edits it then only their local .dbf and .dbt files get their data
> changed :-)

> Documented a way to update the bibliography database that works with
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=c7de2ddf67158733ba15cea4cb8f1786e83776d9
>  

> caolanm->lionel: might be worth having a look at the points a & b in
> that README, not sure if those are bugs or intentional behavior.

> a) oddly base doesn't show the same fields that the bibliography
>widget does, possibly a bug worth fixing ?

Cannot immediately reproduce. Which field is visible in one, but not
the other?

> b) oddly base doesn't seem to "PACK" the dbase III files after
>editing, so deleted records still take up space in the file,
>possibly a bug worth fixing ?

Let's make it an easyhack. Put me in CC on it. It is not entirely
clear when we should pack it. After every change is too much
(performance-wise). When some threshold of space is wasted? When the
.odb file is closed? When the .odb file is saved (but then if only
data and no form / report / ... is changed, we never pack).

Do you have an idea of how to "PACK" a dbase III file? Is is already
implemented in our code and we just need to add the function call or
does that need to be added, too?

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[REVIEW] fix for fdo#46230, shrink the copy area only in the text export

[Markus Mohrhard]

Hey,

[1] fixes the problem that drag and drop did not work correctly in
calc. The problem is that we should not shrink the area already in
ScTransferObj. We should wait until we need to export the data and
limit this to the text export. Please test it especially in the
context of n#677811.

Regards,
Markus

[1] 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a26fe4a39b6f3b2af269b801340c32c28806250
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PROPOSAL] get rid of clone/*, use git submodules for binfilter, dictionaries and help

[Norbert Thiebaud]

On Mon, Mar 12, 2012 at 9:30 AM, Christian Lohmaier
 wrote:
> On Mon, Mar 12, 2012 at 3:26 PM, Christian Lohmaier
>  wrote:
>> [...]
>>> + a build point is identified by one and only one sha, which is
>>> imperative to manage a build-farm ( gerrit+jenkins and the ability to
>>> test-build every patches)
>
> And I forgot:
> Every change in one of the submodules requires touching the containing
> repo as well (to update the submodule's version-info.
>
> So to "test every patch" you cannot just use the containing repo. If
> people check in stuff to one of the submodule but don't update the
> containing repo accordingly, you won't see the change on your
> buildmachine..

hum... that is covered by gerrit (whith 2.3, when you integrate a
patch on a dependent submodule it 'update' the parent accordingly

but still the previous points you mentioned about ./g are indeed true...
and managing branchand change in the submodule can be confusing (the
submodule get checked-out as a detached head, so one need to checkout
a branch/master before doing changes there...

still I'd like to find a way to get the buildbot to build things that
are not necessarily the HEAD fo a branch...
one thing I am considering is improving the external dependency
'fetch' to support git-based external, and then treat these git repos
as 'external dependencies'

Norbert

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PROPOSAL] get rid of clone/*, use git submodules for binfilter, dictionaries and help

[Christian Lohmaier]

On Mon, Mar 12, 2012 at 3:26 PM, Christian Lohmaier
 wrote:
> [...]
>> + a build point is identified by one and only one sha, which is
>> imperative to manage a build-farm ( gerrit+jenkins and the ability to
>> test-build every patches)

And I forgot:
Every change in one of the submodules requires touching the containing
repo as well (to update the submodule's version-info.

So to "test every patch" you cannot just use the containing repo. If
people check in stuff to one of the submodule but don't update the
containing repo accordingly, you won't see the change on your
buildmachine..

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PROPOSAL] get rid of clone/*, use git submodules for binfilter, dictionaries and help

[Christian Lohmaier]

Hi Norbert, *,

On Fri, Mar 9, 2012 at 8:41 PM, Norbert Thiebaud  wrote:
> [using git submodules instead of links of repos in clone]
>
> The pros:
>
> + no more need for ./g

But still need for wrapper or check in configure. As submodules don't
get updated automatically when the reference-info from the parent repo
is changed.
So while the containing repo specifies "binfilter at version xy",
pulling the containing repo won't update the binfilter one.
You need to run git submodule update manually.

> + a build point is identified by one and only one sha, which is
> imperative to manage a build-farm ( gerrit+jenkins and the ability to
> test-build every patches)

But you cannot rely on the bots acually building what is specified
without hacking approprite checks into configure or "g"

and you won't be able to use ./g diff to see the changes in your whole
tree either.

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Bug 37361 depends on bug 46230, which changed state.

Bug 46230 Summary: EDITING: impossible to perform a drag & drop of entire 
row/column
https://bugs.freedesktop.org/show_bug.cgi?id=46230

   What|Old Value   |New Value

 Status|NEW |ASSIGNED
 Resolution||FIXED
 Status|ASSIGNED|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

Re: [PROPOSAL] get rid of clone/*, use git submodules for binfilter, dictionaries and help

[Norbert Thiebaud]

On Mon, Mar 12, 2012 at 2:19 PM, Miklos Vajna  wrote:
> Hi Norbert,
>
> Is this really an issue? Right now only the relevant repos are cloned
> (e.g. by default translations is not cloned), if you do the same with
> submodule init, translations could be a submodule as well. Or did I miss
> something?

you are right...
that would means that ./g remain but is adapted to update the
appropriate submodules based on bin/git-repos

I could each ./g pull to update the submodules after pulling core...
and other user-friendly stuff ...
I need to play a bit more with it


>
> Just to be clear: this is true for any non-core commit, not only merges.

only to the extent that you care for that commit to be visible in core...
practically if you are going to push a patch series on binfilter for
instance, there is no reason to upgrade core at every commits.

but yes you are right it is not only 'merge'

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[3.5.1] build broken in KDE4FilePicker.cxx

[Andreas Radke]

Since latest KDE update (4.8.1) I get this build error in ArchLinux:

R=/build/src && S=$R/libreoffice-core-3.5.1.2 && O=$S/solver/unxlngx6.pro && 
W=$S/workdir/unxlngx6.pro &&  mkdir -p $W/Headers/Library/ && touch 
$W/Headers/Library/simplecanvas.uno.so
In file included from /usr/include/kcompletion.h:24:0,
 from /usr/include/kcombobox.h:27,
 from /usr/include/kfilefiltercombo.h:27,
 from 
/build/src/libreoffice-core-3.5.1.2/fpicker/source/unx/kde4/KDE4FilePicker.cxx:67:
R=/build/src && S=$R/libreoffice-core-3.5.1.2 && O=$S/solver/unxlngx6.pro && 
W=$S/workdir/unxlngx6.pro &&  mkdir -p $W/Headers/Library/ && touch 
$W/Headers/Library/nullcanvas.uno.so
/usr/include/kglobalsettings.h:595:46: error: expected identifier before '(' 
token
/usr/include/kglobalsettings.h:595:46: error: expected '}' before '(' token
/usr/include/kglobalsettings.h:595:46: error: expected ')' before numeric 
constant
/usr/include/kglobalsettings.h:597:1: error: expected unqualified-id before 
'protected'
/usr/include/kglobalsettings.h:679:1: error: expected unqualified-id before 
'private'
/usr/include/kglobalsettings.h:682:21: error: expected unqualified-id before 
')' token
/usr/include/kglobalsettings.h:685:20: error: uninitialized const 'd' 
[-fpermissive]
/usr/include/kglobalsettings.h:688:1: error: expected declaration before '}' 
token

Is this already known? Latest kfpicker commits seem to be only removing other 
compiler warnings.

-Andy
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bin/convwatch.py: graphical layout regression test re-incarnated

[Michael Stahl]

On 11/03/12 16:50, Thorsten Behrens wrote:
> Michael Stahl wrote:
>> like several previous incarnations of the same idea, it bootstraps
>> an office, loads all documents in a directory and prints them to
>> files.
>>
> Hehe, you rock - just, FWIW, there's this in the old build repo:
> 
>  
> http://cgit.freedesktop.org/libreoffice/build/tree/bin/oodocdiff.sh?h=libreoffice-3-4
> 
> (seems it wasn't moved over to solenv/bin),
> 
> which relies on the rather new-fangled batch-conversion /
> batch-printing options of the office binary:
> 
>  --print-to-file [-printer-name printer_name] [--outdir output_dir] files
>   Batch print files to file.
>   If --outdir is not specified then current working dir is used as 
> output_dir.
>   Eg. --print-to-file *.doc
>   --print-to-file --printer-name nasty_lowres_printer --outdir 
> /home/user *.doc

oh, those are so new-fangled i never heard of them :)

>> it is based on a handful of general purpose classes to setup connections
>> to an soffice process in a robust way that could be useful for writing
>> UNO API tests in Python.
>>
> Which is lovely - just, for the sake of orthogonality, we (back in
> the day) opted to only test document printing, and not the (somewhat
> flaky) remote UNO on top. ;)

for me it turned out that the problems of remote UNO are completely
dwarfed by the un-reliability of our awful office code; e.g. i did not
succeed once in printing ~120 specific ODT documents with a single
soffice process in some hours of trying, always crashing with a
different non-reproducible stack, and thus added a connection mechanism
that starts a new soffice process for every document (plus retries),
which worked much better.  working with an un-reliable soffice is a
requirement for this kind of tool, because you may want to compare
against older OOo versions which are, if anything, even worse.

(of course this is also a really simple use case of remote UNO, it only
calls load, print, close in a loop so the usual race conditions don't
have that much opportunity to manifest)

oh, and after loading 1000 documents (it doesn't seem to crash as often
if you don't print) soffice.bin has >1G of resident memory, though i
don't remember if it went away after terminating the remote process, so
maybe that is actually caused by the remoting, but i'd guess it's not.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] [PUSHED] Remove unused code in dpitemdata

[Kohei Yoshida]

Pushed this one also.  Thanks a lot.

I was afraid some of your patches might cause conflicts (since these are
the areas I was modifying a lot in the past few weeks), but luckily all
your patches applied cleanly.

Regards,

Kohei

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] [PUSHED] Remove unused code in dptabres

[Kohei Yoshida]

Pushed to master.  Thanks a lot.

Kohei

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] [PUSHED] Remove unused code

[Kohei Yoshida]

Pushed to master.

Kohei

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOffice / openIndiana ...

[Michael Stahl]

On 12/03/12 15:09, Jonathan Adams wrote:

> # truss output of the specific saxparser command:
> ( LD_LIBRARY_PATH="/home/sal/LibreOffice/libo/solver/unxsoli/lib"
> truss -f /home/sal/LibreOffice/libo/solver/unxsoli/bin/saxparser af_NA
> /home/sal/LibreOffice/libo/i18npool/source/localedata/data/af_NA.xml
> localedata_af_NA_invis.cxx
> file:///home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata/saxparser.rdb
> /home/sal/LibreOffice/libo/solver/unxsoli/bin/types.rdb
> -env:LO_LIB_DIR=file:///home/sal/LibreOffice/libo/solver/unxsoli/lib
> 2>&1 ) > saxparser.log

so it opens
/home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata/saxparser.rdb
to file descriptor 3 successfully, closes it again, spawns a thread,
then opens the same file again to fd 3 succesfully, mmaps the file
succesfully, closes it again, then complains that it couldn't open a
registry file... that's rather odd.  perhaps the rdb file is broken or
something?

git grep says the exception is from cppuhelper/source/servicefactory.cxx

so i guess the code in the "registry" module is involved, you should
debug that a bit or sprinkle it with printfs to see what is going wrong.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Save , Save as HTML and Edit LibreOffice WorkBook without running LO

[Michael Stahl]

On 12/03/12 14:50, libreoffice...@gmail.com wrote:
> Dear Michale,
> 
> Thanks for your reply. We are investigating  ...  in most cases we have 
> a bugs in our code.   If we will found LO bugs we will definitely file it.
> 
> Main goal / question we had was: Is it any component which can edit, 
> save, save as LO calc without LO installed on computer?

for editing ODF files from Java there is also the ODF Toolkit's ODFDOM
library, now an Apache Incubator project.  it is much easier to use and
more reliable than LO, but it only offers very simple document model
operations, e.g. for text documents, there is no layout so it is not
possible to update page number references, and for spreadsheet
documents, there is (AFAIK) no formula evaluation engine, and also it
handles only ODF format, no conversion to/from anything else.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Remove unused code in dpitemdata

[Santiago Martinez]

This patch removes unused code as listed in unusedcode.easy
From 585721f333baa53199ab2dbe36964e5759b3089a Mon Sep 17 00:00:00 2001
From: Santiago Martinez 
Date: Mon, 12 Mar 2012 20:38:51 +0100
Subject: [PATCH] Remove unused code in dpitemdata

---
 sc/inc/dpitemdata.hxx  |2 --
 sc/source/core/data/dpitemdata.cxx |   11 ---
 unusedcode.easy|2 --
 3 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/sc/inc/dpitemdata.hxx b/sc/inc/dpitemdata.hxx
index 3e09d89..10363be 100644
--- a/sc/inc/dpitemdata.hxx
+++ b/sc/inc/dpitemdata.hxx
@@ -79,7 +79,6 @@ public:
 ScDPItemData();
 ScDPItemData(const ScDPItemData& r);
 ScDPItemData(const rtl::OUString& rStr);
-ScDPItemData(double fVal);
 ScDPItemData(sal_Int32 nGroupType, sal_Int32 nValue);
 ~ScDPItemData();
 
@@ -89,7 +88,6 @@ public:
 void SetRangeStart(double fVal);
 void SetRangeFirst();
 void SetRangeLast();
-void SetGroupValue(sal_Int32 nGroupType, sal_Int32 nValue);
 void SetErrorString(const rtl::OUString& rS);
 bool IsCaseInsEqual(const ScDPItemData& r) const;
 
diff --git a/sc/source/core/data/dpitemdata.cxx b/sc/source/core/data/dpitemdata.cxx
index 77c01b9..dd370ca 100644
--- a/sc/source/core/data/dpitemdata.cxx
+++ b/sc/source/core/data/dpitemdata.cxx
@@ -112,9 +112,6 @@ void ScDPItemData::DisposeString()
 ScDPItemData::ScDPItemData(const rtl::OUString& rStr) :
 mpString(new rtl::OUString(rStr)), meType(String) {}
 
-ScDPItemData::ScDPItemData(double fVal) :
-mfValue(fVal), meType(Value) {}
-
 ScDPItemData::ScDPItemData(sal_Int32 nGroupType, sal_Int32 nValue) :
 meType(GroupValue)
 {
@@ -167,14 +164,6 @@ void ScDPItemData::SetRangeLast()
 meType = RangeStart;
 }
 
-void ScDPItemData::SetGroupValue(sal_Int32 nGroupType, sal_Int32 nValue)
-{
-DisposeString();
-maGroupValue.mnGroupType = nGroupType;
-maGroupValue.mnValue = nValue;
-meType = GroupValue;
-}
-
 void ScDPItemData::SetErrorString(const rtl::OUString& rS)
 {
 SetString(rS);
diff --git a/unusedcode.easy b/unusedcode.easy
index e1067ed..77ae5b4 100755
--- a/unusedcode.easy
+++ b/unusedcode.easy
@@ -72,8 +72,6 @@ ScConditionalFormats_Impl::Remove(unsigned short, unsigned short)
 ScCsvControl::ScCsvControl(Window*, ScCsvLayoutData const&, long)
 ScDBCollection::AnonDBs::erase(boost::void_ptr_iterator<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >, ScDBData>)
 ScDBCollection::AnonDBs::size() const
-ScDPItemData::ScDPItemData(double)
-ScDPItemData::SetGroupValue(int, int)
 ScDPLabelData::ScDPLabelData(rtl::OUString const&, short, bool)
 ScDocRowHeightUpdater::TabRanges::TabRanges()
 ScFilterDetect::impl_createFactory(com::sun::star::uno::Reference const&)
-- 
1.7.7.6

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PROPOSAL] get rid of clone/*, use git submodules for binfilter, dictionaries and help

[Miklos Vajna]

Hi Norbert,

On Fri, Mar 09, 2012 at 01:41:11PM -0600, Norbert Thiebaud 
 wrote:
> The pros:
> 
> + no more need for ./g
> + no more need for $(realpath in the build since there is no links left
> + a build point is identified by one and only one sha, which is
> imperative to manage a build-farm ( gerrit+jenkins and the ability to
> test-build every patches)

Nice!

> translations will be moved to ./translations but will not be made a
> submodules due to its prohibitive size.

Is this really an issue? Right now only the relevant repos are cloned
(e.g. by default translations is not cloned), if you do the same with
submodule init, translations could be a submodule as well. Or did I miss
something?

> The cons:
> 
> - cherry picking a patch from 'before' the change to 'after' the
> change will not work if the patch impact one of these repos (due to
> the renaming). that can be mitigated with a pre-processing script to
> change the target name in the patch, since the filename pattern
> impacted is regular and easy to detect... so a simple sed should do
> the job
> 
> - feature branching becomes a bit more cumbersome if you need to
> branch one of the submodule. it boils down to remember the 'submodules
> first' rule: you need to settle submodules operations before core. So,
> for instance when merging back to master you need to merge to master
> in the submodules then commit core (still in the feature branch) to
> pick-up the merge change in the submodules and _then_ merge core.

Just to be clear: this is true for any non-core commit, not only merges.
Given how frequent non-core commits are, this can be accaptable, though.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||46230

--- Comment #225 from Rainer Bielefeld  
2012-03-12 11:43:41 PDT ---
Add "Bug 46230 - EDITING: impossible to perform a drag & drop of entire
row/column", that's really annoying if you are used to work with those edit
functions.

-- 
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: what's with the linking warnings? (alias: [EasyHack] duplicate linked objects)

[Bjoern Michaelsen]

Hi Noel,

On Mon, Mar 12, 2012 at 11:10:20AM +0200, Noel Grandin wrote:
> I'm curious - what's with the linking warnings:
> [ WARN   ] !!!
> [ WARN   ] !!! smoketest/smoketest is linked in by
> Library/libsmoketest.so CppunitTest/libtest_smoketest.so
> [ WARN   ] !!!
> 
> They seem to have been there for as long as I've been building
> LibreOffice (the last 4 months) - are they indicative of an actual
> problem?

They are do not have to be a deadly problem, but they can introduce very hard
to debug problems. As we set stuff like compile flags and include paths on the
linktarget (aka the library) and in the above case the object file is linked in
by two libraries, the flags it is compiled with are actually nondeterministic.
That is Very Bad(tm)!

So the smoketest/smoketest.cxx will either be compiled with the CFLAGS of
Library/libsmoketest.so or with those of CppunitTest/libtest_smoketest.so --
actually it can be compiled different on different machines with the same code.
It can even be compiled different on the same machine! So again: This is Very
Bad(tm) and we should probably never ever have let that happen.

Now it might be possible that the one doing the initial migration carefully
checked that both libs are compiled exactly the same on all platforms (I highly
doubt that), but even then this totally unproof against future changes. Someone
might innocently add a define to the compile flags of one library and create a
terribly hard to reproduce heisenbug.

So this has to go, it should never have been there in the first place. How can
this be removed? There are two possibilities:
a) create a smoketest/smoketest_libtest_smoketest.cxx with this content:

#include "smoketest.cxx"

   and then use that file instead of smoketest/smoketest.cxx in
   CppunitTest/libtest_smoketest. That way, the object gets build twice (with
   possibly different flags and defines) and everything is fine.
   Ugly, but does the job.
b) create a static library smoketest and add the smoketest/smoketest.cxx to it.
   Now instead link that static library into both of the dynamic ones and
   everything is fine.

I just created a EasyHack for this:

 https://bugs.freedesktop.org/show_bug.cgi?id=47246

Best,

Bjoern
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Exporting templates on Windows (Re: [Libreoffice-commits] .: 7 commits - clucene/patches clucene/source configure.in cppuhelper/inc hwpfilter/source sal/inc solenv/gbuild vbahelper/inc)

[Stephan Bergmann]

On 03/12/2012 07:24 PM, Lubos Lunak wrote:

On Monday 12 of March 2012, Stephan Bergmann wrote:

On 03/12/2012 03:09 PM, Lubos Lunak wrote:

(also look e.g. at STL headers, which export the entire std namespace,


Not sure what you mean here.  At least with Fedora GCC 4.6, (all-inline)
std class templates are not visibility-attributed (so would cause the
problems discussed at  if
client code derived from them).


  Almost all STL headers here (4.6) have "namespace std
_GLIBCXX_VISIBILITY(default) {" somewhere near the top.


Ah, right.  Had failed to note that.

Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Remove unused code in dptabres

[Santiago Martinez]

This patch removes unused code as listed in unusedcode.easy
From 2552218909dbee683a87c3052d1c4dd85b4a58fe Mon Sep 17 00:00:00 2001
From: Santiago Martinez 
Date: Mon, 12 Mar 2012 19:22:44 +0100
Subject: [PATCH] Remove unused code in dptabres

---
 sc/inc/dptabres.hxx  |3 ---
 sc/source/core/data/dptabres.cxx |   18 --
 unusedcode.easy  |2 --
 3 files changed, 0 insertions(+), 23 deletions(-)

diff --git a/sc/inc/dptabres.hxx b/sc/inc/dptabres.hxx
index bfdef7f..36ed4ac 100644
--- a/sc/inc/dptabres.hxx
+++ b/sc/inc/dptabres.hxx
@@ -83,7 +83,6 @@ public:
 longGetCount() const{ return nCount; }
 const long* GetSource() const   { return pIndex; }
 const SCROW* GetNameIds() const{ return pData; }
-SCROW   GetNameIdForIndex( long nIndexValue ) const;
 };
 
 typedef ::std::vector ScMemberSortOrder;
@@ -337,8 +336,6 @@ public:
 boolIsBaseForGroup( long nDim ) const;  // any group
 longGetGroupBase( long nGroupDim ) const;
 boolIsNumOrDateGroup( long nDim ) const;
-boolIsInGroup( const ScDPItemData& rGroupData, long nGroupIndex,
-   long nBaseDataId, long nBaseIndex ) const;
 boolIsInGroup( SCROW nGroupDataId, long nGroupIndex,
const ScDPItemData& rBaseData, long nBaseIndex ) const;
 boolHasCommonElement( SCROW nFirstDataId, long nFirstIndex,
diff --git a/sc/source/core/data/dptabres.cxx b/sc/source/core/data/dptabres.cxx
index 3372d68..8db141e 100644
--- a/sc/source/core/data/dptabres.cxx
+++ b/sc/source/core/data/dptabres.cxx
@@ -279,15 +279,6 @@ void ScDPInitState::RemoveMember()
 --nCount;
 }
 
-SCROW ScDPInitState::GetNameIdForIndex( long nIndexValue ) const
-{
-for (long i=0; iGetData()->IsNumOrDateGroup( nDim );
 }
 
-bool ScDPResultData::IsInGroup( const ScDPItemData& rGroupData, long nGroupIndex,
-long nBaseDataId, long nBaseIndex ) const
-{
-const ScDPItemData* pData = pSource->GetItemDataById( nGroupIndex , nBaseDataId);
-if ( pData )
- return pSource->GetData()->IsInGroup( rGroupData, nGroupIndex, *pData , nBaseIndex );
-else
-return false;
-}
 bool ScDPResultData::IsInGroup( SCROW nGroupDataId, long nGroupIndex,
 const ScDPItemData& rBaseData, long nBaseIndex ) const
 {
diff --git a/unusedcode.easy b/unusedcode.easy
index ecc821d..e1067ed 100755
--- a/unusedcode.easy
+++ b/unusedcode.easy
@@ -72,11 +72,9 @@ ScConditionalFormats_Impl::Remove(unsigned short, unsigned short)
 ScCsvControl::ScCsvControl(Window*, ScCsvLayoutData const&, long)
 ScDBCollection::AnonDBs::erase(boost::void_ptr_iterator<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >, ScDBData>)
 ScDBCollection::AnonDBs::size() const
-ScDPInitState::GetNameIdForIndex(long) const
 ScDPItemData::ScDPItemData(double)
 ScDPItemData::SetGroupValue(int, int)
 ScDPLabelData::ScDPLabelData(rtl::OUString const&, short, bool)
-ScDPResultData::IsInGroup(ScDPItemData const&, long, long, long) const
 ScDocRowHeightUpdater::TabRanges::TabRanges()
 ScFilterDetect::impl_createFactory(com::sun::star::uno::Reference const&)
 ScHTMLColOffset::Insert(ScHTMLColOffset const*, unsigned short, unsigned short)
-- 
1.7.7.6

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Exporting templates on Windows (Re: [Libreoffice-commits] .: 7 commits - clucene/patches clucene/source configure.in cppuhelper/inc hwpfilter/source sal/inc solenv/gbuild vbahelper/inc)

[Lubos Lunak]

On Monday 12 of March 2012, Stephan Bergmann wrote:
> On 03/12/2012 03:09 PM, Lubos Lunak wrote:
...

> Looks like a misunderstanding whether hidden visibility is intended for
> "remove unnecessary entries from dynamic symbol tables (but keeping
> certain symbols exported to not violate certain standard requirements)"
> or "allow violations of ODR by hiding classes completely from dynamic
> symbol tables."  I had naively assumed the former, while compiler
> writers apparently use the latter interpretation.

 Yes, I don't remember ever having seen the former interpretation. I've always 
seen hidden visibility as "is never used outside of the .so".

> > So in general I think templates need to be exported
>
> I guess general reluctance against that insight in LO stems from LO
> being cross-platform, and the Windows dllimport/export model being
> substantially different from the GCC/ELF visibility model, and not
> marking (all-inline) templates for neither dllimport/export nor default
> visibility was the only approach that did work across all compilers,
> MSVC, GCC, and Sun.  (If only worked sort of, see Michael's link to
> try/why_some_compilers_suck_more>.)

 I've already pushed the new macro that uses default visibility on ELF and 
nothing elsewhere (not sure about MacOSX, but since it's apparently worked 
well there so far, I've kept it as empty too).

> > (also look e.g. at STL headers, which export the entire std namespace,
>
> Not sure what you mean here.  At least with Fedora GCC 4.6, (all-inline)
> std class templates are not visibility-attributed (so would cause the
> problems discussed at  if
> client code derived from them).

 Almost all STL headers here (4.6) have "namespace std 
_GLIBCXX_VISIBILITY(default) {" somewhere near the top.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Exporting templates on Windows (Re: [Libreoffice-commits] .: 7 commits - clucene/patches clucene/source configure.in cppuhelper/inc hwpfilter/source sal/inc solenv/gbuild vbahelper/inc)

[Stephan Bergmann]

On 03/12/2012 07:15 PM, Lubos Lunak wrote:

  Based on this, I'm fairly certain SAL_DLLPUBLIC_TEMPLATE is the proper fix,
making the template visible on Linux etc., but not doing any dllimport tricks
on Windows. Committed.


FWIW, I came to that conclusion now, too.

Stephan

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED][PATCH] Convert SV_DECL_VARARR_SORT and SV_IMPL_VARARR_SORT with std::set

[Bartosz]

Hi,
This and later contributions is licensed under MPL 1.1 / GPL v3+ / LGPL v3+.

Best Regards
Bartosz Kosiorek

W dniu 12 marca 2012 13:04 użytkownik Ivan Timofeev
napisał:

> Hi Bartosz,
>
>
> On 11.03.2012 01:29, Bartosz wrote:
>
>> I updates the patch.
>> Could you please push it to libreoffice?
>>
>
> Surely! Pushed: http://cgit.freedesktop.org/**libreoffice/core/commit/?id=
> **f2d0fcc26be481c2f872056fb3b840**2169d124d8
>
> But I cannot find your license statement.
>
> Thanks,
> Ivan
> __**_
> 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: Exporting templates on Windows (Re: [Libreoffice-commits] .: 7 commits - clucene/patches clucene/source configure.in cppuhelper/inc hwpfilter/source sal/inc solenv/gbuild vbahelper/inc)

[Lubos Lunak]

On Monday 12 of March 2012, Michael Stahl wrote:
> On 12/03/12 15:09, Lubos Lunak wrote:
> >  Windows/MSVC experts
...
> applying logic to how C++ features interact with linkers on various
> platforms is generally a futile endeavour.

 Works fine for me :).

> >  Assuming that this commit really breaks it on MSVC and the proper change
> > there is to remove the DLLPUBLIC from the template and hope the compiler
> > and linker sort it out somehow, then I guess we'll need to add
> > SAL_TEMPLATE_DLLPUBLIC which does nothing with MSVC and the right thing
> > with gcc/clang.
>
> Voreppe tinderbox is already complaining rather loudly...
>
> >  MSDN article on the dllimport/dllexport flags feels like it doesn't
> > actually say anything, but reading
> > http://support.microsoft.com/kb/132044/en-us makes me think the flags are
> > just optimizations, so nothing will break. But according to it
> > SAL_TEMPLATE_DLLPUBLIC would be the right thing.
>
> i recommend the following to understand the mess you got yourself into
> (link to archive.org because original has been purged):
>
> http://web.archive.org/web/20100504161204/http://blogs.sun.com/GullFOSS/ent
>ry/why_some_compilers_suck_more

 Based on this, I'm fairly certain SAL_DLLPUBLIC_TEMPLATE is the proper fix, 
making the template visible on Linux etc., but not doing any dllimport tricks 
on Windows. Committed.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Remove unused code

[Santiago Martinez]

This patch removes unused code as listed in unusedcode.easy
From 1d2ad5f05d4b415df6ff636c7f62c9ba1ea4a1bf Mon Sep 17 00:00:00 2001
From: Santiago Martinez 
Date: Mon, 12 Mar 2012 19:04:03 +0100
Subject: [PATCH] Remove unused code in dpcache

---
 sc/inc/dpcache.hxx  |3 ---
 sc/source/core/data/dpcache.cxx |   32 
 unusedcode.easy |3 ---
 3 files changed, 0 insertions(+), 38 deletions(-)

diff --git a/sc/inc/dpcache.hxx b/sc/inc/dpcache.hxx
index 9f33db5..8ece780 100644
--- a/sc/inc/dpcache.hxx
+++ b/sc/inc/dpcache.hxx
@@ -136,9 +136,7 @@ public:
 long AppendGroupField();
 void ResetGroupItems(long nDim, const ScDPNumGroupInfo& rNumInfo);
 SCROW SetGroupItem(long nDim, const ScDPItemData& rData);
-const DataListType* GetGroupDimMemberValues(long nDim) const;
 void GetGroupDimMemberIds(long nDim, std::vector& rIds) const;
-void ClearGroupFields();
 
 SCCOL GetDimensionIndex(const rtl::OUString& sName) const;
 sal_uLong GetNumberFormat( long nDim ) const;
@@ -158,7 +156,6 @@ public:
 
 ScDocument* GetDoc() const;
 long GetColumnCount() const;
-long GetGroupFieldCount() const;
 
 const ScDPItemData* GetItemDataById( long nDim, SCROW nId ) const;
 
diff --git a/sc/source/core/data/dpcache.cxx b/sc/source/core/data/dpcache.cxx
index 9ce9e25..a4705b4 100644
--- a/sc/source/core/data/dpcache.cxx
+++ b/sc/source/core/data/dpcache.cxx
@@ -1013,27 +1013,6 @@ SCROW ScDPCache::SetGroupItem(long nDim, const ScDPItemData& rData)
 return -1;
 }
 
-const ScDPCache::DataListType* ScDPCache::GetGroupDimMemberValues(long nDim) const
-{
-if (nDim < 0)
-return NULL;
-
-long nSourceCount = static_cast(maFields.size());
-if (nDim < nSourceCount)
-{
-if (!maFields.at(nDim).mpGroup)
-return NULL;
-
-return &maFields[nDim].mpGroup->maItems;
-}
-
-nDim -= nSourceCount;
-if (nDim < static_cast(maGroupFields.size()))
-return &maGroupFields.at(nDim).maItems;
-
-return NULL;
-}
-
 void ScDPCache::GetGroupDimMemberIds(long nDim, std::vector& rIds) const
 {
 if (nDim < 0)
@@ -1074,12 +1053,6 @@ struct ClearGroupItems : std::unary_function
 
 }
 
-void ScDPCache::ClearGroupFields()
-{
-maGroupFields.clear();
-std::for_each(maFields.begin(), maFields.end(), ClearGroupItems());
-}
-
 SCROW ScDPCache::GetOrder(long nDim, SCROW nIndex) const
 {
 OSL_ENSURE( nDim >=0 && nDim < mnColumnCount, "ScDPTableDataCache::GetOrder : out of bound" );
@@ -1110,9 +1083,4 @@ long ScDPCache::GetColumnCount() const
 return mnColumnCount;
 }
 
-long ScDPCache::GetGroupFieldCount() const
-{
-return maGroupFields.size();
-}
-
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/unusedcode.easy b/unusedcode.easy
index b591d6a..ecc821d 100755
--- a/unusedcode.easy
+++ b/unusedcode.easy
@@ -72,9 +72,6 @@ ScConditionalFormats_Impl::Remove(unsigned short, unsigned short)
 ScCsvControl::ScCsvControl(Window*, ScCsvLayoutData const&, long)
 ScDBCollection::AnonDBs::erase(boost::void_ptr_iterator<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > >, ScDBData>)
 ScDBCollection::AnonDBs::size() const
-ScDPCache::ClearGroupFields()
-ScDPCache::GetGroupDimMemberValues(long) const
-ScDPCache::GetGroupFieldCount() const
 ScDPInitState::GetNameIdForIndex(long) const
 ScDPItemData::ScDPItemData(double)
 ScDPItemData::SetGroupValue(int, int)
-- 
1.7.7.6

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Exporting templates on Windows (Re: [Libreoffice-commits] .: 7 commits - clucene/patches clucene/source configure.in cppuhelper/inc hwpfilter/source sal/inc solenv/gbuild vbahelper/inc)

[Stephan Bergmann]

On 03/12/2012 03:09 PM, Lubos Lunak wrote:

Does this workaround for


...should have been  "no 
code emitted for virtual inline function inherited indirectly from class 
template"



(where I'm still not convinced it is a user error vs. a compiler error)


  I am rather convinced that the original issue
(without -fvisibility-inlines-hidden) is a user error, so I consider this to
be a proper fix rather than a workaround.

  Imagine for example that the template has a static data member - that one
would need to be merged to be just in one place, and that just wouldn't work
if the template was public API but hidden.


I see no fundamental reason why that should not work.  I would argue 
that the compiler could still export that symbol with some form of vague 
linkage, as it does if the template is not hidden.  But I just see that 
GCC does not do that, and even somewhat specifies that it does not do 
that ("type visibility is applied to vague linkage entities associated 
with the class", 
 
in combination with "Most everything in this section [on vague linkage] 
also applies to template instantiations" 
).


Looks like a misunderstanding whether hidden visibility is intended for 
"remove unnecessary entries from dynamic symbol tables (but keeping 
certain symbols exported to not violate certain standard requirements)" 
or "allow violations of ODR by hiding classes completely from dynamic 
symbol tables."  I had naively assumed the former, while compiler 
writers apparently use the latter interpretation.



So in general I think templates need to be exported


I guess general reluctance against that insight in LO stems from LO 
being cross-platform, and the Windows dllimport/export model being 
substantially different from the GCC/ELF visibility model, and not 
marking (all-inline) templates for neither dllimport/export nor default 
visibility was the only approach that did work across all compilers, 
MSVC, GCC, and Sun.  (If only worked sort of, see Michael's link to 
.)



(also look e.g. at STL headers, which export the entire std namespace,


Not sure what you mean here.  At least with Fedora GCC 4.6, (all-inline) 
std class templates are not visibility-attributed (so would cause the 
problems discussed at  if 
client code derived from them).


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: what's with the linking warnings?

[Michael Stahl]

On 12/03/12 10:10, Noel Grandin wrote:
> Hi
> 
> I'm curious - what's with the linking warnings:
>  [ WARN   ] !!!
>  [ WARN   ] !!! smoketest/smoketest is linked in by 
> Library/libsmoketest.so CppunitTest/libtest_smoketest.so
>  [ WARN   ] !!!
> 
> They seem to have been there for as long as I've been building 
> LibreOffice (the last 4 months) - are they indicative of an actual problem?

yes, that kind of thing only works "by accident", depending on whether
the library that happens to propagate its flags to the object file
happens to have flags that also work for the other library.  apparently
people think it's not a problem, given the ever rising number of these
warnings... i've now fixed the ones that occur with my configuration,
which required adding a couple more static libraries...

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

License statement

[David Bolen]

I confirm that all of my past and future contributions to the
LibreOffice project are licensed under the MPL / LGPLv3+.

-- David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW][3-5] Re: Two Python 2.x regressions in LibreOffice 3.5.1RC1

[David Bolen]

Michael Stahl  writes:

> thanks for bringing these regressions to this list; in my experience
> usually QA people aren't very fond of looking at API issues.

Thanks for committing the patches (plus handling the regression introduced
by the proposed patch in fdo#46926).

> unfortunately it's probably too late for 3.5.1 now, but 3.5.2 is just
> some weeks away.

Looks like they've just been pulled into 3-5 so looks good.

> 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 :)

Not sure how I missed mentioning that (I know I intended to), so
thanks for looking at the bugs even without knowing patches were
included.

> 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

Sorry for the delay on this part, as I've been offline a bit.  I'll
cover this shortly.

-- David

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: Issue with vcl Text Control

[Dézsi Szabolcs]

> So basically my question is, is there a way to wrap text on a FixedText,
> or make the background on a MultiLinEdit transparent (or is there a
> better text control I can use?)
>


Hi!


Use SetPaintTransparent( sal_True );
If I remember correctly :)


Szabolcs
  ___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Issue with vcl Text Control

[Andrew Higginson]

Hi,

In the about dialog I am working on, I have some text which needs to
wrap over 2 or more lines.

The control is a vcl::FixedText, however the issue is that this control
(AFAIK) cannot wrap text.

I have tried to therefore use a MultiLineEdit
(svtools/inc/svtools/svmedit.hxx) however the issue with this is that
the text always has a white background - I need the control to have a
transparent background, something I can do with a FixedText with

aFixedText.SetBackground();

So basically my question is, is there a way to wrap text on a FixedText,
or make the background on a MultiLinEdit transparent (or is there a
better text control I can use?)

Thanks

--
Andrew
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH]fdo 45671 split button for calc cell border colour

[Winfried Donkers]

Attached another 'old style button' to split button conversion.

More t o follow.

WinfriedFrom 507666e87408959a327e6364c26957195830273c Mon Sep 17 00:00:00 2001
From: Winfried Donkers 
Date: Mon, 12 Mar 2012 17:25:26 +0100
Subject: [PATCH] fdo#45671 split button for calc cell border color

---
 sc/source/ui/app/scdll.cxx |2 +-
 svx/inc/svx/tbcontrl.hxx   |3 +++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/sc/source/ui/app/scdll.cxx b/sc/source/ui/app/scdll.cxx
index ece5a1f..25712d4 100644
--- a/sc/source/ui/app/scdll.cxx
+++ b/sc/source/ui/app/scdll.cxx
@@ -207,7 +207,7 @@ void ScDLL::Init()
 SvxColorExtToolBoxControl   ::RegisterControl(SID_BACKGROUND_COLOR, pMod);
 SvxFrameToolBoxControl  ::RegisterControl(SID_ATTR_BORDER,  pMod);
 SvxFrameLineStyleToolBoxControl ::RegisterControl(SID_FRAME_LINESTYLE,  pMod);
-SvxFrameLineColorToolBoxControl ::RegisterControl(SID_FRAME_LINECOLOR,  pMod);
+SvxColorExtToolBoxControl   ::RegisterControl(SID_FRAME_LINECOLOR,  pMod);
 SvxClipBoardControl ::RegisterControl(SID_PASTE,pMod );
 SvxUndoRedoControl  ::RegisterControl(SID_UNDO, pMod );
 SvxUndoRedoControl  ::RegisterControl(SID_REDO, pMod );
diff --git a/svx/inc/svx/tbcontrl.hxx b/svx/inc/svx/tbcontrl.hxx
index 8fb558e..7cc2479 100644
--- a/svx/inc/svx/tbcontrl.hxx
+++ b/svx/inc/svx/tbcontrl.hxx
@@ -87,6 +87,9 @@
 for  cell background color (calc)
 Execute-Id  SID_ATTR_CHAR_COLOR_BACKGROUND
 
+for table/cell border color (writer, calc)
+Execute-Id  SID_FRAME_LINECOLOR
+
 SvxColorToolBoxControl
 
 Item type:  SvxBrushItem
-- 
1.7.7

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW] b68f06287d34833a59841b8000641a02d0994eb8: Iterator crash in writerfilter/source/ooxml/OOXMLPropertySetImpl.cxx

[Petr Mladek]

Tor Lillqvist píše v Po 12. 03. 2012 v 15:37 +0200:
> http://cgit.freedesktop.org/libreoffice/core/patch/?id=b68f06287d34833a59841b8000641a02d0994eb8
> . The added comment should give an idea what it's about.

It most likely fixes the problematic
https://bugs.freedesktop.org/show_bug.cgi?id=36982


Best Regards,
Petr

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] .: 17 commits - basctl/source chart2/source dbaccess/source desktop/source framework/source idl/source sal/CppunitTest_sal_rtl_strings.mk sal/inc sal/qa sal/rtl sal/util star

[Lubos Lunak]

On Monday 12 of March 2012, Noel Grandin wrote:
> This is generating a single failure on my build box. Visual Studio 2008.
>
> cd sal && /opt/lo/bin/make -j 15 -rs gb_PARTIALBUILD=T
> [ build CXX ] sal/qa/rtl/strings/test_ostring_stringliterals.cxx
> c:/LibreOffice/libo/sal/qa/rtl/strings/test_ostring_stringliterals.cxx(103)
>
> : error C2440: '' : cannot convert from 'const char
>
> []' to 'rtl::OString'
>  No constructor could take the source type, or constructor
> overload resolution was ambiguous
> [ build MOD ] sal

 Already handled, please update.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[REVIEW 3-5]: don't loose data on disk failure (fsync) fdo#40607

[Michael Meeks]

On Mon, 2012-03-12 at 09:43 +0100, Stephan Bergmann wrote:
> As discussed on IRC, the patch breaks smoketest/adding extensions (and 
> my attempt at a quick fix was futile).

Ah yes - it turns out that:

-::ucbhelper::Content ucbStamp( stampURL, xCmdEnv );
-::rtl::OString stamp(
-RTL_CONSTASCII_STRINGPARAM(CURRENT_STAMP) );
-Reference xData(
-::xmlscript::createInputStream(
-::rtl::ByteSequence(
-reinterpret_cast(stamp.getStr()),
-stamp.getLength() ) ) );

Creates a parent directory if it is not present, something not entirely
obvious when reading it ;-) Fixed on master.

I attach a unified patch:

fdo#40607 - osl_syncFile having written, and avoid doing that on start

Thanks,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot
diff --git a/desktop/source/deployment/manager/dp_manager.cxx b/desktop/source/deployment/manager/dp_manager.cxx
index 4f6f6c04..80a9522 100644
--- a/desktop/source/deployment/manager/dp_manager.cxx
+++ b/desktop/source/deployment/manager/dp_manager.cxx
@@ -32,6 +32,7 @@
 #include "dp_platform.hxx"
 #include "dp_manager.h"
 #include "dp_identifier.hxx"
+#include "rtl/oustringostreaminserter.hxx"
 #include "rtl/ustrbuf.hxx"
 #include "rtl/string.hxx"
 #include "rtl/uri.hxx"
@@ -311,6 +312,41 @@ void PackageManagerImpl::initRegistryBackends()
  m_xComponentContext ) );
 }
 
+// this overcomes previous rumours that the sal API is misleading
+// as to whether a directory is truly read-only or not
+static bool isMacroURLReadOnly( const OUString &rMacro )
+{
+rtl::OUString aDirURL( rMacro );
+::rtl::Bootstrap::expandMacros( aDirURL );
+
+::osl::FileBase::RC aErr = ::osl::Directory::create( aDirURL );
+if ( aErr == ::osl::FileBase::E_None )
+return false; // it will be writeable
+if ( aErr != ::osl::FileBase::E_EXIST )
+return true; // some serious problem creating it
+
+bool bError;
+sal_uInt64 nWritten = 0;
+rtl::OUString aFileURL( aDirURL + "/stamp.sys" );
+::osl::File aFile( aFileURL );
+
+bError = aFile.open( osl_File_OpenFlag_Read |
+ osl_File_OpenFlag_Write |
+ osl_File_OpenFlag_Create ) != ::osl::FileBase::E_None;
+if (!bError)
+bError = aFile.write( "1", 1, nWritten ) != ::osl::FileBase::E_None;
+if (aFile.close() != ::osl::FileBase::E_None)
+bError = true;
+if (osl::File::remove( aFileURL ) != ::osl::FileBase::E_None)
+bError = true;
+
+SAL_INFO(
+"desktop.deployment",
+"local url '" << rMacro << "' -> '" << aFileURL << "' "
+<< (bError ? "is" : "is not") << " readonly\n");
+return bError;
+}
+
 //__
 Reference PackageManagerImpl::create(
 Reference const & xComponentContext,
@@ -320,7 +356,7 @@ Reference PackageManagerImpl::create(
 xComponentContext, context );
 Reference xPackageManager( that );
 
-OUString packages, logFile, stampURL;
+OUString packages, logFile, stamp;
 if (context.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM("user") )) {
 that->m_activePackages = OUSTR(
 "vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages");
@@ -341,8 +377,7 @@ Reference PackageManagerImpl::create(
 //using virtualization it appears that he/she can. Then a shared extension can
 //be installed but is only visible for the user (because the extension is in
 //the virtual store).
-stampURL = OUSTR(
-"vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/stamp.sys");
+stamp = OUSTR("$UNO_USER_PACKAGES_CACHE");
 }
 else if (context.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM("shared") )) {
 that->m_activePackages = OUSTR(
@@ -353,8 +388,7 @@ Reference PackageManagerImpl::create(
 "vnd.sun.star.expand:$SHARED_EXTENSIONS_USER/registry");
 logFile = OUSTR(
 "vnd.sun.star.expand:$SHARED_EXTENSIONS_USER/log.txt");
-stampURL = OUSTR(
-"vnd.sun.star.expand:$UNO_SHARED_PACKAGES_CACHE/stamp.sys");
+stamp = OUSTR("$UNO_SHARED_PACKAGES_CACHE");
 }
 else if (context.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM("bundled") )) {
 that->m_activePackages = OUSTR(
@@ -393,8 +427,7 @@ Reference PackageManagerImpl::create(
 "vnd.sun.star.expand:$TMP_EXTENSIONS");
 that->m_registryCache = OUSTR(
 "vnd.sun.star.expand:$TMP_EXTENSIONS/registry");
-stampURL = OUSTR(
-"vnd.sun.star.expand:$TMP_EXTENSIONS/stamp.sys");
+stamp = OUSTR("$TMP_EXTENSIONS");
 }
 else if (! context.matchAsciiL(
  RTL_CONSTASCII_STRINGPARAM("vnd.sun.star.tdoc:/") )) {
@@ -

Re: [PATCH] fdo#46728: EDITING: soffice.bin crashed with SIGSEGV in Window::GetCursor()

[Thorsten Behrens]

Caolan McNamara wrote:
> The line "pCandidate->Update();" in overlaymanagerbuffered.cxx:376
> triggers a series of events that deletes the overlaymanager who's
> ImpBufferTimerHandler is still executing, i.e. "this" is destroyed.
> 
> We get lucky sometimes because sometimes the drawing happens while the
> flashing text cursor is not-drawn state when we enter. 
> 
> In the absence of alternative ideas, we could try and work some
> reference count stuff in there. Even with pulling the window/cursor info
> out while reference is still valid before this gets deleted, there's
> still use of some members at the end of the method which are equally
> broken :-(
> 
Yeah. Another (though ugly) solution is to use those
Application::PostUserEvent() kludges to get this call
asynchronously...

Cheers,

-- Thorsten


pgpBfJIDQIBEO.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [RESOLVED] 3.5 installer problem, some registry items missing

[Noel Power]

On 12/03/12 14:15, Caolán McNamara wrote:

Now I just set the ENABLE_RELEASE_BUILD to true before building the
install to get the old normal non-parallel build msi installer that
does the right thing
I would say "does the right thing" for me. I'm not a typical user and 
removing and/or upgrading the currently installed LO with a potentially 
unstable developer version is part of my workflow :-) I don't want to 
have to deal with the limitations that the ( no doubt useful especially 
for qa volunteers ) parallel installable version brings me


Noel

ps. the magic registration command is msiexec /i LibODev.msi 
WRITE_REGISTRY=1 ( thanks to Andras ) ( ref fdo#46498 )

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Exporting templates on Windows (Re: [Libreoffice-commits] .: 7 commits - clucene/patches clucene/source configure.in cppuhelper/inc hwpfilter/source sal/inc solenv/gbuild vbahelper/inc)

[Michael Stahl]

On 12/03/12 15:09, Lubos Lunak wrote:
> 
>  Windows/MSVC experts
> 
> On Monday 12 of March 2012, Stephan Bergmann wrote:
>> On 03/10/2012 04:39 PM, Lubos Lunak wrote:
>>> commit 34f8495dd948e2ad9d64c2c19110e69840cefd1a
>>> Author: Luboš Luňák
>>> Date:   Sat Mar 10 15:37:02 2012 +0100
>>>
>>>  exported templates need to be marked as such
>>>
>>>  Otherwise their instances created in other modules may end up
>>>  as non-exported even when used by something exported.
>>>
>>> diff --git a/cppuhelper/inc/cppuhelper/compbase.hxx
>>> b/cppuhelper/inc/cppuhelper/compbase.hxx index 60e99ee..e590412 100644
>>> --- a/cppuhelper/inc/cppuhelper/compbase.hxx
>>> +++ b/cppuhelper/inc/cppuhelper/compbase.hxx
>>> @@ -41,7 +41,7 @@
>>>   namespace cppu \
>>>   { \
>>>   template<  __CLASS_IFC##N>  \
>>> -class SAL_NO_VTABLE WeakComponentImplHelper##N \
>>> +class SAL_NO_VTABLE CPPUHELPER_DLLPUBLIC WeakComponentImplHelper##N \
>>>
>>>   : public ::cppu::WeakComponentImplHelperBase \
>>>
>>>   , public ImplHelperBase##N<  __IFC##N>  \
>>>   { \
>>
>> Does this workaround for 
>> (where I'm still not convinced it is a user error vs. a compiler error)
> 
>  I am rather convinced that the original issue 
> (without -fvisibility-inlines-hidden) is a user error, so I consider this to 
> be a proper fix rather than a workaround.
> 
>  Imagine for example that the template has a static data member - that one 
> would need to be merged to be just in one place, and that just wouldn't work 
> if the template was public API but hidden. So in general I think templates 
> need to be exported (also look e.g. at STL headers, which export the entire 
> std namespace, although I can see that Qt templates don't).
> 
>> work well with MSVC?  I wonder because there all consumers of the
>> template (outside of cppuhelper) will see it as __declspec(dllimport),
>> and (as long as there is no instantiation in cppuhelper) there is no
>> place that would emit it as __declspec(dllexport).
> 
>  I don't know about MSVC. Meaning that I haven't tried and I don't know how 
> export/import works on Windows anyway.

>  But it doesn't make much sense to me. It is not actually the template itself 
> that is or is not exported, because that's just a compile-time concept, but 
> it's instances of it as binary concept that are exported. And how does 
> something know whether some other library does or does not contain Foo< int > 
> without actually looking?

applying logic to how C++ features interact with linkers on various
platforms is generally a futile endeavour.

>  Assuming that this commit really breaks it on MSVC and the proper change 
> there is to remove the DLLPUBLIC from the template and hope the compiler and 
> linker sort it out somehow, then I guess we'll need to add 
> SAL_TEMPLATE_DLLPUBLIC which does nothing with MSVC and the right thing with 
> gcc/clang.

Voreppe tinderbox is already complaining rather loudly...

>  MSDN article on the dllimport/dllexport flags feels like it doesn't actually 
> say anything, but reading http://support.microsoft.com/kb/132044/en-us makes 
> me think the flags are just optimizations, so nothing will break. But 
> according to it SAL_TEMPLATE_DLLPUBLIC would be the right thing.

i recommend the following to understand the mess you got yourself into
(link to archive.org because original has been purged):

http://web.archive.org/web/20100504161204/http://blogs.sun.com/GullFOSS/entry/why_some_compilers_suck_more

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [RESOLVED] 3.5 installer problem, some registry items missing

[Caolán McNamara]

On Thu, 2012-02-23 at 10:25 +, Noel Power wrote:
> I suspect there is something very simple going on here, perhaps to do 
> with the lodev vrs lo ? ( so maybe this doesn't affect the release at all )

FWIW, Noel said...

It is purely a dev build issue and it appear it is intentional, it
seems windows dev-build is supposed to be parallel installable and in
this case it would make no sense for the install to re-register the
active x object activation against the dev install soffice.exe ( or bin
or whatever.

There is some command one can issue to the msi thingy to make it do the
registration ( not sure whether the un-installer though will clean up
properly in that case )

Now I just set the ENABLE_RELEASE_BUILD to true before building the
install to get the old normal non-parallel build msi installer that
does the right thing

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] translate german comments

[Nicolas Christener]

Hi :)

Attached is one more German->English comment translation patch.

Review much appreciated.

Kind regards
nicolas
>From a67c8fb99d0006664b1583bc11258a147ce90f0b Mon Sep 17 00:00:00 2001
From: Nicolas Christener 
Date: Thu, 8 Mar 2012 20:37:40 +0100
Subject: [PATCH] translate german comments

---
 sw/source/core/layout/tabfrm.cxx |  322 ++
 1 files changed, 153 insertions(+), 169 deletions(-)

diff --git a/sw/source/core/layout/tabfrm.cxx b/sw/source/core/layout/tabfrm.cxx
index 95eceb8..40c949f 100644
--- a/sw/source/core/layout/tabfrm.cxx
+++ b/sw/source/core/layout/tabfrm.cxx
@@ -96,10 +96,10 @@ SwTabFrm::SwTabFrm( SwTable &rTab, SwFrm* pSib ):
 // #i26945#
 bConsiderObjsForMinCellHeight = sal_True;
 bObjsDoesFit = sal_True;
-bFixSize = sal_False; //Nicht nochmal auf die Importfilter hereinfallen.
+bFixSize = sal_False; //Don't fall for import filter again.
 nType = FRMC_TAB;
 
-//Gleich die Zeilen erzeugen und einfuegen.
+//Create the lines and insert them.
 const SwTableLines &rLines = rTab.GetTabLines();
 SwFrm *pTmpPrev = 0;
 for ( sal_uInt16 i = 0; i < rLines.Count(); ++i )
@@ -127,7 +127,7 @@ SwTabFrm::SwTabFrm( SwTabFrm &rTab ) :
 // #i26945#
 bConsiderObjsForMinCellHeight = sal_True;
 bObjsDoesFit = sal_True;
-bFixSize = sal_False; //Nicht nochmal auf die Importfilter hereinfallen.
+bFixSize = sal_False; //Don't fall for import filter again.
 nType = FRMC_TAB;
 
 SetFollow( rTab.GetFollow() );
@@ -180,7 +180,7 @@ void SwTabFrm::JoinAndDelFollows()
 |*/
 void SwTabFrm::RegistFlys()
 {
-OSL_ENSURE( Lower() && Lower()->IsRowFrm(), "Keine Zeilen." );
+OSL_ENSURE( Lower() && Lower()->IsRowFrm(), "No rows." );
 
 SwPageFrm *pPage = FindPageFrm();
 if ( pPage )
@@ -432,7 +432,7 @@ void lcl_MoveRowContent( SwRowFrm& rSourceLine, SwRowFrm& rDestLine )
 while ( pTmpDestRow->GetNext() )
 pTmpDestRow = (SwRowFrm*)pTmpDestRow->GetNext();
 
-OSL_ENSURE( pTmpDestRow->GetFollowRow() == pTmpSourceRow, "Knoten in der Tabelle" );
+OSL_ENSURE( pTmpDestRow->GetFollowRow() == pTmpSourceRow, "Table contains node" );
 
 lcl_MoveRowContent( *pTmpSourceRow, *pTmpDestRow );
 pTmpDestRow->SetFollowRow( pTmpSourceRow->GetFollowRow() );
@@ -996,9 +996,9 @@ bool SwTabFrm::Split( const SwTwips nCutPos, bool bTryToSplit, bool bTableRowKee
 lcl_InnerCalcLayout( this->Lower(), LONG_MAX, true );
 }
 
-//Um die Positionen der Zellen mit der CutPos zu vergleichen muessen sie
-//ausgehend von der Tabelle nacheinander berechnet werden. Sie koennen
-//wg. Positionsaenderungen der Tabelle durchaus ungueltig sein.
+//In order to be able to compare the positions of the cells whit CutPos,
+//they have to be calculated consecutively starting from the table.
+//They can definitely be invalid because of position changes of the table.
 SwRowFrm *pRow = static_cast(Lower());
 if( !pRow )
 return bRet;
@@ -1268,9 +1268,9 @@ bool SwTabFrm::Split( const SwTwips nCutPos, bool bTryToSplit, bool bTableRowKee
 
 SwTwips nRet = 0;
 
-//Optimierung beim neuen Follow braucht's kein Paste und dann kann
-//das Optimierte Insert verwendet werden (nur dann treten gluecklicher weise
-//auch groessere Mengen von Rows auf).
+//Optimization: There is no paste needed for the new Follow and the
+//optimized insert can be used (big amounts of rows luckily only occurs in
+//such situations).
 if ( bNewFollow )
 {
 SwFrm* pNxt = 0;
@@ -1344,15 +1344,15 @@ bool SwTabFrm::Join()
 if ( !pFoll->IsJoinLocked() )
 {
 SWRECTFN( this )
-pFoll->Cut();   //Erst ausschneiden um unuetze Benachrichtigungen zu
-//minimieren.
+pFoll->Cut();   //Cut out first to avoid unnecessary notifications.
 
 SwFrm *pRow = pFoll->GetFirstNonHeadlineRow(),
   *pNxt;
 
 SwFrm* pPrv = GetLastLower();
 
-SwTwips nHeight = 0;//Gesamthoehe der eingefuegten Zeilen als Return.
+SwTwips nHeight = 0;//Total height of the inserted rows as return value.
+
 while ( pRow )
 {
 pNxt = pRow->GetNext();
@@ -1818,14 +1818,13 @@ void SwTabFrm::MakeAll()
 
 PROTOCOL_ENTER( this, PROT_MAKEALL, 0, 0 )
 
-LockJoin(); //Ich lass mich nicht unterwegs vernichten.
-SwLayNotify aNotify( this );//uebernimmt im DTor die Benachrichtigung
+LockJoin(); //I don't want to be destroyed on the way.
+SwLayNotify aNotify( this );//does the notification in the DTor
 // If pos is invalid, we have to call a SetInvaKeep at aNotify.
 // Otherwise the keep atribute would not work in front of a table.
 const sal_Bool bOldValidPos = GetVali

[PATCH] Translate German comments in core/connectivity

[Tom Thorogood]

Translate German comments in core/connectivity

patch attached.

-Tom Thorogood
>From ae999e6851ae2969335211737bbce428a2097dcd Mon Sep 17 00:00:00 2001
From: Tom Thorogood 
Date: Fri, 9 Mar 2012 22:35:32 -0500
Subject: [PATCH] Translate german comments in core/connectivity

---
 .../source/drivers/mozab/MPreparedStatement.hxx|1 -
 .../source/inc/odbc/ODatabaseMetaDataResultSet.hxx |1 -
 connectivity/source/inc/odbc/OFunctiondefs.hxx |   23 ---
 .../source/inc/odbc/OPreparedStatement.hxx |1 -
 connectivity/source/inc/odbc/OResultSet.hxx|1 -
 .../source/inc/odbc/OResultSetMetaData.hxx |1 -
 connectivity/source/inc/odbc/OStatement.hxx|1 -
 connectivity/source/parse/sqliterator.cxx  |4 +-
 8 files changed, 12 insertions(+), 21 deletions(-)

diff --git a/connectivity/source/drivers/mozab/MPreparedStatement.hxx b/connectivity/source/drivers/mozab/MPreparedStatement.hxx
index 31cfa97..ce2344f 100644
--- a/connectivity/source/drivers/mozab/MPreparedStatement.hxx
+++ b/connectivity/source/drivers/mozab/MPreparedStatement.hxx
@@ -109,7 +109,6 @@ namespace connectivity
 
 public:
 DECLARE_SERVICE_INFO();
-// ein Konstruktor, der fuer das Returnen des Objektes benoetigt wird:
 OPreparedStatement( OConnection* _pConnection,const ::rtl::OUString& sql);
 void lateInit();
 
diff --git a/connectivity/source/inc/odbc/ODatabaseMetaDataResultSet.hxx b/connectivity/source/inc/odbc/ODatabaseMetaDataResultSet.hxx
index 7a17249..ee2af9e 100644
--- a/connectivity/source/inc/odbc/ODatabaseMetaDataResultSet.hxx
+++ b/connectivity/source/inc/odbc/ODatabaseMetaDataResultSet.hxx
@@ -128,7 +128,6 @@ namespace connectivity
 template < typename T, SQLSMALLINT sqlTypeId > T getInteger ( sal_Int32 columnIndex );
 
 public:
-// ein Konstruktor, der fuer das Returnen des Objektes benoetigt wird:
 ODatabaseMetaDataResultSet(OConnection* _pConnection);
 
 
diff --git a/connectivity/source/inc/odbc/OFunctiondefs.hxx b/connectivity/source/inc/odbc/OFunctiondefs.hxx
index a53f072..e356b64 100644
--- a/connectivity/source/inc/odbc/OFunctiondefs.hxx
+++ b/connectivity/source/inc/odbc/OFunctiondefs.hxx
@@ -64,17 +64,16 @@
 #ifdef OS2__00
 
 #ifdef ODBCIMP
-
-// Stub-Version: dynamische Bindung an die DLL zur Laufzeit.
-// odbcstub definiert die in den Quellen benutzten NSQL...-Methoden
-// als indirekte Funktionsaufrufe.
-// odbcimp zieht sich selbst preos2, odbc und postos2 an.
+// Stub version: dynamic bindings of DLLs at runtime.
+// odbcstup defines them in the NSQL[...] methods as
+// indirect function calls.
+// odbcimp is extended by  preo2, odbc, and postos2.
 //  #include "odbc3imp.hxx"
 
 #else
 
-// Zur Zeit verwenden wir die ODBC-DLL von Watcom-SQL direkt (ueber die
-// mitgelieferte Lib).
+// Currently we use the ODBC dll from Watcom-SQL directly
+// (from the supplied lib)
 
 #ifndef ODBC_OS2
 #define ODBC_OS2
@@ -101,8 +100,8 @@
 
 #endif
 
-// In der ODBC.H von Watcom werden Strings als char * erwartet
-// (nicht, wie sonst bei ODBC ueblich, als UCHAR *).
+// ODBC.H from Watcom will expect strings as 'char *'
+// (not the case elsewhere in ODBC, where it's 'UCHAR *')
 #if defined( ICC )
 #define SDB_ODBC_CHAR unsigned char
 #else
@@ -115,8 +114,7 @@
 
 #ifdef UNX
 
-// Zur Zeit verwenden wir die ODBC-shared library von Q+E direkt (ueber die
-// mitgelieferte Lib).
+// Currently we use the supplied ODBC shared library from Q&E directly.
 
 #ifndef ODBC_UNX
 #define ODBC_UNX
@@ -128,8 +126,7 @@
 #else
 #include 
 #endif
-#undef sal_Bool // Ist in qeodbc.h definiert, wird aber von solar.h noch einmal
-// definiert.
+#undef sal_Bool // Defined in qeodbc.h, and is also defined in solar.h
 
 #define SDB_ODBC_CHAR UCHAR
 #define SQL_WCHAR   (-8)
diff --git a/connectivity/source/inc/odbc/OPreparedStatement.hxx b/connectivity/source/inc/odbc/OPreparedStatement.hxx
index 076c9e05..bd05ea2 100644
--- a/connectivity/source/inc/odbc/OPreparedStatement.hxx
+++ b/connectivity/source/inc/odbc/OPreparedStatement.hxx
@@ -109,7 +109,6 @@ namespace connectivity
 throw (::com::sun::star::uno::Exception);
 public:
 DECLARE_SERVICE_INFO();
-// ein Konstruktor, der fuer das Returnen des Objektes benoetigt wird:
 OPreparedStatement( OConnection* _pConnection,const ::rtl::OUString& sql);
 
 //XInterface
diff --git a/connectivity/source/inc/odbc/OResultSet.hxx b/connectivity/source/inc/odbc/OResultSet.hxx
index e0362251..a128f7d 100644
--- a/connectivity/source/inc/odbc/OResultSet.hxx
+++ b/connectivity/source/inc/odbc/OResultSet.hxx
@@ -200,7 +200,6 @@ namespace connectivity
  ) const;
 public:
 DECLARE_SERVICE_INFO();
-// ein Konstruktor, der fuer das Ret

[PROPOSAL] get rid of clone/*, use git submodules for binfilter, dictionaries and help

[Norbert Thiebaud]

All the extra repositories we have left contain just one module. so It
is possible to change the structure of these repository to remove the
top-level directory in them, and clone them directly in $core/
furthermore, using submodules for them (except translations due to its
size) would allow to identify a build point with one single sha, which
would make stuff much easier for tinderboxes, jenkins, bisection
etc...

The pros:

+ no more need for ./g
+ no more need for $(realpath in the build since there is no links left
+ a build point is identified by one and only one sha, which is
imperative to manage a build-farm ( gerrit+jenkins and the ability to
test-build every patches)

translations will be moved to ./translations but will not be made a
submodules due to its prohibitive size. I have not coded that yet, but
that will involved a 'bootstrap' script to manage the migration
without re-cloning translations
that will be run automatically on make (or maybe at the tail_end of
configure... not sure yet)

The build is pretty insensitive to the translations content.
translations has a very low rate of change and is essentially managed
by timar (i.e the person that coordinate localization activities with
dev). That means that tagging and branching translation in concert
with core will require an extra manual step. the added complexity is
not _that_ great, and impact mostly Petr and people doing release
build.

The cons:

- cherry picking a patch from 'before' the change to 'after' the
change will not work if the patch impact one of these repos (due to
the renaming). that can be mitigated with a pre-processing script to
change the target name in the patch, since the filename pattern
impacted is regular and easy to detect... so a simple sed should do
the job

- feature branching becomes a bit more cumbersome if you need to
branch one of the submodule. it boils down to remember the 'submodules
first' rule: you need to settle submodules operations before core. So,
for instance when merging back to master you need to merge to master
in the submodules then commit core (still in the feature branch) to
pick-up the merge change in the submodules and _then_ merge core.

- if you want to be able to checkout to a commit prior to the
migration point you need to keep clone/* around. The good news is that
it work nicely, the only thing to do after a checkout to a point prior
to the submodules migration is to recreate the links for
binfilter/dictionaries/helpcontent2
that can be done running ./bin/create_bootstrap_links

if you want to see what this look/feel likes, see feature/submodules

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Hello all,

finally I could solve the problem. Basically, for the Windows installation, I 
had to adjust uno.ini in the working directory of my "remote control" 
according to my installation of LO. Furthermore, there are some weird 
inconsistencies concerning URLs. Under Windows I had to set 2 environment 
variables:
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 :-)

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.

Thanks,
Helmar

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOffice / openIndiana ...

[Jonathan Adams]

Any help or advice would be welcome, even if it is only where to start looking:

=
(100/117) Building module i18npool
=
Entering /home/sal/LibreOffice/libo/i18npool/prj

[ build LNK ] Executable/gendict
[ build LNK ] Executable/gencoll_rule
[ build LNK ] Executable/genindex_data
[ build LNK ] Executable/saxparser
[ build LNK ] Executable/genconv_dict
[ build MAK ] i18npool/source/breakiterator
[ build MAK ] i18npool/source/collator
[ build MAK ] i18npool/source/indexentry
[ build MAK ] i18npool/source/textconversion
[ build MAK ] i18npool/source/localedata
Exception on createRegistryServiceFactory specified first registry
could not be open readonly!
Exception on createRegistryServiceFactory specified first registry
could not be open readonly!
gmake[2]: *** [localedata_af_ZA_invis.cxx] Error 1
gmake[2]: *** Waiting for unfinished jobs
gmake[2]: *** [localedata_af_NA_invis.cxx] Error 1
dmake:  Error code 2, while making 'all'

sal@salmon190-241:~/LibreOffice/libo$ cd i18npool/
sal@salmon190-241:~/LibreOffice/libo/i18npool$ gmake
[ build MAK ] i18npool/source/localedata
S=/home/sal/LibreOffice/libo && O=$S/solver/unxsoli &&
W=$S/workdir/unxsoli &&  mkdir -p
$W/CustomTarget/i18npool/source/localedata && O='$S/solver/unxsoli'
S='/home/sal/LibreOffice/libo' W='$S/workdir/unxsoli' gb_AWK='awk'
gb_XSLTPROC='xsltproc' GBUILDDIR='$S/solenv/gbuild'
SRCDIR='/home/sal/LibreOffice/libo' gmake -C
$W/CustomTarget/i18npool/source/localedata -f
$S/i18npool/source/localedata/Makefile && touch
$W/CustomTarget/i18npool/source/localedata.done
gmake[1]: Entering directory
`/home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata'
LD_LIBRARY_PATH="/home/sal/LibreOffice/libo/solver/unxsoli/lib"
/home/sal/LibreOffice/libo/solver/unxsoli/bin/saxparser af_NA
/home/sal/LibreOffice/libo/i18npool/source/localedata/data/af_NA.xml
localedata_af_NA_invis.cxx
file:///home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata/saxparser.rdb
/home/sal/LibreOffice/libo/solver/unxsoli/bin/types.rdb
-env:LO_LIB_DIR=file:///home/sal/LibreOffice/libo/solver/unxsoli/lib
Exception on createRegistryServiceFactory specified first registry
could not be open readonly!
gmake[1]: *** [localedata_af_NA_invis.cxx] Error 1
gmake[1]: Leaving directory
`/home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata'
sal@salmon190-241:~/LibreOffice/libo/i18npool$

# truss output of the specific saxparser command:
( LD_LIBRARY_PATH="/home/sal/LibreOffice/libo/solver/unxsoli/lib"
truss -f /home/sal/LibreOffice/libo/solver/unxsoli/bin/saxparser af_NA
/home/sal/LibreOffice/libo/i18npool/source/localedata/data/af_NA.xml
localedata_af_NA_invis.cxx
file:///home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata/saxparser.rdb
/home/sal/LibreOffice/libo/solver/unxsoli/bin/types.rdb
-env:LO_LIB_DIR=file:///home/sal/LibreOffice/libo/solver/unxsoli/lib
2>&1 ) > saxparser.log

On 5 March 2012 15:03, Jonathan Adams  wrote:
> Still a work in progress ... and a couple of "when it stops at this
> point run this command" kinda hacks.
>
> diff patch is attached, you'll just have to see how far you can get with it.
>
> the user on this system is "sal" because I work for SAL ...
> http://www.salltd.co.uk
>
> Jon
>
> On 5 March 2012 14:08, Michael Meeks  wrote:
>>
>> On Mon, 2012-03-05 at 12:06 +, Jonathan Adams wrote:
>>> I'd prefer to stick with the system supplied gcc, but will move to a
>>> packaged version that is stored somewhere else if that'd help.
>>
>>        Sure - IMHO we should be using the gnu tools as much as possible, if
>> only to reduce the differences across platforms & hence reducing the
>> odd-bug count and number of tweaks to the code & build configuration :-)
>>
>>        Incidentally - do you have a 'patch so far' :-)
>>
>>        "git diff > /tmp/here-i-am.diff"
>>
>>        I'd be happy to have at least -something- in git master that builds a
>> bit further, so that others can jump in and help drive that high water
>> mark higher. What's there now, clearly doesn't work :-) so anything
>> better is better.
>>
>>        Thanks !
>>
>>                Michael.
>>
>> --
>> michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot
>>


saxparser.log
Description: Unix manual page
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Exporting templates on Windows (Re: [Libreoffice-commits] .: 7 commits - clucene/patches clucene/source configure.in cppuhelper/inc hwpfilter/source sal/inc solenv/gbuild vbahelper/inc)

[Lubos Lunak]

 Windows/MSVC experts

On Monday 12 of March 2012, Stephan Bergmann wrote:
> On 03/10/2012 04:39 PM, Lubos Lunak wrote:
> > commit 34f8495dd948e2ad9d64c2c19110e69840cefd1a
> > Author: Luboš Luňák
> > Date:   Sat Mar 10 15:37:02 2012 +0100
> >
> >  exported templates need to be marked as such
> >
> >  Otherwise their instances created in other modules may end up
> >  as non-exported even when used by something exported.
> >
> > diff --git a/cppuhelper/inc/cppuhelper/compbase.hxx
> > b/cppuhelper/inc/cppuhelper/compbase.hxx index 60e99ee..e590412 100644
> > --- a/cppuhelper/inc/cppuhelper/compbase.hxx
> > +++ b/cppuhelper/inc/cppuhelper/compbase.hxx
> > @@ -41,7 +41,7 @@
> >   namespace cppu \
> >   { \
> >   template<  __CLASS_IFC##N>  \
> > -class SAL_NO_VTABLE WeakComponentImplHelper##N \
> > +class SAL_NO_VTABLE CPPUHELPER_DLLPUBLIC WeakComponentImplHelper##N \
> >
> >   : public ::cppu::WeakComponentImplHelperBase \
> >
> >   , public ImplHelperBase##N<  __IFC##N>  \
> >   { \
>
> Does this workaround for 
> (where I'm still not convinced it is a user error vs. a compiler error)

 I am rather convinced that the original issue 
(without -fvisibility-inlines-hidden) is a user error, so I consider this to 
be a proper fix rather than a workaround.

 Imagine for example that the template has a static data member - that one 
would need to be merged to be just in one place, and that just wouldn't work 
if the template was public API but hidden. So in general I think templates 
need to be exported (also look e.g. at STL headers, which export the entire 
std namespace, although I can see that Qt templates don't).

> work well with MSVC?  I wonder because there all consumers of the
> template (outside of cppuhelper) will see it as __declspec(dllimport),
> and (as long as there is no instantiation in cppuhelper) there is no
> place that would emit it as __declspec(dllexport).

 I don't know about MSVC. Meaning that I haven't tried and I don't know how 
export/import works on Windows anyway.

 But it doesn't make much sense to me. It is not actually the template itself 
that is or is not exported, because that's just a compile-time concept, but 
it's instances of it as binary concept that are exported. And how does 
something know whether some other library does or does not contain Foo< int > 
without actually looking?

 Assuming that this commit really breaks it on MSVC and the proper change 
there is to remove the DLLPUBLIC from the template and hope the compiler and 
linker sort it out somehow, then I guess we'll need to add 
SAL_TEMPLATE_DLLPUBLIC which does nothing with MSVC and the right thing with 
gcc/clang.

 MSDN article on the dllimport/dllexport flags feels like it doesn't actually 
say anything, but reading http://support.microsoft.com/kb/132044/en-us makes 
me think the flags are just optimizations, so nothing will break. But 
according to it SAL_TEMPLATE_DLLPUBLIC would be the right thing.

 Windows/MSVC experts, any ideas/opinions?

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Issue with delivering of main_transform.xsl on 3.5 and later

[Petr Mladek]

Tomáš Chvátal píše v Po 12. 03. 2012 v 14:07 +0100:
> We in Gentoo are using that file because we use the helppack build in
> the RPM files (same as translations) as those two really slow down the
> build time with no real benefit for the user. So the crash is proper
> because we are using local help files not the wiki. If I do not store
> the helpfiles the online wiki loads properly.

Ah, I have finally understood your problems. I thought that these files
were needed for online/wiki help.


Hmm, I have had similar problem already in LO-3.4. I have solved it by
the following hack:

1. During build of the main package:

# hack to add icons for helpcontent that is build separately 
(
. ./*Env.Set.sh
mkdir -p $SOLARVER/$INPATH/res/img
perl helpcontent2/helpers/create_ilst.pl
-dir=default_images/res/helpimg >$SOLARVER/$INPATH/res/img/helpimg.ilst
)



2. during installation of the main package:

 
# common helpcontent files 
# create symlinks to /usr/share for noarch help packages 
mkdir -p $RPM_BUILD_ROOT/%lo_prefix/%lo_home/%lo_basis_dir/help
mkdir -p $RPM_BUILD_ROOT/%_datadir/%lo_home/%lo_basis_dir/help
echo "%dir %lo_prefix/%lo_home/%lo_basis_dir/help"
>>file-lists/common_list.txt
echo "%dir %_datadir/%lo_home/%lo_basis_dir/help"
>>file-lists/common_list.txt
for file in idxcaption.xsl idxcontent.xsl main_transform.xsl ; do
install -m 644 solver/*/unxlng*.pro/bin/$file $RPM_BUILD_ROOT/%
lo_prefix/%lo_home/%lo_basis_dir/help
ln -sf %lo_prefix/%lo_home/%lo_basis_dir/help/$file
$RPM_BUILD_ROOT/%_datadir/%lo_home/%lo_basis_dir/help
echo "%lo_prefix/%lo_home/%lo_basis_dir/help/$file"
>>file-lists/common_list.txt
echo "%_datadir/%lo_home/%lo_basis_dir/help/$file"
>>file-lists/common_list.txt
done


You might either use similar hacks in your build script.

Or even better would be to add extra option --enable-common-help-files
or so and make sure that helpcontent2/helpers/create_ilst.pl is called
during normal build and that the files are installer. You need to modify
scp2 to fix the installation.


Best Regards,
Petr

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Save , Save as HTML and Edit LibreOffice WorkBook without running LO

[libreoffice...@gmail.com]

Dear Michale,

Thanks for your reply. We are investigating  ...  in most cases we have 
a bugs in our code.   If we will found LO bugs we will definitely file it.


Main goal / question we had was: Is it any component which can edit, 
save, save as LO calc without LO installed on computer?


Best
Nick


On 3/12/2012 3:31 PM, Michael Meeks wrote:

Hi there,

On Mon, 2012-03-12 at 14:11 +0400, libreoffice...@gmail.com wrote:

We have an OOO|LO workbook in server. Jboss is generating report based on that 
workbook.
This process is written. In old version  ( which was using OOO&  Swing on 
client side)
we were opening that Workbook. Everything was working fine.

Ok - interesting :-)


Now in new version we would like to have LO on server side and use web based
client. For that purpose we have to :

Fine.


1. Generate report on server side in LO workbook ( this is done)

Great.


2. Save it as HTML ( that is also done using code I have sent , but performance
is not very good and sometime LO is crashing)

So - this is something we can (easily?) fix. There should be no serious
performance problem saving as HTML, and it certainly shouldn't crash.
Have you filed bugs for that ? do they have good stack traces ? :-) Are
you using the latest 3.5.1rc2 ? if so, then getting a callgrind trace
again with debug symbols installed for a good trace would be most
helpful; save your file as /tmp/foo.ods and then re-load it:

export OOO_DISABLE_RECOVERY=1
valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin 
--splash-pipe=0 /tmp/foo.ods

And then use callgrind_control to reset profiling just before you do a
manual save as HTML - then calgrind_control --dump just after it, and we
should have a nice profile of what (silly) thing is taking time there.


3. Send it to web based client ( we are using EXT GWT framework for client)

Sure - so that's not our problem :-)


./soffice is not useful becasue then we need first to save file in hdd 
(originaly
file is in database , convert an send to Client.

Fine - I understand it better now, hopefully you can provide some
detailed bug reports with the above data :-) Really, this list is not
for filing bugs on though, but discussing how to solve them and concrete
patches etc. for that.

Thanks !

Michael.



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEWED][REVIEW][3-5] Re: Two Python 2.x regressions in LibreOffice 3.5.1RC1

[Caolán McNamara]

On Fri, 2012-03-09 at 15:48 +0100, Michael Stahl wrote:
> On 07/03/12 11:37, Michael Stahl wrote:
> 
> > PS: please somebody review the above 2 commits and backport to
> > libreoffice-3-5.
> 
> additionally this one is necessary

Full three patches cherry-picked to 3-5 now.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEWED][REVIEW 3-5] fdo#45543 fix RTF import of ms932-encoded characters

[Caolán McNamara]

On Mon, 2012-03-12 at 09:33 +0100, Miklos Vajna wrote:
> I'm attaching a backport of these patches for -3-5

Pushed to 3-5.

C.

Doesn't really matter, but in the ctor member init lists, there isn't
really a need to call the default ctors explicitly, e.g.
, m_aUnicodeBuffer()
, m_aHexBuffer()
could just be left out

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[REVIEW] b68f06287d34833a59841b8000641a02d0994eb8: Iterator crash in writerfilter/source/ooxml/OOXMLPropertySetImpl.cxx

[Tor Lillqvist]

http://cgit.freedesktop.org/libreoffice/core/patch/?id=b68f06287d34833a59841b8000641a02d0994eb8
. The added comment should give an idea what it's about.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [UX advise] Key navigation in ValueSet controls

[Stefan Knorr (Astron)]

Hi Matteo,

> Well, in this case my goal is to let the user see the content of not-full
> rows without explicitly looking for it, and to move rapidly from an item to
> another without too much corrections.

I see.


> Good catch. Also speaking from a Western perspective, I find it somewhat
> confusing to be brought at the opposite side of the one I was moving to (and
> columns can be long and involve scrolling, while rows don't scroll). My
> point is that currently left/right let you navigate through all the items,
> while up/down keys can leave a row "hidden".

This again makes lots of sense to me. Also, we didn't hear anything
about wrapping around from top to bottom being necessary behaviour, so
I guess, just doing it should be fine.


> I don't know the original goals of that features: currently it seems to me
> that if you use modifiers than nothing happens.

As I said, I /think/ you should keep that behaviour.


>>> * If "none" item is present, then it could be accessed only from the
>>>  first item by pressing any of left/up (also page up/home ?) keys.
>>>  When selected, it can be exited only by pressing right/down (also
>>>  page down/end?) keys, but always lead to the first item.
>
> I'm less sure of this, now. If a wrap around for up/down is desired, the
> current behavior of always passing through the "none" item probably makes
> more sense. Unless we find a dedicated key to select that item, which could
> solve the situation. Any idea?

Hrm. Extremely wild idea: use backspace..?
More conventional idea: use Tab to go the normal items, use Shift-Tab
to go to the "None" item.


>>> * Return key behavior: at least it should not close the color
>>>  configuration window, but my guess is that's a misconfiguration of
>>>  the specific instance of ValueSet.
>>
>>
>> Not entirely sure about this one, although probably most people would
>> want to use Return and Tab the same way (i. e. to get to the next
>> widget and select a colour).

I just noticed that wrote that this is used for both both colour
configuration and selection ...
* for the configuration what I wrote makes sense
* for selection, less so – I guess, pressing Return there should
indeed close the popup


Astron.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Issue with delivering of main_transform.xsl on 3.5 and later

[Tomáš Chvátal]

2012/3/12 Jan Holesovsky :
> Hi Petr, Tomas,
>
> On 2012-03-12 at 10:52 +0100, Petr Mladek wrote:
>
>> > I am currently solving tiny bug [1][2] we have in Gentoo about the file in 
>> > the
>> > topic.
>> > It used to be delivered with help disabled on 3.4 but with 3.5 on the file 
>> > is
>> > no longer around so offline help is not available for users.
>> >
>> > Does anyone happen to know what should I patch to make it install like in 
>> > 3.4?
>>
>> This file defines how to display local help, it should not be necessary
>> for offline help that is in wiki and is displayed in a browser. So, the
>> clean solution is to found why it is accessed at all. Kendy, do you have
>> any idea?
>
> No idea without further looking, sorry :-(  Tomas - can you please
> identify the commit that changed that?
>

Well the problem is that it was completely changed with move from 3.4
to 3.5 afaics.

We in Gentoo are using that file because we use the helppack build in
the RPM files (same as translations) as those two really slow down the
build time with no real benefit for the user. So the crash is proper
because we are using local help files not the wiki. If I do not store
the helpfiles the online wiki loads properly.

Also I could kill the offlinehelp completely to work around this issue :)

Cheers

Tom
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Bug 37361 depends on bug 47052, which changed state.

Bug 47052 Summary: Recovery fails because no access to AppData Temp folder
https://bugs.freedesktop.org/show_bug.cgi?id=47052

   What|Old Value   |New Value

 Resolution||WONTFIX
 Status|UNCONFIRMED |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

Re: [PATCH] convert tools/table.hxx to std::map in ScEEParser class in SC module

[Ivan Timofeev]

Hi Noel,


 for ( SCCOL nCol = nStartCol; nCol <= nEndCol; nCol++ )
 {
-   sal_uInt16 nWidth = (sal_uInt16)(sal_uLong) pColWidths->Get( nCol );
+   sal_uInt16 nWidth = 0;
+   if ( rColWidths.find( nCol ) != rColWidths.end() )
+  nWidth = rColWidths[ nCol ];


so this code performs a search twice - firstly 'find', then 
'operator[]'. And it is in the loop. And it is an import filter. Maybe


  iterator it = rColWidths.find( nCol );
  if ( it != rColWidths.end() )
 nWidth = it->second;

is better? Or I am missing smth.?

Regards,
Ivan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Q: Is [collaboration] of some interest? [yes!]

[Eike Rathke]

Hi Riccardo,

On Thursday, 2012-03-08 10:39:47 +, Michael Meeks wrote:

> > 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.

Right, let's coordinate things a bit. Seems this topic comes up more
frequently recently, we should really avoid conflicting approaches.


> > 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.

That's what I had in mind as well. My approach would be to use
a change-tracking enabled document, because (besides that it gives you
the benefit of being able to display who changed what when) then
actually only trackable (content, not attributes) features are enabled,
and the current file based collaboration (aka shared document) uses this
mode as well, as does the compare/merge document feature. It talso
provides functionality to accept/reject changes. Note that I'm Calc
biased here, Writer doesn't have the shared document feature yet, though
it does have change-tracking.


> > 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 ? :-)

I can commit the remainders of what I have (threw away the first
unpromising approach) to a feature branch this week.


> > 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 ;-).

Actually not that much ;-)

> 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.

This is absolutely a must, especially when it comes to edits that move
things in the document, such as inserting/deleting rows/columns or
moving cells.

>   * Jabber provides this guarentee :-) and a beautiful way of
> bootstrapping communication from an existing communication
> tool: telepathy/empathy/IM

Yup, and a hard one to deal with..

>   * Those edits need to do -exactly- the same thing, ie. we'd want
> the same major version of LibreOffice at each end.

I'd rather version the collaboration feature, so each end can
announce/handshake on the minimum collaboration version required,
instead of tie it to the LibO version.

>   ** 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.

That would be a long run, but yes, at the end that's probably what we
want.

>   * And of course, some thinking of good ways of managing
> cursor location

Re: [REVIEWED] fdo#33683: [EasyHack] colorpicker for font and background color no longer resizable

[jumbo444]

Hi Michael,


Michael Meeks-2 wrote
> 
> On Sun, 2012-03-11 at 07:35 -0700, jumbo444 wrote:
>> The patch adds WinBits to the constructor of SvxColorWindow_Impl: the
>> same
>> from OOo 3.2.
> 
>   I see in the bug that you're working on a better version :-)
Actually, the bug appeared between OOo 3.2.1 and OOo/LibO 3.3. That's why I
looked at OOo3.2.1 code to simply copy the same WinBits in the constructor.
However, it does not work exactly the same way, as mentioned on the bug
page.

Michael Meeks-2 wrote
> 
>   I imagine you'd need to connect to some Link / override some virtual
> method to shut the dialog on window close ?
Well, I'm not sure to understand all what you mean, but I will have a deeper
look this week.


Michael Meeks-2 wrote
> 
> PS. did you send a blanket license mail to the list to link into the
> developers wiki page ?
I updated
http://wiki.documentfoundation.org/Development/Developers

Have a good day.

Laurent BP

-
LibreOffice 3.5.0
--
View this message in context: 
http://nabble.documentfoundation.org/PATCH-fdo-33683-EasyHack-colorpicker-for-font-and-background-color-no-longer-resizable-tp3816718p3819079.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

Re: Issue with delivering of main_transform.xsl on 3.5 and later

[Jan Holesovsky]

Hi Petr, Tomas,

On 2012-03-12 at 10:52 +0100, Petr Mladek wrote:

> > I am currently solving tiny bug [1][2] we have in Gentoo about the file in 
> > the 
> > topic.
> > It used to be delivered with help disabled on 3.4 but with 3.5 on the file 
> > is 
> > no longer around so offline help is not available for users.
> >
> > Does anyone happen to know what should I patch to make it install like in 
> > 3.4?
> 
> This file defines how to display local help, it should not be necessary
> for offline help that is in wiki and is displayed in a browser. So, the
> clean solution is to found why it is accessed at all. Kendy, do you have
> any idea?

No idea without further looking, sorry :-(  Tomas - can you please
identify the commit that changed that?

Thank you,
Kendy

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED][PATCH] Convert SV_DECL_VARARR_SORT and SV_IMPL_VARARR_SORT with std::set

[Ivan Timofeev]

Hi Bartosz,

On 11.03.2012 01:29, Bartosz wrote:

I updates the patch.
Could you please push it to libreoffice?


Surely! Pushed: 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f2d0fcc26be481c2f872056fb3b8402169d124d8


But I cannot find your license statement.

Thanks,
Ivan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

License statement

[jumbo444]

Hi,
All my current and past contributions made to the LibreOffice project
are done under MPL1.1+ /LGPLv3+.

Until further notice, all my future contributions to the LibreOffice
project are available under MPL1.1+ / LGPLv3+.

Best Regards,

Laurent BP


-
LibreOffice 3.5.0
--
View this message in context: 
http://nabble.documentfoundation.org/License-statement-tp3819044p3819044.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

Re: Excessive exception size cost ...

[Stephan Bergmann]

On 03/08/2012 06:05 PM, Michael Meeks wrote:

So - there is the 1.9% size saving ~3.3Mb saved (which is a lower bound
- we can do better by being more complete).


Yes, exceptions do come at a cost (in object size).  As I already said, 
if people consider this cost substantial in the case of std::bad_alloc 
thrown from the rtl::O[U]String inline functions, we could change those 
inline functions to use std::abort instead (with the rationale that 
these OOM conditions are currently not handled anywhere, anyway).



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.


The relative numbers are smaller for x86_64, btw.  ;)


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.


So, how large is epsilon in practice?  In other words, which percentage 
of code locations through which any kind of exception can pass can be 
shown to only ever be passed by exceptions that are not handled (and 
thus lead to abort)?  Do you have any actual numbers?



We can also see that of the two potential causes of bloat removal of
not doing this:

a) not in-lining:


Sorry, my parser broke down on the above lines.

[...]


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.


Again, what makes you claim that almost all exceptions thrown in the LO 
code base are left unhandled?


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [ANN] LibreOffice 3.5.1 RC2 available

[ape]

Hi, Peter

1. You have almost solved the problem open the formula as the OLE-object
formula in the form of the OLE Math object
(libreoffice-3-5~2012-03-09_13.41.25_LibO-Dev_3.5.2rc0_Win_x86/Win-x86@6-fast;
the file "16b.docx" - https://bugs.freedesktop.org/attachment.cgi?id=58261).
But there is one problem: it is necessary to delete a single character - is
once an object that is created for some reason when you open the "16b.docx"
(see the attachment). The "long-formula" will fail if the user does not
delete the "delta".
And it is - a great job.

http://nabble.documentfoundation.org/file/n3818974/16b_open.png 

2. But this does not solve the problem with "proekt_MU"
(https://bugs.freedesktop.org/attachment.cgi?id=57754), containing both
types of formulas: by the Word-2003 and by the Word-2010.  This is a
separate bug. What to do with it?

Regards, ape.

--
View this message in context: 
http://nabble.documentfoundation.org/ANN-LibreOffice-3-5-1-RC2-available-tp3811831p3818974.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

Re: Save , Save as HTML and Edit LibreOffice WorkBook without running LO

[Michael Meeks]

Hi there,

On Mon, 2012-03-12 at 14:11 +0400, libreoffice...@gmail.com wrote:
> We have an OOO|LO workbook in server. Jboss is generating report based on 
> that workbook.
> This process is written. In old version  ( which was using OOO & Swing on 
> client side)
> we were opening that Workbook. Everything was working fine. 

Ok - interesting :-)

> Now in new version we would like to have LO on server side and use web based
> client. For that purpose we have to : 

Fine.

> 1. Generate report on server side in LO workbook ( this is done) 

Great.

> 2. Save it as HTML ( that is also done using code I have sent , but 
> performance
> is not very good and sometime LO is crashing)

So - this is something we can (easily?) fix. There should be no serious
performance problem saving as HTML, and it certainly shouldn't crash.
Have you filed bugs for that ? do they have good stack traces ? :-) Are
you using the latest 3.5.1rc2 ? if so, then getting a callgrind trace
again with debug symbols installed for a good trace would be most
helpful; save your file as /tmp/foo.ods and then re-load it:

export OOO_DISABLE_RECOVERY=1
valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin 
--splash-pipe=0 /tmp/foo.ods

And then use callgrind_control to reset profiling just before you do a
manual save as HTML - then calgrind_control --dump just after it, and we
should have a nice profile of what (silly) thing is taking time there.

> 3. Send it to web based client ( we are using EXT GWT framework for client) 

Sure - so that's not our problem :-)

> ./soffice is not useful becasue then we need first to save file in hdd 
> (originaly
> file is in database , convert an send to Client. 

Fine - I understand it better now, hopefully you can provide some
detailed bug reports with the above data :-) Really, this list is not
for filing bugs on though, but discussing how to solve them and concrete
patches etc. for that.

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: Nelp needed for Bug 47052 Recovery fails because no access to AppData Temp folder

[Rainer Bielefeld]

Petr Mladek schrieb:


I see ~/.config/libreoffice/3/user/backup on my system. I wonder if your
system or configuration is somehow messed.


Hi,

I'll do a first step with new profile and see what happens.

Thx

Rainer
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Nelp needed for Bug 47052 Recovery fails because no access to AppData Temp folder

[Petr Mladek]

Rainer Bielefeld píše v Po 12. 03. 2012 v 10:50 +0100:
> Hi,
> 
> I have serious problems with Recovery, what does not work. If that's a 
> general problem that would be really critical. Can you please try to 
> reproduce?

I am unable to reproduce this on Linux.

I am confused by the comment #1, see
https://bugs.freedesktop.org/show_bug.cgi?id=47052#c1
Could you please provide more exact steps to reproduce?


> Today I observed that my User Profile no longer contains a Backup folder 
> - intended or part of the bug?

I see ~/.config/libreoffice/3/user/backup on my system. I wonder if your
system or configuration is somehow messed.


Best Regards,
Petr

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: How to report a LibreOffice crash on Windows like a pro

[Michael Meeks]

Hi Jesus,

On Sat, 2012-03-10 at 21:09 +0100, Jesús Corrius wrote:
> I have made this shameful screencast (my very first one) that shows
> how to report a crash on Windows like a pro:
> 
> http://www.youtube.com/watch?v=fppBTs215yc

Wow - this is awesome ! :-) I learned a fair bit, *fridrich = 666 is
clearly the solution.

What would be even sexier, is if we could link this into the bug filing
assistant for Windows - so if we have a '[ ] does it crash or hang'
selection, and people select it we can show a link to your video ?

I guess Kate was the last one to touch the bug submission
assistant ! :-) would that be do-able ?

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: [ANN] LibreOffice Hamburg Hackfest, April 14/15

[Thorsten Behrens]

> Please find more (but still incomplete) information in our wiki:
> 
>  https://wiki.documentfoundation.org/Hackfest/Hamburg2012
> 
Hi there,

I'm glad to tell you that the TDF board has approved a budget for
travel bursaries for the HackFest - details on above wiki page,
executive summary:
 * transportation-only, please sign-up for coach surfing if you need
   free accomodation
 * volunteer-first - people affiliated with a company involved in
   LibreOffice work will come last
 * first-come-first-served - participants will get reimbursed in
   order of their sign-up on the wiki attendance list, until budget
   runs out.

Please be economic and pick cheap travel - that said, flights to
Hamburg might still be available at a reasonable price.

Looking forward to see many of you there,

-- Thorsten


pgpiQL2jB2Yym.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[REVIEWED] fdo#33683: [EasyHack] colorpicker for font and background color no longer resizable

[Michael Meeks]

Hi Laurent,

On Sun, 2012-03-11 at 07:35 -0700, jumbo444 wrote:
> The patch adds WinBits to the constructor of SvxColorWindow_Impl: the same
> from OOo 3.2.

I see in the bug that you're working on a better version :-)

I imagine you'd need to connect to some Link / override some virtual
method to shut the dialog on window close ?

Thanks !

Michael.

PS. did you send a blanket license mail to the list to link into the
developers wiki page ?
http://wiki.documentfoundation.org/Development/Developers
your table entry there confused me :-)
-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Save , Save as HTML and Edit LibreOffice WorkBook without running LO

[libreoffice...@gmail.com]

Dear Michael ,

We have an OOO|LO workbook in server. Jboss is generating report based on that 
workbook. This process is written. In old version  ( which was using OOO&  
Swing on client side) we were opening that Workbook. Everything was working fine.

Now in new version we would like to have LO on server side and use web based 
client. For that purpose we have to :
1. Generate report on server side in LO workbook ( this is done)
2. Save it as HTML ( that is also done using code I have sent , but performance 
is not very good and sometime LO is crashing)
3. Send it to web based client ( we are using EXT GWT framework for client)


./soffice is not useful becasue then we need first to save file in hdd 
(originaly file is in database , convert an send to Client.

Are you in right way ?
:-)

P.S. See prototypehere  



On 3/12/2012 1:49 PM, Michael Meeks wrote:

On Mon, 2012-03-12 at 13:25 +0400, libreoffice...@gmail.com wrote:

As we informed earlier we are trying to Migrate from OOO Calc to LO
Calc in  our J2EE software.  One of the function we need is to ” SAVE
AS HTML”  OOO|LO Calc Workbook .  Now we are doing it using the code /
method below.

So - I didn't really grok what your use-case is. For "export to HTML"
you must have some model / file format to start with and want to convert
it to something else.

Assuming that is not libreoffice itself, you probably want to look at
running:

./soffice --help
...
--convert-to output_file_extension[:output_filter_name] [--outdir output_dir] 
files
   Batch convert files.
   If --outdir is not specified then current working dir is used as 
output_dir.
   Eg. --convert-to pdf *.doc

Which you can just spawn in the background, will do the conversion and
exit.


ANY CHANCE TO DO IT WITHOUT RUNNING OOO/LO ?  (Like POI can do with
Excel Files.)  . We are looking to http://www.jopendocument.org/ , but
we are very new to LO so any recommendation is very welcome.

That might be possible, you could do more work to the ooconvert thing
to make it possible to bootstrap UNO (@#$@$#%ing difficult sadly) inside
your existing application, and then link the libraries that do the work
into that, but  really it'd be easier to run ./soffice --convert-to
foo.xls baa.ods or whatever.

HTH,

Michael.



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [ANN] LibreOffice 3.5.1 RC2 available

[Petr Mladek]

ape píše v Pá 09. 03. 2012 v 11:17 -0800:
> For export "*.docx" with formulas. 
> This file may contain two types of OLE-objects "formula": formula inherited
> from the "*.doc", and a formula created by the object editor formulas
> MSO-2010. Word-2010 exports in the ODT file of the 1st type as OLE-object
> "image", and type 2 as an OLE-object "formula". OOo.pro import Type 1 as the
> "image" and the 2nd as text. LibO-3.3.4 import Type 1 as OLE-object "image",
> and type 2 is not able to export and leaves an empty space. dev-lo-3.5.2rc2
> imports both types correctly, but can not save the object of the open
> document after editing the file.


> Bug_36..   is the message about 1st type "formulas". That's all.

ok, so the problem with 1st type formulas is solved in the bug 36982.
So, please discuss THIS problem in this bug.

Please, open separate bug for the 2nt type.

Please, we really need two bugs for these two problems. They are
completely independent. The first problem happens only on Windows and it
is a functional problem. The second problem is a missing feature. 

Best Regards,
Petr


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: OpenOffice Addon Plugin on Eclipse

[libreoffice...@gmail.com]

Dear Cedric,

Thank you for your reply. We are not so experienced to write such 
important plugin.  If some one will take initiative we will definitely 
contribute our time as testers.


NetBeans plugins work fine, but we are Eclipse oriented and it would be 
really very nice to have it in Eclipse.  If you and/or some of our 
colleagues will find / develope that plugin in future  please keep 
posting on dev forum or send direct e-mail to me.


Have a nice day

Nick

On 3/8/2012 11:18 PM, libreoffice...@gmail.com wrote:

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

Re: Issue with delivering of main_transform.xsl on 3.5 and later

[Petr Mladek]

Tomáš Chvátal píše v Pá 09. 03. 2012 v 21:51 +0100:
> Hi guys,
> I am currently solving tiny bug [1][2] we have in Gentoo about the file in 
> the 
> topic.
> It used to be delivered with help disabled on 3.4 but with 3.5 on the file is 
> no longer around so offline help is not available for users.
>
> Does anyone happen to know what should I patch to make it install like in 3.4?

This file defines how to display local help, it should not be necessary
for offline help that is in wiki and is displayed in a browser. So, the
clean solution is to found why it is accessed at all. Kendy, do you have
any idea?

A workaround would be to hack the makefiles in helpcontent2 module to
deliver these files into solver, and hack scp2 to install them even when
help is disabled.

Another workaround is to add a hack into your build script.


Best Regards,
Petr

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Save , Save as HTML and Edit LibreOffice WorkBook without running LO

[Michael Meeks]

On Mon, 2012-03-12 at 13:25 +0400, libreoffice...@gmail.com wrote:
> As we informed earlier we are trying to Migrate from OOO Calc to LO
> Calc in  our J2EE software.  One of the function we need is to ” SAVE
> AS HTML”  OOO|LO Calc Workbook .  Now we are doing it using the code /
> method below.  

So - I didn't really grok what your use-case is. For "export to HTML"
you must have some model / file format to start with and want to convert
it to something else.

Assuming that is not libreoffice itself, you probably want to look at
running:

./soffice --help
...
--convert-to output_file_extension[:output_filter_name] [--outdir output_dir] 
files
  Batch convert files.
  If --outdir is not specified then current working dir is used as 
output_dir.
  Eg. --convert-to pdf *.doc

Which you can just spawn in the background, will do the conversion and
exit.

> ANY CHANCE TO DO IT WITHOUT RUNNING OOO/LO ?  (Like POI can do with
> Excel Files.)  . We are looking to http://www.jopendocument.org/ , but
> we are very new to LO so any recommendation is very welcome. 

That might be possible, you could do more work to the ooconvert thing
to make it possible to bootstrap UNO (@#$@$#%ing difficult sadly) inside
your existing application, and then link the libraries that do the work
into that, but  really it'd be easier to run ./soffice --convert-to
foo.xls baa.ods or whatever.

HTH,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Nelp needed for Bug 47052 Recovery fails because no access to AppData Temp folder

[Rainer Bielefeld]

Hi,

I have serious problems with Recovery, what does not work. If that's a 
general problem that would be really critical. Can you please try to 
reproduce?


Today I observed that my User Profile no longer contains a Backup folder 
- intended or part of the bug?


Thx

Rainer
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

what's with the linking warnings?

[Noel Grandin]

Hi

I'm curious - what's with the linking warnings:
[ WARN   ] !!!
[ WARN   ] !!! smoketest/smoketest is linked in by 
Library/libsmoketest.so CppunitTest/libtest_smoketest.so

[ WARN   ] !!!

They seem to have been there for as long as I've been building 
LibreOffice (the last 4 months) - are they indicative of an actual problem?


Regards, Noel Grandin

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

[Noel Grandin]

Hi

OK, I got a version up and running after hacking on the version of gmake 
from the libreoffice repo.


As this point in time, my opinion is that the idea is not worth doing - 
things like touch and cp don't actually seem to trigger very often in 
our build process.

(Unless I'm doing something very wrong).

So I'm going to drop this approach for now.

What I am going to do is run a Windows profiler and see what system 
calls are being triggered by gmake.
I seem to remember seeing something on the GIT mailing list where they 
bypassed the CYGWIN emulation layer to use underlying Windows system 
calls because the default CYGWIN stat() implementation loads a lot more 
information than is actually required for the purposes of make.


-- Noel Grandin

On 2012-03-08 11:07, Michael Meeks wrote:

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.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Bug 37361 depends on bug 32886, which changed state.

Bug 32886 Summary: recent documents list always blank with libreoffice
https://bugs.freedesktop.org/show_bug.cgi?id=32886

   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

Re: [REVIEW 3-5]: don't loose data on disk failure (fsync) fdo#40607

[Stephan Bergmann]

On 03/09/2012 06:17 PM, Michael Meeks wrote:

I'd love some thoughts on this. Of course, finding the right place to
put the osl_syncFile took a fair while, but then to discover that the
dp_manager was bootstrapping all that UCB-ness just to create and delete
a file, twice on startup each time ... we certainly can't be doing an
fsync on startup on old file-systems it'd be a killer, and just look
like an ultra-slow start.

Anyhow - hopefully this will save someone some theoretical data, or at
least give a new idea of where to look for data-loss :-) I also tend to
loathe these 'vnd.expand' URLs. I wish we had a simple low-level API for
them we could use everywhere, that had the more complex (?)
configmgr-ness hooked into it at run-time. Anyhow - hopefully this
didn't break some ultra-complicated expansion use-case.

Thoughts appreciated,


As discussed on IRC, the patch breaks smoketest/adding extensions (and 
my attempt at a quick fix was futile).


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[REVIEW] fdo#45543 fix RTF import of ms932-encoded characters

[Miklos Vajna]

Hi,

There were a number of problems with the RTF import of stateful
encodings (i.e. where we can't process the characters one by one) - see
commits:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d7baacd81bbcfaa35b7fbf9981fa3fa7c9fb1cb4
http://cgit.freedesktop.org/libreoffice/core/commit/?id=0915f1b3d77afa694a2ca692aec307846827da99
http://cgit.freedesktop.org/libreoffice/core/commit/?id=00859026749e005759ce4e7115b746b064cd902b

I'm attaching a backport of these patches for -3-5: the first commit
fixes the real problem, the two later amends are correcting two issues
with the original fix.

Thanks,

Miklos
>From c419aa5bfdff4041132520d2d39b3b1571376fd1 Mon Sep 17 00:00:00 2001
From: Miklos Vajna 
Date: Mon, 13 Feb 2012 18:42:56 +0100
Subject: [PATCH] fdo#45543 fix RTF import of ms932-encoded characters

(cherry picked from commits d7baacd81bbcfaa35b7fbf9981fa3fa7c9fb1cb4,
0915f1b3d77afa694a2ca692aec307846827da99 and
00859026749e005759ce4e7115b746b064cd902b)
---
 writerfilter/source/rtftok/rtfdocumentimpl.cxx |   32 +++
 writerfilter/source/rtftok/rtfdocumentimpl.hxx |6 +++-
 2 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/writerfilter/source/rtftok/rtfdocumentimpl.cxx b/writerfilter/source/rtftok/rtfdocumentimpl.cxx
index 737350b..824615d 100644
--- a/writerfilter/source/rtftok/rtfdocumentimpl.cxx
+++ b/writerfilter/source/rtftok/rtfdocumentimpl.cxx
@@ -305,7 +305,8 @@ RTFDocumentImpl::RTFDocumentImpl(uno::Reference const& x
 m_bWasInFrame(false),
 m_bIsInFrame(false),
 m_bHasPage(false),
-m_aUnicodeBuffer()
+m_aUnicodeBuffer(),
+m_aHexBuffer()
 {
 OSL_ASSERT(xInputStream.is());
 m_pInStream.reset(utl::UcbStreamHelper::CreateStream(xInputStream, sal_True));
@@ -738,9 +739,13 @@ int RTFDocumentImpl::resolvePict(bool bInline)
 
 int RTFDocumentImpl::resolveChars(char ch)
 {
+if (m_aStates.top().nInternalState != INTERNAL_HEX)
+checkUnicode(false, true);
+
 OStringBuffer aBuf;
 
 bool bUnicodeChecked = false;
+bool bSkipped = false;
 while(!Strm().IsEof() && ch != '{' && ch != '}' && ch != '\\')
 {
 if (ch != 0x0d && ch != 0x0a)
@@ -749,13 +754,16 @@ int RTFDocumentImpl::resolveChars(char ch)
 {
 if (!bUnicodeChecked)
 {
-checkUnicode();
+checkUnicode(true, false);
 bUnicodeChecked = true;
 }
 aBuf.append(ch);
 }
 else
+{
+bSkipped = true;
 m_aStates.top().nCharsToSkip--;
+}
 }
 // read a single char if we're in hex mode
 if (m_aStates.top().nInternalState == INTERNAL_HEX)
@@ -764,6 +772,14 @@ int RTFDocumentImpl::resolveChars(char ch)
 }
 if (m_aStates.top().nInternalState != INTERNAL_HEX && !Strm().IsEof())
 Strm().SeekRel(-1);
+
+if (m_aStates.top().nInternalState == INTERNAL_HEX && m_aStates.top().nDestinationState != DESTINATION_LEVELNUMBERS)
+{
+if (!bSkipped)
+m_aHexBuffer.append(ch);
+return 0;
+}
+
 if (m_aStates.top().nDestinationState == DESTINATION_SKIP)
 return 0;
 OString aStr = aBuf.makeStringAndClear();
@@ -2031,8 +2047,7 @@ int RTFDocumentImpl::dispatchFlag(RTFKeyword nKeyword)
 
 int RTFDocumentImpl::dispatchValue(RTFKeyword nKeyword, int nParam)
 {
-if (nKeyword != RTF_U)
-checkUnicode();
+checkUnicode(nKeyword != RTF_U, true);
 RTFSkipDestination aSkip(*this);
 int nSprm = 0;
 RTFValue::Pointer_t pIntValue(new RTFValue(nParam));
@@ -3370,13 +3385,18 @@ void RTFDocumentImpl::setSkipUnknown(bool bSkipUnknown)
 m_bSkipUnknown = bSkipUnknown;
 }
 
-void RTFDocumentImpl::checkUnicode()
+void RTFDocumentImpl::checkUnicode(bool bUnicode, bool bHex)
 {
-if (m_aUnicodeBuffer.getLength() > 0)
+if (bUnicode && m_aUnicodeBuffer.getLength() > 0)
 {
 OUString aString = m_aUnicodeBuffer.makeStringAndClear();
 text(aString);
 }
+if (bHex && m_aHexBuffer.getLength() > 0)
+{
+OUString aString = OStringToOUString(m_aHexBuffer.makeStringAndClear(), m_aStates.top().nCurrentEncoding);
+text(aString);
+}
 }
 
 RTFParserState::RTFParserState()
diff --git a/writerfilter/source/rtftok/rtfdocumentimpl.hxx b/writerfilter/source/rtftok/rtfdocumentimpl.hxx
index 713fd7d..3644375 100644
--- a/writerfilter/source/rtftok/rtfdocumentimpl.hxx
+++ b/writerfilter/source/rtftok/rtfdocumentimpl.hxx
@@ -364,8 +364,8 @@ namespace writerfilter {
 void replayBuffer(RTFBuffer_t& rBuffer);
 /// If we got tokens indicating we're in a frame.
 bool inFrame();
-/// If we have some unicode characters to send.
-void checkUnicode();
+/// If we have some unicode or hex characters to send.
+void checkUnicode(bool bUni

Re: [Libreoffice-commits] .: 7 commits - clucene/patches clucene/source configure.in cppuhelper/inc hwpfilter/source sal/inc solenv/gbuild vbahelper/inc

[Stephan Bergmann]

On 03/10/2012 04:39 PM, Lubos Lunak wrote:

commit 34f8495dd948e2ad9d64c2c19110e69840cefd1a
Author: Luboš Luňák
Date:   Sat Mar 10 15:37:02 2012 +0100

 exported templates need to be marked as such

 Otherwise their instances created in other modules may end up
 as non-exported even when used by something exported.

diff --git a/cppuhelper/inc/cppuhelper/compbase.hxx 
b/cppuhelper/inc/cppuhelper/compbase.hxx
index 60e99ee..e590412 100644
--- a/cppuhelper/inc/cppuhelper/compbase.hxx
+++ b/cppuhelper/inc/cppuhelper/compbase.hxx
@@ -41,7 +41,7 @@
  namespace cppu \
  { \
  template<  __CLASS_IFC##N>  \
-class SAL_NO_VTABLE WeakComponentImplHelper##N \
+class SAL_NO_VTABLE CPPUHELPER_DLLPUBLIC WeakComponentImplHelper##N \
  : public ::cppu::WeakComponentImplHelperBase \
  , public ImplHelperBase##N<  __IFC##N>  \
  { \


Does this workaround for  
(where I'm still not convinced it is a user error vs. a compiler error) 
work well with MSVC?  I wonder because there all consumers of the 
template (outside of cppuhelper) will see it as __declspec(dllimport), 
and (as long as there is no instantiation in cppuhelper) there is no 
place that would emit it as __declspec(dllexport).


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] Bug 45563 - incorrect IMPORT of Zotero RTF, regression

[Chr. Rossmanith]

Am 11.03.2012 22:00, schrieb Miklos Vajna:

On Sun, Mar 11, 2012 at 08:15:54PM +0100, "Chr. 
Rossmanith"  wrote:

Instead of replacing \n with \r (first version of patch) a line \r\n
was added to account for DOS line ends.

It's great that you looked into this! Could you please attach a short
reproducer doc as a reply or to the bug, so I can review your patch +
add a testcase for this bug?
I have a reproducer doc from the person who reported the bug (attached 
to the bug together with an ODT version which is displayed correctly). 
What is the difference between reproducer doc and test case?


Christina
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED][3-5] fdo#45962 "context menu" key with cursor in header/footer makes the cursor jump to document body

[Miklos Vajna]

On Fri, Mar 09, 2012 at 09:09:27PM +0100, Michael Stahl  
wrote:
> this regression in 3.5 is fixed by:
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=87279e0e812bac7f2c17f2758a39bcfd942214af

Pushed, thanks.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: OpenGrok updates ?

[Andras Timar]

Hi Mat,

2012/3/12 Mat M :
> Hello,
>
> I am not sure if OpenGrok is still refreshing.
>
> It references a core/icon-themes folder i don't have [1]. Under 3.5 branch,
> the files exposed are in default_images and ooo_custom_images.
>

OpenGrok indexes the master branch, not libreoffice-3-5 branch.

Regards,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice