[Libreoffice] UNO related crashes on NetBSD
Hi,
The latest -master version crashes reliably on NetBSD (i386 and amd64).
The primary suspect is UNO, the 'uno' binary segfaults:
=
Building module testtools
=
Entering
/usr/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/testtools/inc
Entering
/usr/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/testtools/source/bridgetest/idl
Entering
/usr/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/testtools/com/sun/star/comp/bridge
Entering
/usr/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/testtools/source/bridgetest
cd ../../unxnbsd.pro/lib :
LD_LIBRARY_PATH=/usr/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/solver/unxnbsd.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
/usr/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/solver/unxnbsd.pro/bin/uno
\
-ro uno_services.rdb -ro uno_types.rdb \
-s com.sun.star.test.bridge.BridgeTest -- \
com.sun.star.test.bridge.CppTestObject
/usr/pkgsrc/wip/libreoffice/work/.tools/bin/bash: line 1: 29084 Segmentation
fault (core dumped)
LD_LIBRARY_PATH=/usr/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/solver/unxnbsd.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
/usr/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/solver/unxnbsd.pro/bin/uno
-ro uno_services.rdb -ro uno_types.rdb -s com.sun.star.test.bridge.BridgeTest
-- com.sun.star.test.bridge.CppTestObject
dmake: Error code 139, while making 'runtest'
The symptoms are the same as in this Gentoo/arm bug:
https://bugs.freedesktop.org/show_bug.cgi?id=38332
https://bugs.gentoo.org/show_bug.cgi?id=370975
In July, the amd64 version didn't crash, but I may just have been lucky.
One user tried to debug the i386 binary; this is the gdb output:
(gdb) bt
#0 0xbbba7732 in osl_incrementInterlockedCount ()
from
/d0/build/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/solver/unxnbsd.pro/lib/libuno_sal.so.3
#1 0xbbb6065f in typelib_typedescriptionreference_acquire ()
from
/d0/build/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/solver/unxnbsd.pro/lib/libuno_cppu.so.3
#2 0xbbb65099 in typelib_typedescription_newMIInterface ()
from
/d0/build/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/solver/unxnbsd.pro/lib/libuno_cppu.so.3
#3 0xbbb14d81 in cppu::installTypeDescriptionManager ()
from
/d0/build/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/solver/unxnbsd.pro/lib/libuno_cppuhelpergcc3.so.3
#4 0xbbb13949 in cppu::installTypeDescriptionManager ()
from
/d0/build/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/solver/unxnbsd.pro/lib/libuno_cppuhelpergcc3.so.3
#5 0xbfbfa5f4 in ?? ()
#6 0xbb671688 in ?? ()
#7 0xbfbfa5c8 in ?? ()
#8 0xbbb76618 in uno_type_isAssignableFromData ()
from
/d0/build/pkgsrc/wip/libreoffice/work/libreoffice-core-2011-08-30/solver/unxnbsd.pro/lib/libuno_cppu.so.3
Previous frame inner to this frame (corrupt stack?)
(gdb)
Does any UNO specialist have a clue what to look for ?
--
Francois Tigeot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] More numbering types: one, two, three, ...
On Sep 1, 2011, at 2:19 AM, Mohammad Elahi wrote:
Changed function lcl_formatPersianWord to be more generic, and added support
for some more numbering types:
English word: one, two, three, ...
English cardinal: first, second, third, ...
English cardinal semi-word: 1st, 2nd, 3rd, ...
Persian cardinal word.
I used C++ macros, but do not know whether libreoffice community
likes using it or not?
Any feedback is welcomed.
First, I think extending this from Persian to English already shows the biggest
flaw of this approach: Do you want to extend in in this way for all languages
supported by LibO? I would consider such extension to additional languages a
localization task, a task that typically only consists of translating string
resources. Here, however, someone doing localization would need to add new
constants to NumberingType.idl and would need to add code to
defaultnumberingprovider.cxx. That does not feel right.
That said, concentrating on details of the code:
- At least I do not like macros very much. But at least DEFINE_WORD_TABLE is
local to a single .cxx.
- In C++, no need for
typedef struct {…} NumberWordTable;
Instead, use the shorter
struct NumberWordTable {…};
- the second table is used for irregular cardinal numbers is not empty:
should probably read if not empty?
- In
sal_Unicode *(table1[2][8]);
the superfluous parentheses are IMO confusing, and the sal_Unicode data should
really be const, so rather
sal_Unicode const * table1[2][8];
- For the Persian characters (that cannot be given visibly in an ASCII-only
.cxx file, anyway) the practice of specifying sal_Unicode strings as sequences
of individual characters (a la {0x0635,0x062f,0}) appears acceptable. However,
for English strings, {'o','n','e',0} vs. one is hard to tolerate. Maybe all
the data should be specified as UTF-8 instead, using literal … strings (the
literal Persian UTF-16 characters like 0x0635 become a little harder to
maintain, having to encode them as UTF-8 like \xXX\xYY), and explicitly
converting to rtl::OUString when used.
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] new configure options to make branding easier
Hi, I've just pushed a few more configure options to master in order to make branding LibreOffice easier. There are 3 elements that can be configured now. About bitmap: --with-about-bitmap We already had this this option. Intro bitmap aka splash screen: --with-intro-bitmap We already had this this option, but there are more to configure from now on. It is possible to modify the color, the size, the position and the frame color of progress bar. --with-intro-progressbar-color --with-intro-progressbar-size --with-intro-progressbar-position --with-intro-progressbar-frame-color Start center background bitmaps: --with-startcenter-left-bitmap --with-startcenter-right-bitmap --with-startcenter-rtl-left-bitmap --with-startcenter-rtl-right-bitmap --with-startcenter-space-bitmap Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Proof-of-concept] Drastically speedup the offapi (and oovbaapi) build
Hi Matúš, Bjoern,
I've found a way how to speedup the build of offapi (which is a major
problem on windows - on my box it takes about 10% of the entire build
time). The trick is simple - instead of generating the files one by
one, several .idl's are treated during one idlc call; something that has
been there before gbuildization of the module. Of course, it also
handles the case when everything is built, and just 1 .idl changes - in
that case, only that one is rebuilt.
Unfortunately I am heading for vacation, and cannot finish it before I
go - do you think anybody of you could have a look, please?
With the attached patch, the offapi/UnoApi_offapi.mk (and oovbaapi) has
to change to something like the following; this is of course only part
of that, the other rules have to be adapted the same way, but that
should be ~trivial. Second part of the problem is that idlc have to be
patched to bail out with != 0 exit value, according to the comments it
is not the case right now.
Enjoy :-)
- 8 offapi/UnoApi_offapi.mk 8 -
$(eval $(call
gb_UnoApiTarget_add_idlfiles_noheader,offapi,offapi/com/sun/star/accessibility,\
AccessBridge \
Accessible \
AccessibleContext \
))
$(eval $(call
gb_UnoApiTarget_add_idlfiles_noheader,offapi,offapi/com/sun/star/auth,\
SSOExceptions \
SSOManagerFactory \
SSOPasswordCache \
))
$(eval $(call
gb_UnoApiTarget_add_idlfiles_noheader,offapi,offapi/com/sun/star/awt,\
AccessibleButton \
AccessibleCheckBox \
AccessibleComboBox \
AccessibleDropDownComboBox \
AccessibleDropDownListBox \
AccessibleEdit \
AccessibleFixedText \
AccessibleIconChoiceControl \
AccessibleIconChoiceControlEntry \
AccessibleList \
AccessibleListBox \
[...more here...]
))
[...etc.]
- 8 -
Thank you,
Kendy
diff --git a/solenv/gbuild/UnoApiTarget.mk b/solenv/gbuild/UnoApiTarget.mk
index 935c5ea..1050f6d 100644
--- a/solenv/gbuild/UnoApiTarget.mk
+++ b/solenv/gbuild/UnoApiTarget.mk
@@ -77,14 +77,24 @@ $(call gb_UnoApiTarget_get_header_target,)$(2).hdl :| $(call gb_UnoApiTarget_get
endef
define gb_UnoApiTarget_add_idlfiles_noheader
-$(foreach idl,$(2),$(call gb_UnoApiTarget_add_idlfile_noheader,$(1),$(idl)))
+$(foreach idl,$(3),$(call gb_UnoApiTarget_add_idlfile_noheader,$(1),$(2),$(idl)))
+
+$(call gb_UnoApiPartTarget_get_target,$(2)/noheader.done) : $(foreach repo,$(gb_REPOS),$(foreach idl,$(3),$(realpath $(repo)/$(2)/$(idl).idl)))
+ $$(call gb_Output_announce,$(2),$(true),IDL,2)
+ mkdir -p $(call gb_UnoApiPartTarget_get_target,$(2)) \
+ mkdir -p $(gb_Helper_MISC) \
+ RESPONSEFILE=`$(gb_MKTEMP)` \
+ echo $(call gb_Helper_convert_native,$$(INCLUDE) $$(DEFS) -O $(call gb_UnoApiPartTarget_get_target,$(2)) -verbose -C $$?) {RESPONSEFILE} \
+ $(gb_UnoApiTarget_IDLCCOMMAND) @{RESPONSEFILE} /dev/null \
+ rm -f {RESPONSEFILE} \
+ touch $$@
endef
define gb_UnoApiTarget_add_idlfile_noheader
-$(call gb_UnoApiTarget_get_target,$(1)) : $(call gb_UnoApiPartTarget_get_target,$(2).urd)
-$(call gb_UnoApiPartTarget_get_target,$(2).urd) : $(foreach repo,$(gb_REPOS),$(realpath $(repo)/$(2).idl))
-gb_UnoApiTarget_IDLFILES_$(1) += $(2).idl
+$(call gb_UnoApiTarget_get_target,$(1)) : $(call gb_UnoApiPartTarget_get_target,$(2)/$(3).urd)
+$(call gb_UnoApiPartTarget_get_target,$(2)/$(3).urd) : $(call gb_UnoApiPartTarget_get_target,$(2)/noheader.done)
+gb_UnoApiTarget_IDLFILES_$(1) += $(2)/$(3).idl
endef
@@ -165,10 +175,6 @@ mkdir -p $(dir $(1)) \
endef
-$(call gb_UnoApiPartTarget_get_target,%) :
- $(call gb_Output_announce,$*,$(true),IDL,2)
- $(call gb_UnoApiPartTarget__command,$@,$(dir $*),$,$?,$(INCLUDE),$(DEFS))
-
define gb_UnoApiTarget__command
mkdir -p $(dir $(1)) \
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] new configure options to make branding easier
Hi András, Thank you for the patches :oD Also two more images leftt. The two bitmaps in windows installer. Thanks, KAMI On 09/01/2011 09:57 AM, Andras Timar wrote: Hi, I've just pushed a few more configure options to master in order to make branding LibreOffice easier. There are 3 elements that can be configured now. About bitmap: --with-about-bitmap We already had this this option. Intro bitmap aka splash screen: --with-intro-bitmap We already had this this option, but there are more to configure from now on. It is possible to modify the color, the size, the position and the frame color of progress bar. --with-intro-progressbar-color --with-intro-progressbar-size --with-intro-progressbar-position --with-intro-progressbar-frame-color Start center background bitmaps: --with-startcenter-left-bitmap --with-startcenter-right-bitmap --with-startcenter-rtl-left-bitmap --with-startcenter-rtl-right-bitmap --with-startcenter-space-bitmap Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] vbaevents*.uno.so and libvbaswobj*uno.so location
Hi Petr On 30/08/11 16:07, Petr Mladek wrote: Hi Rene, Caolan or Noel has recently suggested me to move vbaobj.uno.so into the Calc package because it links against libsc and is needed only by Calc. think it was me, and yes vbaobj.uno.so needs to link against libsc = calc and ditto libvbaswobj*uno.so needs to link with sw = writer - stop moving vbaevents*.uno.so to -calc. off the top of my head I don't recall the exact link dependencies here but if we bundle vbaevents*.uno.so then that isn't correct as it is used by both writer and calc so somewhere more common would be better N oel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] new configure options to make branding easier
2011/9/1 Kálmán „KAMI” Szalai kami...@gmail.com: Hi András, Thank you for the patches :oD Also two more images leftt. The two bitmaps in windows installer. No, there are at least 3 images in Windows installer and the download icon. Windows installer was out of scope now. Cheers, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] More numbering types: one, two, three, ...
Hi Stephan
First, I think extending this from Persian to English already shows the
biggest flaw of this approach: Do you want to extend in in this way for all
languages supported by LibO?
Yes, I was trying to make it more generic so can be used by more languages.
But maybe I should not,
I would consider such extension to additional languages a localization
task, a task that typically only consists of translating string resources.
Well at least for persian it is almost translating strings, but there is
some exceptions in translation
which prevent me from using a word by word translation.
Here, however, someone doing localization would need to add new constants
to NumberingType.idl and would need to add code to
defaultnumberingprovider.cxx. That does not feel right.
OK, I'm just started to work with libreoffice code ;) Just searched for a
similar feature which
recently has been added, and used it as a templated to how to write code.
Please, Would you mind tell me what is right in this case? How should I
write code for localizing numbers
which best fits?
That said, concentrating on details of the code:
- At least I do not like macros very much. But at least DEFINE_WORD_TABLE
is local to a single .cxx.
OK
- In C++, no need for
typedef struct {…} NumberWordTable;
Instead, use the shorter
struct NumberWordTable {…};
OK, thanks to mention.
- the second table is used for irregular cardinal numbers is not empty:
should probably read if not empty?
Sorry for typos
- In
sal_Unicode *(table1[2][8]);
the superfluous parentheses are IMO confusing, and the sal_Unicode data
should really be const, so rather
sal_Unicode const * table1[2][8];
- For the Persian characters (that cannot be given visibly in an ASCII-only
.cxx file, anyway) the practice of specifying sal_Unicode strings as
sequences of individual characters (a la {0x0635,0x062f,0}) appears
acceptable. However, for English strings, {'o','n','e',0} vs. one is hard
to tolerate. Maybe all the data should be specified as UTF-8 instead, using
literal … strings (the literal Persian UTF-16 characters like 0x0635
become a little harder to maintain, having to encode them as UTF-8 like
\xXX\xYY), and explicitly converting to rtl::OUString when used.
Thanks,
Yes, but I think as you said it is better to use UTF-8, one of my problems
was defining a two dimensional
array to hold strings with variable length, first I used
(sal_Unicode[]){0x0635, ...}, but a feedback from
community was It's not C++03 compatible, so used constant length arrays
which do not like them.
But by changing it to UTF-8, it even makes the persian strings more
tolerable.
Thanks for useful comments ;)
Thanks
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Wed, 2011-08-31 at 23:54 -0600, Tor Lillqvist wrote: The attached patch is an attempt to bring some sanity to the situation: It seems that you have investigate this quite deeply and I would love to commit and push your patch. However, I am a bit scared. Could somebody else who actually understands the issues involved have a look? I think we're all too chicken to man-up and look at this one :-) I guess the major fear isn't that your code is wrong, it's probably right, it's what stuff relying on the old way of doing things will change. I've been planning, but delayed on tracking down a mystery 2 point offset :-), to put together a did my layout change regression test which would have been perfect to test this. caolan-tor: I suggest bunging this in for now, but putting the old algorithm behind an getenv(SAL_OLD_METRICS) or something for easy side-by-side testing ? I'd be interested in knowing what effects the change has on typical fonts as opposed to the edge cases, i.e. does text rendered in Liberation Serif, Sans, Monotype stay basically the same. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #193 from Carlo Strata carlo.str...@tiscali.it 2011-09-01 02:06:40 PDT --- (In reply to comment #192) Can we add Bug 39355 ? This can be rather humiliating when you send a PDF to someone who uses Adobe Reader instead of a free PDF reader. Hi Everyone, may be this issue is related to this old one https://bugzilla.novell.com/show_bug.cgi?id=467181 whose title was PDF/A export broken - Adobe Acrobat reports Invalid ColorSpace and the fix (take a look to comment 11) would be the same because it's a new regression? I just have added this comment to the coming back (?) bug. Carlo p.s. Comment 11: https://bugzilla.novell.com/show_bug.cgi?id=467181#c11 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Use a custom string to make numbering more flexible
On Tue, 2011-08-30 at 20:24 +0430, Mohammad Elahi wrote: But odt is a standard, can I add any property to it? Certainly - it is polite to go the standards route and propose an addition / change there to improve interop. However - I'd strongly recommend avoiding getting bogged down in that (multi-month) process, there is no way it should block us from improving LibreOffice. Instead - I suggest you hack up a patch for the export filter, and we'll get Thorsten to review that and/or turn it into an ODF extension / proposal. How does that sound ? ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #194 from Carlo Strata carlo.str...@tiscali.it 2011-09-01 02:10:14 PDT --- Hi Everyone, may be this issue is related to this old one https://bugzilla.novell.com/show_bug.cgi?id=467181 whose title was PDF/A export broken - Adobe Acrobat reports Invalid ColorSpace and the fix (take a look to comment 11) would be the same because it's a new regression? I just have added this comment to the coming back (?) bug. Carlo p.s. Comment 11: https://bugzilla.novell.com/show_bug.cgi?id=467181#c11 Il 31/08/2011 21:05, bugzilla-dae...@freedesktop.org ha scritto: https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #192 from Aaron Strontsmanheinzless...@gmail.com 2011-08-31 12:05:35 PDT --- Can we add Bug 39355 ? This can be rather humiliating when you send a PDF to someone who uses Adobe Reader instead of a free PDF reader. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Proof-of-concept] Drastically speedup the offapi (and oovbaapi) build
Hi Kendy, all, On Thu, 01 Sep 2011 10:25:20 +0200 Jan Holesovsky ke...@suse.cz wrote: With the attached patch, the offapi/UnoApi_offapi.mk (and oovbaapi) has to change to something like the following; this is of course only part of that, the other rules have to be adapted the same way, but that should be ~trivial. Second part of the problem is that idlc have to be patched to bail out with != 0 exit value, according to the comments it is not the case right now. Just a word of warning after a short skimming of the patch: It seems like you are using $? with huge amounts of files to create a commandline. This is quite risky on Linux, where you easily hit the command length limits of the shell on certain installs (depending on ulimits). There is solenv/gbuild/Tempfile.mk to work around that (to create response files). Tempfile.mk btw is the easiest way to trigger that good old make 3.81 bug. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] New desktop integration modules
On Sep 1, 2011, at 5:32 AM, Timothy Pearson wrote: I have created a patch that adds Trinity Desktop Environment integration to LibreOffice, and would like to get it included in the upstream LibreOffice sources if you are interested. It is based on the old KDE3 integration module, but has been altered to work with the latest version of TDE. It does not damage or replace the existing KDE3 desktop integration modules, and can be turned on/off with a configure flag at compile time. This is an important feature to users of TDE, as the existing KDE3 integration module will not function properly within the latest releases of TDE. We are prepared to maintain and enhance the TDE integration module for the foreseeable future. The patch can be found here: http://git.trinitydesktop.org/viewgit/index.php?a=viewblobp=Trinity%20Desktop%20Environmenth=33a55305c99e0dc808b25eaba3f7373521eec3e1hb=HEADf=main/thirdparty/libreoffice/3.3.2/patches/libreoffice-trinity.diff If you need the patch in e different format, or have concerns about it, please don't hesitate to contact me! One detail that immediately caught my attention is that the connectivity/source/drivers/tdeab code is obviously based on old connectivity/source/drivers code that still uses active UNO component registration. This would need to be adapted. See http://wiki.services.openoffice.org/wiki/Passive_Component_Registration for the concepts, https://issues.apache.org/ooo/show_bug.cgi?id=113189 for the issue that implemented it, and http://cgit.freedesktop.org/libreoffice/core/commit/?id=9551bf5a1ee5c9275a26f8ec4021e0b7f5665176 for the changeset containing the relevant modifications to connectivity/source/drivers. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] vbaevents*.uno.so and libvbaswobj*uno.so location
Hi Petr, On Tue, 2011-08-30 at 17:07 +0200, Petr Mladek wrote: Caolan or Noel has recently suggested me to move vbaobj.uno.so into the Calc package because it links against libsc and is needed only by Calc. .. I am a bit curious about these changes. Are they needed to fix dependencies or do they avoid a functionality problems? I hope we're getting all of these changes into the scp2/ in core/ Indeed - I'd really like bin/distro-install-file-lists to get written out in master: there is no excuse for this sort of stuff: # create kde4 subpackage mv_file_between_flists kde4_list.txt kde_list.txt $INSTALLDIR/basis$PRODUCTVERSION/program/kde4be1.uno.so mv_file_between_flists kde4_list.txt common_list.txt $INSTALLDIR/basis$PRODUCTVERSION/program/libvclplug_kde4l..so mv_file_between_flists kde4_list.txt common_list.txt $INSTALLDIR/basis$PRODUCTVERSION/program/fps_kde4.uno.so add_used_directories kde4_list.txt common_list.txt When we can fairly trivially do that in the scp2 - surely ? ditto for many of the other hacks in there. Petr - any chance of an easy-hack for that ? ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Proof-of-concept] Drastically speedup the offapi (and oovbaapi) build
Hi Bjoern, On 2011-09-01 at 11:21 +0200, Bjoern Michaelsen wrote: Just a word of warning after a short skimming of the patch: It seems like you are using $? with huge amounts of files to create a commandline. This is quite risky on Linux, where you easily hit the command length limits of the shell on certain installs (depending on ulimits). There is solenv/gbuild/Tempfile.mk to work around that (to create response files). Tempfile.mk btw is the easiest way to trigger that good old make 3.81 bug. Ah right, I just copied the way the response file was created in the old implementation; Tempfile.mk sounds better. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Escaped non-ASCII characters from source files.
On Tue, 2011-08-30 at 00:27 +0900, Takashi Nakamoto wrote: The attached patch solves a compilation error in libxml2 which occurs on Windows with some Asian locales. I would appreciate if someone pushes this. Thanks Takashi ! found pushed in master (hence subject). ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] New desktop integration modules
Hi Timothy, On 2011-08-31 at 22:32 -0500, Timothy Pearson wrote: This is an important feature to users of TDE, as the existing KDE3 integration module will not function properly within the latest releases of TDE. We are prepared to maintain and enhance the TDE integration module for the foreseeable future. The patch can be found here: http://git.trinitydesktop.org/viewgit/index.php?a=viewblobp=Trinity%20Desktop%20Environmenth=33a55305c99e0dc808b25eaba3f7373521eec3e1hb=HEADf=main/thirdparty/libreoffice/3.3.2/patches/libreoffice-trinity.diff If you need the patch in e different format, or have concerns about it, please don't hesitate to contact me! Thank you very much for the patch! Unfortunately, it is based on extremely old LibreOffice - 3.3.2. Can you please bring it up-to-date, and post here again? We need it against the current master, only way it can be applied, and possibly backported to 3.4 (if desirable). Master download / build instructions: http://www.libreoffice.org/get-involved/developers/ All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] inconsistency between rtl::OString/rtl::OUString and optimization opportunities ?
On Wed, 2011-08-31 at 15:41 +0200, Stephan Bergmann wrote: On Aug 31, 2011, at 12:04 PM, Caolán McNamara wrote: ... I'm vaguely thinking of ... i18nutil x_rtl stuff ... hard-coding its refcount argument to 0 or 1 and fixing up its uses to consistently use one or the other public OUString acquire/noacquire ctors done. Sadly half of the x_rtl uses were broken anyway, in the sense that the rtl_uString was just used as a buffer, part of it *copied* into new OUString and the original leaked. Changed the ok ones to use a SAL_NOACQUIRE ctor and a x_rtl_uString_new_WithLength which creates a rtl_uString with a ref-count of 1, and recovered a few of the copy-and-leak cases which were easy conversions to what the original intent was supposed to be, and converted the others to simple sal_Unicode buffers [1] with a loop, I suppose its no real optimization there to use memset or rtl_allocateMemory for that case ? Wouldn't hurt to use memset instead, I'd say. done C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Thu, Sep 01, 2011 at 10:03:40AM +0100, Caolán McNamara wrote: On Wed, 2011-08-31 at 23:54 -0600, Tor Lillqvist wrote: The attached patch is an attempt to bring some sanity to the situation: It seems that you have investigate this quite deeply and I would love to commit and push your patch. However, I am a bit scared. Could somebody else who actually understands the issues involved have a look? I think we're all too chicken to man-up and look at this one :-) I guess the major fear isn't that your code is wrong, it's probably right, it's what stuff relying on the old way of doing things will change. I've been planning, but delayed on tracking down a mystery 2 point offset :-), to put together a did my layout change regression test which would have been perfect to test this. It is very likely to cause re-flowing (at least different line count per page) for many documents, but on the other hand the old behaviour was just wrong (and have been wrong for two decades now, since the introduction of TrueType). caolan-tor: I suggest bunging this in for now, but putting the old algorithm behind an getenv(SAL_OLD_METRICS) or something for easy side-by-side testing ? I'd be interested in knowing what effects the change has on typical fonts as opposed to the edge cases, i.e. does text rendered in Liberation Serif, Sans, Monotype stay basically the same. I just tested with a simple lorem ipsum document with Liberation Serif; page count went down from 24 to 22 after applying the patch, a quite a drastic change I think :( One the bright side, I'm no longer getting oversized buttons and combo boxes. Regards, Khaled -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] few queastions about building sal
On Mon, 2011-08-29 at 20:49 +0200, Stephan Bergmann wrote: Zero. But it does not hurt that much to have them exported, does it? So I would just play it safe. YMMV. Culturally - I think we prefer to play it dangerously - just on principle :-) Having clean code is huge win vs. a very theoretical risk - I don't think there is any chance that anyone can have used them deliberately; I'd love to just remove them if it makes Matus' life easier. Similarly - as Rene says - having conditionals for GLIBC 1 is a nonsense - it is encouraging to see Matus' patch binning them all :-) HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fixing layout breakage in pivot table dialog
Hi Kohei, On 2011-08-30 at 16:55 -0400, Kohei Yoshida wrote: http://cgit.freedesktop.org/libreoffice/core/commit/?id=8bf60230255e0e8da66cafff578f148858cee4ca cherry-picked to the 3.4 branch. A patch for this commit is attached as well for convenience. This fixes a slight layout problem in the main pivot table dialog, where the text Drag the fields from the right into the desired position appeared overlapping the row and data field areas on Windows XP. This commit fixes it. On platforms other than Windows XP there is no such issue. Apparently our dialogs get vertically compressed on Windows XP (for whatever reason). And because the size and position of the page/row/column/data field areas are absolute, this caused the layout breakage on XP. The patch generally looks fine - I just wonder, why there is the vertical compression, and why only on XP? Isn't the root cause something in vcl? Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] More numbering types: one, two, three, ...
On Sep 1, 2011, at 11:00 AM, Mohammad Elahi wrote:
Here, however, someone doing localization would need to add new constants to
NumberingType.idl and would need to add code to defaultnumberingprovider.cxx.
That does not feel right.
OK, I'm just started to work with libreoffice code ;) Just searched for a
similar feature which
recently has been added, and used it as a templated to how to write code.
Please, Would you mind tell me what is right in this case? How should I write
code for localizing numbers
which best fits?
To be honest, I have no idea what the best approach would look like. Maybe
something like this: In the front end, have numbering types specified not by
a single NumberingType constant, but by a tuple of NumberingType constant and
language code (there should already be at least one such enumeration of
language codes in LibO), where the language code is only used by NumberingType
constants like CHARS_WORD, CHARS_CARDINAL_WORD, etc. In the back end, devise
and algorithm and a list of string resources that produces the desired output
for all the combinations of (a) numeric value to be formatted according to the
given (b) tuple of NumberingType constant and language code. Depending on what
special cases the various languages need, the algorithm and the corresponding
list of necessary string resources will grow over time, as more and more
languages are being taken care of. At runtime, the algorithm then obtains the
necessary strings for the given language like is done for all the other
localized strings in LibO.
- the second table is used for irregular cardinal numbers is not empty:
should probably read if not empty?
Sorry for typos
No need to be sorry. :-)
- For the Persian characters (that cannot be given visibly in an ASCII-only
.cxx file, anyway) the practice of specifying sal_Unicode strings as
sequences of individual characters (a la {0x0635,0x062f,0}) appears
acceptable. However, for English strings, {'o','n','e',0} vs. one is hard
to tolerate. Maybe all the data should be specified as UTF-8 instead, using
literal … strings (the literal Persian UTF-16 characters like 0x0635 become
a little harder to maintain, having to encode them as UTF-8 like \xXX\xYY),
and explicitly converting to rtl::OUString when used.
Thanks,
Yes, but I think as you said it is better to use UTF-8, one of my problems
was defining a two dimensional
array to hold strings with variable length, first I used
(sal_Unicode[]){0x0635, ...}, but a feedback from
community was It's not C++03 compatible, so used constant length arrays
which do not like them.
But by changing it to UTF-8, it even makes the persian strings more tolerable.
In the end, the best way to represent those strings will depend on how exactly,
if at all, this is extended to more languages than just Persian (see above).
(For example, if we should take the route I sketched above, those strings would
be stored externally from the C++ source file, anyway, and all this would
become moot.)
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
Hi Tor, On Wednesday, 2011-08-31 23:54:17 -0600, Tor Lillqvist wrote: The attached patch is an attempt to bring some sanity to the situation: It seems that you have investigate this quite deeply and I would love to commit and push your patch. However, I am a bit scared. Could somebody else who actually understands the issues involved have a look? The changes themself look sane, regarding the background Khaled gave and knowing part of his work from older days I didn't hesitate much to commit this :) This only done for 'unx' similar work is needed for 'win' and 'aqua', but I'm not familiar with these platforms and can't test on it. I wonder if this patch will then introduce significant rendering differences between platforms? Or do we have such anyway already (even if the same fonts are present)? Even if it may currently render differently, I think using the correct font metrics on one system where people complained about it is a step into the right direction. We use different layout engines on unx,mac,win and hopefully each system positions glyphs as accurately as possible when given the right input. I just had a glance at the win code and it has some improved metric compatibility for Asian fonts and The line height for Asian fonts is too small and external leading for Asian fonts comments, which seem to indicate a similar problem maybe resulting from the same wrong assumptions. A comment like The factor 0.3 has been confirmed with experiments doesn't give much confidence in the final correctness of that resolution ;) 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] Updating features for 3.5 wiki page as we go ...
On Sun, 2011-08-28 at 00:05 +0200, Eike Rathke wrote: On Saturday, 2011-08-27 04:10:40 +0430, Mohammad Elahi wrote: Numbering in localized persian word is useful in some areas, at least for me it is necessary. Since it is not trivial a function and table is needed. Pushed on master http://cgit.freedesktop.org/libreoffice/core/commit/?id=b470e596db5b58aed9cf9fd6b90045ab4940c054 Great stuff Mohammad. Just a quick request - when it is release time, it is a real pain to have to try to dig through all the commits, and remember the user-noticable features we added for the last release. I also inevitably miss important things. What really helps is if we update the wiki page: http://wiki.documentfoundation.org/ReleaseNotes/3.5 As we go along; that also helps build interest in excitement about the next release as we go (as a bonus feature) :-) Any chance you can add your features (and particularly the credits) there ? Cedric - I harbour unfair suspicions that you've been implementing cool features and also not adding them there ;-) such as the new header/footer stuff - which clearly deserves a screenshot [ hopefully shared with some nice blog entry or other ? ]. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] (no subject)
Hi, On Wednesday, 2011-08-31 01:02:51 -0500, chars...@apple.com wrote: [... bla making it look like coming from a mailer-daemon ...] and [-- Attachment #2: document.exe --] [-- Type: application/octet-stream, Encoding: base64, Size: 29K --] Can we do something against letting all those .exe .scr .zip etc. attachments pass through? 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] IDL @since build error if not OOo
On Wed, 2011-08-31 at 15:45 +0200, Laurent Godard wrote: here is a patch (master branch) that add LibreOffice and LO string support to @since tag in idl files Found pushed - thanks ! :-) Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
The changes themself look sane, regarding the background Khaled gave and knowing part of his work from older days I didn't hesitate much to commit this :) OK, excellect! Khaled, if you want direct commit access, just ask (hmm, file a bug asking for that, is that still the correct procedure?) A comment like The factor 0.3 has been confirmed with experiments doesn't give much confidence in the final correctness of that resolution ;) Heh, indeed. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC] last report
On Sun, 2011-08-28 at 21:21 +0200, Matúš Kukan wrote: GSoC has ended. This was my first experience with open source. I think I was lucky and choose great community. I certainly enjoyed working with you :-) What I have done ? I think Matus has a modesty problem, he did a lot more than this over the course of the project, happily I happen to have a list of them here: + some nice easy hacks to start with: open/save foo, ppt filters + fixed up the res/commandimagelst stuff - to shrink the images.zip, save a chunk of memory and a few cycles too + switched lots of the component_ methods to use prefixes - which helps merging libraries, as well as the iPhone port + worked on link time optimisation + lots of gnumake work to drive towards the big-merged-library scenario All of which is great progress, and looking forward to having you around to work with in the future :-) ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updating features for 3.5 wiki page as we go ...
OK, I add it to the wiki ;) Thanks -Elahi ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Licensing information collection for Dev submitting patch
Hi Norbert, On Sun, 2011-08-28 at 15:01 -0500, Norbert Thiebaud wrote: I've added a 'License' column in the list of developers in the wiki http://wiki.documentfoundation.org/Development/Developers Thanks for doing that :-) there is a 'le...@documentfoundation.org' alias - to which I send private mails where people do this. I can't find public archives, which is prolly for a reason. finding that statement in the mailing list history is not trivial.. so having these referenced in a centralized place in the wiki would help. True. I encourage patch submitters to fill the wiki page above with the relevant information. If you do not want to create a wiki account, send me an email with the information you'd like to see there and I'll fill it for you. Thanks for diging that out :-) Note: I'll use this email for the purpose of registering my statement of license. This is _my_ version of it, by no mean should this be considered a template or a suggested wording :-) IANAL etc... ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #195 from Rainer Bielefeld libreoff...@bielefeldundbuss.de 2011-09-01 03:46:41 PDT --- bugzilla-dae...@freedesktop.org schrieb: https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #194 from Carlo Stratacarlo.str...@tiscali.it 2011-09-01 02:10:14 PDT --- Hi Everyone, may be this issue is related to this old one https://bugzilla.novell.com/show_bug.cgi?id=467181 THIS one definitively not! Please stop this discussion at the wrong place, Bug 35673 is a tracking task bug! Such a question has to be discussed in Bug 39355! CU Rainer -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] More numbering types: one, two, three, ...
Hi, On Thursday, 2011-09-01 09:35:09 +0200, Stephan Bergmann wrote: First, I think extending this from Persian to English already shows the biggest flaw of this approach: Do you want to extend in in this way for all languages supported by LibO? I would consider such extension to additional languages a localization task, a task that typically only consists of translating string resources. String resources wouldn't be sufficient as different locales have different rules for how to form a number string, especially when it comes to ordinals. However, this looks more like spell-out than level numbering and as such misses the point of the numbering provider. If we wanted to implement spell-out I'd rather go for ICU's methods than implementing yet another home-grown solution. 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] build error
Hi Jenei, On Mon, 2011-08-29 at 15:58 +0200, Jenei Gábor wrote: For a while I did not have this error,but now it appears again. Actually I did a totally normal build without debug symbols and dbglevel setting, but still it appears. It seems to be a makefile error of LibreOffice. Has anyone already met the problem? So - I guess the main thing to do is to catch it from clean; so rm -Rf openssl/unxlngi6.pro and re-run 'build' inside there (with a sourced environment). 2011. 08. 26. 14:49 keltezéssel, Caolán McNamara írta: Configured for linux-elf. mkdir: cannot create directory `./unxlngi6/misc/build/openssl-0.9.8o/.': File exists The unxlngi6/misc/build - is slightly odd - are you trying to create a non-product build ? I'd expect unxlngi6.pro. As Caolan says - what are your configure options ? and some more details on your system would be much appreciated: linux distro, version, etc. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updating features for 3.5 wiki page as we go ...
Hi Michael, On Thu, 2011-09-01 at 11:18 +0100, Michael Meeks wrote: Cedric - I harbour unfair suspicions that you've been implementing cool features and also not adding them there ;-) such as the new header/footer stuff - which clearly deserves a screenshot [ hopefully shared with some nice blog entry or other ? ]. Oh indeed that deserves it, thanks for reminding it ;) As for the screenshot it'll need the UI to be finalized... I still have some troubles with the painting there. -- Cedric ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] More numbering types: one, two, three, ...
Hi Eike String resources wouldn't be sufficient as different locales have different rules for how to form a number string, especially when it comes to ordinals. However, this looks more like spell-out than level numbering and as such misses the point of the numbering provider. If we wanted to implement spell-out I'd rather go for ICU's methods than implementing yet another home-grown solution. Yes, it seems a better approach, so may be [PATCH] Add numbering type in persian word should revised by ICU's methods. Thanks -Elahi ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Unknown property NumberingLevel
Hi julien2412, On Wednesday, 2011-08-31 14:21:10 -0700, julien2412 wrote: I took some time to take a look and here is what I found : When I add SVX_UNOEDIT_OUTLINER_PROPERTIES in sd/source/core/stlsheet.cxx I took another look at you approach, it doesn't seem to be correct to add SVX_UNOEDIT_OUTLINER_PROPERTIES at that place. Note that SVX_UNOEDIT_OUTLINER_PROPERTIES includes the already existing SVX_UNOEDIT_NUMBERING_PROPERTIE, see editeng/inc/editeng/unotext.hxx, so adding that duplicates those definitions. Maybe replacing SVX_UNOEDIT_NUMBERING_PROPERTIE with SVX_UNOEDIT_OUTLINER_PROPERTIES would work, but then I guess other places need to be adapted. Someone with insight to Draw and EditEngine should jump in on this. 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] (no subject)
Hi Eike, On 2011-09-01 at 12:18 +0200, Eike Rathke wrote: Can we do something against letting all those .exe .scr .zip etc. attachments pass through? I'd say bug against the fd.o infa... Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Sep 1, 2011, at 12:30 PM, Tor Lillqvist wrote: The changes themself look sane, regarding the background Khaled gave and knowing part of his work from older days I didn't hesitate much to commit this :) OK, excellect! Khaled, if you want direct commit access, just ask (hmm, file a bug asking for that, is that still the correct procedure?) Yes, http://wiki.documentfoundation.org/Development/NewAccount (been there just myself right now…) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Fw from tdf-discuss: Howto start building from tarball for Solaris x86
Hi all, I'm wondering if anyone can help me with my libreoffice build from source problem. Meanwhile I did two trials, one on solaris and one on suse 11.4. Both failed at the point where the real source is required to make libreoffice. The automatic fetch from the web seems not to work since there are some web servers missing. There is no hint how to spreadout the tarball of source code so that it is recognized by the configre and make. So the bootstrap procedure foreseen in the bootstrap package seems to be broken. Below you can find some details about my failed trials. Any advice would be much appreciated. Regards, Karl Hi Karl, maybe it is better to ask on the developers Mailing-List libreoffice@lists.freedesktop.org This here is more about common things around The Document Foundation, not LibreOffice itself. Volker 2011/8/31 Karl Behler k...@behler-garching.de: Hi all again, now I tried the same at home under Suse 11.4. Downloaded libreoffice-bootstrap-3.3.4.1 And followed the build steps: This is my autogen.sh: ./autogen.sh --with-num-cpus=2 --with-ant-home=/downloads/Ant/apache-ant-1.8.2 --with-junit=/downloads/Junit/junit-4.9.jar It runs through without complaining: . configure: creating ./config.status config.status: creating set_soenv config.status: creating Makefile Setting up the environment for building LibreOffice Setting platform independent values... Setting Linux x86-64 specific values... done Setting the environment variables... done Setting the aliases... done * * LibreOffice 330 configuration. * * * Configuration part of LibreOffice 330 build is finished. * * NB! Be aware that you might not be able to build LibreOffice if you * ignore any warning message that were generated during this configuration * process. * To build, do: $ make Developer installation (after you have built): $ make dev-install Configure completed But when I try to do the make: papa@lnx54srv1:~/projects/libreoffice/3341/libreoffice-bootstrap-3.3.4.1 make found wget: wget found md5sum: md5sum 63ddc5116488985e820075e65fbe6aa4-openssl-0.9.8o.tar.gz Keine Daten empfangen. Keine Daten empfangen. Keine Daten empfangen. Keine Daten empfangen. Lesefehler (Die Verbindung wurde vom Kommunikationspartner zurückgesetzt) beim Vorspann (header). Lesefehler (Die Verbindung wurde vom Kommunikationspartner zurückgesetzt) beim Vorspann (header). Keine Daten empfangen. Keine Daten empfangen. Obviously the reason is the same the file ooo.list is outdated and the mentioned packages are not anymore found at the original places. Again - What to do? What to read? Regards Karl Am 31.08.2011 17:25, schrieb Karl Behler: Hi all, I've downloaded the tarball from http://download.documentfoundation.org/libreoffice/src/3.3.4/ and untared everything. So I've got my directory filled with something like @LongLink, libreoffice-artwork-3.3.4.1/, libreoffice-base-3.3.4.1/, libreoffice-bootstrap-3.3.4.1/, libreoffice-calc-3.3.4.1/, libreoffice-components-3.3.4.1/, libreoffice-extensions-3.3.4.1/, libreoffice-extras-3.3.4.1/, libreoffice-filters-3.3.4.1/, libreoffice-help-3.3.4.1/, libreoffice-impress-3.3.4.1/, libreoffice-l10n-3.3.4.1/, libreoffice-libs-core-3.3.4.1/, libreoffice-libs-extern-3.3.4.1/, libreoffice-libs-extern-sys-3.3.4.1/, libreoffice-libs-gui-3.3.4.1/, libreoffice-postprocess-3.3.4.1/, libreoffice-sdk-3.3.4.1/, libreoffice-testing-3.3.4.1/, libreoffice-ure-3.3.4.1/, libreoffice-writer-3.3.4.1/ Now I cd into libreoffice-bootstrap-3.3.4.1 and do the autogen.sh I finally managed to get through this When I say make it tries to fetch a lot from various web locations which do not exist anymore. Why that? I thought I already downloaded the source with the full tarball How can I avoid fetching files from external? How do I have to organize the source from the already downloaded tarball so that it is recognized by the configure and make procedures? My uname -a output is: SunOS sxaug21 5.10 Generic_144501-19 i86pc i386 My autogen options where: ./autogen.sh --with-num-cpus=4 --disable-cups --disable-gconf --disable-gnome-vfs --prefix=/usr/gnu/64 --disable-gstreamer --with-ant-home=/afs/ipp-garching.mpg.de/home/k/kcb/ftp/Ant/apache-ant-1.8.2 --without-junit --disable-fetch-external Any advice? Thanks, Karl -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted -- Volker Merschmann Member of The Document Foundation http://www.documentfoundation.org -- Dr. Karl Behler CODAC IT services ASDEX
Re: [Libreoffice] [PATCH] More numbering types: one, two, three, ...
On Sep 1, 2011, at 1:01 PM, Eike Rathke wrote: On Thursday, 2011-09-01 09:35:09 +0200, Stephan Bergmann wrote: First, I think extending this from Persian to English already shows the biggest flaw of this approach: Do you want to extend in in this way for all languages supported by LibO? I would consider such extension to additional languages a localization task, a task that typically only consists of translating string resources. String resources wouldn't be sufficient as different locales have different rules for how to form a number string, especially when it comes to ordinals. Thats why I sketched that string resources plus algorithm (taking care of all the various language-specific details) thing further down in the thread. However, this looks more like spell-out than level numbering and as such misses the point of the numbering provider. If we wanted to implement spell-out I'd rather go for ICU's methods than implementing yet another home-grown solution. Sounds even better. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
Hi Caolán, On Thursday, 2011-09-01 10:03:40 +0100, Caolán McNamara wrote: On Wed, 2011-08-31 at 23:54 -0600, Tor Lillqvist wrote: The attached patch is an attempt to bring some sanity to the situation: It seems that you have investigate this quite deeply and I would love to commit and push your patch. However, I am a bit scared. Could somebody else who actually understands the issues involved have a look? I think we're all too chicken to man-up and look at this one :-) /me ducks I guess the major fear isn't that your code is wrong, it's probably right, it's what stuff relying on the old way of doing things will change. I've been planning, but delayed on tracking down a mystery 2 point offset :-), to put together a did my layout change regression test which would have been perfect to test this. This indeed may be a problem, users expect documents to render identical, even if it was wrong before. caolan-tor: I suggest bunging this in for now, but putting the old algorithm behind an getenv(SAL_OLD_METRICS) or something for easy side-by-side testing ? Good idea. I'd just rename that to VCL_OLD_FONT_METRICS for clarity. We could also make use of the convwatch tests. We'll also need comparisons with MS applications for the same document. I'd be interested in knowing what effects the change has on typical fonts as opposed to the edge cases, i.e. does text rendered in Liberation Serif, Sans, Monotype stay basically the same. Apparently not. 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] fdo#37195, [REVIEW] take two on the where did my dictionaries go
So the ooo3migration thing was a red herring alright, so here's my
second stab at fdo#37195
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a78a6e013b8d97891aa2b9c9a5dce64a82dc2f06
a) If CreateProcessServiceFactory is called, then common.rdb of
Users/YOU/AppData/Roaming/LibreOffice/3/user/extensions/bundled/registry/
com.sun.star.comp.deployment.component.PackageRegistryBackend/common.rdb is
opened mmapped on windows
b) On a new start of an LibreOffice which wants to synchronize new
config over an old config, then it will want do a copy of
install/share/prereg/bundled/registry/
com.sun.star.comp.deployment.component.PackageRegistryBackend/common.rdb
over
Users/YOU/AppData/Roaming/LibreOffice/3/user/extensions/bundled/registry/
com.sun.star.comp.deployment.component.PackageRegistryBackend/common.rdb
which will fail on windows with error 1224, i.e. ERROR_USER_MAPPED_FILE
c) That aborts the copy_bundled_recursive copy, leaving an old config
pointing to the old location of dictionaries.
d) So for windows at least, CreateProcessServiceFactory shouldn't happen
before copy_bundled_recursive.
This appears to be a (wildly unexpected and impossible to predict)
side-effect of c3ccdabb where it happened to be the case in the past
that CreateProcessServiceFactory didn't get called before
synchronization under windows.
Attached is the backport for 3-4 as this code changed a little between
3-4 and master.
caolanm-Andras: could you arrange to have the attached tested ?
C.
From f9036d7c0b6b8ee00de618f33083ec11cc0e1c7f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= caol...@redhat.com
Date: Thu, 1 Sep 2011 13:43:35 +0100
Subject: [PATCH] Resolves: fdo#37195 CreateProcessServiceFactory can't happen
before sync
If CreateProcessServiceFactory is called, then common.rdb of
Users/YOU/AppData/Roaming/LibreOffice/3/user/extensions/bundled/registry/
com.sun.star.comp.deployment.component.PackageRegistryBackend/common.rdb is
opened mmapped
On a new start of an LibreOffice which wants to synchronize new config over an
old config, then it will want do a copy of
install/share/prereg/bundled/registry/
com.sun.star.comp.deployment.component.PackageRegistryBackend/common.rdb
over
Users/YOU/AppData/Roaming/LibreOffice/3/user/extensions/bundled/registry/
com.sun.star.comp.deployment.component.PackageRegistryBackend/common.rdb
which will fail on windows with error 1224, i.e. ERROR_USER_MAPPED_FILE
That aborts the copy_bundled_recursive copy, leaving an old config
pointing to the old location of dictionaries.
So for windows at least, CreateProcessServiceFactory shouldn't happen before
copy_bundled_recursive.
---
desktop/inc/app.hxx|4 ++--
desktop/source/app/app.cxx | 17 +++--
desktop/source/app/sofficemain.cxx |1 -
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/desktop/inc/app.hxx b/desktop/inc/app.hxx
index 7f9a7ef..e13283d 100644
--- a/desktop/inc/app.hxx
+++ b/desktop/inc/app.hxx
@@ -139,11 +139,11 @@ class Desktop : public Application
voidSetSplashScreenText( const ::rtl::OUString rText );
voidSetSplashScreenProgress( sal_Int32 );
-voidCreateProcessServiceFactory();
+static void ensureProcessServiceFactory();
private:
// Bootstrap methods
-::com::sun::star::uno::Reference ::com::sun::star::lang::XMultiServiceFactory CreateApplicationServiceManager();
+static ::com::sun::star::uno::Reference ::com::sun::star::lang::XMultiServiceFactory CreateApplicationServiceManager();
void RegisterServices( ::com::sun::star::uno::Reference ::com::sun::star::lang::XMultiServiceFactory xSMgr );
void DeregisterServices();
diff --git a/desktop/source/app/app.cxx b/desktop/source/app/app.cxx
index 873588d..1a8fb2f 100644
--- a/desktop/source/app/app.cxx
+++ b/desktop/source/app/app.cxx
@@ -322,7 +322,10 @@ CommandLineArgs* Desktop::GetCommandLineArgs()
{
::osl::MutexGuard aGuard( ::osl::Mutex::getGlobalMutex() );
if ( !pArgs )
+{
+ensureProcessServiceFactory();
pArgs = new CommandLineArgs;
+}
}
return pArgs;
@@ -711,8 +714,15 @@ void Desktop::Init()
copy_bundled_recursive( aPreregBundledPath, aUserPath, +1 );
}
}
-
+
// We need to have service factory before going further.
+// We need to have service factory before going further, but see fdo#37195.
+// Doing this will mmap common.rdb, making it not overwritable on windows,
+// so this can't happen before the synchronization above. Lets rework this
+// so that the above is called *from* ensureProcessServiceFactory or
+// something to enforce this gotcha
+ensureProcessServiceFactory();
+
if( !::comphelper::getProcessServiceFactory().is())
{
OSL_FAIL(Service factory should have been
Re: [Libreoffice] [REVIEW] Fixing layout breakage in pivot table dialog
Hi Kendy, On Thu, 2011-09-01 at 11:59 +0200, Jan Holesovsky wrote: The patch generally looks fine - I just wonder, why there is the vertical compression, and why only on XP? Isn't the root cause something in vcl? The thing is, I don't even know this vertical compression is a defect. It may well be done intentionally. When you compare the size of buttons in other apps in general, they are smaller in XP than in Win7. Given this, and given that it's more complex to adjust the size of the page/row/column/data field areas, I opted for the simpler solution which is to adjust the height of the dialog itself. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kohei.yosh...@suse.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build break when generating RDBs
Hi Peter,
On Tuesday, 2011-08-30 14:36:01 -0400, Peter Foley wrote:
[ build ALL ] top level modules: i18npool
[ build ALL ] loaded modules: i18npool
[ build RDB ] i18npool_test_breakiterator
awk: cmd. line:1: $R/^\?xml version.*$R/ { next; } {
gsub($R/vnd.sun.star.expand:\$OOO_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$OOO_BASE_DIR,$0);
gsub($R/vnd.sun.star.expand:\$BRAND_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$BRAND_BASE_DIR,$0); print; }
awk: cmd. line:1:^ syntax error
awk: cmd. line:1: $R/^\?xml version.*$R/ { next; } {
gsub($R/vnd.sun.star.expand:\$OOO_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$OOO_BASE_DIR,$0);
gsub($R/vnd.sun.star.expand:\$BRAND_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$BRAND_BASE_DIR,$0); print; }
awk: cmd. line:1: ^ backslash not last character on line
make: ***
[/libreoffice/workdir/unxlngx6.pro/RdbTarget/i18npool_test_breakiterator.rdb]
Error 1
I'm getting the above build error which seems to be caused by $R being
added to the awk regex expression by gb_Helper_abbreviate_dirs.
Apparently you're the only one getting this error, so I wonder what may
be different on your system? I doubt this is a general
gb_Helper_abbreviate_dirs always inserts $R before / problem. Which
platform are you on? I presume winmingw, because that (and windows)
defines gb_Helper_abbreviate_dirs_native to something different than the
general gb_Helper_abbreviate_dirs:
solenv/gbuild/Helper.mk:define gb_Helper_abbreviate_dirs
solenv/gbuild/platform/solaris.mk:gb_Helper_abbreviate_dirs_native =
$(gb_Helper_abbreviate_dirs)
solenv/gbuild/platform/winmingw.mk:define gb_Helper_abbreviate_dirs_native
solenv/gbuild/platform/ios.mk:gb_Helper_abbreviate_dirs_native =
$(gb_Helper_abbreviate_dirs)
solenv/gbuild/platform/windows.mk:define gb_Helper_abbreviate_dirs_native
solenv/gbuild/platform/macosx.mk:gb_Helper_abbreviate_dirs_native =
$(gb_Helper_abbreviate_dirs)
solenv/gbuild/platform/unxgcc.mk:gb_Helper_abbreviate_dirs_native =
$(gb_Helper_abbreviate_dirs)
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] bug in vcl make files?
Hi all, As I tried to compile vcl module with raised dbglevel I found out the following error at linking: /home/LOff/libo/workdir/unxlngi6.pro/CxxObject/vcl/unx/headless/svpgdi.o: In function `dbgOut(boost::shared_ptrbasebmp::BitmapDevice const)': svpgdi.cxx:(.text._Z6dbgOutRKN5boost10shared_ptrIN7basebmp12BitmapDeviceEEE[dbgOut(boost::shared_ptrbasebmp::BitmapDevice const)]+0x13a): undefined reference to `basebmp::debugDump(boost::shared_ptrbasebmp::BitmapDevice const, std::basic_ostreamchar, std::char_traitschar )' collect2: ld returned 1 exit status make: *** [/home/LOff/libo/workdir/unxlngi6.pro/LinkTarget/Library/libvclplug_svplo.so] Error 1 As I saw in cpp code this should be ok, so probably basebmp debug.cxx is not marked for linking in the project. Could someone look at this issue who knows make files? Thanks, Gabor ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] warining elimination
Hello,
Here is a patch to avoid compile time warnings, actually most of them
are unfortunatelly not in our source but in libraries like OpenSSL,
could you tell me why are these libraries compiled? On most of the linux
machines it should be already installed, aren't compiled shared
libraries enough? And why? I actually don't understand why it's
compiled, it should be mentioned only as a dependency, so who doesn't
have it shoul look up on apt/rpm.
Gabor
From 1b27ced6fc523886ba748e9a4e3e67fbf6312852 Mon Sep 17 00:00:00 2001
From: Gabor Jenei jen...@elte.hu
Date: Thu, 1 Sep 2011 12:30:03 +0200
Subject: [PATCH] fix warnings
---
cppcanvas/source/mtfrenderer/emfplus.cxx | 108 -
cppcanvas/source/mtfrenderer/implrenderer.cxx |8 +-
sc/source/core/inc/parclass.hxx |2 +-
sc/source/core/tool/parclass.cxx | 12 ++--
svtools/source/filter/wmf/enhwmf.cxx | 15 ++--
svtools/source/filter/wmf/winmtf.cxx |2 +-
6 files changed, 72 insertions(+), 75 deletions(-)
diff --git a/cppcanvas/source/mtfrenderer/emfplus.cxx
b/cppcanvas/source/mtfrenderer/emfplus.cxx
index 327fd41..b70f90a 100644
--- a/cppcanvas/source/mtfrenderer/emfplus.cxx
+++ b/cppcanvas/source/mtfrenderer/emfplus.cxx
@@ -270,7 +270,7 @@ namespace cppcanvas
s header parts;
EMFP_DEBUG (printf (EMF+\tregion\n));
-EMFP_DEBUG (printf (EMF+\theader: 0x%08x parts: %d\n,
header, parts));
+EMFP_DEBUG (printf (EMF+\theader: 0x%08x parts: %d\n,
(unsigned int)header, (int)parts));
if (parts) {
if( parts0 ||
sal_uInt32(parts)SAL_MAX_INT32/sizeof(sal_Int32) )
@@ -280,12 +280,12 @@ namespace cppcanvas
for (int i = 0; i parts; i ++) {
s combineMode [i];
-EMFP_DEBUG (printf (EMF+\tcombine mode [%d]:
0x%08x\n, i, combineMode [i]));
+EMFP_DEBUG (printf (EMF+\tcombine mode [%d]:
0x%08x\n, i,(unsigned int)combineMode [i]));
}
}
s initialState;
-EMFP_DEBUG (printf (EMF+\tinitial state: 0x%08x\n,
initialState));
+EMFP_DEBUG (printf (EMF+\tinitial state: 0x%d\n,(int)
initialState));
}
};
@@ -355,7 +355,7 @@ namespace cppcanvas
s header type;
-EMFP_DEBUG (printf (EMF+\tbrush\nEMF+\theader: 0x%08x type:
%d\n, header, type));
+EMFP_DEBUG (printf (EMF+\tbrush\nEMF+\theader: 0x%08x type:
%d\n,(unsigned int) header,(int) type));
switch (type) {
case 0:
@@ -364,7 +364,7 @@ namespace cppcanvas
s color;
solidColor = ::Color (0xff - (color 24), (color
16) 0xff, (color 8) 0xff, color 0xff);
-EMFP_DEBUG (printf (EMF+\tsolid color: 0x%08x\n,
color));
+EMFP_DEBUG (printf (EMF+\tsolid color: 0x%08x\n,
(unsigned int)color));
break;
}
@@ -373,19 +373,19 @@ namespace cppcanvas
{
s additionalFlags wrapMode;
-EMFP_DEBUG (printf (EMF+\tpath gradient, additional
flags: 0x%02x\n, additionalFlags));
+EMFP_DEBUG (printf (EMF+\tpath gradient, additional
flags: 0x%02x\n,(unsigned int) additionalFlags));
sal_uInt32 color;
s color;
solidColor = ::Color (0xff - (color 24), (color
16) 0xff, (color 8) 0xff, color 0xff);
-EMFP_DEBUG (printf (EMF+\tcenter color: 0x%08x\n,
color));
+EMFP_DEBUG (printf (EMF+\tcenter color:
0x%08x\n,(unsigned int) color));
s areaX areaY;
EMFP_DEBUG (printf (EMF+\tcenter point: %f,%f\n,
areaX, areaY));
s surroundColorsNumber;
-EMFP_DEBUG (printf (EMF+\tsurround colors: %d\n,
surroundColorsNumber));
+EMFP_DEBUG (printf (EMF+\tsurround colors:
%d\n,(int) surroundColorsNumber));
if( surroundColorsNumber0 ||
sal_uInt32(surroundColorsNumber)SAL_MAX_INT32/sizeof(::Color) )
surroundColorsNumber =
SAL_MAX_INT32/sizeof(::Color);
@@ -396,14 +396,14 @@ namespace cppcanvas
surroundColors[i] = ::Color (0xff - (color 24),
(color 16) 0xff, (color 8) 0xff, color 0xff);
if (i == 0)
secondColor = surroundColors [0];
-EMFP_DEBUG (printf (EMF+\tsurround color[%d]:
0x%08x\n, i, color));
+EMFP_DEBUG (printf (EMF+\tsurround color[%d]:
0x%08x\n, i, (unsigned
Re: [Libreoffice] bug in vcl make files?
On 1 September 2011 15:14, Jenei Gábor jen...@elte.hu wrote: Hi all, As I tried to compile vcl module with raised dbglevel I found out the following error at linking: /home/LOff/libo/workdir/unxlngi6.pro/CxxObject/vcl/unx/headless/svpgdi.o: In function `dbgOut(boost::shared_ptrbasebmp::BitmapDevice const)': svpgdi.cxx:(.text._Z6dbgOutRKN5boost10shared_ptrIN7basebmp12BitmapDeviceEEE[dbgOut(boost::shared_ptrbasebmp::BitmapDevice const)]+0x13a): undefined reference to `basebmp::debugDump(boost::shared_ptrbasebmp::BitmapDevice const, std::basic_ostreamchar, std::char_traitschar )' collect2: ld returned 1 exit status make: *** [/home/LOff/libo/workdir/unxlngi6.pro/LinkTarget/Library/libvclplug_svplo.so] Error 1 As I saw in cpp code this should be ok, so probably basebmp debug.cxx is not marked for linking in the project. Could someone look at this issue who knows make files? That's not about makefiles. debugDump() is not marked for exporting, you can do this in cxx file with SAL_DLLPUBLIC_EXPORT or in hxx files. But in hxx you need to use library specific macro defined as in http://opengrok.libreoffice.org/xref/core/basebmp/inc/basebmp/bitmapdevice.hxx#42 It's more complicated because of error in windows compilers, I think. I have pushed this one. ( http://cgit.freedesktop.org/libreoffice/core/commit/?id=e21822008dff0c618e8947d7343bc70d51d47ec3 ) Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] warining elimination
Hello Gábor, 2011/9/1 Jenei Gábor jen...@elte.hu: Hello, Here is a patch to avoid compile time warnings, actually most of them are unfortunatelly not in our source but in libraries like OpenSSL, could you tell me why are these libraries compiled? On most of the linux machines it should be already installed, aren't compiled shared libraries enough? And why? I actually don't understand why it's compiled, it should be mentioned only as a dependency, so who doesn't have it shoul look up on apt/rpm. You can configure --with-system-openssl. Same applies to many system libs. See distro-configs/ and ./configure --help On Windows for example one has to compile everything. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] some cleanup of Kashida justification code
On Thu, 2011-09-01 at 01:28 +0200, Khaled Hosny wrote: Hello all, While trying to fix the eternal brokenness of Kashida justification code, I found some low hanging cleanups. See attached patches. Great that someone is working on that, IIRC Martin was particular exercised about the Kashida stuff ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] how to tell build process where to find DirectX?
Hi My DirectX is installed in C:\Program Files\Microsoft DirectX SDK (February 2010) But the canvas part of the build process doesn't seem to be able to find it. Any help appreciated. Thanks, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html = Building module canvas = Entering /cygdrive/c/libreoffice/git2/libo/canvas/prj cd .. make -s -r -j2 make -s -r deliverlog CxxObject/canvas/source/directx/dx_bitmap.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_bitmapcanvashelper.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_canvasbitmap.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_canvasfont.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_canvashelper.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_canvashelper_texturefill.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_devicehelper.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_gdiplususer.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_impltools.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_linepolypolygon.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_textlayout.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_textlayout_drawhelper.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib CxxObject/canvas/source/directx/dx_vcltools.o is linked in by Library/idirectx9canvas.lib Library/igdipluscanvas.lib C:/libreoffice/git2/libo/solenv/gbuild/extensions/final_ObjectOwner.mk:43: [ WARN ] !!! [ WARN ] !!! duplicate linked objects [ WARN ] !!! [ build CXX ] canvas/source/directx/dx_bitmap [ build CXX ] canvas/source/directx/dx_bitmapcanvashelper [ build CXX ] canvas/source/directx/dx_canvas c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_canvasbitmap c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_canvasfont c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_canvashelper c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_canvashelper_texturefill c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_devicehelper c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_gdiplususer c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_impltools c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_linepolypolygon c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_textlayout c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_textlayout_drawhelper c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_vcltools c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ] canvas/source/directx/dx_9rm c:\libreoffice\git2\libo\canvas\source\directx\dx_winstuff.hxx(86) : fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory [ build CXX ]
[Libreoffice] minutes of tech. steering call ...
Present: + Norbert, Andras, Bjoern, Petr, Kendy, Caolan, Rainer, Stephan, Kohei, Michael + Finished Action Items + in-progress: setup gerrit a test repo (Bjoern) + in-progress: disable .po file editing hook: only to be used in translations (Norbert) + add Thorsten as qa list co-administator (Rainer) + come up with a new 3.4 / 3.3 schedule with dropped / less frequent monthly release (Petr) + check and enable new RTF import in master by default (Cedric) + Pending Action Items + at hackfest: get Bjoern setup with a vhost for gerrit (Thorsten / Christian) + in-progress: get bugzilla query wrt. master regressions to Michael (Rainer) + New extensions website: publish / tdf blog (Florian) + enable on-line updates for QA for dailies ... (Kendy) + non-TDF branding technical question(s) (Thorsten) + close bug-voting (no) wontfix with rational (Rainer) + fixup qa list configuration (Thorsten) + write substance of what is needed wrt. the extensions templates announce send to Florian (Andreas) * Agenda items + pending action items + request to move 3.5.x feature-freeze forward (Cor) + still not available + ODF / standards work file-format patches / flow (Michael) + review xmloff patches carefully to get sane XML in our namespaces + forward as formal proposals to the ODF TC via Thorsten + we should not block progress on this AA: + publicise / aggregate our list of proposals / extensions (Thorsten) + Release mgmt (Petr) + 3.4.3 status + released, looks good. + discuss Petr's new schedule + reducing stable release frequency as we move in updated schedule published: + have a TSC decision point for skipping 3.3.5 if there are no changes worth releaseing + QA update (Rainer) + 3.4.3 works as expected - no show stoppers + intermittent win32 only dictionary loss in 3.4.3 (#37195) + Caolan has heroically fixed it (probably) + bug filing interface (Loic working on it) AA: + need more ideas / design / interface input (Michael) + next bug hunting session - next Tuesday + http://wiki.documentfoundation.org/QA/IRCSessions#Monthly_Bug_Hunting_Sessions + Oracle / OO.o extensions repo is flaky + need to accelerate move to the new extensions repo + Stephan welcome / introduction -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED][PATCH] warining elimination
On Thu, 2011-09-01 at 15:34 +0200, Jenei Gábor wrote: Hello, Here is a patch to avoid compile time warnings Looks fine, we get screwed a bit because sal_Int32 is an int on x86_64 and long on x86 which triggers some of these. And they're inside debug mode I think in this case. The alternative fix for some of them, though probably overkill for debug stuff is the SAL_PRIdINT32, SAL_PRIuUINT32, SAL_PRIxUINT32 and SAL_PRIXUINT32 set of stuff. I pushed this, but some conflicts from changes in between, I just dropped the conflicting bits. OpenSSL, could you tell me why are these libraries compiled? On most of the linux machines it should be already installed, aren't compiled shared libraries enough IIRC, correct me if I'm wrong, the soname of openssl changes a bit so stuff linked against one doesn't resolve against another, even if we linked the universal build against an old one. Possibly reworking the bits that require openssl to use nss and/or linking statically might make some of that go away. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build break when generating RDBs
On Thu, 1 Sep 2011, Eike Rathke wrote:
Hi Peter,
On Tuesday, 2011-08-30 14:36:01 -0400, Peter Foley wrote:
[ build ALL ] top level modules: i18npool
[ build ALL ] loaded modules: i18npool
[ build RDB ] i18npool_test_breakiterator
awk: cmd. line:1: $R/^\?xml version.*$R/ { next; } {
gsub($R/vnd.sun.star.expand:\$OOO_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$OOO_BASE_DIR,$0);
gsub($R/vnd.sun.star.expand:\$BRAND_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$BRAND_BASE_DIR,$0); print; }
awk: cmd. line:1:^ syntax error
awk: cmd. line:1: $R/^\?xml version.*$R/ { next; } {
gsub($R/vnd.sun.star.expand:\$OOO_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$OOO_BASE_DIR,$0);
gsub($R/vnd.sun.star.expand:\$BRAND_BASE_DIR\$R/program$R/,
vnd.sun.star.expand:$BRAND_BASE_DIR,$0); print; }
awk: cmd. line:1: ^ backslash not last character on line
make: ***
[/libreoffice/workdir/unxlngx6.pro/RdbTarget/i18npool_test_breakiterator.rdb]
Error 1
I'm getting the above build error which seems to be caused by $R being
added to the awk regex expression by gb_Helper_abbreviate_dirs.
Apparently you're the only one getting this error, so I wonder what may
be different on your system? I doubt this is a general
gb_Helper_abbreviate_dirs always inserts $R before / problem. Which
platform are you on? I presume winmingw, because that (and windows)
defines gb_Helper_abbreviate_dirs_native to something different than the
general gb_Helper_abbreviate_dirs:
I'm actually building libreoffice in a gentoo linux x64 chroot.
I don't know if the chroot is causing this problem or not.
awk is 4.0.0
make is 3.82
Let me know if you need any more info.
Thanks,
Peter
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 36703, which changed state. Bug 36703 Summary: Regressions with the new graphite2 https://bugs.freedesktop.org/show_bug.cgi?id=36703 What|Old Value |New Value Resolution|FIXED | Status|RESOLVED|REOPENED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] unnecessary build actions?
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? 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 ...). In a very similar vein, I see lots of this paradigm: ... 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? Thanks, Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH] warining elimination
Hello Jenei, * On Thu, 2011-09-01 at 15:34 +0200, Jenei Gábor wrote: Here is a patch to avoid compile time warnings It seems that your patch has touched the license header in svtools/source/filter/wmf/enhwmf.cxx. IMHO we should revert this part. Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH] warining elimination
Yes,naturally it was only by mistake, so you can make it to be the old. 2011. 09. 01. 18:14 keltezéssel, Korrawit Pruegsanusak írta: Hello Jenei, * On Thu, 2011-09-01 at 15:34 +0200, Jenei Gábor wrote: Here is a patch to avoid compile time warnings It seems that your patch has touched the license header in svtools/source/filter/wmf/enhwmf.cxx. IMHO we should revert this part. Best Regards, ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] More numbering types: one, two, three, ...
Hi Mohammad, On Thursday, 2011-09-01 16:04:53 +0430, Mohammad Elahi wrote: However, this looks more like spell-out than level numbering and as such misses the point of the numbering provider. If we wanted to implement spell-out I'd rather go for ICU's methods than implementing yet another home-grown solution. Yes, it seems a better approach, so may be [PATCH] Add numbering type in persian word should revised by ICU's methods. I thought the persian word numbers were meant to be used in numbering, isn't that the case? Please don't confuse numbering used for paragraphs with general spell-out of numbers. 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] [PATCH] More numbering types: one, two, three, ...
Hi Eike I thought the persian word numbers were meant to be used in numbering, isn't that the case? Well, I wanted to use it for a few page numbers in start of my document. Instead of roman numbers which is customary in some English books. Please don't confuse numbering used for paragraphs with general spell-out of numbers. Well, I wanted to used spell-out of numbers in Persian words as first pages numbers :/ -Elahi ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] new BUG 36594
Hi Jenei,
On Wednesday, 2011-08-31 12:59:06 +0200, Jenei Gábor wrote:
Hello Eike,
I made the changes you said, and I resolved the no linefeed issue
also, I hope it is ok now, and can be pushed, actually for me worked
fine with all types of comments. Also I tried to follow the
principals you said. So, push it if you think there is no need to
correct something.
You're on the right track :-)
First, I have a question because I'm by no means an SQL expert:
+::rtl::OUString delComment(const ::rtl::OUString sQuery){
[...]
+for(size_t i=0;inQueryLen;i++){
+if(sCopy[i]=='\' !bIsText2 !bComment) bIsText1=!bIsText1;
+if(sCopy[i]=='\'' !bIsText1 !bComment) bIsText2=!bIsText2;
+if(sCopy[i]=='\n' bComment) bComment=false;
+if(!bIsText1 !bIsText2 (i+1)nQueryLen sCopy[i]=='-'
sCopy[i+1]=='-') bComment=true;
+if(!bIsText1 !bIsText2 (i+1)nQueryLen sCopy[i]=='/'
sCopy[i+1]=='/') bComment=true;
+if(!bComment) sTemp.append(sCopy[i],1);
This and the similar loop in getComment() treats also // as comment
leader, I thought only -- is used for comment until end of line?
A short web search didn't come up with anything different.
Second, I erred earlier when I talked about the struct with nPos,
I overlooked that doSaveAsDoc() reconstructs the query string with
sTranslatedStmt = m_xComposer-getComposedQuery();
so actually the resulting sTranslatedStmt may be different from the
original m_sStatement and the positions may not match and your previous
approach with searching for LFs would be needed instead. Sorry for
confusion. Just tell me about the // leader and I'll fix things up for
you.
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] [PATCH] new BUG 36594
Well, as I know for HSQL -- and // are equal, so // is like one line
comment in C++. Well,thanks for your work on the other hand :)
Gabor
2011. 09. 01. 20:15 keltezéssel, Eike Rathke írta:
Hi Jenei,
On Wednesday, 2011-08-31 12:59:06 +0200, Jenei Gábor wrote:
Hello Eike,
I made the changes you said, and I resolved the no linefeed issue
also, I hope it is ok now, and can be pushed, actually for me worked
fine with all types of comments. Also I tried to follow the
principals you said. So, push it if you think there is no need to
correct something.
You're on the right track :-)
First, I have a question because I'm by no means an SQL expert:
+::rtl::OUString delComment(const ::rtl::OUString sQuery){
[...]
+for(size_t i=0;inQueryLen;i++){
+if(sCopy[i]=='\' !bIsText2 !bComment) bIsText1=!bIsText1;
+if(sCopy[i]=='\'' !bIsText1 !bComment) bIsText2=!bIsText2;
+if(sCopy[i]=='\n' bComment) bComment=false;
+if(!bIsText1 !bIsText2 (i+1)nQueryLen sCopy[i]=='-'
sCopy[i+1]=='-') bComment=true;
+if(!bIsText1 !bIsText2 (i+1)nQueryLen sCopy[i]=='/'
sCopy[i+1]=='/') bComment=true;
+if(!bComment) sTemp.append(sCopy[i],1);
This and the similar loop in getComment() treats also // as comment
leader, I thought only -- is used for comment until end of line?
A short web search didn't come up with anything different.
Second, I erred earlier when I talked about the struct with nPos,
I overlooked that doSaveAsDoc() reconstructs the query string with
sTranslatedStmt = m_xComposer-getComposedQuery();
so actually the resulting sTranslatedStmt may be different from the
original m_sStatement and the positions may not match and your previous
approach with searching for LFs would be needed instead. Sorry for
confusion. Just tell me about the // leader and I'll fix things up for
you.
Eike
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] bug in vcl make files?
On 1 September 2011 21:26, Stephan Bergmann stephan.bergmann.second...@googlemail.com wrote: On Sep 1, 2011, at 3:47 PM, Matúš Kukan wrote: On 1 September 2011 15:14, Jenei Gábor jen...@elte.hu wrote: Hi all, As I tried to compile vcl module with raised dbglevel I found out the following error at linking: /home/LOff/libo/workdir/unxlngi6.pro/CxxObject/vcl/unx/headless/svpgdi.o: In function `dbgOut(boost::shared_ptrbasebmp::BitmapDevice const)': svpgdi.cxx:(.text._Z6dbgOutRKN5boost10shared_ptrIN7basebmp12BitmapDeviceEEE[dbgOut(boost::shared_ptrbasebmp::BitmapDevice const)]+0x13a): undefined reference to `basebmp::debugDump(boost::shared_ptrbasebmp::BitmapDevice const, std::basic_ostreamchar, std::char_traitschar )' collect2: ld returned 1 exit status make: *** [/home/LOff/libo/workdir/unxlngi6.pro/LinkTarget/Library/libvclplug_svplo.so] Error 1 As I saw in cpp code this should be ok, so probably basebmp debug.cxx is not marked for linking in the project. Could someone look at this issue who knows make files? That's not about makefiles. debugDump() is not marked for exporting, you can do this in cxx file with SAL_DLLPUBLIC_EXPORT or in hxx files. But in hxx you need to use library specific macro defined as in http://opengrok.libreoffice.org/xref/core/basebmp/inc/basebmp/bitmapdevice.hxx#42 It's more complicated because of error in windows compilers, I think. I have pushed this one. ( http://cgit.freedesktop.org/libreoffice/core/commit/?id=e21822008dff0c618e8947d7343bc70d51d47ec3 ) You cannot do it that way -- it will not work on Windows. See http://wiki.services.openoffice.org/wiki/Symbol_Visibility for details (in short, you need the BASEBMP_DLLPUBLIC/BASEBMP_DLLIMPLEMENTATION stuff in the header file if you want to be able to link against the function on Windows). Yeah, tinderbox is complaining.. I did not know I can't do even this. Will try to remember to prepare a proper patch tomorrow, unless someone beats me to it… Maybe I will do this today, but if not, thanks for proper patch Matúš ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] bug in vcl make files?
2011. 09. 01. 21:26 keltezéssel, Stephan Bergmann írta: On Sep 1, 2011, at 3:47 PM, Matúš Kukan wrote: On 1 September 2011 15:14, Jenei Gáborjen...@elte.hu wrote: Hi all, As I tried to compile vcl module with raised dbglevel I found out the following error at linking: /home/LOff/libo/workdir/unxlngi6.pro/CxxObject/vcl/unx/headless/svpgdi.o: In function `dbgOut(boost::shared_ptrbasebmp::BitmapDevice const)': svpgdi.cxx:(.text._Z6dbgOutRKN5boost10shared_ptrIN7basebmp12BitmapDeviceEEE[dbgOut(boost::shared_ptrbasebmp::BitmapDevice const)]+0x13a): undefined reference to `basebmp::debugDump(boost::shared_ptrbasebmp::BitmapDevice const, std::basic_ostreamchar, std::char_traitschar )' collect2: ld returned 1 exit status make: *** [/home/LOff/libo/workdir/unxlngi6.pro/LinkTarget/Library/libvclplug_svplo.so] Error 1 As I saw in cpp code this should be ok, so probably basebmp debug.cxx is not marked for linking in the project. Could someone look at this issue who knows make files? That's not about makefiles. debugDump() is not marked for exporting, you can do this in cxx file with SAL_DLLPUBLIC_EXPORT or in hxx files. But in hxx you need to use library specific macro defined as in http://opengrok.libreoffice.org/xref/core/basebmp/inc/basebmp/bitmapdevice.hxx#42 It's more complicated because of error in windows compilers, I think. I have pushed this one. ( http://cgit.freedesktop.org/libreoffice/core/commit/?id=e21822008dff0c618e8947d7343bc70d51d47ec3 ) You cannot do it that way -- it will not work on Windows. Seehttp://wiki.services.openoffice.org/wiki/Symbol_Visibility for details (in short, you need the BASEBMP_DLLPUBLIC/BASEBMP_DLLIMPLEMENTATION stuff in the header file if you want to be able to link against the function on Windows). Will try to remember to prepare a proper patch tomorrow, unless someone beats me to it… -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Well, it's a unix like system specific source, so I guess there is no need to use it in Windows, but thanks for your warn though. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] new BUG 36594
Hi Jenei,
On Thursday, 2011-09-01 20:31:11 +0200, Jenei Gábor wrote:
Well, as I know for HSQL -- and // are equal, so // is like one line
comment in C++.
Hmm.. ok.
Btw, this
+if(sCopy[i]=='\n' || i==nQueryLen-1){
+nCommentLen++;
+if(i==nQueryLen-1)sTemp.append(sCopy[i],1);
+if(bComment) bComment=false;
+sTemp.append((sal_Unicode)'\n');
appends yet another \n if there was already one at the very end of the
query string, is that intentional?
Well,thanks for your work on the other hand :)
I'm rearranging some logic to fold various if's away that are
unnecessarily executed in the loops. I'll let you know details later.
How can I quickly setup a database and query to test this thing?
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] [PATCH] new BUG 36594
Well, if you are using linux you could get mysql and its client from apt
on Debian based systems(I guess on redhat based systems you can use
yum), well, the plus linefeed is not really intentional but does not
cause any problem, so I didn't mind too much. But also in LibreOffice
Base if you turn on running SQL query in SQL edit view it will pass the
SQL query directly to HSQL without any type of modification, or check,
so if you push this button it should work totally as a HSQL prompt.
Gabor
2011. 09. 01. 21:59 keltezéssel, Eike Rathke írta:
Hi Jenei,
On Thursday, 2011-09-01 20:31:11 +0200, Jenei Gábor wrote:
Well, as I know for HSQL -- and // are equal, so // is like one line
comment in C++.
Hmm.. ok.
Btw, this
+if(sCopy[i]=='\n' || i==nQueryLen-1){
+nCommentLen++;
+if(i==nQueryLen-1)sTemp.append(sCopy[i],1);
+if(bComment) bComment=false;
+sTemp.append((sal_Unicode)'\n');
appends yet another \n if there was already one at the very end of the
query string, is that intentional?
Well,thanks for your work on the other hand :)
I'm rearranging some logic to fold various if's away that are
unnecessarily executed in the loops. I'll let you know details later.
How can I quickly setup a database and query to test this thing?
Eike
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] make install File not found: dict-de-DE.oxt
Hi all, I finally managed to build libreoffice (git downloaded from yesterday) on my OpenSuse 11.4. But while everything went fine the final make install fails with following output: libreoffice/core sudo make install Installing in /usr/local... Running LibreOffice installer Subroutine installer::epmfile::getcwd redefined at /home/papa/projects/libreoffice/core/solenv/bin/modules/installer/epmfile.pm line 43 ... checking environment variables ... make_installer.pl, version 1.0 Product list file: openoffice.lst Taking setup script from solver Unpackpath: /tmp Compiler: unxlngx6 Product: LibreOffice BuildID: 0 Build: OOO350 No minor set Product version Installpath: /usr/local Package format: native Not calling epm No file stripping Unzip ARCHIVE files Languages: en-US ... checking required files ... .. searching zip ... Found: /usr/bin/zip ... analyzing openoffice.lst ... rmdir: konnte „/tmp/LibreOffice//logging/“ nicht entfernen: Das Verzeichnis ist nicht leer ... reading include paths ... ... analyzing script: /home/papa/projects/libreoffice/core/solver/unxlngx6.pro/bin/setup_osl.ins ... ... analyzing directories ... ... analyzing files ... ... analyzing scpactions ... ... analyzing shortcuts ... ... analyzing unix links ... ... analyzing profile ... ... analyzing profileitems ... ... analyzing modules ... ... languages en-US ... ... analyzing files ... ERROR: The following files could not be found: ERROR: File not found: dict-de-AT.oxt ERROR: File not found: dict-de-CH.oxt ERROR: File not found: dict-de-DE.oxt ... cleaning the output tree ... ... removing directory /tmp/ooopackaging/i_130181314909971 ... ** ERROR: ERROR: Missing files in function: remove_Files_Without_Sourcedirectory ** ** ERROR: Saved logfile: /tmp/LibreOffice//logging/en-US/log_OOO350_en-US.log ** Thu Sep 1 22:46:15 2011 (00:04 min.) Failed to install: at /home/papa/projects/libreoffice/core/solenv/bin/ooinstall line 120. make: *** [install] Fehler 255 Sounds to me like a trivial problem, but I'm too unexperienced ??? Any advice? Regards, Karl -- Dr. Karl Behler, E1 CODAC MPI f. Plasmaphysik Boltzmannstr. 2 85748 Garching +49 89 3299-1351 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] cppcheck scope
This patch should fix the cppcheck style warnings for grfmgr.cxx:
core/svtools/source/graphic/grfmgr.cxx
278 variableScope style The scope of the variable 'nNewLeft' can be
reduced
278 variableScope style The scope of the variable 'nNewTop' can be
reduced
278 variableScope style The scope of the variable 'nNewRight' can be
reduced
278 variableScope style The scope of the variable 'nNewBottom' can be
reduced
279 variableScope style The scope of the variable 'fScale' can be
reduced
patch is released under LGPLv3.
-- Kenneth
diff --git a/svtools/source/graphic/grfmgr.cxx b/svtools/source/graphic/grfmgr.cxx
index 43b8687..4e3d994 100644
--- a/svtools/source/graphic/grfmgr.cxx
+++ b/svtools/source/graphic/grfmgr.cxx
@@ -275,8 +275,6 @@ sal_Bool GraphicObject::ImplGetCropParams( OutputDevice* pOut, Point rPt, Size
const MapMode aMap100( MAP_100TH_MM );
SizeaSize100;
longnTotalWidth, nTotalHeight;
-longnNewLeft, nNewTop, nNewRight, nNewBottom;
-double fScale;
if( nRot10 )
{
@@ -301,17 +299,17 @@ sal_Bool GraphicObject::ImplGetCropParams( OutputDevice* pOut, Point rPt, Size
if( aSize100.Width() 0 aSize100.Height() 0 nTotalWidth 0 nTotalHeight 0 )
{
-fScale = (double) aSize100.Width() / nTotalWidth;
-nNewLeft = -FRound( ( ( pAttr-GetMirrorFlags() BMP_MIRROR_HORZ ) ? pAttr-GetRightCrop() : pAttr-GetLeftCrop() ) * fScale );
-nNewRight = nNewLeft + FRound( aSize100.Width() * fScale ) - 1;
+double fScale = (double) aSize100.Width() / nTotalWidth;
+const long nNewLeft = -FRound( ( ( pAttr-GetMirrorFlags() BMP_MIRROR_HORZ ) ? pAttr-GetRightCrop() : pAttr-GetLeftCrop() ) * fScale );
+const long nNewRight = nNewLeft + FRound( aSize100.Width() * fScale ) - 1;
fScale = (double) rSz.Width() / aSize100.Width();
rPt.X() += FRound( nNewLeft * fScale );
rSz.Width() = FRound( ( nNewRight - nNewLeft + 1 ) * fScale );
fScale = (double) aSize100.Height() / nTotalHeight;
-nNewTop = -FRound( ( ( pAttr-GetMirrorFlags() BMP_MIRROR_VERT ) ? pAttr-GetBottomCrop() : pAttr-GetTopCrop() ) * fScale );
-nNewBottom = nNewTop + FRound( aSize100.Height() * fScale ) - 1;
+const long nNewTop = -FRound( ( ( pAttr-GetMirrorFlags() BMP_MIRROR_VERT ) ? pAttr-GetBottomCrop() : pAttr-GetTopCrop() ) * fScale );
+const long nNewBottom = nNewTop + FRound( aSize100.Height() * fScale ) - 1;
fScale = (double) rSz.Height() / aSize100.Height();
rPt.Y() += FRound( nNewTop * fScale );
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Thu, Sep 01, 2011 at 02:43:53PM +0100, Caolán McNamara wrote: On Thu, 2011-09-01 at 11:47 +0200, Khaled Hosny wrote: I just tested with a simple lorem ipsum document with Liberation Serif; page count went down from 24 to 22 after applying the patch Comparison with MSWord will be good to do too, with/without the use extra leading compatibility option. MSWord is not known for its sane handling of font metrics, and I have been told recent (2007-) broke it even further. Regards, Khaled -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH] warining elimination
On Thu, Sep 01, 2011 at 06:48:50PM +0200, Jenei Gábor jen...@elte.hu wrote: Yes,naturally it was only by mistake, so you can make it to be the old. Done. pgpED0rTebcU8.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] make install File not found: dict-de-DE.oxt
Hi Karl, 2011/9/1 Karl Behler (IPP) karl.beh...@ipp.mpg.de: ERROR: The following files could not be found: ERROR: File not found: dict-de-AT.oxt ERROR: File not found: dict-de-CH.oxt ERROR: File not found: dict-de-DE.oxt Today I merged the 3 German dictionary packs into 1. A git pull should solve your problem. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Thu, Sep 01, 2011 at 12:12:28PM +0200, Eike Rathke wrote: This only done for 'unx' similar work is needed for 'win' and 'aqua', but I'm not familiar with these platforms and can't test on it. I wonder if this patch will then introduce significant rendering differences between platforms? Or do we have such anyway already (even if the same fonts are present)? Even if it may currently render differently, I think using the correct font metrics on one system where people complained about it is a step into the right direction. We use different layout engines on unx,mac,win and hopefully each system positions glyphs as accurately as possible when given the right input. I had this idea in mind for a while: unifying the text layout code of all platforms, using HarfBuzz, Cairo, FreeType etc. This would give us more control over text layout (e.g. we can support user selectable OpenType features and more typographic niceties) as well as consistent text rendering on all platforms. The downside is that might give the user different experience between LibreOffice and applications using native APIs (though it can be a good thing sometimes, for example apple does not support Indic scripts in their OpenType implementation, while FOSS font stack does). It also means less code to maintain and debug. But I'm still far from understanding the current text layout code to seriously propose this. Mozilla is moving into this direction as well. Regards, Khaled -- Khaled Hosny Egyptian Arab signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Proof-of-concept] Drastically speedup the offapi (and oovbaapi) build
Hi Kendy, Bjoern On 1 September 2011 10:25, Jan Holesovsky ke...@suse.cz wrote: Hi Matúš, Bjoern, I've found a way how to speedup the build of offapi (which is a major problem on windows - on my box it takes about 10% of the entire build time). The trick is simple - instead of generating the files one by one, several .idl's are treated during one idlc call; something that has been there before gbuildization of the module. Of course, it also handles the case when everything is built, and just 1 .idl changes - in that case, only that one is rebuilt. That's nice. Unfortunately I am heading for vacation, and cannot finish it before I go - do you think anybody of you could have a look, please? So, I had a look, it works that way but is not so much faster. With the attached patch, the offapi/UnoApi_offapi.mk (and oovbaapi) has to change to something like the following; this is of course only part of that, the other rules have to be adapted the same way, but that should be ~trivial. Second part of the problem is that idlc have to be patched to bail out with != 0 exit value, according to the comments it is not the case right now. I was not working on the second part yet and I do not intend to do so. Could someone else do it? I have no idea what idlc is anyway. Enjoy :-) Well, it took a while, or more. Not so much fun but not really problem. Bjoern, could you please approve patches? And how to push them ? First the Kendy's one and then change it? I have attached just one patch for better reviewing but created two. (for UnoApiTarget.mk) Now results.. in offapi: before: make -srj 4 = 75s make -sr = 206s after: make -srj 4 = 71s make -sr = 183s It's little more interesting for oovbaapi: (make -sr) 49s - 34s But that does not take much. May be for Windows it will be bigger difference but also this is something. Or is it possible to process even more files at once? Also from different directories? And there were side-effects. I have no idea why but I had to add include directives for a few idl files (also attached). Thank you, You are welcome, thanks for bringing this up. Matúš diff --git a/solenv/gbuild/UnoApiTarget.mk b/solenv/gbuild/UnoApiTarget.mk index 935c5ea..061c2b7 100644 --- a/solenv/gbuild/UnoApiTarget.mk +++ b/solenv/gbuild/UnoApiTarget.mk @@ -60,46 +60,55 @@ gb_UnoApiTarget_IDLFILES_$(1) := endef define gb_UnoApiTarget_add_idlfiles -$(foreach idl,$(2),$(call gb_UnoApiTarget_add_idlfile,$(1),$(idl))) +$(foreach idl,$(3),$(call gb_UnoApiTarget_add_idlfile,$(1),$(2),$(idl))) + +$(call gb_UnoApiPartTarget_get_target,$(2)/idl.done) : $(foreach repo,$(gb_REPOS),$(foreach idl,$(3),$(realpath $(repo)/$(2)/$(idl).idl))) + $(gb_UnoApiPartTarget__command) endef define gb_UnoApiTarget_add_idlfile -$(call gb_UnoApiTarget_get_target,$(1)) : $(call gb_UnoApiPartTarget_get_target,$(2).urd) -$(call gb_UnoApiPartTarget_get_target,$(2).urd) : $(foreach repo,$(gb_REPOS),$(realpath $(repo)/$(2).idl)) -gb_UnoApiTarget_HPPFILES_$(1) += $(2).hdl -gb_UnoApiTarget_HPPFILES_$(1) += $(2).hpp -gb_UnoApiTarget_IDLFILES_$(1) += $(2).idl +$(call gb_UnoApiTarget_get_target,$(1)) : $(call gb_UnoApiPartTarget_get_target,$(2)/$(3).urd) +$(call gb_UnoApiPartTarget_get_target,$(2)/$(3).urd) : $(call gb_UnoApiPartTarget_get_target,$(2)/idl.done) +gb_UnoApiTarget_HPPFILES_$(1) += $(2)/$(3).hdl +gb_UnoApiTarget_HPPFILES_$(1) += $(2)/$(3).hpp +gb_UnoApiTarget_IDLFILES_$(1) += $(2)/$(3).idl -$(call gb_UnoApiTarget_get_header_target,)$(2).hpp :| $(call gb_UnoApiTarget_get_target,$(1)) -$(call gb_UnoApiTarget_get_header_target,)$(2).hdl :| $(call gb_UnoApiTarget_get_target,$(1)) +$(call gb_UnoApiTarget_get_header_target,)$(2)/$(3).hpp :| $(call gb_UnoApiTarget_get_target,$(1)) +$(call gb_UnoApiTarget_get_header_target,)$(2)/$(3).hdl :| $(call gb_UnoApiTarget_get_target,$(1)) endef define gb_UnoApiTarget_add_idlfiles_noheader -$(foreach idl,$(2),$(call gb_UnoApiTarget_add_idlfile_noheader,$(1),$(idl))) +$(foreach idl,$(3),$(call gb_UnoApiTarget_add_idlfile_noheader,$(1),$(2),$(idl))) + +$(call gb_UnoApiPartTarget_get_target,$(2)/idl_noheader.done) : $(foreach repo,$(gb_REPOS),$(foreach idl,$(3),$(realpath $(repo)/$(2)/$(idl).idl))) + $(gb_UnoApiPartTarget__command) endef define gb_UnoApiTarget_add_idlfile_noheader -$(call gb_UnoApiTarget_get_target,$(1)) : $(call gb_UnoApiPartTarget_get_target,$(2).urd) -$(call gb_UnoApiPartTarget_get_target,$(2).urd) : $(foreach repo,$(gb_REPOS),$(realpath $(repo)/$(2).idl)) -gb_UnoApiTarget_IDLFILES_$(1) += $(2).idl +$(call gb_UnoApiTarget_get_target,$(1)) : $(call gb_UnoApiPartTarget_get_target,$(2)/$(3).urd) +$(call gb_UnoApiPartTarget_get_target,$(2)/$(3).urd) : $(call gb_UnoApiPartTarget_get_target,$(2)/idl_noheader.done) +gb_UnoApiTarget_IDLFILES_$(1) += $(2)/$(3).idl endef define gb_UnoApiTarget_add_idlfiles_nohdl -$(foreach idl,$(2),$(call gb_UnoApiTarget_add_idlfile_nohdl,$(1),$(idl))) +$(foreach idl,$(3),$(call
Re: [Libreoffice] [Proof-of-concept] Drastically speedup the offapi (and oovbaapi) build
On Thu, Sep 1, 2011 at 4:35 AM, Jan Holesovsky ke...@suse.cz wrote: Hi Bjoern, On 2011-09-01 at 11:21 +0200, Bjoern Michaelsen wrote: Just a word of warning after a short skimming of the patch: It seems like you are using $? with huge amounts of files to create a commandline. This is quite risky on Linux, where you easily hit the command length limits of the shell on certain installs (depending on ulimits). There is solenv/gbuild/Tempfile.mk to work around that (to create response files). Tempfile.mk btw is the easiest way to trigger that good old make 3.81 bug. Ah right, I just copied the way the response file was created in the old implementation; Tempfile.mk sounds better. wouldn't it be nicer and more efficient to adapt iclc to have a mode where stdin is the list of file to compile(1) ? the ouput follow usually a pattern based on the input file that way you avoid the whole tempfile dance... Norbert (1) IIRC idlc has a stdin mode, but it is to compile 1 file from stdin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
