Following Abdel's recent work, I need this to compile. Going in now.
JMarc
Index: src/lyxserver.C
===
--- src/lyxserver.C (revision 15163)
+++ src/lyxserver.C (working copy)
@@ -44,6 +44,7 @@
#include "funcrequest.h"
#include "LyX
This makes qt3 compile again. Going in now.
JMarc
Index: src/frontends/qt3/QDialogView.C
===
--- src/frontends/qt3/QDialogView.C (revision 15287)
+++ src/frontends/qt3/QDialogView.C (working copy)
@@ -19,7 +19,7 @@
namespace lyx {
This is needed when assertions are disabled.
Committing now.
JMarc
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.1110
diff -u -r1.1110 ChangeLog
--- src/insets/C
Angus,
I have problems compiling lengthcommon.C with gcc 3.2.2 and need the
attached patch. Any reason why I should not apply it?
JMarc
Attached is a compilation fix. At least on my egcs 2.91.66 compile is
broken due to changes in the xforms frontend.
I also eliminated a few warnings in the same code area.
--
Baruch Even
http://baruch.ev-en.org/
graphics.diff.gz
Index: frontends/controllers/ControlGraphics.C
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlGraphics.C,v
retrieving revision 1.37
diff -u -p -r1.37 ControlGraphics.C
--- frontends/controllers/Con
Jean-Marc Lasgouttes wrote:
Following Abdel's recent work, I need this to compile. Going in now.
It is really weird that it compiles without it for me... But you are
right, I see a call to lyx_gui::register_socket_callback() in there.
weird.
Abdel.
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
>> Following Abdel's recent work, I need this to compile. Going in
>> now.
Abdelrazak> It is really weird that it compiles without it for me...
Abdelrazak> But you are right, I see a call t
On Wed, Sep 27, 2006 at 03:46:54PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> > Following Abdel's recent work, I need this to compile. Going in now.
>
> It is really weird that it compiles without it for me... But you are
> right, I see a call to lyx_gui::register_socket_cal
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
Following Abdel's recent work, I need this to compile. Going in
now.
Abdelrazak> It is really weird that it compiles without it for me...
Abdelrazak> But you are
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| This is needed when assertions are disabled.
Huh? what is that making a difference?
--
Lgb
Lars Gullik Bjønnes wrote:
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| This is needed when assertions are disabled.
Huh? what is that making a difference?
It allows to use BOOST_CURRENT_FUNCTION when asserts are disabled
(because boost assertions use this).
JMarc
Jean-Marc Lasgouttes wrote:
> Angus,
>
> I have problems compiling lengthcommon.C with gcc 3.2.2 and need the
> attached patch. Any reason why I should not apply it?
I have never had a problem with a zero byte patch...
--
Angus
On Monday 05 April 2004 16:35, Jean-Marc Lasgouttes wrote:
> Angus,
>
> I have problems compiling lengthcommon.C with gcc 3.2.2 and need the
> attached patch. Any reason why I should not apply it?
You should switch to kmail, that everytime it sees attached and not
attachement asks for it. :-)
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
>> Angus,
>>
>> I have problems compiling lengthcommon.C with gcc 3.2.2 and need
>> the attached patch. Any reason why I should not apply it?
Angus> I have never had a problem with a zero byte patch...
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes:
Jose'> On Monday 05 April 2004 16:35, Jean-Marc Lasgouttes wrote:
>> Angus,
>>
>> I have problems compiling lengthcommon.C with gcc 3.2.2 and need
>> the attached patch. Any reason why I should not apply it?
Jose'> You should switch to k
Jean-Marc Lasgouttes wrote:
>>> I have problems compiling lengthcommon.C with gcc 3.2.2 and need
>>> the attached patch. Any reason why I should not apply it?
>
> Angus> I have never had a problem with a zero byte patch...
>
> Umph.
Ahhh. No reasons why you should not apply it and every reason w
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
I have problems compiling lengthcommon.C with gcc 3.2.2 and need
the attached patch. Any reason why I should not apply it?
>>
Angus> I have never had a problem with a zero byte patch...
>> Umph
Well I dont have write access in those areas anyhow, thats why I post the
patch and not apply it directly.
Anyhow, as long as it works its fine with me, I'm no control freak.
On Tue, 20 Mar 2001, Angus Leeming wrote:
> Someone beat you to it, it would appear...
> A
>
> On Monday 19 March 2001
Angus Leeming <[EMAIL PROTECTED]> writes:
| Well, it wasn't me. I thought it might be the anonymous creator of namespace
| anon!
Ok, so we have to do some investigating...
Lgb
Someone beat you to it, it would appear...
A
On Monday 19 March 2001 23:12, Baruch Even wrote:
> > Attached is a compilation fix. At least on my egcs 2.91.66 compile is
> broken due to changes in the xforms frontend.
>
> I also eliminated a few warnings in the same code area.
>
> --
> Baruch
On Tuesday 20 March 2001 10:28, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Someone beat you to it, it would appear...
> | A
>
> And failed to mention it in the ChangeLog file...
Well, it wasn't me. I thought it might be the anonymous creator of namespace
anon!
Angus Leeming <[EMAIL PROTECTED]> writes:
| Someone beat you to it, it would appear...
| A
And failed to mention it in the ChangeLog file...
Lgb
Dekel Tsur <[EMAIL PROTECTED]> writes:
| Index: frontends/controllers/ControlGraphics.C
| ===
| RCS file:
|/usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlGraphics.C,v
| retrieving revision 1.37
| diff -u -p -r1.37
On Tue, May 14, 2002 at 02:34:29PM +0300, Dekel Tsur wrote:
> @@ -190,7 +190,7 @@ namespace {
> // These are the strings that are stored in the LyX file and which
> // correspond to the LaTeX identifiers shown in the comments at the
> // end of each line.
> -char const * const rorigin_lyx_strs[
On Tue, May 14, 2002 at 01:44:53PM +0200, Lars Gullik Bjønnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
> | -char const * const rorigin_lyx_strs[] = {
> | +char const * rorigin_lyx_strs[] = {
>
> What compilation errors?
frontends/.libs/libfrontends.a(ControlGraphics.o): In function
frnt::
On Tue, May 14, 2002 at 02:51:29PM +0300, Dekel Tsur wrote:
> > | -char const * const rorigin_lyx_strs[] = {
> > | +char const * rorigin_lyx_strs[] = {
>
> I know my compiler is crappy (I'll switch to gcc3 soon), but there is no
> reason to use the 2nd const above.
Sure there is. You are not sup
I wonder why I did not fix these ones last time I compiled without
assertions... Anyway, here are a few files that require
#include
Lars, considering that this is (slightly) ugly, would you prefer a
patch that includes this header in debug.h (considering that these
names are only needed with ly
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| I wonder why I did not fix these ones last time I compiled without
| assertions... Anyway, here are a few files that require
| #include
>
| Lars, considering that this is (slightly) ugly, would you prefer a
| patch that includes this header in d
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I
Lars> wonder why I did not fix these ones last time I compiled without
Lars> | assertions... Anyway, here are a few files that require |
Lars> #include
>>
Lars> | Lars, consi
The following patch fixes compilation for me with clang and libc++ (with
autotools I set CXX="clang++ --stdlib=libc++").
This is a workaround to https://llvm.org/bugs/show_bug.cgi?id=24137
to be fixed in 3.7.1 or 3.8.0.
Can someone confirm that adding the default constructor like that is
harml
Jean-Marc Lasgouttes wrote:
> The following patch fixes compilation for me with clang and libc++ (with
> autotools I set CXX="clang++ --stdlib=libc++").
>
> This is a workaround to https://llvm.org/bugs/show_bug.cgi?id=24137
> to be fixed in 3.7.1 or 3.8.0.
>
> Can someone confirm that adding th
Le 08/01/2016 08:59, Jean-Marc Lasgouttes a écrit :
The following patch fixes compilation for me with clang and libc++ (with
autotools I set CXX="clang++ --stdlib=libc++").
This is a workaround to https://llvm.org/bugs/show_bug.cgi?id=24137
to be fixed in 3.7.1 or 3.8.0.
Can someone confirm tha
Le 08/01/16 22:50, Guillaume Munch a écrit :
I tried to look it up. It might work right now but I think we should
get rid of this subclassing entirely. It is just used for
forward-declaration and defining helper functions. I have a bad feeling
about starting to define custom constructors for STL
Le 10/01/2016 20:42, Jean-Marc Lasgouttes a écrit :
Le 08/01/16 22:50, Guillaume Munch a écrit :
I tried to look it up. It might work right now but I think we should
get rid of this subclassing entirely. It is just used for
forward-declaration and defining helper functions. I have a bad feeling
Le 10/01/16 22:17, Guillaume Munch a écrit :
Since you have gotten a +1 from somebody else, sure. I was not so sure
myself, so I wanted to offer an alternative that was sure to be safe. I
think this will have to be done nevertheless, so I am going to keep it
for later.
Indeed Georg's comment lo
Le 10/01/2016 21:26, Jean-Marc Lasgouttes a écrit :
Le 10/01/16 22:17, Guillaume Munch a écrit :
Since you have gotten a +1 from somebody else, sure. I was not so sure
myself, so I wanted to offer an alternative that was sure to be safe. I
think this will have to be done nevertheless, so I am go
Le 10/01/16 22:33, Guillaume Munch a écrit :
I imagine that Toc and other classes are being forward-declared in some
headers probably for the same speed reason. Toc.h is there to provide an
alternative to the forward declarations without sacrificing speed (or
maybe my Toc.h already includes too m
Le 08/01/2016 22:39, Georg Baum a écrit :
Jean-Marc Lasgouttes wrote:
The following patch fixes compilation for me with clang and libc++ (with
autotools I set CXX="clang++ --stdlib=libc++").
This is a workaround to https://llvm.org/bugs/show_bug.cgi?id=24137
to be fixed in 3.7.1 or 3.8.0.
Can
Jean-Marc Lasgouttes wrote:
> Le 10/01/16 22:17, Guillaume Munch a écrit :
>> Since you have gotten a +1 from somebody else, sure. I was not so sure
>> myself, so I wanted to offer an alternative that was sure to be safe. I
>> think this will have to be done nevertheless, so I am going to keep it
Le 10/01/2016 21:38, Jean-Marc Lasgouttes a écrit :
Le 10/01/16 22:33, Guillaume Munch a écrit :
I imagine that Toc and other classes are being forward-declared in some
headers probably for the same speed reason. Toc.h is there to provide an
alternative to the forward declarations without sacrif
Le 17/04/2016 01:03, Guillaume Munch a écrit :
Le 10/01/2016 21:38, Jean-Marc Lasgouttes a écrit :
Le 10/01/16 22:33, Guillaume Munch a écrit :
I imagine that Toc and other classes are being forward-declared in some
headers probably for the same speed reason. Toc.h is there to provide an
altern
42 matches
Mail list logo
