Re: [Libreoffice] 3.5 release from QA to point-zero

[Cor Nouws]

Hi Norbert,

Norbert Thiebaud wrote (13-09-11 23:48)

On Tue, Sep 13, 2011 at 2:42 PM, Cor Nouws  wrote:


Thus the solution is: earlier feature freeze.


I disagree that this is _the_ solution. we could feature freeze
today... and that would not change a things unless QA is actually
done... and reciprocally, there is no need for a feature freeze to
start doing serious QA work... that is, even if a couple of feature
were to be integrated in the 2 or 3 weeks you may want to extend the
freeze, that still would translate in 95%+ of the code untouched in
these 2 to 3 weeks.


I agree with you.


That is why I mentioned what mmeeks translated into a 'slushy freeze',
that is a period pre-official freeze where we self-impose an elevated
attention to commit breakages or a 'quiet period' if you will, where
emphasis is on bug fixing... in counterpart we need to get QA used to
QA master. Heck I even thing we could function that wall all the way
to RC1 (and use the notion o 'beta' just as a 'state of affair'
buzzword, but still on master) If someone really want to commit
invasive/dangerous things in the pre-RC period, then they should do a
feature branch until we branch for RC1. at RC1 you get 2 full weeks to
do a formal QA campaign, and then go on weekly RC... Again with QA
using daily build to verify asap that bug are closed... If continuous
QA was paid attention to, the formal RC1 QA should be mostly a matter
of verifying that things do still work.


OK.


I strongly believe that the best way to have a quality release is to
have a process that tend to make RC1 QA an acceptance test rather than
a 'let's start finding the bugs' starting point, which I feel is
pretty much what happened for 3.4... Granted for the 3.4 release,
master has seen pretty invasive change quite shortly prior to the
official branching for beta ( due to m106 merge mostly), so certainly
the dev side of the house made it very hard for QA to kick in gear in
a timely manner but we will _not_ have that again for 3.5.


Indeed, that is a difference on the positive side.
On the other side, at this stage more fundamental changes in the code 
base are going on (at least that is my impression).



What the QA team can do this time around though, is not hold a grunge
against the mistake that were done in 3.4 and em-brass the goal that
master be 'should deliverable every day' (1).


I do not have the idea that there is a negative sentiment in the current 
work, due to the un-lucky circumstances with 3.4



Of course that is an extreme requirement... but the idea behind this
motto is that we should aim to be in a position such that at any given
day, we could decide to branch a RC1 for the next version.


That would be a sort of perfect balance between development and QA.
And of course the whole discussion is about that: the balance.

That of course was part of the initial discussion too (1).
We can't however trust that just saying "we need more QA" etc is enough.
And I know the good work that is going on on that front, and I also 
trust that we grow better gradually. Maybe I am a bit conservative in my 
expectations. And that also has to do with the balance in my feeling 
what I know from working many years with early versions, what I see 
under my fingers etc.


And because of balance: indeed a longer time for QA, or earlier feature 
freeze of course can not be _the_ solution.
In previous mails in this thread I already mentioned some things that we 
can do to try to get more QA at the right time.
But again repeating my self: I know how hard it is to have enough time 
available for that work.
And with more daily releases present, we can do better testing, but it 
also demands for more available time.
(So when Ubuntu's Scot James expects better results with monthly 
releases, he probably puts a heavy burden on the QA community (2)


I really start to wonder what Rainers indea is on this subject.


The elephant in the room to make that (and quite frankly any other QA
approach) a viable reality is automated testing. These are hard, and
even harder when GUI is involved, but they are well worth it.  Stephan
Bergmann just took up the goal of getting subsequent tests running
again into daily build.. that is a great step in the right
direction...


One of the many good things that we can see that is going on :-)

Regards,
Cor


(1) that is why I do not give to much weight to the objection about
'moving the freeze date'. We choose a fairly rapid release schedule,
if a feature cannot make it into one release... it will make the next
one... six month later... it is not like missing the cut-off limit
means 2 to 3 years delay anymore...


1) http://lists.freedesktop.org/archives/libreoffice/2011-June/014201.html
2) http://netsplit.com/2011/09/08/new-ubuntu-release-process/

--
 - Cor
 - http://nl.libreoffice.org

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

[Libreoffice] Need to add Arabic Math Symbols to "Libreoffice Math"

[Ibraheem Saed]

Hello everybody,

 
  LibreOffice Math doesn't support Arabic math symbols.
 
  I need to add the Arabic math symbols to "LibreOffice Math" Aligned from 
right to left.
 
  Arabic math symbols like are English math symbols; but writing is reversed 
(from right to left and symbols are opposite).
 
  for example:
  in English: the root symbol write as this:

 
  but in Arabic: the root symbol write as this:



other example:
in English: the integration symbol write as this:

 


  but in Arabic: the integration symbol write as this:




last example:

in English: the equation write as this:


 



  but in Arabic: the equation write as this aligned from right to left:




this link will help you: 
http://en.wikipedia.org/wiki/Modern_Arabic_mathematical_notation#Some_features_of_Arabic_mathematical_notation


please, this very important for Arabs to add this feature in "LibreOffice Math".

I will help you as I can; just contact with me by this e.mail: 
ibraheem5...@hotmail.com

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

[Libreoffice] Need to add Arabic Math Symbols to LibreOffice Math

[Ibraheem Saed]

Hello everybody,
 
  LibreOffice Math doesn't support Arabic math symbols.
 
  I need to add the Arabic math symbols to "LibreOffice Math" Aligned from 
right to left.
 
  Arabic math symbols like are English math symbols; but writing is reversed 
(from right to left and symbols are opposite).
 
  for example:
  in English: the root symbol write as this:

 
  but in Arabic: the root symbol write as this:



other example:
in English: the integration symbol write as this:

 


  but in Arabic: the integration symbol write as this:




last example:

in English: the equation write as this:


 



  but in Arabic: the equation write as this aligned from right to left:




this link will help you: 
http://en.wikipedia.org/wiki/Modern_Arabic_mathematical_notation#Some_features_of_Arabic_mathematical_notation


please, this very important for Arabs to add this feature in "LibreOffice Math".

I will help you as I can; just contact with me by this e.mail: 
ibraheem5...@hotmail.com

thank you.


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

[Libreoffice] Need to add Arabic Math Symbols to LibreOffice Math

[Ibraheem Saed]

Hello everybody,
 
  LibreOffice Math doesn't support Arabic math symbols.
 
  I need to add the Arabic math symbols to "LibreOffice Math" Aligned from 
right to left.
 
  Arabic math symbols like are English math symbols; but writing is reversed 
(from right to left and symbols are opposite).
 
  for example:
  in English: the root symbol write as this:

 
  but in Arabic: the root symbol write as this:



other example:
in English: the integration symbol write as this:

 


  but in Arabic: the integration symbol write as this:




last example:

in English: the equation write as this:


 



  but in Arabic: the equation write as this aligned from right to left:




this link will help you: 
http://en.wikipedia.org/wiki/Modern_Arabic_mathematical_notation#Some_features_of_Arabic_mathematical_notation


please, this very important for Arabs to add this feature in "LibreOffice Math".

I will help you as I can; just contact with me by this e.mail: 
ibraheem5...@hotmail.com

thank you.

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

[Libreoffice] Arabic Math Symbols

[Ibraheem Saed]

Hello everybody,
 
  LibreOffice Math doesn't support Arabic math symbols.
 
  I need to add the Arabic math symbols to "LibreOffice Math" Aligned from 
right to left.
 
  Arabic math symbols like are English math symbols; but writing is reversed 
(from right to left and symbols are opposite).
 
  for example:
  in English: the root symbol write as this:

 
  but in Arabic: the root symbol write as this:



other example:
in English: the integration symbol write as this:

 


  but in Arabic: the integration symbol write as this:




last example:

in English: the equation write as this:


 



  but in Arabic: the equation write as this aligned from right to left:




this link will help you: 
http://en.wikipedia.org/wiki/Modern_Arabic_mathematical_notation#Some_features_of_Arabic_mathematical_notation


please, this very important for Arabs to add this feature in "LibreOffice Math".

I will help you as I can; just contact with me by this e.mail: 
ibraheem5...@hotmail.com

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

[Libreoffice] [PATCH] Libreoffice's hunspell: Twofold affix stripping plus compound compatibility

[Arno Teigseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This patch enables hunspell to deal with two-level-inflexed compound
words.

like kichwa:
wiñana -> wiñashka (two levels of inflexion) + compounds =
wiñashka+kuna+ntin+mi


note, the file lingucomponent/unxlngx6.pro/lib/libspelllo.so must be
removed before rebuilding, or else this patch won't be picked up

Perhaps there are better ways to make the build process aware of the
need to rebuild libsepelllo.so?

as you've already figured out, this is one of my first patches o_O beware

Arno

- -

$ hunspell -d qu_EC -m
wiñashkakunantinmi
wiñashkakunantinmi  pa:wiñashka st:wiñana # stem # Perfect 3rd person
singular pa:kuna st:kuna pa:ntin st:ntin pa:mi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5v6pkACgkQEMIGVCc8BjDLHwCggGEL66N/53csBRyuPDP+ITGs
/CoAoMqx7TgMYWhnBr5GliItDLUHSlqc
=X0J+
-END PGP SIGNATURE-
>From ecea3f9e53793140e10a4e6b79d7ef5cb3714f19 Mon Sep 17 00:00:00 2001
From: Arno Teigseth 
Date: Tue, 13 Sep 2011 18:34:16 -0500
Subject: [PATCH] added twofold affix+compound to hunspell, as the official fixed https://sourceforge.net/tracker/index.php?func=detail&aid=3288562&group_id=143754&atid=756395

---
 hunspell/hunspell-twoaffixcompound.patch |   80 ++
 hunspell/makefile.mk |1 +
 2 files changed, 81 insertions(+), 0 deletions(-)
 create mode 100644 hunspell/hunspell-twoaffixcompound.patch

diff --git a/hunspell/hunspell-twoaffixcompound.patch b/hunspell/hunspell-twoaffixcompound.patch
new file mode 100644
index 000..71881a2
--- /dev/null
+++ b/hunspell/hunspell-twoaffixcompound.patch
@@ -0,0 +1,80 @@
+--- misc/hunspell-1.3.2/src/hunspell/affixmgr.cxx	2010-06-17 15:56:41.0 +0200
 misc/build/hunspell-1.3.2/src/hunspell/affixmgr.cxx	2011-02-10 20:47:22.0 +0100
+@@ -48,6 +48,7 @@
+   compoundroot = FLAG_NULL; // compound word signing flag
+   compoundpermitflag = FLAG_NULL; // compound permitting flag for suffixed word
+   compoundforbidflag = FLAG_NULL; // compound fordidden flag for suffixed word
++  compoundmoresuffixes = 0; // allow more suffixes within compound words
+   checkcompounddup = 0; // forbid double words in compounds
+   checkcompoundrep = 0; // forbid bad compounds (may be non compound word with a REP substitution)
+   checkcompoundcase = 0; // forbid upper and lowercase combinations at word bounds
+@@ -404,6 +405,10 @@
+   }
+}
+ 
++   if (strncmp(line,"COMPOUNDMORESUFFIXES",20) == 0) {
++   compoundmoresuffixes = 1;
++   }
++
+if (strncmp(line,"CHECKCOMPOUNDDUP",16) == 0) {
+checkcompounddup = 1;
+}
+@@ -1626,8 +1631,9 @@
+ if (onlycpdrule) break;
+ if (compoundflag && 
+  !(rv = prefix_check(st, i, hu_mov_rule ? IN_CPD_OTHER : IN_CPD_BEGIN, compoundflag))) {
+-if ((rv = suffix_check(st, i, 0, NULL, NULL, 0, NULL,
+-FLAG_NULL, compoundflag, hu_mov_rule ? IN_CPD_OTHER : IN_CPD_BEGIN)) && !hu_mov_rule &&
++if (((rv = suffix_check(st, i, 0, NULL, NULL, 0, NULL,
++FLAG_NULL, compoundflag, hu_mov_rule ? IN_CPD_OTHER : IN_CPD_BEGIN)) || 
++(compoundmoresuffixes && (rv = suffix_check_twosfx(st, i, 0, NULL, compoundflag && !hu_mov_rule &&
+ sfx->getCont() &&
+ ((compoundforbidflag && TESTAFF(sfx->getCont(), compoundforbidflag, 
+ sfx->getContLen())) || (compoundend &&
+@@ -1640,9 +1646,11 @@
+ if (rv ||
+   (((wordnum == 0) && compoundbegin &&
+ ((rv = suffix_check(st, i, 0, NULL, NULL, 0, NULL, FLAG_NULL, compoundbegin, hu_mov_rule ? IN_CPD_OTHER : IN_CPD_BEGIN)) ||
++(compoundmoresuffixes && (rv = suffix_check_twosfx(st, i, 0, NULL, compoundbegin))) || // twofold suffixes + compound
+ (rv = prefix_check(st, i, hu_mov_rule ? IN_CPD_OTHER : IN_CPD_BEGIN, compoundbegin ||
+   ((wordnum > 0) && compoundmiddle &&
+ ((rv = suffix_check(st, i, 0, NULL, NULL, 0, NULL, FLAG_NULL, compoundmiddle, hu_mov_rule ? IN_CPD_OTHER : IN_CPD_BEGIN)) ||
++(compoundmoresuffixes && (rv = suffix_check_twosfx(st, i, 0, NULL, compoundmiddle))) || // twofold suffixes + compound
+ (rv = prefix_check(st, i, hu_mov_rule ? IN_CPD_OTHER : IN_CPD_BEGIN, compoundmiddle)
+   ) checked_prefix = 1;
+ // else check forbiddenwords and needaffix
+@@ -2118,8 +2126,9 @@
+ if (onlycpdrule) break;
+ if (compoundflag &&
+  !(rv = prefix_check(st, i, hu_mov_rule ? IN_CPD_OTHER : IN_CPD_BEGIN, compoundflag))) {
+-if ((rv = suffix_check(st, i, 0, NULL, NULL, 0, NULL,
+-FLAG_NULL, compoundflag, h

Re: [Libreoffice] Questions about Easyhack 37007 Add Math symbol "There does not exist"

[Julien Nabet]

Le 13/09/2011 14:01, Caolán McNamara a écrit :

On Tue, 2011-08-23 at 22:46 +0200, Julien Nabet wrote:

I put the patch as it is now. (i haven't git updated my libo repository
since 2 days).
In addition of this patch, there are the 2 png files.

FWIW, the opensymbol font is available in extras/source/truetype the
source .sfd is available if you wanted to e.g. use fontforge to edit it
to play with adding a 0x2204 to it

C.

Hello,

Here what I've done with fontforge for the moment :
- add an element (it's added at the end, I don't know how to place it 
next to "existential" symbol)

- add info glyph to put U+2204
but I'm stuck with the glyph graph part.
If I import a png, the slot still shows X
I'll try to find more info but if someone has tips...

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

Re: [Libreoffice] 3.5 release from QA to point-zero

[Norbert Thiebaud]

On Tue, Sep 13, 2011 at 2:42 PM, Cor Nouws  wrote:
>
> Thus the solution is: earlier feature freeze.

I disagree that this is _the_ solution. we could feature freeze
today... and that would not change a things unless QA is actually
done... and reciprocally, there is no need for a feature freeze to
start doing serious QA work... that is, even if a couple of feature
were to be integrated in the 2 or 3 weeks you may want to extend the
freeze, that still would translate in 95%+ of the code untouched in
these 2 to 3 weeks.

That is why I mentioned what mmeeks translated into a 'slushy freeze',
that is a period pre-official freeze where we self-impose an elevated
attention to commit breakages or a 'quiet period' if you will, where
emphasis is on bug fixing... in counterpart we need to get QA used to
QA master. Heck I even thing we could function that wall all the way
to RC1 (and use the notion o 'beta' just as a 'state of affair'
buzzword, but still on master) If someone really want to commit
invasive/dangerous things in the pre-RC period, then they should do a
feature branch until we branch for RC1. at RC1 you get 2 full weeks to
do a formal QA campaign, and then go on weekly RC... Again with QA
using daily build to verify asap that bug are closed... If continuous
QA was paid attention to, the formal RC1 QA should be mostly a matter
of verifying that things do still work.

I strongly believe that the best way to have a quality release is to
have a process that tend to make RC1 QA an acceptance test rather than
a 'let's start finding the bugs' starting point, which I feel is
pretty much what happened for 3.4... Granted for the 3.4 release,
master has seen pretty invasive change quite shortly prior to the
official branching for beta ( due to m106 merge mostly), so certainly
the dev side of the house made it very hard for QA to kick in gear in
a timely manner but we will _not_ have that again for 3.5.
(actually it has become very very unlikely that we will have any kind
of massive merge anymore. any works pulled from an old CWS or AOOo --
if they start coding something useful -- will necessarily be in the
form of patch series with limited functional scope)

What the QA team can do this time around though, is not hold a grunge
against the mistake that were done in 3.4 and em-brass the goal that
master be 'should deliverable every day' (1).
Of course that is an extreme requirement... but the idea behind this
motto is that we should aim to be in a position such that at any given
day, we could decide to branch a RC1 for the next version.

The elephant in the room to make that (and quite frankly any other QA
approach) a viable reality is automated testing. These are hard, and
even harder when GUI is involved, but they are well worth it.  Stephan
Bergmann just took up the goal of getting subsequent tests running
again into daily build.. that is a great step in the right
direction...


Norbert

(1) that is why I do not give to much weight to the objection about
'moving the freeze date'. We choose a fairly rapid release schedule,
if a feature cannot make it into one release... it will make the next
one... six month later... it is not like missing the cut-off limit
means 2 to 3 years delay anymore...
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] duplicateif in vcl/source/gdi/outdev3.cxx

[Eike Rathke]

Hi julien2412,

On Tuesday, 2011-09-13 13:03:41 -0700, julien2412 wrote:

> Here's another "duplicateif" detected by cppcheck (thanks to Jesse's report
> ;-) )in vcl/source/gdi/outdev3.cxx (line 1999) :
> if( nMatchType & IMPL_FONT_ATTR_OTHERSTYLE )
> {
> if( !(nMatchType & IMPL_FONT_ATTR_OTHERSTYLE) )
> nTestMatch -= 1;
> }
> else if( nMatchType & IMPL_FONT_ATTR_OTHERSTYLE )
> nTestMatch -= 1;

I'd call that a triplicateif.. actually doing nothing.

> I tried to find from when it's been there but after 5 minutes of searching
> in gitk, I gave up.
> (if someone knows a quick way to find at which commit a specific change has
> been made... )

git log -G is your friend.

git log -G 'nMatchType.+IMPL_FONT_ATTR_OTHERSTYLE' vcl/source/gdi/outdev3.cxx

leads to
git show 4b2ab50308532bd070d9af4ef3d4893256cbe931

a CWS integration consisting of
git show c34627e6c9722436a2c2627f4f52b4b2ddf0d95a
and a following
git show ddb0bc2ec0f4e65168003549cd15000b4c0b8aea


> Could someone explain the logic of all this ? First I thought about a typo
> but even with 1 typo, it means nothing.

The original intent of that construct, even when seen with the removed
code in between, isn't really clear to me, but the negated condition
looks like a copy&paste error from the code that was removed in commit
ddb0bc2ec0f4e65168003549cd15000b4c0b8aea, with

// IMPL_FONT_ATTR_OTHERSTYLE- OldStyle, ... so negativ points

I conclude that indeed a negative weight should be added, so

if (nMatchType & IMPL_FONT_ATTR_OTHERSTYLE)
nTestMatch -= 1;

looks right to me.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] 3.5 release from QA to point-zero

[Cor Nouws]

Hi Caolán,

Caolán McNamara wrote (13-09-11 12:30)

On Tue, 2011-09-13 at 08:26 +0200, Cor Nouws wrote:

Hope I have made my concerns a bit more clear now.


Not really, I'm probably in the same boat as Kohei and somewhat confused


Ah good to read. Real devs never are good in understanding my more 
abstract communications :-)



by the whole thread. Maybe we need *shorter* emails that don't try to be
polite ;-) Problem at the top, proposed solutions afterwards.


So:
I have seen no data that convinces me that there is enough time between 
feature freeze and release to ensure reasonable quality.
And I have reasons to be cautious, because I know how hard it is to make 
time free for good testing and reporting + that we see so little 
LOMaster bugs being reported, which I consider a sign of lack of 
attention, rather than a sign of absence of bugs.


Thus the solution is: earlier feature freeze.

That is short .. however, maybe I overlook some data/facts, and have a 
wrong understanding of the situation. (Therefore my apparently to 
complicated attempt to get first a mutual understanding of the playing 
field etc.)



"I think 3-5 will be a crap release because there's too many changes
that I don't think we'll be able to test between now and release", is
that the summary ? or "I believe 3-4 was a crap release because of X, Y
and Z, I think we can avoid that by D".


Ah yes, short too. I choose the first. But that is neither my style, nor 
my belief - only my fear.



I never felt we got specifics on the "3-4 was bad". I'm not saying it


Devs experince this different from people in marketing and l10n groups, IMO.

(

So to try and avoid
getting caught by windows-specific bugs we are now making windows
dailies available. That should help on that front anyway.


which is great! )


--
 - Cor
 - http://nl.libreoffice.org

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

[Libreoffice] duplicateif in vcl/source/gdi/outdev3.cxx

[julien2412]

Hello,

Here's another "duplicateif" detected by cppcheck (thanks to Jesse's report
;-) )in vcl/source/gdi/outdev3.cxx (line 1999) :
if( nMatchType & IMPL_FONT_ATTR_OTHERSTYLE )
{
if( !(nMatchType & IMPL_FONT_ATTR_OTHERSTYLE) )
nTestMatch -= 1;
}
else if( nMatchType & IMPL_FONT_ATTR_OTHERSTYLE )
nTestMatch -= 1;

I tried to find from when it's been there but after 5 minutes of searching
in gitk, I gave up.
(if someone knows a quick way to find at which commit a specific change has
been made... )

Could someone explain the logic of all this ? First I thought about a typo
but even with 1 typo, it means nothing.

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/duplicateif-in-vcl-source-gdi-outdev3-cxx-tp807p807.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: [Libreoffice] [PUSHED][patch] memset used on struc with std::vector / Windows code

[Eike Rathke]

Hi Pierre-André,

On Tuesday, 2011-09-13 19:52:23 +0200, Pierre-André Jacquod wrote:

> The fact to change to class and use boost::noncopyable is an
> improvement not related to this point I guess,

Yes.

> since before the copy-ctor and copy assignment would have worked with
> the struct.

Well, it would had worked by accident.. and not done the right thing. It
would had copied pServicesSvr and the instance handles and refcount, all
these would had been out of sync if the underlying real data changed.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: cppcheck duplicate if expressions in bulmaper.cxx (sd part)

[julien2412]

I had forgot this topic sorry.
Commited and pushed on Master.
Thank you to both of you for your advice.

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/cppcheck-duplicate-if-expressions-in-bulmaper-cxx-sd-part-tp3321094p578.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: [Libreoffice] [REVIEWED] [PUSHED 3-4] cherry-pick to 3-4: fix fdo#39485 Data corruption for matrices

[Kohei Yoshida]

On Sun, 2011-09-11 at 21:36 +0200, Eike Rathke wrote:
> Hi,
> 
> Please review and cherry-pick to 3-4
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=90e489f068d09aaaf46ab15d35091198ed84bed1
> 
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39485

Reviewed and tested, and pushed to the 3-4 branch with my sign-off.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc

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

Re: [Libreoffice] [REVIEW] cherry-pick to 3-4: fix fdo#40590 defined names not resolved during file load

[Eike Rathke]

Hi Kohei,

On Tuesday, 2011-09-13 11:50:03 -0400, Kohei Yoshida wrote:

> Actually, I would feel comfortable not cherry-picking these changes, but
> wait until 3.5.  There are quite a number of existing hacks in this area
> that are specially tailored for importing formula expressions, and they
> make it a bit harder for me to decide whether this change won't
> introduce issues in some weird corners.  Sorry about this.

Ok, that's what reviews and sign-offs are for ;)

The only "weird corners" that come to my mind are places where

a) AddString() would be abused similarly to the cases I changed.
   I thoroughly inspected every use of AddString() in the code but
   didn't find any other, both in master and 3-4.

b) lcl_ScDocFunc_CreateTokenArrayXML() is used in a context it's not
   supposed to be used. I _think_ this doesn't happen, as the only
   places using it are ScDocFunc::InterpretEnglishString() and
   ScDocFunc::EnterMatrix(), both if pDoc->IsImportingXML()==true


  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED][patch] memset used on struc with std::vector / Windows code

[Pierre-André Jacquod]

Hello,


That should happen in a DdeInstData ctor instead.


I intended to do something easier:
struct DdeInstData
{
short x;

DdeInstData(); // and of course implementing this
}


I've moved it into the ctor now.


Thanks, I was not able to react very quickly, making this during free 
time ... and on Linux. Sorry.


Just for my education [answer is optional]:

The fact to change to class and use boost::noncopyable is an improvement 
not related to this point I guess, since before the copy-ctor and copy 
assignment would have worked with the struct.


Or did I missed something?

Thanks.

regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] cherry-pick to 3-4: fix fdo#40590 defined names not resolved during file load

[Eike Rathke]

Hi Kohei,

On Tuesday, 2011-09-13 11:33:34 -0400, Kohei Yoshida wrote:

> However, while trying to re-create a test case for our unit test, I've
> discovered an issue.  I'd like to get your take on it.
> 
> Here is what I did.
> 
> 1. Create a new spreadsheet document.
> 2. Go to Insert - Names - Define
> 3. Create a new name MyName1 and assign "1+2" to it.  Push Add to add
> this name, but don't close the dialog yet.
> 4. Create a new name MyName2 and assign "MyName1*10".  Push Add to add
> this name.
> 5. MyName2 becomes myname1*10 (all lowercase), which is a sign that the
> name compilation has failed.
> 
> Having said this, this problem already exists before your changes, so
> I'm fine cherry-picking these commits to at least fix the reported case.
> Let me do a little more review before making the final call.  The change
> is non-trivial, so I have to dig a little more to understand this code
> change...

Actually that problem exists in every version.. the reason is that the
new names exist only in the dialog's collection until one confirms the
dialog with OK, so the compiler doesn't find the name in the "real"
collection of the document/sheet. This could only be overcome by passing
the dialog's name collection to the compiler to make it known at that
step.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Problem using Java for integration from JBoss 5.1

[Herter, Scott]

We have been using OpenOffice in the past to convert RTF documents to PDF and 
to print them.  We have upgraded and after updating the Jar files in our EAR 
file we now get an exception:

2011-09-13 10:58:19,725 ERROR [STDERR] (http-0.0.0.0-8080-1) Error   DOMSource 
cannot be processed: check that saxon9-dom.jar is on the classpath
2011-09-13 10:58:19,725 ERROR [STDERR] (http-0.0.0.0-8080-1) 
net.sf.saxon.trans.XPathException: DOMSource cannot be processed: check that 
saxon9-dom.jar is on the classpath
2011-09-13 10:58:19,725 ERROR [STDERR] (http-0.0.0.0-8080-1)   at 
net.sf.saxon.event.Sender.send(Sender.java:226)
2011-09-13 10:58:19,725 ERROR [STDERR] (http-0.0.0.0-8080-1)   at 
net.sf.saxon.IdentityTransformer.transform(IdentityTransformer.java:29)
2011-09-13 10:58:19,725 ERROR [STDERR] (http-0.0.0.0-8080-1)   at 
com.napersoft.databases.R70.NRUtils.decodeXML(NRUtils.java:1160)
...

Without the OpenOffice 3.3 jar files that code works fine, with the 3.3 Jar 
files it fails with the message above.  The code being invoked has nothing to 
do with OpenOffice, it has to do with formatting some XML for display.  I 
noticed that there is a saxon9.jar as part of the 3.3 jars and that is included 
in the manifest as a jar file dependency and it is bundled with the EAR file.  
It is like some of the Jar files are replacing or interfering with the 
javax.xml.* packages provided by JBoss.

Is there some minimal set of 3.3 jars I can use?  Most of the time we are 
loading an RTF document and converting it to PDF or printing it.  We also use 
cursors to search for bookmarks and insert page breaks as well as get a page 
count.

Any help would be appreciated.

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

Re: [Libreoffice] l10ntools ".src" encoding

[Andras Timar]

Hi,

2011/9/13 Caolán McNamara :
> I imagine that in the real-world the .src files are always in utf-8
> format ?
>

Yes, all are in utf-8. As far as I remember utf-8 was introduced in OOo 2.0.

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

Re: [Libreoffice] [REVIEW] cherry-pick to 3-4: fix fdo#40590 defined names not resolved during file load

[Kohei Yoshida]

On Tue, 2011-09-13 at 11:33 -0400, Kohei Yoshida wrote:
> Having said this, this problem already exists before your changes, so
> I'm fine cherry-picking these commits to at least fix the reported
> case.
> Let me do a little more review before making the final call.  The
> change
> is non-trivial, so I have to dig a little more to understand this code
> change... 

Actually, I would feel comfortable not cherry-picking these changes, but
wait until 3.5.  There are quite a number of existing hacks in this area
that are specially tailored for importing formula expressions, and they
make it a bit harder for me to decide whether this change won't
introduce issues in some weird corners.  Sorry about this.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc

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

Re: [Libreoffice] [REVIEW] cherry-pick to 3-4: fix fdo#40590 defined names not resolved during file load

[Kohei Yoshida]

On Sun, 2011-09-11 at 15:37 +0200, Eike Rathke wrote:
> Hi,
> 
> Please review and cherry-pick to 3-4
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f42e4d03b04204b7a864f3c5c9c03548f5e2392
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=34c9a01b075788653b89c244eb8b3fcee54bfa68
> 
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=40590

Hi Eike,

So, I've reviewed your changes, and confirms that it indeed fixes the
use case reported in fdo#40590.

However, while trying to re-create a test case for our unit test, I've
discovered an issue.  I'd like to get your take on it.

Here is what I did.

1. Create a new spreadsheet document.
2. Go to Insert - Names - Define
3. Create a new name MyName1 and assign "1+2" to it.  Push Add to add
this name, but don't close the dialog yet.
4. Create a new name MyName2 and assign "MyName1*10".  Push Add to add
this name.
5. MyName2 becomes myname1*10 (all lowercase), which is a sign that the
name compilation has failed.

Having said this, this problem already exists before your changes, so
I'm fine cherry-picking these commits to at least fix the reported case.
Let me do a little more review before making the final call.  The change
is non-trivial, so I have to dig a little more to understand this code
change...

Regards,

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc

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

Re: [Libreoffice] core dump in dmake on Windows - debugging procedure?

[Noel Grandin]

Ah thanks, I forgot to specify
  --with-max-jobs=1 --with-num-cpus=1
when running configure and it defaulted to 2.

Norbert Thiebaud wrote:
> On Tue, Sep 13, 2011 at 8:09 AM, Noel Grandin  wrote:
>> Hi
>>
>> I'm getting a core dump inside dmake with current HEAD on a Windows 7 box
>> building with Visual Studio 2008.
>> What is the debugging procedure?
>>
>> Thanks, Noel Grandin.
>>
>> c:/libreoffice/git2/libo/workdir/wntmsci12.pro/CxxObject/hwpfilter/qa/cppunit/te
>> st_hwpfilter.o
>>Creating library
>> c:/libreoffice/git2/libo/workdir/wntmsci12.pro/LinkTarget/Cp
>> punitTest/itest_hwpfilter_test_hwpfilter.lib and object
>> c:/libreoffice/git2/libo
>> /workdir/wntmsci12.pro/LinkTarget/CppunitTest/itest_hwpfilter_test_hwpfilter.exp
>>
>> /usr/bin/sh: line 1:  4656 Segmentation fault  (core dumped) make -s -r
>> -j2
> you need to build -with -j1 or use make 3.82
> as the message during ./autogen.sh should have indicated...
>
> Norbert
>
> PS: your core dump was not in dmake, but in make (gnu make)
>

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


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

[Libreoffice] l10ntools ".src" encoding

[Caolán McNamara]

Looking through l10tools there were some ByteString encoding A to
ByteString encoding B things in there, where pragma's in .src files
seemed to in the past indicate their encoding which would then get
converted to MS1252 (or something of that nature)

As far as I could tell, there are no such pragmas still in use in
any .src file, nor was there any way to change the "destination
encoding" away from 1252, so all it could possibly do is convert from
1252 to 1252, i.e. no-op if I read it correctly.

So I removed it all, which allows me to throw out a goodly part of the
old tools ByteString. Now if there *are* any pragmas that control
encodings in .src files generated somehow the l10ntools will bail out
with an exit(-1) and error message, a build here on some random
languages works fine, so just a heads up if I've missed something
obvious.

I imagine that in the real-world the .src files are always in utf-8
format ?

C.

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

Re: [Libreoffice] core dump in dmake on Windows - debugging procedure?

[Norbert Thiebaud]

On Tue, Sep 13, 2011 at 8:09 AM, Noel Grandin  wrote:
> Hi
>
> I'm getting a core dump inside dmake with current HEAD on a Windows 7 box
> building with Visual Studio 2008.
> What is the debugging procedure?
>
> Thanks, Noel Grandin.
>
> c:/libreoffice/git2/libo/workdir/wntmsci12.pro/CxxObject/hwpfilter/qa/cppunit/te
> st_hwpfilter.o
>    Creating library
> c:/libreoffice/git2/libo/workdir/wntmsci12.pro/LinkTarget/Cp
> punitTest/itest_hwpfilter_test_hwpfilter.lib and object
> c:/libreoffice/git2/libo
> /workdir/wntmsci12.pro/LinkTarget/CppunitTest/itest_hwpfilter_test_hwpfilter.exp
>
> /usr/bin/sh: line 1:  4656 Segmentation fault  (core dumped) make -s -r
> -j2

you need to build -with -j1 or use make 3.82
as the message during ./autogen.sh should have indicated...

Norbert

PS: your core dump was not in dmake, but in make (gnu make)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Stastical functions and ODF 1.2

[Regina Henschel]

Hi Wolfgang,

Wolfgang Pechlaner schrieb:

Hallo,

I'm just checking, the implemtation with ODF 1.2 specification. There
are some functions with new parameters, and also new functions
(LEGALICY.**). I've therefore questions.
1) shall I write bug-reports ?
2) If yes, only one, or for every function.


Yes, for separate for each function

3) shall I implement the new functions, and try, to extend the existings.


Please, before you start, discuss here what you think is needed to do to 
fullfill ODF and how you will solve it. As far as I remember, especially 
FDIST has fundamental problems.


Kind regards
Regina

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

[Libreoffice] core dump in dmake on Windows - debugging procedure?

[Noel Grandin]

Hi

I'm getting a core dump inside dmake with current HEAD on a Windows 7 box 
building with Visual Studio 2008.
What is the debugging procedure?

Thanks, Noel Grandin.

c:/libreoffice/git2/libo/workdir/wntmsci12.pro/CxxObject/hwpfilter/qa/cppunit/te
st_hwpfilter.o
   Creating library c:/libreoffice/git2/libo/workdir/wntmsci12.pro/LinkTarget/Cp
punitTest/itest_hwpfilter_test_hwpfilter.lib and object c:/libreoffice/git2/libo
/workdir/wntmsci12.pro/LinkTarget/CppunitTest/itest_hwpfilter_test_hwpfilter.exp

/usr/bin/sh: line 1:  4656 Segmentation fault  (core dumped) make -s -r -j2
dmake:  Error code 139, while making 'all'
Retrying /cygdrive/c/libreoffice/git2/libo/tail_build/prj


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


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

[Libreoffice] Stastical functions and ODF 1.2

[Wolfgang Pechlaner]

Hallo,

I'm just checking, the implemtation with ODF 1.2 specification. There 
are some functions with new parameters, and also new functions 
(LEGALICY.**). I've therefore questions.

1) shall I write bug-reports ?
2) If yes, only one, or for every function.
3) shall I implement the new functions, and try, to extend the existings.

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

[Libreoffice] [PUSHED][patch] memset used on struc with std::vector / Windows code

[Caolán McNamara]

On Sun, 2011-09-11 at 15:48 +0200, Eike Rathke wrote:
> Hi Pierre-André,
> 
> On Sunday, 2011-09-11 14:20:57 +0200, Pierre-André Jacquod wrote:
> 
> > the struct DdeInstData contains a std::vector, but was initialized
> > with memset( pData,0,sizeof(DdeInstData) )
> 
> Good catch.

Yup, great catch. Thanks for this, pushed now.

> That should happen in a DdeInstData ctor instead.

I've moved it into the ctor now.

C.

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

Re: [Libreoffice] Questions about Easyhack 37007 Add Math symbol "There does not exist"

[Caolán McNamara]

On Tue, 2011-08-23 at 22:46 +0200, Julien Nabet wrote:
> I put the patch as it is now. (i haven't git updated my libo repository 
> since 2 days).
> In addition of this patch, there are the 2 png files.

FWIW, the opensymbol font is available in extras/source/truetype the
source .sfd is available if you wanted to e.g. use fontforge to edit it
to play with adding a 0x2204 to it

C.



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

Re: [Libreoffice] Questions about Easyhack 37007 Add Math symbol "There does not exist"

[Caolán McNamara]

On Thu, 2011-08-25 at 14:14 -0700, julien2412 wrote:
> Metrics seem different but perhaps I'm wrong or perhaps I should have done
> the test in another way.

Thanks for doing this. Yeah, they're quite different really. Its not so
much that they *look* different which wouldn't be too much of a problem,
but clearly the glyphs are of different sizes so if e.g. we removed
StarSymbol and used Stix instead then existing equations wouldn't flow
in the available space the same way as they currently do. With knock on
effects for writer and calc as well as they use those bullets.

This doesn't of course preclude using Stix for *new* documents, just
that opensymbol has to hang around to render pre-existing documents.

C.

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

[Libreoffice] [PUSHED][PATCH] HTML export cleanup

[Caolán McNamara]

On Sat, 2011-08-20 at 13:00 +0300, Harri Pitkänen wrote:
> A few cleanups and removal of HTML 3.2 from HTML export options. In case HTML 
> 3.2 has been previously selected as the HTML variant it will be converted to 
> Netscape Navigator.

Marking that these got pushed back on Aug 13th by Tor.

C.


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

[Libreoffice] [PUSHED][PATCH] BUG 38486

[Caolán McNamara]

On Fri, 2011-08-12 at 11:14 +0200, Jenei Gábor wrote:
> Please review the patch and push it to git.

Marking that this got pushed by Norbert back on Aug 12.

C.

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

Re: [Libreoffice] [PUSHED][PATCH] convert xml2cmp to gbuild

[Bjoern Michaelsen]

Hi all,

On Tue, 13 Sep 2011 08:40:34 +0200
Stephan Bergmann 
wrote:

> On 09/13/2011 08:18 AM, Stephan Bergmann wrote:
> > On 09/12/2011 11:23 PM, Norbert Thiebaud wrote:
> >> On Mon, Sep 12, 2011 at 4:04 PM, Peter
> >> Foley wrote:
> >>>
> >>> Another gbuild conversion.
> >>
> >> Nice.
> >>
> >> Pushed, Thanks.
> >
> > It ~looks like this broke the latest Mac OSX gcc-4.0.1 (PPC)
> > tinderbox build, see
> > .
> > (Though I have no clue what went wrong; at least cannot easily
> > reproduce on unxlngx6.pro.)
> 
> I think the problem is using static libraries.  IIRC, on Mac OS X, if 
> you link against two static libs -lA -lB, order is important, and if
> B need symbols from A (that the executable into which the two are
> linked does not already take from A), it won't find them.  What could
> help in this specific case is to switch the order of x2c_support and
> x2c_xcd in xml2cmp/Executable_*.mk.  (Will try that out on my Mac,
> but that can take a while.  Another solution might be to use Mac OS X
> ld switches -all_load or -force_load.)

at

http://cgit.freedesktop.org/libreoffice/core/tree/solenv/gbuild/platform/unxgcc.mk#n312

for the general gcc case we are wrapping the static libs in the linker
command in start-group/end-group, which should help, but it seems like
this is missing on the osx platform files. Maybe doing the same there
would help?

Best,

Bjoern



-- 
https://launchpad.net/~bjoern-michaelsen


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

[Libreoffice] [PUSHED][PATCH] Use STL find() in SvxNumberFormatShell

[Caolán McNamara]

On Tue, 2011-08-09 at 01:32 +0200, Maciej Rumianowski wrote:
> Hi Eike,
> Dnia 2011-08-07, nie o godzinie 21:31 +0200, Eike Rathke pisze:
> > 
> > I suggest
> > 
> > ::std::vector::iterator GetAdded_Impl( size_t nKey );
> > 
> As promised I have done this :)

Just marking that this got PUSHED back on the 9th Aug.

C.

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

[Libreoffice] [PUSHED][PATCH] add missing quotes to bashscript allowing space in variables

[Caolán McNamara]

On Fri, 2011-08-05 at 13:08 +0200, Tomáš Chvátal wrote:
> Dne 4.8.2011 22:06, Philipp Weissenbacher napsal(a):
> > Hi!
> > You probably forgot to attach your patch ;-).
> >
> > Philipp
> >
> > On Tuesday, 2 August 2011, Tomas Chvatal  wrote:
> >
> Yep,
> you are right, I sent it off this thread so it is best to reattach again :)

This one seems to have slipped through the net. *Seems* sane anyway :-)

Now pushed, had to use git am --ignore-whitespace to get it to apply,
maybe that's why it didn't get pushed.

C.

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

Re: [Libreoffice] unnecessary build actions?

[Caolán McNamara]

On Thu, 2011-09-01 at 12:12 -0400, Kevin Hunter wrote:
> Hullo LibO Devs,
> 
> In a search of my build.log for libuno_sal, the first reference I see 
> points me to lines that look line this (newlines added for email clarity):
> 
> -
> rm -f ../unxlngx6/lib/check_libuno_sal.so.3
> 
> mv ../unxlngx6/lib/libuno_sal.so.3 ../unxlngx6/lib/check_libuno_sal.so.3
> 
> [...]/solenv/bin/checkdll.sh  [...]  ../unxlngx6/lib/check_libuno_sal.so.3
> 
> rm -f ../unxlngx6/lib/libuno_sal.so
> 
> cd ../unxlngx6/lib && ln -s libuno_sal.so.3 libuno_sal.so
> 
> Making:libuno_sal.so.3
> 
> ccache g++ [...] -o ../unxlngx6/lib/libuno_sal.so.3 [...]
> -
> 
> Question: if we're making libuno_sal.so.3 afresh, what's the rational to 
> bother performing various checks on it prior to making it?

Odd, if I touch rtl/source/locale.c and do "build" I get...
gcc  ..   -o ../../unxlngx6/obj/locale.o locale.c
g++ ... -o ../unxlngx6/lib/libuno_sal.so.3 ...
rm -f ../unxlngx6/lib/check_libuno_sal.so.3
mv ../unxlngx6/lib/libuno_sal.so.3 ../unxlngx6/lib/check_libuno_sal.so.3
Checking DLL ../unxlngx6/lib/check_libuno_sal.so.3 ...
rm -f ../unxlngx6/lib/libuno_sal.so
cd ../unxlngx6/lib && ln -s libuno_sal.so.3 libuno_sal.so

i.e. build, then check, not what you seem to have, i.e. check then build

> Further, I don't see where the first line's reference to 
> check_libuno_sal.so.3 comes from.  i.e.  When did it get built prior? 
> Similar question goes for line 2 above (mv ...).

The order they are supposed to happen (any maybe actually are happening,
just out-of-order build log due to parallel building or different
stdout/stderr streams) is as above, where the checking dll stuff is done
by checkdll in soltools/checkdll. i.e. compile to shared lib, rename it,
test it for sanity and rename it back if its ok, otherwise leave it
renamed as broken and abort.

> ...
> rm -f path/to/file
> gcc -o path/to/file [...]
> ...
> 
> That gcc command will just overwrite the file if it's there, no? 
> Therefore, why execute rm?

Don't see this either, perhaps I'm missing the obvious how-to-reproduce
this. Either way though, it looks like output from the "old-style"
build+dmake build system, rather that the "new-style" gmake build system
which stuff is migrating over to.

C.

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

Re: [Libreoffice] git account request

[Olivier Hallot]

Em 13-09-2011 07:26, Marco escreveu:


On Sun, 11 Sep 2011 23:07:20 +0200, Olivier Hallot 
 wrote:



Hi Marco

Do you mind to write some lines on how you succeded to have the big 
source code set under Eclipse CDT?




Hi Olivier,
I'll write down some wiki notes on the subject, as soon as possible.

Cheers,
-- Marco


Horay!

--
Olivier Hallot
Founder, Steering Commitee Member - The Document Foundation
Voicing the enterprise needs
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812

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

Re: [Libreoffice] 3.5 release from QA to point-zero

[Caolán McNamara]

On Tue, 2011-09-13 at 08:26 +0200, Cor Nouws wrote:
> Hope I have made my concerns a bit more clear now.

Not really, I'm probably in the same boat as Kohei and somewhat confused
by the whole thread. Maybe we need *shorter* emails that don't try to be
polite ;-) Problem at the top, proposed solutions afterwards.

"I think 3-5 will be a crap release because there's too many changes
that I don't think we'll be able to test between now and release", is
that the summary ? or "I believe 3-4 was a crap release because of X, Y
and Z, I think we can avoid that by D".

I never felt we got specifics on the "3-4 was bad". I'm not saying it
was awesome, just to hard to get a handle on something nebulous. One
possibility is that it was stuff like the dictionary-upgrade failure on
windows. That was pretty gruesome I suppose. So to try and avoid
getting caught by windows-specific bugs we are now making windows
dailies available. That should help on that front anyway.

C.

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

Re: [Libreoffice] git account request

[Marco]

On Sun, 11 Sep 2011 23:07:20 +0200, Olivier Hallot  
 wrote:



Hi Marco

Do you mind to write some lines on how you succeded to have the big  
source code set under Eclipse CDT?




Hi Olivier,
I'll write down some wiki notes on the subject, as soon as possible.

Cheers,
-- Marco

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] From sal/cppunit.h to sal/precppunit.hxx

[Stephan Bergmann]

On 09/13/2011 11:50 AM, Lubos Lunak wrote:

On Monday 12 of September 2011, Stephan Bergmann wrote:

Hi all,

With
  come three changes for CppUnit based tests in the
LibO code base:


  Please update http://wiki.documentfoundation.org/Development/Unit_Tests to
match the current status.


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

[Libreoffice] [PUSHED] Mi first very little patch

[Caolán McNamara]

On Sun, 2011-09-11 at 22:04 +0200, CaStarCo wrote:
> I've created a second (very little too) patch to reduce the scope of a
> variable.

Thanks for this, looks good. Pushed now. Are you building under windows
btw ?

C.

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

Re: [Libreoffice] From sal/cppunit.h to sal/precppunit.hxx

[Lubos Lunak]

On Monday 12 of September 2011, Stephan Bergmann wrote:
> Hi all,
>
> With
> df0cbd510eda28e2f7cef9> come three changes for CppUnit based tests in the
> LibO code base:

 Please update http://wiki.documentfoundation.org/Development/Unit_Tests to 
match the current status.

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

Re: [Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build

[Michael Stahl]

On 13.09.2011 11:33, Stephan Bergmann wrote:
> On 09/13/2011 11:20 AM, Stephan Bergmann wrote:
>> On 09/13/2011 11:18 AM, Michael Stahl wrote:
>>> guess somebody should put back the solenv deps :)
>>
>> doing it right now
> 
> 
> 
> -Stephan

looks like the Mesa module also has the problem, can you fix that as well?

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

Re: [Libreoffice] helpful debugging writer cut and paste stuff

[Caolán McNamara]

On Mon, 2011-09-12 at 19:02 +0200, Miklos Vajna wrote:
> On Mon, Sep 12, 2011 at 05:06:27PM +0100, Caolán McNamara 
>  wrote:
>
> Thanks, last time I had to debug that, I used a memory stream and just
> dumped the contents to stdout, but your solution is smarter. :)

*mumble*, for a moment I played with the idea of a "TeeStream" which
would take a two streams as an argument, writing/reading to both so
could wrap any stream and simultaneously mirror any changes to the
wrapped stream to a debugging file, but dismissed it as silly effort.

> > As an aside, is the "editengine" rtf parser going to be touched
> > by the rtf re-work[1], or was it just the writer im/export ?
> 
> The later. The editengine one is used by calc, right?

Yeah, the editengine (in "editeng" these days) is basically the drawing
layer's textbox text renderer which is used by draw, calc and so forth.

C.

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

Re: [Libreoffice] additional symbols or alternatively stencils in Draw templates

[Caolán McNamara]

On Mon, 2011-09-12 at 23:58 +0200, Ulrich Moser wrote:
> A first step in that direction would be offering more drawing symbols 
> like a symbol set for BPMN. If someone could give some assistance on how 
> such an additional symbol set could be integrated I would be willing to 
> provide it. The further step would be implementing stencils in Draw 
> templates.

So, the existing galleries are in "extras/source/gallery". Perhaps Kami
can give an overview of "how to add a new gallery" to extras for the
"integrated into LibreOffice" case ?

> Is there anybody else interested in such an extension and able to aid 
> with the programming part?

Galleries can be deployed as extensions as well as integrated right into
the installed product, there should be some preexisting examples
available, googling on "Gallery Extensions".

FWIW I have an extension at
http://svn.fedorahosted.org/svn/openoffice.org-diafilter/ which is a
gallery extension (as well as a import filter for the dia format) 

http://svn.fedorahosted.org/svn/openoffice.org-diafilter/gallery/gallerygen.odg 
contains a macro to make a gallery from a dir IIRC

C.

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

Re: [Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build

[Stephan Bergmann]

On 09/13/2011 11:20 AM, Stephan Bergmann wrote:

On 09/13/2011 11:18 AM, Michael Stahl wrote:

guess somebody should put back the solenv deps :)


doing it right now




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

Re: [Libreoffice] [PUSHED][PATCH] convert xml2cmp to gbuild

[Stephan Bergmann]

On 09/13/2011 08:40 AM, Stephan Bergmann wrote:

On 09/13/2011 08:18 AM, Stephan Bergmann wrote:

On 09/12/2011 11:23 PM, Norbert Thiebaud wrote:

On Mon, Sep 12, 2011 at 4:04 PM, Peter Foley
wrote:


Another gbuild conversion.


Nice.

Pushed, Thanks.


It ~looks like this broke the latest Mac OSX gcc-4.0.1 (PPC) tinderbox
build, see
.

(Though I have no clue what went wrong; at least cannot easily reproduce
on unxlngx6.pro.)


I think the problem is using static libraries. IIRC, on Mac OS X, if you
link against two static libs -lA -lB, order is important, and if B need
symbols from A (that the executable into which the two are linked does
not already take from A), it won't find them. What could help in this
specific case is to switch the order of x2c_support and x2c_xcd in
xml2cmp/Executable_*.mk. (Will try that out on my Mac, but that can take
a while. Another solution might be to use Mac OS X ld switches -all_load
or -force_load.)


Hm, can't reproduce the problem on my Mac OS X 10.6 box.  Strange.

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

Re: [Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build

[Stephan Bergmann]

On 09/13/2011 11:18 AM, Michael Stahl wrote:

On 13.09.2011 11:09, Stephan Bergmann wrote:

On 09/13/2011 01:00 AM, Norbert Thiebaud wrote:

On Mon, Sep 12, 2011 at 4:53 PM, Michael Stahl   wrote:

On 12.09.2011 23:26, Peter Foley wrote:

--- a/MathMLDTD/prj/build.lst
+++ b/MathMLDTD/prj/build.lst
@@ -1,3 +1,2 @@
-md   MathMLDTD   :   solenv NULL
-md   MathMLDTD   usr1- 
  all md_mkout NULL
-md   MathMLDTD\prj   get - 
  all md_prj NULL
+md   MathMLDTD   : NULL


you remove the dependency on solenv; it seems that currently we don't
have any module (except solenv of course, and "testautomation" which
doesn't do anything) that does not directly or indirectly depend on
solenv; i wonder why that is?  is there perhaps some reason that modules
must depend on solenv?


isn't that for the basic setup of solver ? (mkdir od bin inc etc..)
but I believe Deliver.mk do the mkdir by precaution anyways.. so that
should no have any impact here..


But that might explain the strange tinderbox failure at
,
a missing 350minor.mk early one, where xml2cmp is one of the first three
modules being built (in parallel).

-Stephan


thanks for reminding me, 3X0minor.mk was the thing that i only vaguely
remembered.  apparently it's still necessary in converted modules
because we start gmake indirectly via dmake.

guess somebody should put back the solenv deps :)


doing it right now

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

Re: [Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build

[Michael Stahl]

On 13.09.2011 11:09, Stephan Bergmann wrote:
> On 09/13/2011 01:00 AM, Norbert Thiebaud wrote:
>> On Mon, Sep 12, 2011 at 4:53 PM, Michael Stahl  wrote:
>>> On 12.09.2011 23:26, Peter Foley wrote:
 --- a/MathMLDTD/prj/build.lst
 +++ b/MathMLDTD/prj/build.lst
 @@ -1,3 +1,2 @@
 -md   MathMLDTD   :   solenv NULL
 -md   MathMLDTD   usr1 
-   all md_mkout NULL
 -md   MathMLDTD\prj   get  
-   all md_prj NULL
 +md   MathMLDTD   : NULL
>>>
>>> you remove the dependency on solenv; it seems that currently we don't
>>> have any module (except solenv of course, and "testautomation" which
>>> doesn't do anything) that does not directly or indirectly depend on
>>> solenv; i wonder why that is?  is there perhaps some reason that modules
>>> must depend on solenv?
>>
>> isn't that for the basic setup of solver ? (mkdir od bin inc etc..)
>> but I believe Deliver.mk do the mkdir by precaution anyways.. so that
>> should no have any impact here..
> 
> But that might explain the strange tinderbox failure at 
> , 
> a missing 350minor.mk early one, where xml2cmp is one of the first three 
> modules being built (in parallel).
> 
> -Stephan

thanks for reminding me, 3X0minor.mk was the thing that i only vaguely
remembered.  apparently it's still necessary in converted modules
because we start gmake indirectly via dmake.

guess somebody should put back the solenv deps :)

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

[Libreoffice] development summary: year 2011, week 36

[Petr Mladek]

Hi,

this time a brief summary of what happened during the 36th week in 2011
on LibreOffice repositories and the living branches:

+ master:LO-3.5 development
+ libreoffice-3-3:   fixes for LO-3.3.5 bug fix release
+ libreoffice-3-4:   fixes for LO-3.4.4 bug fix release

There are two logs for each branch:

+ bugfixes--week--.txt lists all commits that 
reference a proper
  bug id from a variety of trackers, i.e. #i... referring to the 
OpenOffice
  issuezilla, fdo# to freedesktop, rhbz# to RedHat bugzilla

+ commit-log--week--.txt lists all relevant commits 
on the actual
  source repositories

Many thanks to all contributors - you make all the difference!


Best Regards,
Petr
nothing this week
+ calc
+ speed up range name lookup by index. (bnc#715104) [Kohei Yoshida]
+ impress
+ fix hang in slideshow. (fdo#32861) [Thorsten Behrens]
+ libs-core
+ createProcessServiceFactory can't happen before sync (fdo#37195) [Caolán McNamara]
+ writer
+ fix leak in pdf export. (i#116448) [Andor Ertsey]
+ core
+ add cppunit test for SwScanner that would have caught (fdo#40449) [Caolán McNamara]
+ dbGridControl::RemoveColumn even if no corresponding Model column (fdo#40701) [Lionel Elie Mamane]
+ enable to replace the vendor name in Windows installer, (bnc#571489) [Andras Timar]
+ fix for Don't reset selected colour on tab switch (i#95158) [Katarina Machalkova]
+ fix hang in slideshow. (fdo#32861) [Thorsten Behrens]
+ fix reading of w:textbox contents (bnc#693388) [Luboš Luňák]
+ fix recalculate matrix formula dimension correctly (fdo#39485) [Eike Rathke]
+ fix stop abusing regular string token for XML import (fdo#40590) [Eike Rathke]
+ fmXGridPeer::getByIndex: Error checking of pGrid->GetModelColumnPos(nId) call (fdo#40701) [Lionel Elie Mamane]
+ importing Flip properties of custom shapes. (bnc#705985) [Muthu Subramanian]
+ kill O(n^2) complexity of unique bookmark name creation (i#118224) [Christoph Lutz]
+ related: always include xmlsecurity library for macro-security (fdo#40420) [Caolán McNamara]
+ related: don't crash on missing/failing xmlsecurity lib (fdo#40420) [Caolán McNamara]
+ related: we now know the bounds of the broken gcc versions (gcc#50255) [Caolán McNamara]
+ resolves/Related: uninitialized issymbol member variable (fdo#40449) [Caolán McNamara]
+ sb140: @executable_path -> @loader_path hack missed some instances (i#117079) [Stephan Bergmann]
+ sb140: avoid references to object across XAggregation::setDelegator boundary (i#114718) [Stephan Bergmann]
+ sb140: avoid ring-ref that keeps ref counted objects alive forever (i#116785) [Stephan Bergmann]
+ sb140: avoid uninitialized RGB values for full-transparency pixels (i#116872) [Stephan Bergmann]
+ sb140: avoid unncessary static class data members (which are destroyed too late) (i#117082) [Stephan Bergmann]
+ sb140: do not leak Lockfile instance (i#117084) [Stephan Bergmann]
+ sb140: do not leak Thread_Impl from desktop::Acceptor (i#116910) [Stephan Bergmann]
+ sb140: do not mis-use XTypeProvider.getImplementationId in XUnoTunnel.getSomething (i#117291) [Stephan Bergmann]
+ sb140: removed unused mutex guard (i#117294) [Stephan Bergmann]
+ sb140: sb140: clean up memory upon exit (i#116981) [Stephan Bergmann]
+ sb140: solenv/gbuilt/JunitTest.mk fails to remove the userdir (i#117080) [Stephan Bergmann]
+ sb140: solenv/gbuilt/{Cpp,J}unitTest.mk typos (i#117081) [Stephan Bergmann]
+ sb140: support ENABLE_SYMBOLS (i#117085) [Stephan Bergmann]
+ sb140: use ImplInheritanceHelper (i#117292) [Stephan Bergmann]
+ sb140: use auto_ptr to track member lifetime (i#116786) [Stephan Bergmann]
+ sb140: use rtl::Static (i#117295) [Stephan Bergmann]
+ spellchecking tried to keep a reference to a temporary (fdo#40449) [Caolán McNamara]
+ update shape fill preview on switch to this tab (i#95158) [Katarina Machalkova]
+ update to latest version of vcredist (fdo#40399) [Andras Timar]
nothing this week
+ calc
+ "thereof" should be translated to modern English [Lior Kaplan]
+ adjust the dialog size to make sure the bottom text is visible. [Kohei Yoshida]
+ crash when modifing a named range [Eike Rathke]
+ don't extend the merged area by one for shadows [Markus Mohrhard]
+ fixed various crashes due to newly introduced [Eike Rathke]
+ speed up range name lookup by index. (bnc#715104) [Kohei Yoshida]
+ impress
+ fix hang in slideshow. (fdo#32861) [Thorsten Behrens]
+ libs-core
+ createProcessServiceFactory can't happen before sync (fdo#37195) [Caolán McNamara]
+ don't rely on ../ure to find javaldx, use proper ../basis-link/ure-link [Lionel Elie Mamane]
+ writer
+ fix leak in pdf export. (i#116448) [Andor Ertsey]
+ binfilter
+ add back in unused ctor in order to have something for now [Caolán McNamara]
+ another ro

Re: [Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build

[Stephan Bergmann]

On 09/13/2011 01:00 AM, Norbert Thiebaud wrote:

On Mon, Sep 12, 2011 at 4:53 PM, Michael Stahl  wrote:

On 12.09.2011 23:26, Peter Foley wrote:

--- a/MathMLDTD/prj/build.lst
+++ b/MathMLDTD/prj/build.lst
@@ -1,3 +1,2 @@
-md   MathMLDTD   :   solenv NULL
-md   MathMLDTD   usr1- 
  all md_mkout NULL
-md   MathMLDTD\prj   get - 
  all md_prj NULL
+md   MathMLDTD   : NULL


you remove the dependency on solenv; it seems that currently we don't
have any module (except solenv of course, and "testautomation" which
doesn't do anything) that does not directly or indirectly depend on
solenv; i wonder why that is?  is there perhaps some reason that modules
must depend on solenv?


isn't that for the basic setup of solver ? (mkdir od bin inc etc..)
but I believe Deliver.mk do the mkdir by precaution anyways.. so that
should no have any impact here..


But that might explain the strange tinderbox failure at 
, 
a missing 350minor.mk early one, where xml2cmp is one of the first three 
modules being built (in parallel).


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

Re: [Libreoffice] fix for fdo#33960 "cross reference to a list number, dot bug" makes sw/qa/complex/writer fail

[Stephan Bergmann]

On 09/07/2011 11:15 PM, Troy Rollo wrote:

On Wednesday 07 September 2011, Stephan Bergmann wrote:

Troy, will you come up with a fix that brings
sw/source/core/doc/number.cxx and
sw/qa/complex/writer/CheckCrossReferences.java in sync again?


I won't be able to do that until mid November due to other commitments.


Reopened  "cross 
reference to a list number, dot bug" and disabled the failing tests as 
 
"fdo#33960#, fdo#35690#: Disabled failing checkCrossReferences tests for 
now."


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

Re: [Libreoffice] Commit 66f05b5d5acc43e4615bc19045d3600ed93e328b breaks the build

[Thorsten Behrens]

Francois Tigeot wrote:
> > the shebang is actually a red herring: the real problem is in
> > filter/source/svg/makefile.mk, that uses plain "python" in case of
> > "$(SYSTEM_PYTHON)" != "". Commit 82f6c0502e51afbc25e5bf0fcee7914a1a5b3f28
> > should fix the problem.
> 
> Indeed it does. Thanks !
> 
Thanks guys, for cleaning up after me.

Cheers,

-- Thorsten


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