I know nothing of lyx2lyx but have a question that recently came up.
Is it common when exporting to older LyX formats to convert some insets
to ERT? It seems common, e.g., when adding a feature in a new version of
LyX that does not exist in an older version of LyX.
If it is common, from what I un
On 10/14/20 3:25 PM, Yuriy Skalko wrote:
>> It's the other way that's needed here:
>>
>> template<>
>> unsigned long long convert(string const & s)
>>
>> {
>>
>> return strtoull(s);
>>
>> }
>>
>>
>> I assume that will fix it.
>>
>>
>> Riki
> Thanks, it helps.
Great, fixed then.
Riki
--
lyx-dev
> It's the other way that's needed here:
>
> template<>
> unsigned long long convert(string const & s)
>
> {
>
> return strtoull(s);
>
> }
>
>
> I assume that will fix it.
>
>
> Riki
Thanks, it helps.
Yuriy
diff --git a/src/support/convert.cpp b/src/support/convert.cpp
index af0ad62f2b..7
On 10/14/20 12:50 PM, José Abílio Matos wrote:
On Wednesday, October 14, 2020 4:37:18 PM WEST Richard Kimberly Heck
wrote:
> I guess size_t must be unsigned long long on your machine? Can you try
> adding a template declaration for convert to
> support/convert.cpp?
>
> Riki
It is alread
> I guess size_t must be unsigned long long on your machine? Can you try adding
> a template declaration for convert to support/convert.cpp?
>
> Riki
As José said it is already defined on my 64-bit system. Probably CMake
files (I use it for build) should be updated.
Yuriy
--
lyx-devel mailing
On Wednesday, October 14, 2020 4:37:18 PM WEST Richard Kimberly Heck wrote:
> I guess size_t must be unsigned long long on your machine? Can you try
> adding a template declaration for convert to
> support/convert.cpp?
>
> Riki
My first joke would be to replace all the code by:
#include
auto
On Wednesday, October 14, 2020 4:37:18 PM WEST Richard Kimberly Heck wrote:
> I guess size_t must be unsigned long long on your machine? Can you try
> adding a template declaration for convert to
> support/convert.cpp?
>
> Riki
It is already there:
#ifdef HAVE_LONG_LONG_INT
template<>
string con
On 10/14/20 11:12 AM, Yuriy Skalko wrote:
I have linking error after commit 28ae543a (Fix signed-ness warnings):
src/CMakeFiles/LyX2.4.dir/output_latex.cpp.obj:output_latex.cpp:(.text+0x1b1a):
undefined reference to `unsigned long long lyx::convert,
std::allocator > >(std::__cxx11::basic_
I have linking error after commit 28ae543a (Fix signed-ness warnings):
src/CMakeFiles/LyX2.4.dir/output_latex.cpp.obj:output_latex.cpp:(.text+0x1b1a):
undefined reference to `unsigned long long lyx::convert,
std::allocator > >(std::__cxx11::basic_string, std::allocator >)'
Yuriy
On 08/09/2019 20:47, pdv wrote:
On 08/09/2019 17:47, Kornel Benko wrote:
Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De
Visschere:
In the source files (ConverterCache.cpp, Application.cpp,
FileName.cpp and GuiClipboard.cpp) I don’t see macro’s which could
optionally include th
On 09/09/2019 11:49, pdv wrote:
On 08/09/2019 21:12, Jean-Marc Lasgouttes wrote:
Le 08/09/2019 à 14:14, Patrick De Visschere a écrit :
LyX includes a 3thparty boost-version (1.68), but I don’t find any
references to it in my XCode project and I think I’m actually using
my macports boost (which
On 08/09/2019 21:12, Jean-Marc Lasgouttes wrote:
Le 08/09/2019 à 14:14, Patrick De Visschere a écrit :
LyX includes a 3thparty boost-version (1.68), but I don’t find any
references to it in my XCode project and I think I’m actually using my
macports boost (which is 1.71).
This might explain it:
> On 9 Sep 2019, at 00:41, Stephan Witt wrote:
>
> Am 08.09.2019 um 22:44 schrieb Patrick De Visschere :
>>
>>
>>
>>> On 8 Sep 2019, at 21:03, Stephan Witt wrote:
>>>
>>> Am 08.09.2019 um 20:47 schrieb pdv :
On 08/09/2019 17:47, Kornel Benko wrote:
> Am Sonntag, 8. September
Am 08.09.2019 um 22:44 schrieb Patrick De Visschere :
>
>
>
>> On 8 Sep 2019, at 21:03, Stephan Witt wrote:
>>
>> Am 08.09.2019 um 20:47 schrieb pdv :
>>>
>>> On 08/09/2019 17:47, Kornel Benko wrote:
Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
> In the
> On 8 Sep 2019, at 21:03, Stephan Witt wrote:
>
> Am 08.09.2019 um 20:47 schrieb pdv :
>>
>> On 08/09/2019 17:47, Kornel Benko wrote:
>>> Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and
Le 08/09/2019 à 14:14, Patrick De Visschere a écrit :
LyX includes a 3thparty boost-version (1.68), but I don’t find any
references to it in my XCode project and I think I’m actually using my
macports boost (which is 1.71).
This might explain it: I’ve upgraded my macports boost and this breaks
Am 08.09.2019 um 20:47 schrieb pdv :
>
> On 08/09/2019 17:47, Kornel Benko wrote:
>> Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
>>> In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and
>>> GuiClipboard.cpp) I don’t see macro’s which could opti
On 08/09/2019 17:47, Kornel Benko wrote:
Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and
GuiClipboard.cpp) I don’t see macro’s which could optionally include the
relevant code which is probabl
Am 08.09.2019 um 14:14 schrieb Patrick De Visschere :
>
> Yes, I have a few different settings (but I didn’t change them recently as
> far as I know) and I’m using (gui) CMake 3.15.1
> and XCode = Version 10.3 (10G8)
I’m using
- cmake version 3.12.0
- Xcode 10.3, Build version 10G8
ATM, I’m una
Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
> In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and
> GuiClipboard.cpp) I don’t see macro’s which could optionally include the
> relevant code which is probably in the boost::crc module. I suppose
Yes, I have a few different settings (but I didn’t change them recently as far
as I know) and I’m using (gui) CMake 3.15.1
and XCode = Version 10.3 (10G8)
LYX_CPACK = ON : Use the CPack management (Implies LYX_INSTALL option)
LYX_LOCALVERSIONING = OFF : Add version info to created package name (o
Am 08.09.2019 um 10:02 schrieb Patrick De Visschere :
>
> Sorry, mistyped the last “f”: it should have been 01ee3bf1e5, the master
> branch on 5 sept.
I see. Yes, this is HEAD for me too. This is what works for me.
Perhaps you have different cmake flags?
I have:
-- LYX_CPACK
Sorry, mistyped the last “f”: it should have been 01ee3bf1e5, the master branch
on 5 sept.
> On 8 Sep 2019, at 09:34, Stephan Witt wrote:
>
> Am 07.09.2019 um 10:14 schrieb pdv :
>>
>> LyX fails to build on macos (Mojave, CMake, XCode) with the latest commit
>> (01ee3bf1f5) with message:
>>
Am 07.09.2019 um 10:14 schrieb pdv :
>
> LyX fails to build on macos (Mojave, CMake, XCode) with the latest commit
> (01ee3bf1f5) with message:
>
> Undefined symbols for architecture x86_64:
> "boost::assertion_failed_msg(char const*, char const*, char const*, char
> const*, long)", referenced
LyX fails to build on macos (Mojave, CMake, XCode) with the latest
commit (01ee3bf1f5) with message:
Undefined symbols for architecture x86_64:
"boost::assertion_failed_msg(char const*, char const*, char const*,
char const*, long)", referenced from:
boost::array::operator[](unsigned lon
Am Sonntag, 16. Oktober 2016 um 17:05:03, schrieb Jürgen Spitzmüller
> Am Sonntag, den 16.10.2016, 16:55 +0200 schrieb Kornel Benko:
> > OK. Have you enabled std:regex?
>
> Yes.
>
> > If yes, you could try to find
> > bold 'foo' from the home position, while setting 'don't ignore
> > format' i
Am Sonntag, den 16.10.2016, 16:55 +0200 schrieb Kornel Benko:
> OK. Have you enabled std:regex?
Yes.
> If yes, you could try to find
> bold 'foo' from the home position, while setting 'don't ignore
> format' in adv search settings?
>
> Expected: the first 'foo', but with std:regex the second 'f
Am Sonntag, 16. Oktober 2016 um 16:13:20, schrieb Jürgen Spitzmüller
> Am Sonntag, den 16.10.2016, 15:02 +0200 schrieb Kornel Benko:
> > It took ages to compile gcc6.2.0 ...
> > The test with this compiler (+cmake and again without '-std=c++14')
> > does compile and link everything.
> > Could y
Am Sonntag, den 16.10.2016, 15:02 +0200 schrieb Kornel Benko:
> It took ages to compile gcc6.2.0 ...
> The test with this compiler (+cmake and again without '-std=c++14')
> does compile and link everything.
> Could you give cmake a chance?
I tried again with a clean build and now succeeded. The
Am Sonntag, 16. Oktober 2016 um 13:13:38, schrieb Jürgen Spitzmüller
> Am Sonntag, den 16.10.2016, 04:08 -0700 schrieb Kornel Benko:
> > Am Sonntag, 16. Oktober 2016 um 12:46:28, schrieb Jürgen Spitzmüller
> >
> > > As of today (probably related to a system update),
> >
> >
> > This means prob
Le 16/10/2016 à 12:46, Jürgen Spitzmüller a écrit :
As of today (probably related to a system update), master does not link
any longer. I get:
BiblioInfo.o: In function
Less intimidating version (hand made) is:
BiblioInfo.o: In function
`lyx::BibTeXInfo::getValueForKey(string const&, lyx::Buf
Am Sonntag, den 16.10.2016, 04:08 -0700 schrieb Kornel Benko:
> Am Sonntag, 16. Oktober 2016 um 12:46:28, schrieb Jürgen Spitzmüller
>
> > As of today (probably related to a system update),
>
>
> This means probably also c++-compiler update.
Yes.
>
> What about trying with a clean build tree?
Am Sonntag, 16. Oktober 2016 um 12:46:28, schrieb Jürgen Spitzmüller
> As of today (probably related to a system update),
This means probably also c++-compiler update.
What about trying with a clean build tree?
> master does not link
> any longer. I get:
>
> BiblioInfo.o: In function
> `lyx::
As of today (probably related to a system update), master does not link
any longer. I get:
BiblioInfo.o: In function
`lyx::BibTeXInfo::getValueForKey(std::__cxx11::basic_string, std::allocator > const&, lyx::Buffer
const&, std::__cxx11::basic_string,
std::allocator > const&, std::__cxx11::basic_st
Am 12.06.2014 um 19:03 schrieb Kornel Benko :
> commit 3b14de740df6b5733e65c5d0fe850cb24b1a8cd1
> Author: Kornel Benko
> Date: Thu Jun 12 19:02:29 2014 +0200
>
>Cmake build: Symplify use of linking optional libraries found via
> find_package
This change solved
On 10/11/13 15:02, Jean-Marc Lasgouttes wrote:
> The best to make it work is to have a look at getStatus in
> frontends/qt4/GuiView.cpp. There you can expand the current handling
> of LFUN_DIALOG_SHOW to mark the function as disabled as needed.
>
> Then, the patch you sent should just work.
I jus
Le 10/11/2013 14:19, Tommaso Cucinotta a écrit :
On 10/11/13 13:09, Jean-Marc Lasgouttes wrote:
Or mark the lfun "unknown" when not supported.
how do I do this marking ? For now, the chat is activated via
A-x dialog-show chat
The best to make it work is to have a look at getStatus in
fr
On 10/11/13 13:09, Jean-Marc Lasgouttes wrote:
> Or mark the lfun "unknown" when not supported.
how do I do this marking ? For now, the chat is activated via
A-x dialog-show chat
it's not a real LFUN, just a request to show a specific dialog. Is OptItem
going to work in such case ?
Is the on
Or mark the lfun "unknown" when not supported.
Jmarc
Georg Baum a écrit :
>Tommaso Cucinotta wrote:
>
>> One tiny issue, though: the "LyX Chat" menu in stdmenus.inc: that is
>going
>> to be added anyway, even though the "dialog-show lyx-chat" is not
>going to
>> be anyway meaningful without US
Tommaso Cucinotta wrote:
> One tiny issue, though: the "LyX Chat" menu in stdmenus.inc: that is going
> to be added anyway, even though the "dialog-show lyx-chat" is not going to
> be anyway meaningful without USE_QXMPP ?
>
> Is there a way to get rid of the menu entry as well, in such case ?
Ye
Am Samstag, 9. November 2013 um 23:25:27, schrieb Tommaso Cucinotta
> On 09/11/13 18:56, Kornel Benko wrote:
> > /usr/src/lyx/lyx/src/frontends/qt4/GuiView.cpp:4177: undefined reference to
> > `lyx::frontend::createGuiBuddies(lyx::frontend::GuiView&)'
> > /usr/src/lyx/lyx/src/frontends/qt4/GuiVi
On 09/11/13 18:56, Kornel Benko wrote:
> /usr/src/lyx/lyx/src/frontends/qt4/GuiView.cpp:4177: undefined reference to
> `lyx::frontend::createGuiBuddies(lyx::frontend::GuiView&)'
> /usr/src/lyx/lyx/src/frontends/qt4/GuiView.cpp:4183: undefined reference to
> `lyx::frontend::createGuiChat(lyx::fron
...
/usr/src/lyx/lyx/src/frontends/qt4/GuiView.cpp:4177: undefined reference to
`lyx::frontend::createGuiBuddies(lyx::frontend::GuiView&)'
/usr/src/lyx/lyx/src/frontends/qt4/GuiView.cpp:4183: undefined reference to
`lyx::frontend::createGuiChat(lyx::frontend::GuiView&)'
...
Kornel
sign
2012/8/15 Abdelrazak Younes:
> Yes, same idiom should be used: theLaTeXFonts()
> As a matter of fact, all singletons are gathered in a single class,
> maybe you should also follow this trend.
Thanks. I've implemented the function now to LyX.cpp following the
model of the other singleton access fun
On Tue, Aug 14, 2012 at 10:10 PM, Pavel Sanda wrote:
> Abdelrazak Younes wrote:
>> Maybe it was optimized out by the linker.
>
> Yes this will the problem. If object is in library without being called it
> would be omitted
> unless you use --whole-archive for ld. So either one need to use it in c
Abdelrazak Younes wrote:
> Maybe it was optimized out by the linker.
Yes this will the problem. If object is in library without being called it
would be omitted
unless you use --whole-archive for ld. So either one need to use it in core or
move the
definition to qt4 library. Or use function to o
On 14/08/2012 16:54, Jürgen Spitzmüller wrote:
I seem to be blind. Why does the attached patch fail to link with
autotools? The error I get is
CXXLD lyx
frontends/qt4/liblyxqt4.a(GuiDocument.o): In function
`lyx::frontend::GuiDocument::updateFontlist()':
/home/jspitzm/lyx/lyx-devel/src/frontend
On 08/14/2012 10:54 AM, Jürgen Spitzmüller wrote:
I seem to be blind. Why does the attached patch fail to link with
autotools? The error I get is
CXXLD lyx
frontends/qt4/liblyxqt4.a(GuiDocument.o): In function
`lyx::frontend::GuiDocument::updateFontlist()':
/home/jspitzm/lyx/lyx-devel/src/front
Le 29/11/2011 16:10, Jean-Marc Lasgouttes a écrit :
Richard,
The following patch has not been baclported to branch (r39772+r39791).
The changes are in now. Stephan, I did not update the mac compiling
script, since there are many other changes between trunk and branch.
JMarc
On 11/29/2011 10:45 AM, Kornel Benko wrote:
> Am Dienstag, 29. November 2011 um 10:17:37, schrieb Richard Heck
>
>> On 11/29/2011 10:10 AM, Jean-Marc Lasgouttes wrote:
>>> Richard,
>>>
>>> The following patch has not been baclported to branch (r39772+r39791).
>>>
>>> OK?
>>>
>> Sure. Did you see
Am Dienstag, 29. November 2011 um 10:17:37, schrieb Richard Heck
> On 11/29/2011 10:10 AM, Jean-Marc Lasgouttes wrote:
> > Richard,
> >
> > The following patch has not been baclported to branch (r39772+r39791).
> >
> > OK?
> >
> Sure. Did you see the message about CMake, as well? Does this cover
Le 29/11/11 16:17, Richard Heck a écrit :
On 11/29/2011 10:10 AM, Jean-Marc Lasgouttes wrote:
Richard,
The following patch has not been backported to branch (r39772+r39791).
OK?
Sure. Did you see the message about CMake, as well? Does this cover that?
It is its cousin of some sort :)
I'll
On 11/29/2011 10:10 AM, Jean-Marc Lasgouttes wrote:
> Richard,
>
> The following patch has not been baclported to branch (r39772+r39791).
>
> OK?
>
Sure. Did you see the message about CMake, as well? Does this cover that?
Richard
AppKit
+endif
+
# everything below the line containing the single backslashs
# an ugly hack and needed because of the
# linking problems described in ../Makefile.am
Index: src/tex2lyx/Makefile.am
===
--- src/tex2lyx/Makefile.am (r
Jean-Marc Lasgouttes skrev:
BTW, is linking with gold a win with LyX?
It's supposed to be faster, although I haven't tried it. I don't think
it affects runtime speed though, only build speed.
--
Pelle
Hi,
Jean-Marc Lasgouttes skrev:
Abdelrazak Younes writes:
Because QtGui is a dynamic library it handles its dependency alone.
What you say would be try if we did static linking.
It seems to me that, in the old days, dynamic libraries requires extra -lFoo
too.
I think it depends on which
Abdelrazak Younes writes:
> Because QtGui is a dynamic library it handles its dependency alone.
> What you say would be try if we did static linking.
It seems to me that, in the old days, dynamic libraries requires extra -lFoo
too.
BTW, are we sure we cannot get rid of the X11 code?
pendency alone. What
you say would be try if we did static linking.
Abdel.
uses X11 libs directly in at least one place:
> src/frontends/qt4/GuiApplication.cpp
Could someone explain to me how this works? QtGui has to link to X11
somewhere, right? How come pkg-config does not need to specify an
explicit -lX11?
BTW, is linking with gold a win with LyX?
JMarc
Hi Sven,
Sven Hoexter skrev:
Oh and I've no profound knowledge of the issue so it's possible that the
better solution would be to fix something in Qt's pkg-config in Debian.
It's not Qt's fault -- lyx uses X11 libs directly in at least one place:
src/frontends/qt4/GuiApplication.cpp
--
Pelle
y and easy to work around with
explicitly linking against Xlib (added -lX11 via LDCONFIG enviroment variable).
It would be more interestingly to know if other distributions or people
here experimented with gold so far and what the results where?
Oh and I've no profound knowledge of the iss
Rob Oakes wrote:
> Any guidance or feedback would be greatly appreciated.
if its not gcc 4.4 then try to clean checkout from svn tree.
there are some linking issues from time to time.
pavel
On 08/16/2009 03:35 PM, Peter Kümmel wrote:
Rob Oakes wrote:
Dear LyX-Developers,
After taking a bit of a break from LyX development for summer projects
at work and vacations, I was rather eager to jump back in but have
encountered a bit of a problem. When I checked out the most revision o
Rob Oakes wrote:
> Dear LyX-Developers,
>
> After taking a bit of a break from LyX development for summer projects
> at work and vacations, I was rather eager to jump back in but have
> encountered a bit of a problem. When I checked out the most revision of
> LyX, I am not able to compile it. In
Dear LyX-Developers,
After taking a bit of a break from LyX development for summer projects
at work and vacations, I was rather eager to jump back in but have
encountered a bit of a problem. When I checked out the most revision of
LyX, I am not able to compile it. Instead, I get a slew of ra
Kornel Benko wrote:
Am Saturday 02 August 2008 schrieb Dov Feldstern:
OK, the problem is this: it doesn't compile with the --disable-nls flag;
without this flag it compiles cleanly. I always compile with this flag,
though I don't know if it still has any significance? But I guess it should
Am Saturday 02 August 2008 schrieb Dov Feldstern:
> Pavel Sanda wrote:
> > Dov Feldstern wrote:
> >> Abdelrazak Younes wrote:
> >>> Dov Feldstern wrote:
> Hi!
>
> Linux, Qt 4.2.1:
>
> frontends/qt4/.libs/liblyxqt4.a(GuiApplication.o): In function
> `lyx::frontend::GuiA
Pavel Sanda wrote:
Dov Feldstern wrote:
Abdelrazak Younes wrote:
Dov Feldstern wrote:
Hi!
Linux, Qt 4.2.1:
frontends/qt4/.libs/liblyxqt4.a(GuiApplication.o): In function
`lyx::frontend::GuiApplication::setGuiLanguage()':
/home/dovf/lyx-trunk-new/src/frontends/qt4/GuiApplication.cpp:1031:
u
Am Friday 01 August 2008 schrieb Kornel Benko:
> You have to define somewhere (in e.g. GuiApplication.cpp)
> namespace lyx {
> std::string Message::main_lang_;
> }
>
> because this variable is declared static in class mMessage
Grrrm ... I meant class Messages of cours
Am Friday 01 August 2008 schrieb Pavel Sanda:
> Dov Feldstern wrote:
> > Abdelrazak Younes wrote:
> >> Dov Feldstern wrote:
> >>> Hi!
> >>>
> >>> Linux, Qt 4.2.1:
> >>>
> >>> frontends/qt4/.libs/liblyxqt4.a(GuiApplication.o): In function
> >>> `lyx::frontend::GuiApplication::setGuiLanguage()':
> >>
Dov Feldstern wrote:
> Abdelrazak Younes wrote:
>> Dov Feldstern wrote:
>>> Hi!
>>>
>>> Linux, Qt 4.2.1:
>>>
>>> frontends/qt4/.libs/liblyxqt4.a(GuiApplication.o): In function
>>> `lyx::frontend::GuiApplication::setGuiLanguage()':
>>> /home/dovf/lyx-trunk-new/src/frontends/qt4/GuiApplication.cpp:1
Abdelrazak Younes wrote:
Dov Feldstern wrote:
Hi!
Linux, Qt 4.2.1:
frontends/qt4/.libs/liblyxqt4.a(GuiApplication.o): In function
`lyx::frontend::GuiApplication::setGuiLanguage()':
/home/dovf/lyx-trunk-new/src/frontends/qt4/GuiApplication.cpp:1031:
undefined reference to `lyx::Messages::main
Hi!
Linux, Qt 4.2.1:
frontends/qt4/.libs/liblyxqt4.a(GuiApplication.o): In function
`lyx::frontend::GuiApplication::setGuiLanguage()':
/home/dovf/lyx-trunk-new/src/frontends/qt4/GuiApplication.cpp:1031: undefined
reference to `lyx::Messages::main_lang_'
collect2: ld returned 1 exit status
mak
Pavel Sanda wrote:
here too.
bisect leads me here:
http://www.lyx.org/trac/changeset/24249
Andre'?
Well, it's not exactly surprising that replacing an empty assert macro
with one that actually barks increases the noise level ;-)
And no, that change is not the problem...
i'm no
> > > > Well, it's not exactly surprising that replacing an empty assert macro
> > > > with one that actually barks increases the noise level ;-)
> > > >
> > > > And no, that change is not the problem...
> > >
> > > i'm not claiming that it is the root of the problem. just that before
> > > this
On Thu, Apr 17, 2008 at 10:51:25PM +0200, Pavel Sanda wrote:
> > > > here too.
> > > >
> > > > bisect leads me here:
> > > > http://www.lyx.org/trac/changeset/24249
> > > > Andre'?
> > >
> > > Well, it's not exactly surprising that replacing an empty assert macro
> > > with one that actually bark
> > > here too.
> > >
> > > bisect leads me here:
> > > http://www.lyx.org/trac/changeset/24249
> > > Andre'?
> >
> > Well, it's not exactly surprising that replacing an empty assert macro
> > with one that actually barks increases the noise level ;-)
> >
> > And no, that change is not the probl
> > here too.
> >
> > bisect leads me here:
> > http://www.lyx.org/trac/changeset/24249
> > Andre'?
>
> Well, it's not exactly surprising that replacing an empty assert macro
> with one that actually barks increases the noise level ;-)
>
> And no, that change is not the problem...
i'm not claim
On Wed, Apr 16, 2008 at 09:09:40AM +0200, Pavel Sanda wrote:
> > g++ -g -O2 -o lyxclient boost.o client.o debug.o gettext.o Messages.o
> > ../../src/support/.libs/liblyxsupport.a -L/usr/lib -lQtCore
> > ../../boost/.libs/liblyxboost.a -lSM -lICE -lz -L/usr/lib64 -lX11
> > ../../src/support/.libs
> g++ -g -O2 -o lyxclient boost.o client.o debug.o gettext.o Messages.o
> ../../src/support/.libs/liblyxsupport.a -L/usr/lib -lQtCore
> ../../boost/.libs/liblyxboost.a -lSM -lICE -lz -L/usr/lib64 -lX11
> ../../src/support/.libs/liblyxsupport.a(debug.o): In function
here too.
bisect leads me h
g++ -g -O2 -o lyxclient boost.o client.o debug.o gettext.o Messages.o
../../src/support/.libs/liblyxsupport.a -L/usr/lib -lQtCore
../../boost/.libs/liblyxboost.a -lSM -lICE -lz -L/usr/lib64 -lX11
../../src/support/.libs/liblyxsupport.a(debug.o): In function
`lyx::LyXErr::disable()':
/cvs/lyx-
>
> Right, all files are included in the same file with monolithic builds so
> the anonymous namespace will not solve Pavel's problem.
>
>> why dont we put it in header Abdel ?
>
> I just put them inside the functions. This should solve your problem.
yes this will solve it too.
thanks,
pavel
Pavel Sanda wrote:
Try putting both of these variables in an anonymous namespace.
hm, dont understand why this should help.
Same variable in the same namespace. That's what causes the conflict.
yes.
Anonymous namespace, I think, has file scope.
but thats where i dont follow you.
>>> Try putting both of these variables in an anonymous namespace.
>>>
>>
>> hm, dont understand why this should help.
>>
>>
> Same variable in the same namespace. That's what causes the conflict.
yes.
> Anonymous namespace, I think, has file scope.
but thats where i dont follow you. to
Pavel Sanda wrote:
GuiPainter.cpp: At global scope:
GuiPainter.cpp:433: error: redefinition of 'const int lyx::frontend::d'
GuiFontMetrics.cpp:180: error: 'const int lyx::frontend::d' previously
defined here
Try putting both of these variables in an anonymous namespace.
hm, d
>> GuiPainter.cpp: At global scope:
>> GuiPainter.cpp:433: error: redefinition of 'const int lyx::frontend::d'
>> GuiFontMetrics.cpp:180: error: 'const int lyx::frontend::d' previously
>> defined here
>>
>>
> Try putting both of these variables in an anonymous namespace.
hm, dont understand wh
i fixed this. anyway there is still problem:
GuiPainter.cpp: At global scope:
GuiPainter.cpp:433: error: redefinition of 'const int lyx::frontend::d'
GuiFontMetrics.cpp:180: error: 'const int lyx::frontend::d' previously defined
here
Try putting both of these variables in an anonymous nam
> This is probably a consequence of some change I made, but I don't know
> anything about monolithic builds (do I do them?) or where information
no, unless you use --enable-monolithic options in configure, you dont.
they are more speedy in case you want to build lyx from a clean tree -
all cpp
Pavel Sanda wrote:
hi,
i started having these linking errs when using monolithic builds...
This is probably a consequence of some change I made, but I don't know
anything about monolithic builds (do I do them?) or where information
regarding them is contained. It looks as though
hi,
i started having these linking errs when using monolithic builds...
./.libs/liblyxcore.a(TextClass.o): In function
`__static_initialization_and_destruction_0':
/home/installer/lyx/dbg_1.6/src/TextClass.cpp:112: undefined reference to
`lyx::InsetLayout::InsetLayout()'
./.libs/li
I guess, dynamic should be default on Linux, and static only default on
Mac and Windows, but this way it compiles at least out-of-the-box.
Andre'
Index: configure.ac
===
--- configure.ac(revision 19626)
+++ configure.ac
Le 27 juin 07 à 12:24, Alfredo Braunstein a écrit :
Mael Hilléreau wrote:
Thanks for the suggestion. How do you think would it help error
handling? Right now we don't show latex errors line numbers at all.
In fact, I was thinking of non blocking errors or warnings, which are
indicated into t
Mael Hilléreau wrote:
>> Thanks for the suggestion. How do you think would it help error
>> handling? Right now we don't show latex errors line numbers at all.
>
> In fact, I was thinking of non blocking errors or warnings, which are
> indicated into the LaTeX log and often come with a line numbe
Le 27 juin 07 à 11:51, Alfredo Braunstein a écrit :
On 6/27/07, Mael Hilléreau <[EMAIL PROTECTED]> wrote:
What about displaying line numbers in the source view? This may not
be hard to do and could help error handling as well... But it would
Thanks for the suggestion. How do you think would it
On 6/27/07, Mael Hilléreau <[EMAIL PROTECTED]> wrote:
What about displaying line numbers in the source view? This may not
be hard to do and could help error handling as well... But it would
be needed to consider child documents separately (offset due to
preamble skipping).
Thanks for the sugg
Le 20 juin 07 à 17:06, Alfredo Braunstein a écrit :
The following short patch is a links the source view window with
the work
area: now when navigating with the cursor the line of the latex source
which should contain the corresponding position of the cursor
position is
selected.
The patch
I'm not sure I'll be able to follow closely in the next days, so unless
someone else wants to take care of it I prefer to leave it for 1.5.x (soon
I hope ;-))
I agree. Let us just push 1.5.0 out...
Bo
José Matos wrote:
> On Monday 25 June 2007 19:50:41 Bo Peng wrote:
>>
>> Then you have a combined OK from Abdel and me, you need to wait for
>> Jose's.
>>
>> Jose: This looks like 1.5.x stuff but showing where the cursor is in
>> the view source window is a nice thing to have.
>
> I was tempted
On Monday 25 June 2007 19:50:41 Bo Peng wrote:
>
> Then you have a combined OK from Abdel and me, you need to wait for Jose's.
>
> Jose: This looks like 1.5.x stuff but showing where the cursor is in
> the view source window is a nice thing to have.
I was tempted to say yes, but then I saw Alfre
thing that would be nice to have is the reverse linking:
implementing it is trivial, but then the combination of the two would
interfere with the selection of text in the source view window, and that's
very bad. So the best would be to have an independent selection, but I
don't know how
1 - 100 of 381 matches
Mail list logo
