w, argh...
I think the call to isInMainFile() should not use spellingLocation, but just
the location given by functionDecl->getLocation() .
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
at'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
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
to use <http://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 checka
gt; "Revert 'Rewrite Qt4 based nested yield mutex
> > locking,'" but unfortunately without any rationale.
> >
> > So it looks somewhat plausible that this got broken again (if it ever was
> > actuall
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 dialo
> http://stackoverflow.com/questions/936687/how-do-i-declare-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.fre
ntation of the number, it
doesn't say whether hex will be uppercase 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
___
7;t work. Do not use those C(XX)FLAGS you used (and I'll remove
that from the wiki, it was apparently 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
ting that docs are not necessary (or valueing merging
higher) to be eventually shooting ourselves in the foot.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
find out what the
> code in some particular source file does, especially in cases where one can
> easily be mislead and spend hours looking at irrelevant code before
> realizing...)
I think that would be very helpful.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ated a one-liner saying
what the function actually does.
> But to really fix the problem you mention, I'm afraid only
> large-scale refactoring helps.
Quite possibly. But a) that's a lot more work, b) for that, it still helps to
know what the code is supposed to do in the fi
r mess. That's yet
another advantage of documentation - even you yourself are reminded of what
the code is supposed to do, and everybody touching such code is less likely
to run into a different direction.
--
Lubos Lunak
l.lu...@suse.cz
__
eState. Except that it
doesn't seem to work, as far as I can judge SwCursor::RestoreState() doesn't
really restore anything (quite hard to say, so much for "trivial APIs don't
need docs").
--
Lubos Lunak
l.lu...@suse.cz
___
L
s it worth fixing/removing
> for good/anything else)? [Actually, I wouldn't be surprised if there
> was a copy somewhere else that works ;-)]
I've figured it out. SwCrsrSaveState only saves the state on the stack, the
actual restoring is done by
On Wednesday 01 of December 2010, Sebastian Spaeth wrote:
> On Wed, 1 Dec 2010 15:31:56 +0100, Lubos Lunak wrote:
> > I've figured it out. SwCrsrSaveState only saves the state on the stack,
> > the actual restoring is done by SwCursor::RestoreSavePos(). I'll chan
> if you find doxygen-style documentation in some gui, gfx, or impress
> header files, it's from me. ;)
Good. I'll consider that mitigating consequences, so I will not suggest to
Kendy to punish you with having to work with Qt-based code for a while :).
That, of course, on its own wouldn't be a punishment, but that could come
after getting back.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
k that is the default value for X.Org if it can't find out the real
value from the hardware or configuration options. Normally X should find out
the real DPI, although desktops also have options for various misguided
attempts at forc
afest patch I've managed to come
up with :-/, but since it still moves around initialization of some stuff,
I'd like somebody else to check. Thanks.
[*] Speaking of the bugreport, does it ring a bell to somebody? I can't find
it now.
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/d
nt for it, but I'm not
familiar with those areas of LO yet, so I can't say for sure.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
er for this :) ?
Where should it be located, under
http://freedesktop.org/wiki/Software/LibreOffice ?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
creating the binary, no matter how useless it is in the end.
I'm not quite sure about the HP part of the patch, but since I assume there
the ld option has the same brain-damaged result and I see no good reason for
that option's existence anywhere in LO, I've included it in
=b799041d66f5f5ec944b6baeec43df01fd3ace2c
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
t least fdo#37013 too.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
about
plugins).
The commit responsible for this problem is
f9496177a4c942f2acc39a978a3cd65689f14d8d in libs-gui. I don't understand the
code, but apparently the new constraints introduced by the commit are not met
by code using the class.
--
Lubos Lunak
l.lu...@su
ar*)'
> [-fpermissive]
>
> Afaik this can be fixed with adding -fpermissive to the CXXFLAGS.
> But is this the proper fix?
No. Presumably the new bison version finally realized it's 21st century and
started using const char* instead of plain char* when referring const
stri
been
changed again.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
check if my repos are
> up-to-date? I used status for it. I will try with LibreOfficeLinux
> distro. Is it problem if I build with Ubuntu/8.04 on 32 and 64 bit?
It is not enough to rebuild just sw, you also need to rebuild the module
where the change triggering this h
d by that one, as I cannot say for
sure either way whether it matters for sw or not. However as the result with
the patch looks ok to me I decided not to change that one, as I have no idea
how I'd propagate the option to editeng from sw anyway.
--
Lubos Lunak
l.lu...@suse.cz
_
On Monday 23 of May 2011, Markus Mohrhard wrote:
> Pushed to master.
> http://cgit.freedesktop.org/libreoffice/calc/commit/?id=d30c66cb1954103a159
>da2ef82dba4bf9685844f
>
> Would be nice if we could get 2 additional reviews for 3-4-0.
+1, pushed to 3-4-0.
--
Lubos Lunak
On Monday 23 of May 2011, Tor Lillqvist wrote:
> > We need 2 more reviews for the libreoffice-3-4-0 branch.
>
> +1 from me
+1, pushed to 3-4-0.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesk
eview and push it to 3.4 and 3.4.0?
>
> Looks fine => pushed into libreoffice-3-4 branch, see
> http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4
>&id=97c995a22c1602679a3e386f994a20b23d07f429
>
> We need two more reviews for 3-4-0 branch.
+1
--
On Monday 23 of May 2011, Chr. Rossmanith wrote:
> Hi,
>
> the attached patch removes __cdecl and uses SAL_CALL instead.
Pushed, thanks.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop
g wrong or need to be
> improved before committing.
Committed to master and 3-4, thanks.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
so that it's easier to see
- attach the patch instead of posting it inline (it failed to apply,
apparently the mailer changed the formatting)
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://list
think we should continue working on LO and not get involved at
this time at all. The situation seems to be the best realistic outcome and it
seems we can't improve it, so let's be happy about it, but we should not
drown our resources in something that has unsure future and value
related to the
> recent move from dmake to gmake?
>
> I've tried to poke around a bit but, but I can't really make much
> sense of this. Any ideas?
Yes. It would help if you posted the actual errors, there are none in the
output you've pr
't be made
This seems to be a result of b246ad5ff409a7a51091c0b3c1fe50e0eb468fc4 in
bootstrap and libvisio version update since my last build. The attached patch
fixes the problem for me, but since I have no idea why those checks were
there, I'm just checking.
--
Lubos Lunak
l.lu.
On Friday 24 of June 2011, Jan Holesovsky wrote:
> Hi Lubos,
>
> Lubos Lunak píše v Pá 24. 06. 2011 v 16:40 +0200:
> > could somebody who understands tarball fetching review the attached
> > patch? I did make clean, pulled, configured with --with-systems-libs and
n work at all without grabbing the mouse - you'll
need to try and find out.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
tone age of window management handling, but there I'd
simply wait for somebody to complain first if that's the case.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
.. don't ask) that supported a subset of automake+make
functionality and while people could still build using automake+make if they
wished so for whatever strange reason, using unsermake was just so much
better.
--
Lubos Lunak
l.lu...@suse.cz
__
On Wednesday 29 of June 2011, Thorsten Behrens wrote:
> Lubos Lunak wrote:
> > It is not another dmake, as I understand it, as you cannot simply nuke
> > our dmake copy now and expect things to still work, whereas that would
> > work with a gnumake copy as long as that one&#
On Wednesday 29 of June 2011, Bjoern Michaelsen wrote:
> On Wed, 29 Jun 2011 17:56:42 +0200
>
> Lubos Lunak wrote:
> > Correct me if I'm wrong, but I haven't seen proposals for any other
> > kinds of extensions to the gmake copy.
>
> yet.
So what? Are we
,y) style,
> not start position and length though this is clearly the same for an x
> of 0
Usual style in what way? O[U]StringBuffer don't have any other range
function, but O[U]String uses start+len for such cases (copy, replaceAt), so
this seems inconsistent.
--
Lubos Lunak
On Thursday 30 of June 2011, Caolán McNamara wrote:
> On Thu, 2011-06-30 at 13:46 +0200, Lubos Lunak wrote:
> > O[U]StringBuffer don't have any other range
> > function, but O[U]String uses start+len for such cases (copy, replaceAt),
> > so this seems inconsistent.
>
&
On Saturday 02 of July 2011, Caolán McNamara wrote:
> On Fri, 2011-07-01 at 17:53 +0200, Lubos Lunak wrote:
> > On Thursday 30 of June 2011, Caolán McNamara wrote:
> > > Do we have a preference ?, I'm easy either way.
> >
> > Since nobody seems to have a pre
Hello,
who knows how to add a unit test?
http://wiki.documentfoundation.org/Development/Unit_Tests is incomplete (what
if there is no qa/makefile.mk?) and obsolete (it assumes that this
qa/makefile.mk is dmake-based).
--
Lubos Lunak
l.lu...@suse.cz
memory not allocated by
the ctor (located in the cppunit library).
Thanks
PS: The real question is of course "WTH does it not crash for others with
debug build?", but I guess that'll remain a mystery.
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/configure.in b/configure.i
How would that work? The non-debug 3rd-party lib will always use non-debug
version of list and that means we'd have to manually somehow use non-debug
version of list as well when interfacing with the library. That sounds pretty
unfeas
On Wednesday 13 of July 2011, Caolán McNamara wrote:
> On Tue, 2011-07-12 at 10:35 +0200, Lubos Lunak wrote:
> > On Monday 11 of July 2011, Caolán McNamara wrote:
> > > I reckon we probably have to bite the bullet and drop -D_GLIBCXX_DEBUG
> > > from solenv ?
> >
&
On Monday 11 of July 2011, Caolán McNamara wrote:
> On Mon, 2011-07-11 at 15:32 +0200, Lubos Lunak wrote:
> > Hello,
> >
> > who knows how to add a unit test?
> >
> > http://wiki.documentfoundation.org/Development/Unit_Tests is incomplete
> > (what if th
around objects in the header (and not in the main text), so I see no
regression in the behavior.
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/sw/source/core/text/txtfly.cxx b/sw/source/core/text/txtfly.cxx
index 513c2d5..a900867 100644
--- a/sw/source/core/text/txtfly.cxx
+++ b/sw/source/core
hyperlinks
> -RunText( rInfos.pField->GetFieldName() );
> +String sExpand( rInfos.pField->ExpandField( true ) );
> +sExpand.SearchAndReplaceAll( 0x0A, 0x0B );
This line looks strange. What is the reason for this?
> +RunText( sExpand );
> +
> m_pSer
evel 0 style), just an sprmPIlvl and an sprmPIlfo. Therefore there
> was no call to SwWW8ImplReader::Read_POutLvl to set nOutlineLevel.
Pushed, bug closed, thanks.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freed
On Friday 29 of July 2011, Caolán McNamara wrote:
> On Thu, 2011-07-28 at 17:14 +0200, Lubos Lunak wrote:
> > > -// Find another way for hyperlinks
> > > -RunText( rInfos.pField->GetFieldName() );
> > > +String sExpand(
On Thursday 28 of July 2011, Caolán McNamara wrote:
> proposing this fix for 3-4
> http://cgit.freedesktop.org/libreoffice/writer/commit/?id=a7058d28e5d36778b
>9f16308632ffb4c9608479c
>
Reviewed, pushed.
--
Lubos Lunak
l.l
he third and subsequent numbering levels.
Checked and pushed, thanks.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Monday 01 of August 2011, Lubos Lunak wrote:
> On Friday 22 of July 2011, Troy Rollo wrote:
> > Before this patch, when importing from docx, if there were no parent
> > numbering levels in the number formats for outline numbered paragraphs,
> > the import would include all
of the patches much simpler.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
or the error message, the best I've
come up with was simply a wrapper around dlerror(), which I admit is not very
nice API either, would there be any better approach?
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/cppuhelper/source/shlib.cxx b/cppuhelper/source/shlib.cxx
index a979454..1beed1f
On Wednesday 03 of August 2011, Tomáš Chvátal wrote:
> 0001-Add-one-more-libdir-path-for-detection-with-qt4-on-3.patch
Pushed.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.
ached if you think it might be useful, feel free to
> use/disregard/change totally etc.
I agree that ideally the code should be changed to make the error dialog
actually show what the problem was, but there are the problems you mention,
that's why I wanted to at least push the patch I
On Wednesday 03 of August 2011, Caolán McNamara wrote:
> On Tue, 2011-08-02 at 14:58 +0200, Lubos Lunak wrote:
> > - osl_loadModule*() functions are plain C functions from stable API, so
> > no overloading to add the extra argument for the error message, the best
> > I've
who have already done
their setup will need to adjust for this. People who only have ccache
installed but haven't done anything will get slower builds, as the default
ccache cache size is vastly unsufficient for LO builds, so ccache will only
create cache contents that will be eventually thrown
On Monday 08 of August 2011, Christian Lohmaier wrote:
> On Mon, Aug 8, 2011 at 11:33 AM, Lubos Lunak wrote:
> > On Monday 08 of August 2011, Norbert Thiebaud wrote:
> >> I've pushed
> >> http://cgit.freedesktop.org/libreoffice/core/commit/?id=57cf026739a3d7
usage of STL drags in these problems, but that's not a problem that
couldn't be solved. Certainly much easier than having code cluttered with
checks and casts that serve no real purpose.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Tuesday 09 of August 2011, Stephan Bergmann wrote:
> On Aug 9, 2011, at 3:02 PM, Lubos Lunak wrote:
> > Too bad usage of STL drags in these problems, but that's not a problem
> > that couldn't be solved.
>
> How?
namespace lostd // or just no namespace at
On Tuesday 09 of August 2011, Stephan Bergmann wrote:
> On Aug 9, 2011, at 5:15 PM, Lubos Lunak wrote:
> > namespace lostd // or just no namespace at all, any other 'list' class is
> > unlikely
> > {
> > template< ... >
> > class list : public ::st
On Wednesday 10 of August 2011, Stephan Bergmann wrote:
> On Aug 10, 2011, at 12:31 PM, Lubos Lunak wrote:
> > On Tuesday 09 of August 2011, Stephan Bergmann wrote:
> >> Technically, lostd::list is no longer a container, as it violates the
> >> requirement that t
it, I can possibly see at least some reason for time
having 25 hours, but 10 seconds without 20 seconds being 10 seconds (and
there is actually explicit code to ensure that)?
Does somebody know why the Time class does either of these and how much would
break if I fixed these two to be sane
e of something (no compilation errors) by
marking it as deprecated, building with that and grepping the output for
deprecation warnings.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Thursday 11 of August 2011, Thorsten Behrens wrote:
> Lubos Lunak wrote:
> > As much as I don't like it, I can possibly see at least some reason for
> > time having 25 hours, but 10 seconds without 20 seconds being 10 seconds
> > (and there is actually ex
fff66ec7330,
rOLENode=...)
at /home/llunak/build/src/l2/sw/source/filter/ww8/wrtww8gr.cxx:280
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
stlport if we link KDE, unclear - Lubos: thoughts ?
I don't see the point of using stlport if the system is capable of building
KDE, in which case I'd expect the compiler to provide an adequate STL
implementation itself.
--
Lubos Lunak
l.lu...@suse.cz
___
s present.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ck, the
other with KDE stack (and KDE is actually not a DE,
http://dot.kde.org/2009/11/24/repositioning-kde-brand).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/ma
clone/components/cui/source/tabpages/borderconn.cxx:215:1: error: narrowing
conversion of '-1u' from 'size_t' to 'short unsigned int' inside { }
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ight ;-) they should all be built, and delivered into the solver, but
> only the ones you specify should be bundled
Does that mean you have broken KDE integration with that change :) ?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreO
On Wednesday 09 of February 2011, Michael Meeks wrote:
> On Tue, 2011-02-08 at 20:43 +0100, Lubos Lunak wrote:
> > On Sunday 06 of February 2011, Michael Meeks wrote:
> > > Right ;-) they should all be built, and delivered into the solver, but
> > > only the ones yo
t is LibreOffice do their own kde4 integration, so I
> assumed that the generic builds are good for QA and for folks doing
> computer archeology.
And I'd encourage this. Some of the fixes I've done in the KDE4 integration
code work much better with rece
My patch is attached to the bug report and is under the LGPLv3+/MPL
> > dual license.
Pushed to master, thanks.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Sunday 27 of February 2011, Rafael Dominguez wrote:
> More list cleaning for writer.
Pushed, thanks.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listi
On Tuesday 01 of March 2011, Lubos Lunak wrote:
> On Sunday 27 of February 2011, Rafael Dominguez wrote:
> > More list cleaning for writer.
>
> Pushed, thanks.
And fixed it, too. Please make sure the code compiles after your changes.
--
Lubos Lunak
On Monday 28 of February 2011, Martin Kepplinger wrote:
> Hi,
>
> This translates the german code comments of writer/sw/source/ui/docvw to
> english.
Thanks, pushed.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
On Wednesday 02 of March 2011, Rafael Dominguez wrote:
> More List container cleaning up, added an append function to ParagraphList,
> removed some unused code in writer. All the test passed succesfully.
Pushed, thanks.
--
Lubos Lunak
l.lu...@s
On Friday 04 of March 2011, Guillaume Poussel wrote:
> And again new patches attached (2/2)
>
> 2011/3/3 Guillaume Poussel :
> > Attached patches for components and filters.
Pushed (all 7 patches in the 3 mails), thanks.
--
Lubos Lunak
quite easy, but making it reasonably right gets
increasingly painful, especially if the embedded app has no support for it
(client side of XEmbed, etc.).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lis
lers
we care about, then we could switch to nullptr and #define it ourselves when
not provided by the compiler automatically.
--
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
On Thursday 24 of March 2011, Lubos Lunak wrote:
> Attached is a patch for introducing the warning (quite obvious) and a list
> of warnings (duplicates removed). I don't want to enable the warning right
> now, since although I've already reduced the number of warnings, I don
em. There were tons of them initially (it's header
files that trigger them), but my patch for fixing SdrObject::operator=() has
cleaned up most of them. It's probably good enough to go now.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice
On Thursday 24 of March 2011, Caolán McNamara wrote:
> On Thu, 2011-03-24 at 17:29 +0100, Lubos Lunak wrote:
> > a list of warnings (duplicates removed).
> > I don't want to enable the warning right now, since although I've
> > already reduced the number of warnin
On Friday 25 of March 2011, Caolán McNamara wrote:
> On Fri, 2011-03-25 at 13:55 +0100, Lubos Lunak wrote:
> > It should be the current full list, with duplicates removed (i.e. once
> > per every source of the problem, not once per every time it's reported).
> >
ypeid( *pFieldmark ).name(), pCheckboxFm, dynamic_cast< void* >(
pCheckboxFm ), typeid( *pCheckboxFm ).name());
(where 'ptr' is what you get from the pMarksAccess->makeNoTextFieldBookmark()
call before casting to anything).
--
Lubos Lunak
l.lu...@suse.cz
___
no-)exceptions should be completely unrelated to RTTI.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 25 of March 2011, Pierre-André Jacquod wrote:
> Hello,
>
> On 03/25/2011 02:13 PM, Lubos Lunak wrote:
> > On Friday 25 of March 2011, Caolán McNamara wrote:
> >> argh!, I meant to say "then things are *not* too bad", not "*too* bad".
> >
'? And, looking at this description, is there any
plan to get rid of these superfluous sal_xxx types eventually?
[*]
http://wiki.documentfoundation.org/Development/Easy_Hacks#Get_rid_of_sal_uLong
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOff
On Monday 28 of March 2011, Bjoern Michaelsen wrote:
> Hi Lubos,
> On Mon, 28 Mar 2011 12:45:11 +0200
>
> Lubos Lunak wrote:
> > Specifically, the simple and logical type for numbers happens to be
> > 'int'. Some kind of intptr type is usually only for ugly ha
On Tuesday 29 of March 2011, Bjoern Michaelsen wrote:
> Hi Lubos,
>
> On Tue, 29 Mar 2011 15:11:44 +0200
>
> Lubos Lunak wrote:
> > Why not? I generally just need a number and int fits that perfectly.
> > I really don't care how many bits it has as long as it wo
On Wednesday 30 of March 2011, Bjoern Michaelsen wrote:
> Lubos Lunak wrote:
> > If it's used for marshalling, then it can't be changed. Or, if it
> > can, then it doesn't matter if the data would be simply marshalled as
> > int.
>
> Some sal_* =&g
1 - 100 of 726 matches
Mail list logo
