On Tuesday 29 of November 2011, Michael Meeks wrote:
> Ah - but this is what I added:
>
> Window* Window::GetParentDialog() const
One 'const' missing (or one too much).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice maili
$(filter s,$(MAKEFLAGS)),,VERBOSE=T) -P$(BUILD_NCPUS) $(2)
> -P$(GMAKE_PARALLELISM) gb_MAKETARGET=$(gb_MAKETARGET) $(eval
> gb_BuildplTarget_COMPLETEDTARGETS+=$(1))
> endef
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
increase object size compared to -ggdb2?
http://lists.freedesktop.org/archives/libreoffice/2011-April/010408.html
Short answer: yes.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.fr
ce any problems with -gdwarf-4.
So -gdwarf-4 looks like a sensible default to me. Even if not, I'm going to
use it (quick hack: modify your LO make script to add it to $CXXFLAGS).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Thursday 01 of December 2011, Lionel Elie Mamane wrote:
> On Thu, Dec 01, 2011 at 12:14:32PM +0100, Lubos Lunak wrote:
> > On Wednesday 30 of November 2011, Tom Tromey wrote:
> >> First, one must consider the tradeoffs. I always use -g3 when building
> >> gdb, bec
On Thursday 01 of December 2011, Lubos Lunak wrote:
> On Wednesday 30 of November 2011, Tom Tromey wrote:
> > These options cause debuginfo for
> > most big types to be shared across compilation units, a huge size win.
> > This also makes gdb use less memory.
>
> I&
s, also errors. Tinderbox mails are already pretty difficult
to read as they are and anything that makes people less motivated to do more
than just glance at them is bad. Thanks for switching tinderbox to -s.
--
Lubos Lunak
l.lu...@suse.cz
___
Li
em? I don't know if/where
we have a suitable place.
The documents would be also usable for automated tests, but seeing the
discussion about subsequenttests right now it's probably not the right time
to try to figure it out.
--
Lubos Lunak
On Wednesday 07 of December 2011, Michael Meeks wrote:
> On Thu, 2011-12-01 at 17:35 +0100, Lubos Lunak wrote:
> > > So -gdwarf-4 looks like a sensible default to me. Even if not, I'm
> > > going to use it (quick hack: modify your LO make script to add it to
> >
ore/docnode/nodes.cxx does instantiate SwNode, so I really
don't know.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
a: Did you know that despite being seemingly highly
optimized, with stuff like OUStringBuffer::makeStringAndClear() or the
obnoxious RTL_CONSTASCII_USTRINGPARAM macro, O(U)String* actually does some
rather pathetic things like ctors first checking if there's any memory to
free or allocat
On Monday 12 of December 2011, Lubos Lunak wrote:
> Attached source code has a testing implementation of the format function and
> a simple logging macro.
In case somebody actually tries to build it :), the easiest way seems to be:
g++ -Wall -O2 -save-temps
a.cxx -DUNX -DLINUX -I$LODIR/
On Monday 12 of December 2011, Stephan Bergmann wrote:
> On 12/12/2011 04:30 PM, Lubos Lunak wrote:
> > I'd like to propose changes to the SAL_INFO etc. family of the new
> > logging functions that would replace the somewhat strange usage
> >
> > SAL_INFO(&quo
On Monday 12 of December 2011, Michael Meeks wrote:
> On Mon, 2011-12-12 at 16:30 +0100, Lubos Lunak wrote:
> > The format-based usage uses a printf-like function that, unlike printf,
> > is typesafe and extensible. If people would be interested, the function
> > itself cou
Hello,
I find it mildly annoying that gbuild outputs "[ build CXX ]
starmath/source/types", without the .cxx extension, i.e. a non-existent file.
Especially since other target types like LNK do output "[ build LNK ]
Library/libsmlo.so". Any objections to the attache
27;, the app then will
crash as soon as it reaches the limit.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Thursday 15 of December 2011, Stephan Bergmann wrote:
> On 12/13/2011 07:56 PM, Lubos Lunak wrote:
> > But it might the moment you realize you're trading away things like
> >
> > SAL_INFO( "foo", 1<< 2 ) or SAL_INFO( "foo", &quo
On Thursday 15 of December 2011, Stephan Bergmann wrote:
> On 12/15/2011 02:57 PM, Lubos Lunak wrote:
> > The "bar"<< "baz", which, at first glance, is nonsense. Code is not
> > only written, it is also read, and many more times.
>
> Still do
On Thursday 08 of December 2011, Lubos Lunak wrote:
> On Wednesday 07 of December 2011, Michael Meeks wrote:
> > On Thu, 2011-12-01 at 17:35 +0100, Lubos Lunak wrote:
> > > > So -gdwarf-4 looks like a sensible default to me. Even if not, I'm
> > > > going
On Wednesday 14 of December 2011, Bjoern Michaelsen wrote:
> Hi Lubos,
>
> On Wed, Dec 14, 2011 at 04:45:29PM +0100, Lubos Lunak wrote:
> > I find it mildly annoying that gbuild outputs "[ build CXX ]
> > starmath/source/types", without the .cxx extension, i.e. a no
alue mpGraphic, so that suggests it is possible to re-initialize the class
using this call. But then using this init() call first and later one of the
ones inherited from GraphicDescript will leave mpGraphic inconsistent.
Presumably the proper fix is to get rid of the init() calls and use directly
ces, set the tab size
correctly or whatever it is your editor needs.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
it to the libreoffice-3-4 branch, see
> http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4
>&id=005f59ac32ce48397fa7df3b4f6586467c7f9bda
> http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4
>&id=09b32d79015b9e4fd933492b495b99ab1
On Wednesday 28 of December 2011, Marcel Metz wrote:
> Hello lo-devs,
>
> There is never an instance of mpDateTable allocated and a lot of
> code is never executed because of that. This patch removes the
> unused code.
Pushed, thanks.
--
Lubos Lunak
cgit.freedesktop.org/libreoffice/filters/commit/?h=libreoffice-3-4&i
>d=9dcc765e88bf23418ffbf66345e4eaa4c36005e4
Yes, it's correct.
> We need two more approvals for the 3-4-5 branch.
One.
--
Lubos Lunak
l.lu...@suse.cz
__
assumption. Your patch makes sense
> and I have pushed it to the 3-4 branch, see
> http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id
>=502ef71db74c3cdb1433c3402a0d93971dc47f1b
>
> We need two more approvals for the 3-4-5 branch.
Looks ok.
--
Lubos L
bs-core/commit/?h=libreoffice-3-4
>&id=395c05c288116683ffb3bceb658f61694c042b28
>
> We need 2 more approvals for the 3-4-5 branch.
Makes sense.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Sunday 01 of January 2012, Olivier Hallot wrote:
> Please find attached a partial fix for Easy Hack FDO43460
>
> Part XXI
> Module
> oox
Pushed, thanks.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing l
On Sunday 01 of January 2012, Olivier Hallot wrote:
> Please find attached a partial fix for Easy Hack FDO43460
>
> Part XXVI
> Module
> package
Pushed.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.
On Monday 02 of January 2012, Olivier Hallot wrote:
> Please find attached a partial fix for Easy Hack FDO43460
>
> Part XXVII
> Modules
> padmin, pyuno, rdbmaker, regexp, registry, rsc, sal
Pushed as well.
--
Lubos Lunak
lows a ctor to directly call another ctor, but otherwise
init() seems to be the only correct option.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Tuesday 03 of January 2012, Marcel Metz wrote:
> Hello lo-devs,
>
> this patch removes the unused (according to OpenGrok) GetIsoFallback
> function from the tools module.
Looks ok, pushed.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOf
(i.e. addresses
remain the same), which does not seem to be the case, this is just an
optimization. The 16 looks a bit like a magic number anyway.
You also removed the check for m_pGlosArr being NULL in the code below:
SwGlossaries::~SwGlossaries()
{
- sal_uInt16 nCount = m_pGlosArr? m_
The same like before.
Pushed.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
.begin()); it !=
aFldNames.end(); ++it)
{
-pArray[i] = *aFldNames.GetObject(i);
+pArray[i] = **it;
^^^
+delete *it;
}
Fixed, pushed.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
;isEmpty() patches I've reviewed are
correct, I expect the rest will be as well, and by now you are the expert in
this field anyway :). You can still post for review other patches where you
won't be sure.
--
Lubos Lunak
l.lu...@suse.cz
hanks (and all the notes were correct).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
not sure what you mean here - the overviews do include also global
non-namespaced objects, search
http://api.libreoffice.org/docs/cpp/ref/names/index.html for
e.g. 'typereg_writer_destroy'.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffi
On Wednesday 04 of January 2012, Stephan Bergmann wrote:
> On 01/04/2012 04:15 PM, Lubos Lunak wrote:
> > On Wednesday 04 of January 2012, Stephan Bergmann wrote:
> >> (One downside of doxygen appears to be that
> >> it does not generate an overview of all the non-class
On Wednesday 04 of January 2012, Gustavo Pacheco wrote:
> Hi!
>
> Partial fix for Easy Hack FDO43460 (part XXII) for review.
>
> Part XXII
> modules
> jvmfwk, l10ntools, lingucomponent
Pushed, thanks.
--
Lubos L
but the
> patch also touches some of the mac specific code like
> fpicker/source/aqua/SalAquaFilePicker.mm so it would be maybe a good
> idea to test this patch.
Compiled for me too, so let's say the only way to check for problems is by
running into them :). Pus
On Tuesday 03 of January 2012, Marcel Metz wrote:
> ---
> binfilter/inc/bf_starmath/smmod.hxx |2 ++
> binfilter/inc/bf_sw/shellres.hxx|2 +-
> 2 files changed, 3 insertions(+), 1 deletions(-)
Pushed all patches.
--
Lubos Lunak
l.l
g out we
have this filter that can handle it or by finding out we have this extension
that can handle it.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 06 of January 2012, Michael Stahl wrote:
> On 06/01/12 17:35, Lubos Lunak wrote:
> > On Friday 06 of January 2012, Michael Stahl wrote:
> >> in the case of pdfimport, isn't there a potential licensing problem
> >> because it uses GPL-licensed xpdf/pop
broken to me to unconditionally move a table
forward just depending on whether there is something before it. Git blame
shows a CWS merge, so it is unhelpful.
--
Lubos Lunak
l.lu...@suse.cz
From 63e7d5a92a9580b1e04026657eb99bfef3480fde Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=
t; custom document information.
>
> Please consider this patch for inclusion.
Pushed.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
-push-all-the-data-as-properties-one-by-one approach, so I wonder what
the common way of avoiding this problem is? Preferably something that's not
an ugly hack, excuse the naivety.
Thanks
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing li
On Tuesday 24 of January 2012, Michael Stahl wrote:
> On 23/01/12 21:31, Lubos Lunak wrote:
> > Technically, I get in SwXDocumentSettings::_setSingleValue() first a
> > call with HANDLE_CURRENT_DATABASE_DATA_SOURCE and then with
> > HANDLE_CURRENT_DATABASE_COMMAND. They
iling lists
- it makes adding tags like [PUSHED] more cumbersome
- one would hope that by 2012 everybody interested in filtering mail can
actually do it based on the List-Id header, which has the additional benefit
of really filtering mails from the mailing list
--
Lubos Lunak
l.lu...@su
hat doesn't look very good to me. Does somebody know where a good place for
such a file would be?
Thanks.
PS: A good place meaning that people would actually be able to find it and use
it, which rules out the option of burying it in some random wiki page.
--
Lubos Lunak
l.lu...@suse.cz
__
ke, last
decade) to have 'reply-to-mailing-list' and that solves the problem. And that
was a plural you, if I wanted to get all those useless duplicates of replies
to my mails, I would have said so.
--
Lubos Lunak
l.lu...@suse.cz
__
On Wednesday 25 of January 2012, Regina Henschel wrote:
> Hi,
>
> Lubos Lunak schrieb:
> > On Tuesday 24 of January 2012, khagaroth wrote:
> >> While at it, it would be nice to also set Reply-To:
> >> libreoffice@lists.freedesktop.org.
> >
> > Oh
On Wednesday 25 of January 2012, Stephan Bergmann wrote:
> On 01/25/2012 12:04 PM, Lubos Lunak wrote:
> > if I wanted to get all those useless duplicates of replies to my
> > mails, I would have said so.
>
> This might be a controversial issue. While I too feel I don
On Wednesday 25 of January 2012, Fridrich Strba wrote:
> On 24/01/12 16:26, Lubos Lunak wrote:
> > - it leaves less room for the actually important part of the subject when
> > browsing mail
> > - which gets expecially insane when forwarding mails futher or between
> >
On Wednesday 25 of January 2012, Thorsten Behrens wrote:
> Lubos Lunak wrote:
> > (and the filter-it-out suggestion is ridiculous, what if somebody really
> > explicitly also CC-ed me e.g. because it's urgent?).
>
> http://help.cselabs.umn.edu/email/procmail ;)
Cool! S
ebody sign-off and push to -3-5, please?
>
> I cherry-picked it to -3-5, but it would be good to have 2 more reviews
> to push it to -3-5-0 as well.
One.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.free
irely a matter of taste and IMO it's not worth to affect git
blame by things like this.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
han's problem, but your changes (both the commit and
the attached patch) break the document from bnc#743331 (picture in the
upper-right corner).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://l
od with scripts, he'd be more than welcome to e.g. use them to
change writer's cryptic indentifiers to something that does not need
decyphering. Which would affect git blame as well, but in this case the huge
increase in readability of the code would be more than worth it. Tasks for
On Tuesday 24 of January 2012, Stephan Bergmann wrote:
> On 01/24/2012 04:40 PM, Lubos Lunak wrote:
> > I intend to put just a short note to the documentation in sal/log.hxx
> > pointing to this file (so that additions wouldn't trigger rebuilds), but
> > I'm not su
ormat enough to be certain about the fix, but I
expect it is quite clear from the logic of the thing, so I've committed as
b5a73d4b2b283d3d1a57ac0f66b608998960a873 . Please review and backport.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice ma
rocessComponentContext in code that does not thread the
> component context more locally).
How usual is the case that one does not want to pass
comphelper::getProcessComponentContext() to all these functions? Or in other
words, why not simply make it the default argument value?
--
Lub
hat, and is the least intrusive change.
>
> Can you please review for -3-5 and -3-5-0?
Pushed to 3-5.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
avoid most of the unneeded output and still, I assume, would do and be an
optimal default.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
should agree on what the recommended way is? I personally think
the simplest and most elegant solution is to go with 'it = container.erase(
it );" and move the "++it" out of for()'s parentheses to an else block of the
if() condition (oh well, ease of use
On Thursday 02 of February 2012, Stephan Bergmann wrote:
> On 02/02/2012 11:26 AM, Lubos Lunak wrote:
> > I agree with all the points, but in Julien's defense, I remember
> > exactly this same approach was pushed in recently as a fix to the same
> > issue elsewhere.
>
temState(), but also to make it more
visible that it is an out argument. The intuitive reading of "if(
set.HasItem( which, item ))" to me is "does 'set' have an item of
type 'which' that is 'item'?".
--
Lubos Lunak
l.lu...@suse.c
rom performance point of
view.
I can't comment on other reasons why this might have been split though.
[*] Seriously, I can't find a thing. Is there actually something using the
library?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ust plain 1-byte -> 2-bytes extension.
> Anyhow - on this topic:
>
> Any chance of SAL_UNUSED ? ;-) At worse, SAL_UNUSED_PARAM.
SAL_UNUSED_PARAM? And that's how the Writer codebase came around ... . Unlike
RTL_CONSTASCII_USTRINGPARAM(), this one is unlikely to be
On Thursday 09 of February 2012, Lubos Lunak wrote:
> On Thursday 09 of February 2012, Michael Meeks wrote:
> > Personally, I'd -love- someone to rename ~all of these
> > RTL_USTR() or RTL_STR() or somesuch - we have enough pointlessly hard to
> > read and indent co
On Thursday 09 of February 2012, Caolán McNamara wrote:
> On Thu, 2012-02-09 at 18:16 +0100, Lubos Lunak wrote:
> > suggests that OString in fact does not stop at \0's when handling
> > strings. I'm kind of baffled by this, I personally consider it a flaw
> > that a
On Friday 10 of February 2012, Stephan Bergmann wrote:
> On 02/09/2012 06:16 PM, Lubos Lunak wrote:
> > Attached is a patch that removes the need for
> > RTL_CONSTASCII_USTRINGPARAM (henceafter called 'macro', because it annoys
> > me to write this even in it
On Friday 10 of February 2012, Stephan Bergmann wrote:
> On 02/10/2012 11:30 AM, Lubos Lunak wrote:
> > +/**
> > + * @overload
> > + * @since LibreOffice 3.6
> > + */
> > +oslGenericFunction SAL_CALL getFunctionSymbol( const
> > ::rtl::O
On Friday 10 of February 2012, Stephan Bergmann wrote:
> On 02/10/2012 12:18 PM, Lubos Lunak wrote:
> > This is sal/, so the library needs to maintain binary compatibility,
> > does it not? That requires adding the OUString overload rather than
> > fixing the exiting func
ere.)
Everywhere, eventually. If it can work for ctors, it should work everywhere
else too.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
es of the latter to become
> uses of the former; so if you seek consistency across a function, it
> might be better to replace other occurrences of sal_True/False than to
> do the opposite).
Moreover, although the change technically keeps the code the same, it
slightly breaks the semantics
nd while I've eventually found a way to do it, based on
http://www.macieira.org/blog/2011/07/initialising-an-array-with-cx0x-using-constexpr-and-variadic-templates/
,
see attachment, it turns out to be unusable in practice. Maybe later.
--
Lubos Lunak
l.lu...@suse.cz
// With gcc-4.5.1
d, since I'm already asking, is the Windows performance the reason include
files are scattered this way? E.g. in sw/ I find this actually rather
annoying, some .hxx files are in inc/, some next to .cxx sources, Writer
AFAIK does not really export anything anyway, and I always have to jump
around ju
On Thursday 09 of February 2012, Lubos Lunak wrote:
> Actually, no need for a week, this one is reasonably simple. Therefore I
> challenge RTL_CONSTASCII_USTRINGPARAM to a fight to the death. Its death,
> that is.
>
> Attached is a patch that removes the need for RTL_CONSTASC
odata.
It is doable with a macro [*], but then we're back at the beginning of this
RTL_CONSTASCII_USTRINGPARAM discussion.
[*] http://www.macieira.org/blog/2011/07/qstring-improved/
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
hing that
is not intended to be changed, so the second const does serve a purpose and
theoretically this form is actually the correct one, but in practice people
do not bother with the second const for the convenience of less typing and
easier
, which avoids the ambiguity in all the other places where
the value passed is const.
BTW, the two ctor variants even do different things, despite looking
semantically equivalent at a first look, so this looks like misdesigned API
to me.
--
Lubos Lunak
l.lu...@suse.cz
s are disabled.
Any objections to switching to gnu++0x ?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Thursday 23 of February 2012, Stephan Bergmann wrote:
> On 02/23/2012 05:08 PM, Lubos Lunak wrote:
> > commit 437fe5a11f68d1848c49121394f16f09611b made me notice that we
> > actually build with -std=c++0x and not -std=gnu++0x, which I think would
> > make more sense a
ments,
which can be satisfied by providing a notice and our source code.
Specifically, I think section 5 of LGPLv3 applies here.
But the proper solution to this problem is finding somebody who can't say
IANAL and thus should be able to provide a founded answer. I would be
surprised
ions
- with today's systems (overcommitting, etc.) it is rather pointless to guard
against allocation failures
Does somebody see a good reason not to just remove it?
--
Lubos Lunak
l.lu...@suse.cz
From e1e3406cb73559c7760f0e28965a8bb0c4c19b4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo
xt time the larger string can cause
running out of memory when appending to OUStringBuffer, when invokend with
OUString's operator+, or any other of those functions that OSL_ENSURE the
allocation result and are done with it.
--
Lubos Lunak
l.lu...@suse.cz
_
does not really need it in OUString ctors.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Wednesday 29 of February 2012, Stephan Bergmann wrote:
> On 02/29/2012 03:28 PM, Lubos Lunak wrote:
> > On Wednesday 29 of February 2012, Stephan Bergmann wrote:
> >> However, there are also situations where bad input (malicious or
> >> otherwise) would cause an appli
On Wednesday 29 of February 2012, Lionel Elie Mamane wrote:
>So here's the patch for a boost-free OUString, with manually
>implemented const_iterator.
> +OSL_ASSERT( p <= s->getLength() );
OSL_ASSERT() is obsolete, use normal assert().
--
Lubos Lu
On Wednesday 29 of February 2012, Caolán McNamara wrote:
> On Wed, 2012-02-29 at 17:11 +0100, Lubos Lunak wrote:
> > Do we actually have code that tries to gracefully handle running out of
> > memory? Because if not, and I doubt we realistically do[*]
>
> Its not O[U]String
On Tuesday 28 of February 2012, Lubos Lunak wrote:
> I'd like to revisit the choice of considering string literals to be either
> ASCII or UTF-8, as discussed in the thread about removing
> RTL_CONSTASCII_USTRINGPARAM. While I was ambivalent about it, I now think
> we should g
al, I think there are more
important problems than having a homebrewn build system that seems to work
good enough), but even handwritting Makefile files could have probably won
such "fair" comparison.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
TL_CONSTASCII_STRINGPARAM( "bar" ))
+ foo.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( "bar" ))
that this will be soon obsolete by these changes and easily replaced by plain
foo == "bar"
(Do we have an Easy Hack asking for the above, so that I change it? I
couldn&#
Windows/MSVC experts
On Monday 12 of March 2012, Stephan Bergmann wrote:
> On 03/10/2012 04:39 PM, Lubos Lunak wrote:
> > commit 34f8495dd948e2ad9d64c2c19110e69840cefd1a
> > Author: Luboš Luňák
> > Date: Sat Mar 10 15:37:02 2012 +0100
> >
> > exported te
libo/sal/qa/rtl/strings/test_ostring_stringliterals.cxx(103)
>
> : error C2440: '' : cannot convert from 'const char
>
> []' to 'rtl::OString'
> No constructor could take the source type, or constructor
> overload resolution was ambiguous
> [
On Monday 12 of March 2012, Michael Stahl wrote:
> On 12/03/12 15:09, Lubos Lunak wrote:
> > Windows/MSVC experts
...
> applying logic to how C++ features interact with linkers on various
> platforms is generally a futile endeavour.
Works fine for me :).
> > Assuming th
On Monday 12 of March 2012, Stephan Bergmann wrote:
> On 03/12/2012 03:09 PM, Lubos Lunak wrote:
...
> Looks like a misunderstanding whether hidden visibility is intended for
> "remove unnecessary entries from dynamic symbol tables (but keeping
> certain symbols exported to no
or clang-3.1r152540. So it looks like we
can either just enable the warning and selectively disable it, or we can have
a configure check if some older gcc version has the problem (well, given that
#pragma diagnostic is recent with gcc, it'll need an #ifdef anyway).
$ g++ -Wall dtor
ably want
77ee92a6bd8f40022ab03325d158de4b67a41dd0 , which I think only made it to 3-5
branch but not 3-5-1, in which case you probably want
ee67c55260ec7723c39606955ccdbd3e2934935a .
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
Li
301 - 400 of 726 matches
Mail list logo
