compiler and switched to it,
and it seems one of its nice features should be the ability to analyze and
rewrite code, in which case a change like this or e.g. the 'str.length() ==
0' -> 'str.isEmpty()' change could be done reliably by writting some clang
code. I still need
On Saturday 17 of March 2012, Lubos Lunak wrote:
> svx/inc/svx/sdrpaintwindow.hxx |3 +++
> 1 file changed, 3 insertions(+)
>
> New commits:
> commit 9865a0d430da8948210a2cd9d4bae08e6023f4c8
> Author: Luboš Luňák
> Date: Sat Mar 17 08:39:26 2012 +0100
>
>
ere have
been only master commits from me (heh...), you most probably need to either
update or do a clean rebuild (I think I've noticed this one as well and it
needed 'make offapi.clean').
--
Lubos Lunak
l.lu...@suse.cz
___
L
"registration of SDK with Visual Studio [2008] seems to
> be the answer". How do I do that?
in the menu: Microsoft Windows SDK 7.1 -> Visual Studio Registration ->
Windows SDK Configuration Tool
--
Lubos Lunak
l.lu...@suse.cz
at touches lcms2 even with a
ten-foot pole does this define). Is the attached patch a good way to solve
the problem as well? I don't know what the usual idiom of handling this is,
so I'd like somebody to check.
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/lcms2/lcms2-windows-export
http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1332055201.31263#14239
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
27;ve pasted at
http://pastebin.ca/2129689 the log for 'make' after first running 'make
embedserv.clean' (there's other stuff being needlessly rebuilt for whatever
reason). At the end of the log there's also a find command showing that the
library has been built, b
OUStringBuffer? If so, is it OK to clone STRING:SearchBackward(...)
> > to OUStringBuffer::SearchBackward(...)?
No. As said above, if the addition is justified, for consistency it should be
modeled after OUString, not String.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Monday 19 of March 2012, Matúš Kukan wrote:
> On 18 March 2012 21:03, Lubos Lunak wrote:
> > MSVC/Windows build fails at the very end with an error about emserlo.dll
> > missing, probably caused by the recent embedserv conversion to gbuild. As
> > this is seem to be buil
anything there. Hmm, except that this CMS_DLL_BUILD defining
is done in MSVC project file, so I assume that's not used for gcc build. I
suppose the lcms2 build should add -DCMS_DLL_BUILD to CPPFLAGS when not doing
msvc build?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Monday 19 of March 2012, Noel Grandin wrote:
> On 2012-03-19 08:27, Lubos Lunak wrote:
> > That said, I myself dislike the buffer class. I doubt its
> > preallocation is a significant requirement for good performance
> > (especially given it's only 16 characters).
ra bonus points if the code fits to one line and doesn't look like a
madness written by somebody in a maniacal "proper C++(tm)"-induced frenzy.)
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.or
;
> so I guess there is some kind of corruption in the string "pThis" that
> is being passed around.
The this=0x29 suggests that the string is inside another type that is
referenced using a null pointer. Check out the gdb backtrace and search for
where an
On Monday 19 of March 2012, Stephan Bergmann wrote:
> On 03/19/2012 07:27 AM, Lubos Lunak wrote:
> > Or, actually, seeing that _rtl_uString is marked as internal by the
> > doxygen doc, it looks like it might be doable even now. Something to add
> > to my TODO list for maki
methods from that file that no longer exist
> in the source.
That will not work reliably, unless your process also verifies that they are
really unused in all configurations. The list is generated from one
configuration and a manual check is needed that each item is in
oils this,
> > anyway.)
>
> And the += operator irritates me.
Before I start experimenting with more stuff in OUString that might look a
bit like operator+= , what exactly is so irritating about operator= or
operator+= in OUString and why?
On Tuesday 20 of March 2012, Caolán McNamara wrote:
> On Tue, 2012-03-20 at 15:20 +0100, Lubos Lunak wrote:
> > Before I start experimenting with more stuff in OUString that might look
> > a bit like operator+= , what exactly is so irritating about operator= or
> > operator+
uilds, or we can say we follow the C++11/Boost/etc. trend and
not use them, in which case we can have one macro for portable way of saying
noexcept and have an EasyHack for removing the other specifications. BTW, it
should be also noted that SAL_THROW() expands to nothing with gcc.
Op
On Monday 19 of March 2012, Michael Meeks wrote:
> On Mon, 2012-03-19 at 07:33 +0100, Lubos Lunak wrote:
> > Oh, I see. I've already noticed this myself, and that's a good
> > explanation for Voreppe's (lack of) builds. That's a rather bad bug for
> > ti
gt; gb_FULLDEPS := $(true)
> endif
Is this the same like should be with --disable-dependency-tracking, except
that it seems it does not with gbuild?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 23 of March 2012, Lubos Lunak wrote:
> On Thursday 22 of March 2012, Norbert Thiebaud wrote:
> > --- a/solenv/gbuild/gbuild.mk
> > +++ b/solenv/gbuild/gbuild.mk
> > @@ -113,8 +113,12 @@ endif
> >
> > # for clean, setuplocal and removelocal goals we s
opies the .h file
needs to be used even with --disable-dependency-tracking (if there's one), or
there needs to be an early invoked make target that copies everything that
should be copied, or this .h copying idea needs to be dropped.
--
Lubos Lunak
l.lu...@suse.cz
_
77c0cbb4d90c7f6bdcd831bf3
> >
> > and updated the @6-fast and @15-Prague Win32 tinderboxes to use that.
>
> I would not do that so quickly. gbuild does not seem to be ready for
> --disable-dependency-tracking.
> If you get error in i18npool
I have reverted the above commit in
On Monday 26 of March 2012, Norbert Thiebaud wrote:
> On Mon, Mar 26, 2012 at 10:43 AM, Lubos Lunak wrote:
> > I have reverted the above commit in 3-5, the 3-5 tinderbox page is red
> > enough.
>
> The commit above only implement no_dep correctly.. it does not force
> you
de777c0cbb4d90c7f6bdcd831bf3 this problem is now visible in
> i18npool. I fixed it in master as part of
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=15bd35e4f2646ef0bba
>0cc24d171989c9e3ac6e4
>
> Attached patch is aimed to solve this problem for 3-5 branch.
Looks ok t
that the SDK must
be registered as default with Visual Studio (in the menu: Microsoft Windows
SDK 7.1 -> Visual Studio Registration -> Windows SDK Configuration Tool).
You can also have a look at configure.in to see what the check actually looks
for.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Tuesday 27 of March 2012, Matúš Kukan wrote:
> On 26 March 2012 17:31, Lubos Lunak wrote:
> > [ build srs ]
> > /builds/tinderbox/libo-master/basctl/source/basicide/basicprint.src cpp:
> > line 31, Fatal error: Cannot open include file "svx/svxids.hrc"
On Thursday 29 of March 2012, Lubos Lunak wrote:
> hwpfilter/CppunitTest_hwpfilter_test_hwpfilter.mk |1 +
> 1 file changed, 1 insertion(+)
>
> New commits:
> commit 61d6d08667e03271604007fe602063c08e0e8608
> Author: Luboš Luňák
> Date: Thu Mar 29 16:52:42 2012 +0200
&
generating broken .d files (although IIRC the problem was generating Windows
paths rather than Unix paths).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Wednesday 21 of March 2012, Lubos Lunak wrote:
> On Monday 19 of March 2012, Michael Meeks wrote:
> > On Mon, 2012-03-19 at 07:33 +0100, Lubos Lunak wrote:
> > > Oh, I see. I've already noticed this myself, and that's a good
> > > explanation for Voreppe&#x
as
disabling the canvas caused the internal cairo to be dragged in by things
depending on it.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
hen I somehow doubt you'll manage to get
3.4.5 working with that. In fact I'm even surprised the link mentions 3.5 as
usable with Clang, since I had to do several fixes in master this month to
get LO compile and run with Clang on Linux.
--
Lubos Lunak
l.lu...@suse.cz
On Tuesday 20 of March 2012, Lubos Lunak wrote:
> - C++11 deprecates it and instead introduces a noexcept keyword which
> forbids the function to throw anything
>
> I'm not strongly biased either way, but what we have right now are really
> just pretty comments on function
On Thursday 29 of March 2012, Caolán McNamara wrote:
> On Thu, 2012-03-29 at 16:56 +0200, Lubos Lunak wrote:
> > Is there any need to run UI stuff during build? IOW, can't we simply
> > globally force using headless for everything during build?
>
> Unix has the env S
WW8AttributeOutput::FormatULSpace(), we apparently do write
sprmPFContextualSpacing as 2 bytes, which seems wrong.
So could you please explain why you decided to fix the problem this way?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice maili
htly to avoid the copy in the OUString constructor and pushed,
thank you.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
"/" shows things like
nodepath = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("/")) + nodepath;
where the / string instance can be avoided completely. My changes won't do
anything about the long-lived / instances though, so there indeed one shared
instance may take care of all
On Sunday 01 of April 2012, R Skinner wrote:
> On 03/31/12 18:49, Lubos Lunak wrote:
> > If you use the Clang compiler, then I somehow doubt you'll manage to
> > get 3.4.5 working with that. In fact I'm even surprised the link mentions
> > 3.5 as usable with C
On Sunday 01 of April 2012, Rafael Dominguez wrote:
> 0001-Replace-List-with-std-vector-EPPTHyperlink.patch
Looks good, pushed, thank you.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
h
e, pushed, thank you.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
based only on valgrind or if you had some
documents where the sizes didn't exactly match what the spec says.
Miklos has already fixed Read_UL(), but your patch lists more places. Could
you check why those places needed the change and make them read the proper
sizes according to what the
strings (literals, or statically initialized and const
> std::string objects), it could put them all together into one instance in
> const data section.
I doubt any compiler we use treats std::string specially, I'd expect it's a
normal class for it just like any other.
--
age should probably be checked by someone more knowledgeable and
> experienced than me. Maybe it is nothing, but it is probably worth
> checking to be sure.
It seems to me you are correct. I've added !IsEmpty() check to the if(),
which should do what the o
On Tuesday 03 of April 2012, Lubos Lunak wrote:
> On Tuesday 03 of April 2012, Daniel Bankston [danthedev] wrote:
> > Hello, everyone,
> >
> > I have attached my patches for EasyHack Bug 46610.
>
> Looks good to me, I only removed the return's at the end of functi
fix is trivial
here, but still).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
minserter.hxx directly into rtl/ustring.hxx
(hopefully I'm right that it won't break anything in practice), so if you now
need to know what 'foo' is, just do
SAL_DEBUG( "foo is " << foo );
The git commit hook will reject commits with these debug outputs lef
On Tuesday 03 of April 2012, Michael Meeks wrote:
> On Tue, 2012-04-03 at 17:52 +0200, Lubos Lunak wrote:
> > On Tuesday 03 of April 2012, Tor Lillqvist wrote:
> > > (SAL_REINTERPRET_CAST is not used anywhere, says opengrok, so that can
> > > be binned outright.)
> &g
On Tuesday 03 of April 2012, Lubos Lunak wrote:
> On Tuesday 03 of April 2012, Michael Meeks wrote:
> > On Tue, 2012-04-03 at 17:52 +0200, Lubos Lunak wrote:
> > > On Tuesday 03 of April 2012, Tor Lillqvist wrote:
> > > > (SAL_REINTERPRET_CAST is not used an
est it and add to 3-5
> > too.
>
> I assume a7eb227cfcd783ffdccdcec9b56451fb54c26eb6 and
> c813c009479db3fab58fc48740ab8f80ceb93a26, but Luboš should know the
> details.
Yes, but they need 174a1d3c3da7457884a2f79016e8a9375fd5297e fi
On Wednesday 04 of April 2012, Daniel Bankston wrote:
> Lubos Lunak wrote:
> > It seems to me you are correct. I've added !IsEmpty() check to the if(),
> > which should do what the original author wanted.
>
> I'm still a little worried about that aClip object t
inherits from XInterface in 3 different ways, and I wonder what the point of
the explicit casts is. I'll go with thinking the casts are pointless historic
garbage and try plain call to acquire(), it shouldn't make it worse.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ctRegistry_getMutex() gets a warning with Clang that can be
cleanly fixed only by breaking binary compatibility).
Do we have something for either of these?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
to have
> an overloaded operator== and to force bar.equalsfoo("").
Quite possibly yes :). Why would you want the explicit less convenient way?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
OUString anyway, and
it'd also require that person to actually not test the code. So hopefully
very unlikely and IMO not worth the inconvenience.
There'd be also the possibility of getting a warning about comparing const
char* pointers into the compilers, but
is undefined if the comparison
evaluates to true or false (depends on string literal duplicates merging).
Which is why this would be a problem, but compilers warn about this.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
inally going to offer my build machine for this if
needed (it's got nothing to do during the nights anyway, and more than one
rebuild and repack daily probably shouldn't be needed). I have no idea about
the storage requirements of this or the time needed for reasonable repacking,
but if th
please tell me. I'm aware only of these cases where the explicit
OUString ctor is needed:
- return statements (because of the gcc bug)
- tool String class (because that one itself is obsolete and uses should be
converted to OUString)
- when OUString object is really needed, e.g. with t
t does #include
.
PS: I think you didn't want to include the solenv/gbuild/LinkTarget.mk change
in the patch.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 06 of April 2012, Lubos Lunak wrote:
> I'm aware only of these cases where the explicit
> OUString ctor is needed:
>
> - return statements (because of the gcc bug)
> - tool String class (because that one itself is obsolete and uses should be
> converted to OUSt
ot
> that large, so I attached it to this mail.
Looks ok to me, pushed, thank you.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
So because of the 2 things noticed, I think there should be both and so
> just replace "1" by "2" and have "SERVICE_NAME2" as second operand.
>
> Perhaps I'm wrong or missed something, any idea ?
No, your analysis look
t copied it from those few lines above, where there is the
same duplication.
> I've got not idea, if we can just remove WB_DOCKABLE or if it should be
> replaced by another constant.
>
> Any advice ?
I think you can simply remove one of the duplicates.
--
Lubos Lunak
l.lu...
014d35597a37c3220c261e35ae to just
> add a break at the end of line 251.
>
> could it be useful to push this on 3.5 branch this trivial fix ?
Pushed.
Note that it is a good practice to always end each 'case' with break (or
add /*fallthrough intended*/ ) so that the problem
mails
from the Clang tinderbox, where the watchdog eventually kills it, so this is
just to point you to the reason for it.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
mp;rEntries) const;
Why is that? Changing the return value to a reference argument makes the API
worse and it seems like an unnecessary change to me.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.fr
on't know if the debug-draw is still usefull this
> way. I don't understand why this was done.
I don't either, but your patch looks good to me, so I've pushed it, thank
you.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mai
or is there a bigger problem?
[1] http://pastebin.com/S06cqSX6
[2]
http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&full-log=1334074224.6419
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@li
dified for Windows, so that it does not
create symlinks, but instead it copies a file if the one in solver/ is newer.
That would still require 'make dev-install' after every change, but I expect
it should be reasonably fast, quite convenient to use, and probably the be
like the dynamic loader on your system does not support dlsym to
> report a symbol not exported by the lib itself, but only indirectly by a
> lib the first lib links against.
Note that you can check what the dynamic loader does by doing
LD_DEBUG=symbols command (see LD_DEBUG=help /bin/tr
no cycle and it should make sure that anything that does
or will need localedata_en will have it ready.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
to do to get it included into the official tinderbox
> results? (assuming that would be a useful thing).
It happens automatically with -m all . At least it did with my tinderbox.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
L
On Wednesday 11 of April 2012, Rafael Dominguez wrote:
> On Wed, Apr 11, 2012 at 2:53 PM, Caolán McNamara wrote:
> > On Tue, 2012-04-10 at 12:52 +0200, Lubos Lunak wrote:
> > > List* GetSelectEntryList( sal_uInt16 nDepth
t the
problematic rtl::Reference), and then build all of LO
with -DRTL_AUTOMATIC_USING.
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/sal/Library_sal.mk b/sal/Library_sal.mk
index 0b6e30f..eaacf07 100644
--- a/sal/Library_sal.mk
+++ b/sal/Library_sal.mk
@@ -54,6 +54,11 @@ $(eval $(call gb_Library_add
On Thursday 12 of April 2012, Norbert Thiebaud wrote:
> On Thu, Apr 12, 2012 at 7:14 AM, Noel Grandin wrote:
> > So finally (about 3 months later than expected) I've got the tinderbox I
> > promised up and running at my company (Peralex).
>
> Great :-)
>
> > On
On Thursday 05 of April 2012, Mark Wolf wrote:
> Hi, all.
>
> Here are some more comments translated from German to English. This time
> for the 'core/odk' folder.
Could somebody German-speaking please review the patch? It hasn't been pushed
yet as far as I can te
On Thursday 12 of April 2012, Norbert Thiebaud wrote:
> On Thu, Apr 12, 2012 at 9:25 AM, Lubos Lunak wrote:
> > On Thursday 12 of April 2012, Norbert Thiebaud wrote:
> >> On Thu, Apr 12, 2012 at 7:14 AM, Noel Grandin wrote:
> >> > So finally (about 3 months lat
On Thursday 12 of April 2012, Miklos Vajna wrote:
> Hi,
>
> See
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=f4e0cba
>
> I'm attaching a backport of the fix for 3-5.
Pushed.
--
Lubos Lunak
l.lu...@suse.cz
___
L
of what the build target builds in each module is
already a prerequisite for the module's checks (and it'd definitely be so in
an ideal world where everything is tested).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice
ially is bad is when make install (thankfully gone) or make
> check rebuild unneeded stuff which gets rebuilt on every pass.
What especially is bad is when unneeded stuff gets rebuilt on every pass.
Fixed that for ya :).
--
Lubos Lunak
l.lu...@suse.cz
___
#x27;ve removed the unnecessary virtual on the operator() and fixed the error
before pushing.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 13 of April 2012, Rene Engelhard wrote:
> On Fri, Apr 13, 2012 at 04:35:27PM +0200, Lubos Lunak wrote:
> > On Thursday 12 of April 2012, Rene Engelhard wrote:
> > > On Thu, Apr 12, 2012 at 09:13:30PM +0200, Matúš Kukan wrote:
> > > > Or do people use make c
On Friday 13 of April 2012, Matúš Kukan wrote:
> On 13 April 2012 16:32, Lubos Lunak wrote:
> > On Thursday 12 of April 2012, Matúš Kukan wrote:
> >> Maybe it is better to just let check target depend on build target ?
> >> In general.
> >
> > Do you mea
behaviour of the old version. But the comment
you added to the code next to the erasing probably doesn't explain much other
than that the code is there for some reason, this comment above explains it
better, so I've added it to the commit log message. Otherwise the patches
looke
be used there) and more visible that
it is an out argument ("&aExchangeList" makes it obvious that the variable
will be changed by the function).
Could you still please provide patches for these? Thanks.
--
Lubos Lunak
l.lu...@suse.cz
_
On Friday 13 of April 2012, Stephan Bergmann wrote:
> On 04/12/2012 03:59 PM, Lubos Lunak wrote:
> > would somebody see a problem with this?
> >
> > sal/inc/rtl/ustring.hxx :
> > +#ifdef RTL_AUTOMATIC_USING
> > +using ::rtl::OUString;
> > +using ::r
tl::OUStringToOString;
>
> and allow that to be used in .cxx only but not in .hxx. Then again the gain
> is limited by that and its not automatically checkable without some ugly
> extra scripting (right?).
How is this in practice different from my proposal, besides the two
limitation
e path.
(c:/cygwin)/home/tinderbox/libreoffice is not that short, but the build has
finished successfully, the resulting .msi installed without problems, and I
didn't notice any problems when running it. Has that been fixed somehow as
well?
--
Lubos Lunak
l.lu...@suse.cz
_
it should be removed just because
unusedcode.easy lists it. It should always be checked whether what's listed
should really be removed, the file is just automatically generated and it is
fallible.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffic
actually are. Given that sc/sd/sw are the
biggest three, it probably even makes the biggest difference to disable the
two that one does not work on.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http:/
, and I checked that .odt
export/import (which uses it too) still works. But I have no idea what the
difference actually is, besides making reading use the same value like
writing.
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/sw/source/core/unocore/unoframe.cxx b/sw/source/core/unocore
d debug builds with visibility
disabled and link, and build release builds with object inclusion, but I
don't know if that is worth it.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
::vector();
return aLbTree.GetSelectEntryList( nType );
which will avoid the copy when calling the other function as well, and the
function is not called at all when not needed. I tweaked that before
committing, now it's perfect :).
--
Lubos Lunak
l.
On Tuesday 17 of April 2012, Tomáš Chvátal wrote:
> Dne 17.4.2012 10:11, Lubos Lunak napsal(a):
> > On Tuesday 17 of April 2012, Tom ChvXXtal wrote:
> >> --enable-ext-languagetool requires --with-java now bit more sanely.
...
> >> AC_MSG_CHECKING([for Languag
On Monday 16 of April 2012, Matúš Kukan wrote:
> On 16 April 2012 18:23, Lubos Lunak wrote:
> > It is made even worse by the fact that make+gbuild order build commands
> > so that allmost all compiles go first and linking goes last
>
> As I've seen complaining about th
On Monday 16 of April 2012, Markus Mohrhard wrote:
> 2012/4/16 Lubos Lunak :
> > On Monday 16 of April 2012, Michael Meeks wrote:
> >> Oh - and finally (Lubos) I pushed an item to the ESC agenda to
> >> discuss whether we should be exposing tons of classes an
On Tuesday 17 of April 2012, Stephan Bergmann wrote:
> On 04/16/2012 06:23 PM, Lubos Lunak wrote:
> > On Monday 16 of April 2012, Michael Meeks wrote:
> >>Oh - and finally (Lubos) I pushed an item to the ESC agenda to discuss
> >> whether we should be exposing tons o
On Tuesday 17 of April 2012, Bjoern Michaelsen wrote:
> On Tue, Apr 17, 2012 at 02:19:59PM +0200, Lubos Lunak wrote:
> > I don't think it would hurt parallelism much, because the linking of svx
> > needs to be done somewhen, and make should have enough of other stuff to
>
econd->getPropertyValue(PropertyNameSupplier::GetPropertyNameSupplier(
>) .GetName( PROP_Z_ORDER )) >>= itemZOrder )
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
arning
were valid, recent gcc would emit it too.
Or does that mean I should enable WaE for the MSVC tinderbox too? That should
be some fun, with people even now not bothering to fix that build that much.
--
Lubos Lunak
l.lu...@suse.cz
___
Yes, equalsAsciiL() has been kind of obsolete since recently. Do we still
suggest to use it somewhere?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
401 - 500 of 726 matches
Mail list logo
