not be taking sides in such politics, especially
given that the problem does not appear to be resolved or even having a
consensus.
On Thursday 18 of March 2021, Thorsten Behrens wrote:
> Lubos Lunak wrote:
> > I disagree with the plan. Git uses master, so we should stick with
> >
ay I see it, if this is supposed to fix something, then it actually
doesn't, and it can create technical problems. If it's supposed to do
something else, it's not up to us to solve somebody else's problem, and it
can backfire.
PS: I can't miss the irony of renaming 'master' in
not, anyway).
Developer builds should of course fall flat on their face in such cases, but
in practice it's probably better to value end product stability more than
practically insignificant warnings from a tool.
--
Lubos Lunak
l.lu...@collabora.com
On Monday 08 of December 2014, Bjoern Michaelsen wrote:
Hi Lubos,
On Fri, Dec 05, 2014 at 06:46:17PM +0100, Lubos Lunak wrote:
On Thursday 04 of December 2014, Michael Meeks wrote:
* Large scale renames (Kendy)
...
+ if cleanup there; perhaps some improved naming too
support better names for Writer (Bjorn)
+ can re-write classes with Clang ? (Michael)
Clang should be able to rewrite pretty much whatever would matter. E.g.
compilerplugins/clang/store/changefunctioncalls.cxx could be used to rename
all calls of a specific function.
--
Lubos Lunak
function, because that one requires
also the this pointer, so you need to go with boost::bind. See e.g. 96369e97.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman
usually form part of the public API of a class.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
that there shouldn't be
any big trouble there.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
a patch but compilers do not allow specifying proper path
refering to the .dwo file when building in a different path).
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org
, it'd also break it considerably. Unless that has improved recently
(which I doubt), things like hidden symbol visibility make these functions
practically useless.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice
, the original code had several unhandled switch cases together and I
overlooked that (not that I get how the fix worked in master).
Andras, could you please include the commit back to 4.2+4.3 together with
74c6ba1b741ae76ad9e2f2b81be3e3178163f085 ? Thanks.
--
Lubos Lunak
l.lu...@collabora.com
on destruction? Stack-allocated
objects is probably the most sensible C++ lifecycle management ever, so if it
doesn't work with vcl, vcl has got to be seriously broken in that regard.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
://people.centos.org/tru/devtools-2/ for Linux
extensions). In other words, all the include files that end up copied
to the SDK's include/ directory still need to be compileable by a
non-C++11 compiler.
But we are only people, so I added checking of this to the odk checkapi test.
--
Lubos Lunak
l.lu
by functionDecl-getLocation() .
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
class or function actually are.
But that's exactly the point of what Max says. The warning is not bogus.
Using a dynamic_cast where a static_cast is known to work well is a sign of
the un-debuggable world of defensive programming that you speak of.
--
Lubos Lunak
l.lu...@collabora.com
a bad idea to have it there).
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
or lowercase. The question is of
course how much code makes an assumption about this and whether the change is
worth it.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman
-a-2d-array-in-c-
using-new) Any idea?
The sizes are constants, there's no such problem.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Thursday 17 of April 2014, Lubos Lunak wrote:
On Wednesday 16 of April 2014, Stephan Bergmann wrote:
Jan-Marek, all,
Any details on the reason for the revert, and whether it could be the
cause for the newly seen crash?
KDE4 file dialog support is currently apparently broken one way
.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice
in VCL that I created for handling
embedded fonts, that should be the place to start if you want to give
implementing this a try.
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/oox/Library_oox.mk b/oox/Library_oox.mk
index 8d07153..a4aeb7c 100644
--- a/oox/Library_oox.mk
+++ b/oox/Library_oox.mk
a document.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
downloads only those .pdb files it actually needs, and it can cache them
locally, so it's hopefully not that much.
- is there any other option I should be asking :) ?
Attached is a tinderbox master.sh script I currently use.
--
Lubos Lunak
l.lu...@suse.cz
master.sh
Description: application
with OOXML.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
gb_StaticLibrary_use_externals,plugcon,gtk cairo)) helps with the problem,
but I assume this cannot be just hardcoded and I don't know how to do it
properly? Gbuild experts?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http
that UNO somehow appears more natural in languages that
aren't C++ :)
Probably nobody has spent enough time to design that boilerplate for those
other languages :).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice
the README), expect it won't rewrite anything and only
generate the data.
There's no white-listing either, but that shouldn't be difficult, and the
code could be similarly extended to also check for unused structs/classes,
enums, etc.
--
Lubos Lunak
l.lu...@suse.cz
. The macro is a cumbersome
micro-optimization and here it presumably doesn't make any difference. Just
calling matchIgnoreAsciiCase() should do.
Also note that LO has SAL_N_ELEMENTS macro for getting the number of items in
an array.
--
Lubos Lunak
l.lu...@suse.cz
, be prepared to do some work to keep it running now and then.
Nah, the Clang build does not break more often than GCC build. But I don't
know if Clang-3.0 builds LO without problems, you may need to upgrade to at
least 3.1.
--
Lubos Lunak
l.lu...@suse.cz
On Saturday 06 of April 2013, Bjoern Michaelsen wrote:
Just out of curiousity, what are the numbers for sc now, if you have them
at hand?
make Library_sc
PCH: 5:18 (PCH creation is about 24 seconds).
non-PCH: 16:38
--
Lubos Lunak
l.lu...@suse.cz
- .so dependencies. I
do not see a good use case where this would be a problem.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
, but am happy to hear other opinions and input on the issue. We
should gather all areas this might impact and go into it wellprepared.
Comments welcome!
Can we please have a clearer statement on what this would (not might) fix?
--
Lubos Lunak
l.lu...@suse.cz
3 hours, without PCH it'd be at least
4 (I don't remember anymore and it'd take a while to measure).
I have not tried with GCC, and with Clang it's actually not worth it at all.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice
-by: Petr Mladek pmla...@suse.cz
Reviewed-by: Petr Mladek pmla...@suse.cz
I have reverted this commit, as it fails on at least two 4-0 tinderboxes
(Clang and Win-x86_6). I also couldn't find anything like this in master.
Please check the commit.
--
Lubos Lunak
l.lu...@suse.cz
On Friday 29 of March 2013, Noel Power wrote:
On 29/03/13 16:18, Lubos Lunak wrote:
On Thursday 28 of March 2013, Noel Power wrote:
I have reverted this commit, as it fails on at least two 4-0
tinderboxes (Clang and Win-x86_6). I also couldn't find anything like
this in master.there
On Tuesday 26 of March 2013, Peter Foley wrote:
On Tue, Mar 26, 2013 at 2:19 PM, Lubos Lunak l.lu...@suse.cz wrote:
That already exists: configure CC=clang CXX=clang++
What's the point of having such an explicit option? We already have
enough options that reinvent the wheel.
I just felt
,
+AS_HELP_STRING([--enable-clang],
+[Build using the clang compiler.]),
+)
+
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
for the eye.
How do others see this?
I think there is still so much to do before arguing about spaces or other
similar matter of taste details that have very little practical consequences.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
files with GCC and the difference, if any, is just lost in the
noise.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
' but not the first.
Is there some way we can propagate the failure / exit code from the
spawned process through icerun ? perhaps that is fixed already, I have:
$ icerun --version
ICERUN 0.9.98.3
Hmm ... WEXITSTATUS fun :-/ ... I'll fix this upstream.
--
Lubos Lunak
l.lu...@suse.cz
such a tool at all? If Glade is not capable of providing
sensible defaults for spacing and similar features, cannot our code for
loading the .ui files handle that?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
be possible to check mechanically, while I
do not see a way to prevent the problem above.
Opinions on this?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
target, so they both should work.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
don't know about GCC (besides the rumour that PCH
there is fragile), but with Clang I actually couldn't see any noticeable
improvement when using PCH (barring the cases when it seems to make the
compile even slower for me for some reason). With MSVC the difference is big
though.
--
Lubos Lunak
directives should not be left in
the sources, one way or another.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 01 of March 2013, Christina Rossmanith wrote:
Hi,
Lubos Lunak has prepared a huge automatically generated patch removing all
those ::rtl prefixes. So it is a little waste of time to prepare such
patches manually. Instead maybe you could help removing
RTL_CONSTASCII_(U)STRINGPARAM
start after any upgrade to cater for potential changes in bundled
extensions etc.).
I followed the instructions here:
https://wiki.documentfoundation.org/QA/HowToBibisect
I have edited the page to not recommend running the binary without the
wrapper.
--
Lubos Lunak
l.lu...@suse.cz
On Friday 22 of February 2013, Stefan Schick wrote:
Hey,
there are more translation patches to come in the next days...
All of my past future contributions to LibreOffice may be
licensed under the MPL/LGPLv3+ dual license.
Pushed, thanks for the patch.
--
Lubos Lunak
l.lu...@suse.cz
,
but it looks like it doesn't create the .zip archives to upload, quite
possibly for similar reasons.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
at places where the receiving side expects them,
worked on a clean-up of that code, but didn't come around yet to push
it. Will happen shortly.
I don't know what the code is supposed to do exactly, but just from looking
at it I agree with Matteo's comments on it.
--
Lubos Lunak
l.lu...@suse.cz
:-)
It is intentional that some C++11 features are used if available, in order to
provide various benefits (SAL_OVERRIDE for example).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman
On Thursday 21 of February 2013, Michael Meeks wrote:
Hi Lubos,
On Mon, 2013-02-18 at 15:01 +0100, Lubos Lunak wrote:
Heh; so do not merge is the equivalent of do not submit but much
clearer and friendlier, fits inside the text limit.
Huh? Friendlier? Clearer??? It says pretty much
') {
break;
}
}
-/* make sure the buffer is \0 terminated */
-if (nBytes 0)
-{
-pReceiveBuffer[nBytes-1] = 0;
-}
Did you really mean to remove this part?
--
Lubos Lunak
l.lu...@suse.cz
On Wednesday 20 of February 2013, julien2412 [via Document Foundation Mail
Archive] wrote:
Lubos Lunak wrote
On Tuesday 19 of February 2013, Julien Nabet wrote:
diff --git a/desktop/source/app/officeipcthread.cxx
b/desktop/source/app/officeipcthread.cxx index 8db7946..445ccb4 100644
collects a larger number of commits between two rebuilds, then if a breakage
shows up, nobody seems to feel responsible. So, if possible, I think it'd be
better if this was run more often than 2-3 weeks, possibly as another
tinderbox running the check.
--
Lubos Lunak
l.lu...@suse.cz
On Monday 18 of February 2013, Tom Tromey wrote:
Lubos == Lubos Lunak l.lu...@suse.cz writes:
Lubos This could be very useful ('catch throw' is so cumbersome in
Lubos gdb),
Is there something we could do to improve it?
I don't know how much control gdb over exception handling has, so I
anymore. As there have
been no other changes in the area, I suspect this commit. Could you please
have a look?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
generally
aren't very fast, but if the function was called every time in the ctor, then
depending on fast it is that might make it debug-build-only feature.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
On Saturday 16 of February 2013, Michael Meeks wrote:
On Fri, 2013-02-15 at 21:50 +0100, Lubos Lunak wrote:
PPS: please do not shoot the messenger...
I'm not shooting the messenger, I'm telling him that the way it is he'll
sooner or later need to go on more errands.
Heh; so do
of a patch is uploaded, whereas -2 are 'sticky'.
That should be made more obvious in the wording then. I normally use -1/-2 as
the reverse of +1/+2 and the current 'do not merge' is vague enough to mean
anything in that direction. It should include 'I disagree with the change' or
similar.
--
Lubos
On Friday 15 of February 2013, Norbert Thiebaud wrote:
On Fri, Feb 15, 2013 at 12:36 PM, Lubos Lunak l.lu...@suse.cz wrote:
That should be made more obvious in the wording then. I normally use
-1/-2 as the reverse of +1/+2
Well, there are not symetrical:
Yes, I get that now. I didn't
'/'discussion' gives a clear road on how to
proceed for the contributor.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Running 'make VERBOSE=1' will show you also the executed commands, so you can
find the failing one and debug what the problem is.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org
desktop
@li @c desktop.deployment
+@li @c desktop.migration
Note that the idea is that next to the area name there is a very short
description of it (especially for the non-obvious ones).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
/GenericCommands.xcu . How do
I get the UI strings for the usage in the code (i.e. including l10n) and,
since I assume that includes removing it from the .xcu file, will something
else be affected by that?
--
Lubos Lunak
l.lu...@suse.cz
void SvxFontNameBox_Impl::CheckAndMarkUnknownFont( const OUString
are updated while building the
targets, and before second build LinkTarget .d files are created from
object .d using concat-deps.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org
logic (rewriting external headers to .done files, which is
necessary for correctness of incremental builds) that doesn't make sense
as a make builtin.
Although concat-deps is not a trivial code, it's not that complicated either,
and the builtins are already LO-specific code anyway.
--
Lubos
to 'make 21 | tee build_error.log' .
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
on Windows because of a stray SAL_CALL, see
668bec99efb4a15ca0fe364fa3c217baba8a6f27 .
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
case.
So why is this not said in the commit log message? As it is, there was no way
to find out what your commit was actually about, other than the obvious.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
On Monday 21 of January 2013, Stephan Bergmann wrote:
On 01/21/2013 06:05 PM, Lubos Lunak wrote:
On Monday 21 of January 2013, Stephan Bergmann wrote:
While the gotcha of printing a large unsigned value as a negative value
thanks to calling rtl_ustr_valueOfInt64 internally can be a problem
this line more clear
(and perhaps removing the double use of OUString)?
aRetStr += (Typ: + xIdlClass-getName() + );
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman
more likely than usage of a problematic value of
the type, so IMO it makes more sense to cater to realistic usage rathen than
handle more problematic but next to impossible scenarios.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
it in
e8bbb76827dd7a0e30d7d1db34a812a84d85f390
- if SvStream gets overload for bool, the warning can be dumped
Or am I missing something there?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
it gets
fixed.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
, not in the (non-existent) String class documentation, so any bets on
what the reality is?
Could you please add these cases to the strings wiki page?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http
:
On Friday 11 of January 2013, Lubos Lunak wrote:
So, based on this, the best solution to the problem that I can see is
creating fromNumber() or number() , overloaded for all signed/unsigned
int/long/long long types and all floats because of the lame language
ambiguity. The original valueOf() can
On Friday 11 of January 2013, Noel Grandin wrote:
On 2013-01-10 15:55, Lubos Lunak wrote:
- There's no need for valueOfChar(). There is already OUString ctor from
sal_Unicode, so the valueOf() overload for it is just making an obvious
thing complicated. Code using it can be converted to use
On Friday 11 of January 2013, Jean-Noël Rouvignac wrote:
2013/1/10 Lubos Lunak l.lu...@suse.cz
Unless all you want to convert is only places which do the explicit
cast, this will need a (fairly simple) Clang plugin.
Sure, if you feel like writing one.
Actually, I'd prefer
unotools, I get the following error when
building unotools_inc :
gb_Deliver-deliver : file does not exist in solver, and cannot be
delivered :
/Users/Shared/Repos/LO/core/solver/unxmacxi.pro/lib/libcomphelpgcc3.dylib
make unotools.all
--
Lubos Lunak
l.lu...@suse.cz
and if it's really needed this way? It dates back to 2009, so repo
history is as usually useless.
[*]
ERROR: The following files could not be found:
ERROR: File not found: Microsoft.VC80.CRT.manifest
ERROR: File not found: msvcp80.dll
ERROR: File not found: msvcr80.dll
--
Lubos Lunak
l.lu...@suse.cz
structure to the Win32 representation.
i.e. from /cygdrive/C/libo to C:\libo
I have not done this, apparently make always gets windows paths when building
LO, or does somebody have a problem with this (builtins have (Built-in)
prefix when doing verbose make)?
--
Lubos Lunak
l.lu...@suse.cz
On Thursday 10 of January 2013, Michael Meeks wrote:
On Wed, 2013-01-09 at 20:01 +0100, Lubos Lunak wrote:
Looks what I found under the tree! Faster make for Cygwin. Granted, I had
put it there first, but still nice.
Nice work ! :-)
I'd love to see a configure option
the explicit
cast, this will need a (fairly simple) Clang plugin.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
build. And I don't
quite understand why you'd want this change, what problem are you trying to
solve?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On Thursday 10 of January 2013, Noel Grandin wrote:
On 2013-01-10 15:55, Lubos Lunak wrote:
- There's no need for valueOfChar(). There is already OUString ctor from
sal_Unicode, so the valueOf() overload for it is just making an obvious
thing complicated. Code using it can be converted
On Thursday 10 of January 2013, Tomáš Chvátal wrote:
2013/1/10 Lubos Lunak l.lu...@suse.cz:
As written in subject the variable is used on multiple targets and it
ignores the user defined cflags/cxxflags.
This should never happen and all our targets should take into effect the
user defined
On Saturday 05 of January 2013, Michael Meeks wrote:
On Fri, 2013-01-04 at 15:12 +0100, Lubos Lunak wrote:
Having said that - it is something we really want to do; can we drop
the published easy hack bug in this regard (or just close it) to avoid
the drip of patches there ?
I'm
the original valueOf() completely, and that results in all the
follow-up issues that I raised.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
DEBUG=1', that will disable optimizations.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
in gb_LinkTarget_LinkTarget?
- (as a general rule) for non-obvious commits, please include in the commit
log message not only what but also why, such as a link to this thread. In a
year somebody's bound to want to reshuffle the flags and wonder about the
commit.
--
Lubos Lunak
l.lu...@suse.cz
host where developers could test their changes
or find out more about tinderboxes breakages (which are sometimes rather hard
to debug from just the log)? Thanks.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice
are
actually sal_Bool resp. sal_Unicode).
[***] That meaning language integer types, not the SAL stuff. Overloading on
the latter would not change anything.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
.a
lpha0_MacOS_x86_sdk.dmg) but not in others (like
http://dev-builds.libreoffice.org/daily/master/Win-x86@6/2013-01-09_08.31.
35/).
I think I have fixed this one in tinbuild.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice
On Wednesday 09 of January 2013, Michael Stahl wrote:
On 09/01/13 17:02, Lubos Lunak wrote:
Is there really such a big difference between
OUString::valueOf( sal_Int32( 0 ))
and
OUString::valueOfInt32( 0 )
it has the advantage of being explicit in what type it expects; however
i
place?
It's when building RPM packages, which are supposed to be built with
$RPM_OPT_FLAGS.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
simple commands used by gbuild such as
mkdir or cp, and since fork() is pretty slow on Cygwin, this makes some
operations such as delivering noticeably faster. Tinderbox #6 has been using
it for two weeks without a problem.
--
Lubos Lunak
l.lu...@suse.cz
On Wednesday 09 of January 2013, Lubos Lunak wrote:
Looks what I found under the tree! Faster make for Cygwin. Granted, I had
put it there first, but still nice.
Oh well, looks like somebody actually does develop LO on Windows :). So on a
related note, two more things that might be helpful
On Wednesday 09 of January 2013, Lubos Lunak wrote:
Looks what I found under the tree! Faster make for Cygwin. Granted, I had
put it there first, but still nice.
Those of you who build on Windows, you might want to pull again from
git://gerrit.libreoffice.org/dev-tools.git and update your
1 - 100 of 823 matches
Mail list logo
