On Fri, Dec 16, 2022 at 10:42:07PM +0100, Yu Jin wrote:
> Am Fr., 16. Dez. 2022 um 21:47 Uhr schrieb Scott Kostyshak:
>
> > On Fri, Dec 16, 2022 at 09:18:08PM +0100, Yu Jin wrote:
> > > Done at 26a3a085
> >
> > Sorry for the late comment Yu Jin, but should that line be conditional
> > on (not?) LY
Am Fr., 16. Dez. 2022 um 21:47 Uhr schrieb Scott Kostyshak:
> On Fri, Dec 16, 2022 at 09:18:08PM +0100, Yu Jin wrote:
> > Done at 26a3a085
>
> Sorry for the late comment Yu Jin, but should that line be conditional
> on (not?) LYX_EXTERNAL_Z?
>
> I'm guessing that the answer is that it's only neces
On Fri, Dec 16, 2022 at 09:18:08PM +0100, Yu Jin wrote:
> Am Fr., 16. Dez. 2022 um 09:16 Uhr schrieb Kornel Benko :
>
> > Am Fri, 16 Dec 2022 07:37:00 +0100
> > schrieb Yu Jin:
> >
> > > > Yes it does work, but actually I had a better idea to use
> > > > ${_Qt6ZlibPrivate_OWN_INCLUDE_DIRS} instead
Am Fr., 16. Dez. 2022 um 09:16 Uhr schrieb Kornel Benko :
> Am Fri, 16 Dec 2022 07:37:00 +0100
> schrieb Yu Jin:
>
> > > Yes it does work, but actually I had a better idea to use
> > > ${_Qt6ZlibPrivate_OWN_INCLUDE_DIRS} instead of
> "${CMAKE_PREFIX_PATH}/include/QtZlib",
> > > because it is in th
Am Fri, 16 Dec 2022 07:37:00 +0100
schrieb Yu Jin :
> > Yes it does work, but actually I had a better idea to use
> > ${_Qt6ZlibPrivate_OWN_INCLUDE_DIRS} instead of
> > "${CMAKE_PREFIX_PATH}/include/QtZlib",
> > because it is in the variable already. I have sent a patch here:
> > https://www.mail
Am Do., 15. Dez. 2022 um 22:54 Uhr schrieb Yu Jin :
> Am Mi., 14. Dez. 2022 um 19:50 Uhr schrieb Scott Kostyshak <
> skost...@lyx.org>:
>
>> On Sat, Dec 10, 2022 at 05:09:46PM +0100, Kornel Benko wrote:
>> > Am Sat, 10 Dec 2022 15:38:43 +0100
>> > schrieb Yu Jin :
>> >
>> > > Am Do., 8. Dez. 2022
Am Mi., 14. Dez. 2022 um 19:50 Uhr schrieb Scott Kostyshak :
> On Sat, Dec 10, 2022 at 05:09:46PM +0100, Kornel Benko wrote:
> > Am Sat, 10 Dec 2022 15:38:43 +0100
> > schrieb Yu Jin :
> >
> > > Am Do., 8. Dez. 2022 um 16:11 Uhr schrieb Kornel Benko >:
> > >
> > > > Am Thu, 8 Dec 2022 09:52:29 -0
On Sat, Dec 10, 2022 at 05:09:46PM +0100, Kornel Benko wrote:
> Am Sat, 10 Dec 2022 15:38:43 +0100
> schrieb Yu Jin :
>
> > Am Do., 8. Dez. 2022 um 16:11 Uhr schrieb Kornel Benko :
> >
> > > Am Thu, 8 Dec 2022 09:52:29 -0500
> > > schrieb Scott Kostyshak :
> > >
> > > > On Mon, Dec 05, 2022 at 10
Am Sat, 10 Dec 2022 15:38:43 +0100
schrieb Yu Jin :
> Am Do., 8. Dez. 2022 um 16:11 Uhr schrieb Kornel Benko :
>
> > Am Thu, 8 Dec 2022 09:52:29 -0500
> > schrieb Scott Kostyshak :
> >
> > > On Mon, Dec 05, 2022 at 10:15:18PM +0100, Yu Jin wrote:
> > > > Am Mo., 5. Dez. 2022 um 10:39 Uhr schrieb
Am Do., 8. Dez. 2022 um 16:11 Uhr schrieb Kornel Benko :
> Am Thu, 8 Dec 2022 09:52:29 -0500
> schrieb Scott Kostyshak :
>
> > On Mon, Dec 05, 2022 at 10:15:18PM +0100, Yu Jin wrote:
> > > Am Mo., 5. Dez. 2022 um 10:39 Uhr schrieb Pavel Sanda :
> > >
> > > >
> > > > Given that on major linux distr
Am Thu, 8 Dec 2022 09:52:29 -0500
schrieb Scott Kostyshak :
> On Mon, Dec 05, 2022 at 10:15:18PM +0100, Yu Jin wrote:
> > Am Mo., 5. Dez. 2022 um 10:39 Uhr schrieb Pavel Sanda :
> >
> > >
> > > Given that on major linux distributions will still link against qt5
> > > I think stikcing for 2.4 wi
On Mon, Dec 05, 2022 at 10:15:18PM +0100, Yu Jin wrote:
> Am Mo., 5. Dez. 2022 um 10:39 Uhr schrieb Pavel Sanda :
>
> >
> > Given that on major linux distributions will still link against qt5
> > I think stikcing for 2.4 with Qt 5 is just fine...
>
>
> I think my curiosity helped here :)
>
> So
On Mon, Dec 05, 2022 at 08:24:42AM +0100, Yu Jin wrote:
> Am So., 4. Dez. 2022 um 20:03 Uhr schrieb Pavel Sanda :
>
> > Did you update gzlib or compiler?
> >
>
> No, it I just tried to compile with Qt5 though, it works, only Qt6
> doesn't... I don't understand why, I even tried to update to zlib
Am So., 4. Dez. 2022 um 20:03 Uhr schrieb Pavel Sanda :
> Did you update gzlib or compiler?
>
No, it I just tried to compile with Qt5 though, it works, only Qt6
doesn't... I don't understand why, I even tried to update to zlib 1.2.13,
but no success.
--
Eugene
--
lyx-devel mailing list
lyx-de
On Sun, Dec 04, 2022 at 10:17:25AM +0100, Yu Jin wrote:
> I can't build master currently on Windows, I get these errors:
Did you update gzlib or compiler?
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
I can't build master currently on Windows, I get these errors:
Schweregrad Code Beschreibung Projekt Datei Zeile Unterdrückungszustand
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzread" in Funktion ""public: virtual int __cdecl
gz::gzstreambuf::underflow(void)" (?underfl
Am 29.07.2020 um 11:45 schrieb Jürgen Spitzmüller :
>
> Am Dienstag, den 21.07.2020, 21:20 +0200 schrieb Stephan Witt:
>> I cannot compile the german Users Guide w/o errors anymore with
>> master.
>>
>> Two errors are for broken references like this:
>>
>> Xindy error: Cross-reference-target ("
Am Dienstag, den 21.07.2020, 21:20 +0200 schrieb Stephan Witt:
> I cannot compile the german Users Guide w/o errors anymore with
> master.
>
> Two errors are for broken references like this:
>
> Xindy error: Cross-reference-target ("Nomenklatur}}}|hyperpage")
> does not exist!
Should be fixed.
Am 21.07.2020 um 21:34 schrieb Stephan Witt :
>
> Am 21.07.2020 um 21:20 schrieb Stephan Witt :
>>
>> Hi,
>>
>> I cannot compile the german Users Guide w/o errors anymore with master.
>>
>> Two errors are for broken references like this:
>>
>> Xindy error: Cross-reference-target ("Nomenklatur
Am 21.07.2020 um 21:20 schrieb Stephan Witt :
>
> Hi,
>
> I cannot compile the german Users Guide w/o errors anymore with master.
>
> Two errors are for broken references like this:
>
> Xindy error: Cross-reference-target ("Nomenklatur}}}|hyperpage") does not
> exist!
>
> and tons of errors
Hi,
I cannot compile the german Users Guide w/o errors anymore with master.
Two errors are for broken references like this:
Xindy error: Cross-reference-target ("Nomenklatur}}}|hyperpage") does not
exist!
and tons of errors like that:
Undefined control sequence.
\item plus3\p
Op 15-6-2012 12:15, Bogdan Roman schreef:
On 15-Jun-12 11:05 am, Vincent van Ravesteijn wrote:
Op 15-6-2012 11:54, Bogdan Roman schreef:
I still don't see the added value of this script. The script is doing
nothing else than calling cmake with predefined arguments. You said
you
want to auto
On 15-Jun-12 11:05 am, Vincent van Ravesteijn wrote:
Op 15-6-2012 11:54, Bogdan Roman schreef:
I still don't see the added value of this script. The script is doing
nothing else than calling cmake with predefined arguments. You said you
want to automate the detection of the arguments, but this
Op 15-6-2012 11:54, Bogdan Roman schreef:
I still don't see the added value of this script. The script is doing
nothing else than calling cmake with predefined arguments. You said you
want to automate the detection of the arguments, but this is not what
the build script does, this is what is CM
On 15-Jun-12 10:37 am, Vincent van Ravesteijn wrote:
Hmm, you may be right. I've looked more closely at the script and
there are some things still wrong, e.g. "deploy" option is not
implemented but advertised as a command line option. I admit, I don't
like the fact that the script needs to be e
Op 15-6-2012 11:33, Bogdan Roman schreef:
On 15-Jun-12 10:27 am, Vincent van Ravesteijn wrote:
Op 15-6-2012 11:04, Bogdan Roman schreef:
Why don't you use CMake directly ? That's the recommended way to
compile
LyX on Windows.
Where's that recommendation? Right now the recommended way I see
Hmm, you may be right. I've looked more closely at the script and
there are some things still wrong, e.g. "deploy" option is not
implemented but advertised as a command line option. I admit, I don't
like the fact that the script needs to be edited either.
If there is interest in this, I am w
On 15-Jun-12 10:27 am, Vincent van Ravesteijn wrote:
Op 15-6-2012 11:04, Bogdan Roman schreef:
Why don't you use CMake directly ? That's the recommended way to compile
LyX on Windows.
Where's that recommendation? Right now the recommended way I see is
the INSTALL.Win32 file and other info poi
Op 15-6-2012 11:04, Bogdan Roman schreef:
Why don't you use CMake directly ? That's the recommended way to compile
LyX on Windows.
Where's that recommendation? Right now the recommended way I see is
the INSTALL.Win32 file and other info pointing to it.
Yes, and this file reads: "5Confi
Hmm, you may be right. I've looked more closely at the script and there
are some things still wrong, e.g. "deploy" option is not implemented but
advertised as a command line option. I admit, I don't like the fact that
the script needs to be edited either.
If there is interest in this, I am wil
On 1/9/2012 3:03 PM, Jean-Marc Lasgouttes wrote:
> Le 09/01/12 19:19, Rob Oakes a écrit :
>> I've tried to Google the source of this error, but can't figure it. The
>> code compiles fine on Mac OS X, Linux, and 32 bit Windows mingw.
>> Moreover, there are templates for const char *, and char * so I
Le 09/01/12 19:19, Rob Oakes a écrit :
I've tried to Google the source of this error, but can't figure it. The
code compiles fine on Mac OS X, Linux, and 32 bit Windows mingw.
Moreover, there are templates for const char *, and char * so I don't
understand why it's not happy. The version of gmake
Dear Developers,
I had a few minutes this morning so I thought that I would try and fix
some bugs related to XHTML output. However, I don't have access to my
normal laptop and was working on a Windows box with a 64 build of Qt
4.8, QtCreator (x64) and the mingw-w64 compiler.
In the process of try
Dear LyX Developers,
I'm trying to add a simple list objet to the OutputParams header file, but I
keep getting strange errors and I can't figure out what's causing them.
Here's what I would like to do:
#include
#include
...
std::list footlist;
However, I can't get that far. When I include In
On Sun, Apr 3, 2011 at 9:25 PM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> Pavel Sanda wrote:
>> > gcc 4.1.2
>> > Qt 4.4.1
>>
>> simple ifdef for QTabWidget helps, but there is probably better fix since i
>> needed
>> ifdefs only in spellcheck, not in findavdanced dialog which uses QTabWidget
>>
Pavel Sanda wrote:
> Pavel Sanda wrote:
> > gcc 4.1.2
> > Qt 4.4.1
>
> simple ifdef for QTabWidget helps, but there is probably better fix since i
> needed
> ifdefs only in spellcheck, not in findavdanced dialog which uses QTabWidget
> as well.
just committed workaround for the time being. p
Pavel Sanda wrote:
> gcc 4.1.2
> Qt 4.4.1
simple ifdef for QTabWidget helps, but there is probably better fix since i
needed
ifdefs only in spellcheck, not in findavdanced dialog which uses QTabWidget as
well.
> GuiSpellchecker.h:29: error: expected class-name before '{' token
> GuiSpellcheck
gcc 4.1.2
Qt 4.4.1
GuiSpellchecker.h:29: error: expected class-name before '{' token
GuiSpellchecker.h:29: warning: 'class lyx::frontend::SpellcheckerWidget' has
virtual functions but non-virtual destructor
GuiSpellchecker.cpp: In constructor
'lyx::frontend::SpellcheckerWidget::SpellcheckerWidge
Am Sonntag, den 18.07.2010, 15:08 +0200 schrieb Kornel Benko:
> Am Sonntag 18 Juli 2010 schrieb Kornel Benko:
> > There are errors like this:
>
> Still more errors. Nobody sees it?
On a other Ubuntu machine I see the same errors,
and there is a fix but it was not enabled.
Peter
Am Sonntag, den 18.07.2010, 19:43 +0200 schrieb Kornel Benko:
> Am Sonntag 18 Juli 2010 schrieb Richard Heck:
> > On 07/18/2010 09:08 AM, Kornel Benko wrote:
> > > Am Sonntag 18 Juli 2010 schrieb Kornel Benko:
> > >
> > >
> > >> There are errors like this:
> > >>
> > >>
> > > Still more e
Am Sonntag 18 Juli 2010 schrieb Richard Heck:
> On 07/18/2010 09:08 AM, Kornel Benko wrote:
> > Am Sonntag 18 Juli 2010 schrieb Kornel Benko:
> >
> >
> >> There are errors like this:
> >>
> >>
> > Still more errors. Nobody sees it?
> >
> >
>
> Nothing like this using autotools, anywa
On 07/18/2010 09:08 AM, Kornel Benko wrote:
Am Sonntag 18 Juli 2010 schrieb Kornel Benko:
There are errors like this:
Still more errors. Nobody sees it?
Nothing like this using autotools, anyway. And we do have:
/// Compare a docstring with a C string of ASCII characters
bool op
Am Sonntag 18 Juli 2010 schrieb Kornel Benko:
> There are errors like this:
Still more errors. Nobody sees it?
...
In file included from
/usr/BUILD/BuildLyx/src/frontends/qt4/_allinone_const.C:108:
/usr/src/lyx/lyx-devel/src/frontends/qt4/GuiHyperlink.cpp: In member function
‘void lyx::frontend:
>
> ...
> /usr/src/lyx/branch-1.6/src/frontends/qt4/GuiSpellchecker.cpp: In member
> function ‘virtual bool lyx::frontend::GuiSpellchecker::eventFilter(QObject*,
> QEvent*)’:
> /usr/src/lyx/branch-1.6/src/frontends/qt4/GuiSpellchecker.cpp:95: error:
> expected unqualified-id before numeric cons
There are errors like this:
/usr/src/lyx/branch-1.6/src/frontends/qt4/GuiBibtex.cpp: In member function
‘virtual void lyx::frontend::GuiBibtex::updateContents()’:
/usr/src/lyx/branch-1.6/src/frontends/qt4/GuiBibtex.cpp:332: error: no match
for ‘operator==’ in ‘btprint == "btPrintNotCited"’
If I
Pavel Sanda wrote:
Linking...
CutAndPaste.obj : error LNK2019: unresolved external symbol "public: bool
__thiscall lyx::InsetCollapsable::undefined(void)const "
([EMAIL PROTECTED]@lyx@@QBE_NXZ) referenced in function "void
__cdecl lyx::cap::switchBetweenClasses(class boost::shared_ptrlyx::Text
> Linking...
> CutAndPaste.obj : error LNK2019: unresolved external symbol "public: bool
> __thiscall lyx::InsetCollapsable::undefined(void)const "
> ([EMAIL PROTECTED]@lyx@@QBE_NXZ) referenced in function "void
> __cdecl lyx::cap::switchBetweenClasses(class boost::shared_ptr lyx::TextClass> con
..\..\..\..\src\insets\InsetText.cpp(71) : error C2664:
'std::_Tree<_Traits>::iterator::iterator(std::_Tree_nod<_Traits>::_Node
*,const std::_Tree<_Traits> *)' : cannot convert parameter 1 from
'std::_Tree<_Traits>::const_iterator' to 'std::_Tree_nod<_Traits>::_Node *'
with
[
_
Georg Baum wrote:
> Am Freitag, 27. Oktober 2006 15:11 schrieb Peter Kümmel:
>> I kill this endless thread by committing now,
>> it's not worth the trouble.
>
> Please add a comment why this ugly construct is needed, otherwise nobody
> knows why the pointer juggling is done.
>
> To me it looks l
Am Freitag, 27. Oktober 2006 16:52 schrieb Peter Kümmel:
> does fabs work under linux? then we could change it to using fabs.
fabs is part of the C standard since ages.
Georg
Am Freitag, 27. Oktober 2006 15:11 schrieb Peter Kümmel:
> I kill this endless thread by committing now,
> it's not worth the trouble.
Please add a comment why this ugly construct is needed, otherwise nobody
knows why the pointer juggling is done.
To me it looks like a bug in MSVC that the origi
Am Freitag, 27. Oktober 2006 17:49 schrieb Jean-Marc Lasgouttes:
> Isn't std::abs supposed to have a double variant?
Yes. And I would prefer to use that instead of fabs. It did probably not
work because cmath was not included.
Georg
> Isn't std::abs supposed to have a double variant?
>
Maybe it mas the missing math header.
Yeap, adding cmath solves the problem.
Patch submitted.
Bo
Jean-Marc Lasgouttes wrote:
>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> Peter> Jonathan Vogt wrote:
>>> Am Freitag 27 Oktober 2006 16:52 schrieb Peter Kümmel:
Jonathan Vogt wrote:
> Am Freitag 27 Oktober 2006 16:14 schrieb Bo Peng:
>> The problem is still there. Why
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> Jonathan Vogt wrote:
>> Am Freitag 27 Oktober 2006 16:52 schrieb Peter Kümmel:
>>> Jonathan Vogt wrote:
Am Freitag 27 Oktober 2006 16:14 schrieb Bo Peng:
> The problem is still there. Why not use fabs in math.h? At least
>>>
Jonathan Vogt wrote:
> Am Freitag 27 Oktober 2006 16:52 schrieb Peter Kümmel:
>> Jonathan Vogt wrote:
>>> Am Freitag 27 Oktober 2006 16:14 schrieb Bo Peng:
The problem is still there. Why not use fabs in math.h? At least this
makes lyx compile.
>> does fabs work under linux? then we coul
Am Freitag 27 Oktober 2006 16:52 schrieb Peter Kümmel:
> Jonathan Vogt wrote:
> > Am Freitag 27 Oktober 2006 16:14 schrieb Bo Peng:
> >>
> >> The problem is still there. Why not use fabs in math.h? At least this
> >> makes lyx compile.
> >
>
> does fabs work under linux? then we could change it to
does fabs work under linux? then we could change it to using fabs.
Of course, math.h is needed though.
Bo
Jonathan Vogt wrote:
> Am Freitag 27 Oktober 2006 16:14 schrieb Bo Peng:
>>> 8\VC\include\math.h(491): or 'float abs(float)'
>>> 2>C:\Program Files\Microsoft Visual Studio
>>> 8\VC\include\math.h(487): or 'double abs(double)'
>>> 2>C:\Program Files\Microsoft Visual Studio
>>> 8\VC\i
Bo Peng wrote:
>> 8\VC\include\math.h(491): or 'float abs(float)'
>> 2>C:\Program Files\Microsoft Visual Studio
>> 8\VC\include\math.h(487): or 'double abs(double)'
>> 2>C:\Program Files\Microsoft Visual Studio
>> 8\VC\include\math.h(485): or 'long abs(long)'
>> 2>C:\Program
Am Freitag 27 Oktober 2006 16:14 schrieb Bo Peng:
> > 8\VC\include\math.h(491): or 'float abs(float)'
> > 2>C:\Program Files\Microsoft Visual Studio
> > 8\VC\include\math.h(487): or 'double abs(double)'
> > 2>C:\Program Files\Microsoft Visual Studio
> > 8\VC\include\math.h(485): or
8\VC\include\math.h(491): or 'float abs(float)'
2>C:\Program Files\Microsoft Visual Studio
8\VC\include\math.h(487): or 'double abs(double)'
2>C:\Program Files\Microsoft Visual Studio
8\VC\include\math.h(485): or 'long abs(long)'
2>C:\Program Files\Microsoft Visual Studio
8
Peter Kümmel wrote:
Back to start:
It's just a reference initialization:
int i0;
int & i = i0;
int & r1 = i;
int & r2 = *(&i);
...
Where's the problem?
No problem per see. I just find it a bit ugly but I have no problem with it.
Abdel.
Peter Kümmel wrote:
> Abdelrazak Younes wrote:
>> Abdelrazak Younes wrote:
>>> Peter Kümmel wrote:
Edwin Leuven wrote:
> 2 of 'em, see below. someone knows what i should do? thanks, ed.
>
>
> 2>output_latex.C
> 2>C:\Program Files\Microsoft Visual Studio 8\VC\include\ostream
Jean-Marc Lasgouttes wrote:
>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> Peter> Jean-Marc Lasgouttes wrote:
>>> Both are ugly. Again: can we use difftime?
>
> Peter> sorry have missed your difftime idea, yes it works:
>
> Peter> && abs(difftime(l.changetime, r.changetime)) <
Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Peter Kümmel wrote:
>>> Edwin Leuven wrote:
2 of 'em, see below. someone knows what i should do? thanks, ed.
2>output_latex.C
2>C:\Program Files\Microsoft Visual Studio 8\VC\include\ostream(581) :
error C2248: 'std
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Edwin Leuven wrote:
2 of 'em, see below. someone knows what i should do? thanks, ed.
2>output_latex.C
2>C:\Program Files\Microsoft Visual Studio 8\VC\include\ostream(581) :
error C2248: 'std::basic_ios<_Elem,_Traits>::basic_ios' : cannot access
pri
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> Jean-Marc Lasgouttes wrote:
>> Both are ugly. Again: can we use difftime?
Peter> sorry have missed your difftime idea, yes it works:
Peter> && abs(difftime(l.changetime, r.changetime)) < 300;
I propose to use this, then.
JMarc
Peter Kümmel wrote:
Jean-Marc Lasgouttes wrote:
Both are ugly. Again: can we use difftime?
sorry have missed your difftime idea, yes it works:
&& abs(difftime(l.changetime, r.changetime)) < 300;
Confirmed.
Abdel.
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> Edwin Leuven wrote:
Abdelrazak Younes wrote:
do we need to cast lyx::time_type to ... ?
No, the difference:
sure, but that will have the same type no?
Abdelraz
Peter Kümmel wrote:
Edwin Leuven wrote:
2 of 'em, see below. someone knows what i should do? thanks, ed.
2>output_latex.C
2>C:\Program Files\Microsoft Visual Studio 8\VC\include\ostream(581) :
error C2248: 'std::basic_ios<_Elem,_Traits>::basic_ios' : cannot access
private member declared in cl
Jean-Marc Lasgouttes wrote:
>
> Both are ugly. Again: can we use difftime?
sorry have missed your difftime idea, yes it works:
&& abs(difftime(l.changetime, r.changetime)) < 300;
--
Peter Kümmel
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Edwin Leuven wrote:
Abdelrazak Younes wrote:
do we need to cast lyx::time_type to ... ?
No, the difference:
sure, but that will have the same type no?
Abdelrazak> no, we need an explici
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>> #include
>>
>> +#ifdef _MSC_VER +namespace std +{ + inline __int64 abs(__int64 i)
>> + { + return _abs64(i);
>> + }
>> +}
>> +#endif
>>
Peter> A other -but more ugly- solution is (at least in this file)
Peter> #ifdef _MSC_VER
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> If there are no objections I check in this later today:
Wait for Georg's comments.
JMarc
Edwin Leuven wrote:
Abdelrazak Younes wrote:
Edwin Leuven wrote:
no, we need an explicit int (not unsigned long) because MSVC doesn't
know how to choose between the different abs version (the one in
math.h requires a double).
i just wondered whether the difference between two lyx::time_type'
Edwin Leuven wrote:
> 2 of 'em, see below. someone knows what i should do? thanks, ed.
>
>
> 2>output_latex.C
> 2>C:\Program Files\Microsoft Visual Studio 8\VC\include\ostream(581) :
> error C2248: 'std::basic_ios<_Elem,_Traits>::basic_ios' : cannot access
> private member declared in class 'std:
Peter Kümmel wrote:
> Jean-Marc Lasgouttes wrote:
>> But are we sure that int is a wide enough type?
>
> there is no abs function for 64 bit ints,
> so we must define it:
>
> Index: changes.C
> ===
> --- changes.C (revision 15576)
Jean-Marc Lasgouttes wrote:
> But are we sure that int is a wide enough type?
there is no abs function for 64 bit ints,
so we must define it:
Index: changes.C
===
--- changes.C (revision 15576)
+++ changes.C (working copy)
@@ -18
Abdelrazak Younes wrote:
Edwin Leuven wrote:
no, we need an explicit int (not unsigned long) because MSVC doesn't
know how to choose between the different abs version (the one in math.h
requires a double).
i just wondered whether the difference between two lyx::time_type's is
again a lyx::ti
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Edwin Leuven wrote:
>> Abdelrazak Younes wrote:
do we need to cast lyx::time_type to ... ?
>>> No, the difference:
>> sure, but that will have the same type no?
Abdelrazak> no, we need an explicit int (not unsi
Edwin Leuven wrote:
> 2 of 'em, see below. someone knows what i should do? thanks, ed.
>
>
> 2>output_latex.C
it's line 311:
odocstream & os(change_encoding ? par_stream : ucs4);
Edwin Leuven wrote:
Abdelrazak Younes wrote:
do we need to cast lyx::time_type to ... ?
No, the difference:
sure, but that will have the same type no?
no, we need an explicit int (not unsigned long) because MSVC doesn't
know how to choose between the different abs version (the one in math
Abdelrazak Younes wrote:
do we need to cast lyx::time_type to ... ?
No, the difference:
sure, but that will have the same type no?
Jean-Marc Lasgouttes wrote:
What is time_t on your system?
long if i am not mistaken:
#ifndef _TIME32_T_DEFINED
typedef _W64 long __time32_t; /* 32-bit time value */
#define _TIME32_T_DEFINED
#endif
#ifndef _TIME64_T_DEFINED
#if _INTEGRAL_MAX_BITS >= 64
typedef __int64 __time64_t;
Edwin Leuven wrote:
Jean-Marc Lasgouttes wrote:
"Edwin" == Edwin Leuven <[EMAIL PROTECTED]>
writes:
2> changes.C ..\..\..\src\changes.C(52) : error C2668: 'abs' :
2> ambiguous call to overloaded function
I guess the file misses a using std::abs;
that was also what i thought, but it didn't s
Edwin Leuven wrote:
2 of 'em, see below. someone knows what i should do? thanks, ed.
I was output to ask the same. The first one seems difficult but the
second one is easy (changes.C). Just need to cast to (int)...
Abdel.
> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
Edwin> Jean-Marc Lasgouttes wrote:
>>> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
>>
2> changes.C ..\..\..\src\changes.C(52) : error C2668: 'abs' :
2> ambiguous call to overloaded function
>> I guess the file misses a using st
Jean-Marc Lasgouttes wrote:
"Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
2> changes.C ..\..\..\src\changes.C(52) : error C2668: 'abs' :
2> ambiguous call to overloaded function
I guess the file misses a
using std::abs;
that was also what i thought, but it didn't solve it
do we need
> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
2> changes.C ..\..\..\src\changes.C(52) : error C2668: 'abs' :
2> ambiguous call to overloaded function
I guess the file misses a
using std::abs;
JMarc
2 of 'em, see below. someone knows what i should do? thanks, ed.
2>output_latex.C
2>C:\Program Files\Microsoft Visual Studio 8\VC\include\ostream(581) :
error C2248: 'std::basic_ios<_Elem,_Traits>::basic_ios' : cannot access
private member declared in class 'std::basic_ios<_Elem,_Traits>'
2>
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc, I propose modifying the 13x version of
Angus> boost/detail/limits.hpp to this (this is what the next boost
Angus> version, 1.31.0 will have).
Angus> It will resolve Jeremy's problem and enable us to support
Angus> Itaniu
Jean-Marc,
I propose modifying the 13x version of boost/detail/limits.hpp to this
(this is what the next boost version, 1.31.0 will have).
It will resolve Jeremy's problem and enable us to support Itanium
machines.
Ok?
Angus
#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) |
Configuration
Host type: i686-pc-linux-gnu
Special build flags:warnings assertions xforms-image-loader
C Compiler: gcc
C Compiler flags: -g -O2
C++ Compiler: g++ (2.95.1)
C++ Compiler flags:
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Mar 03, 2003 at 11:17:25AM +0100, Jean-Marc Lasgouttes wrote:
| > We used to have things like handling `explicit' keyword for older c++
| > compilers (by #define'ing explicit to empty string). This does not
| > apply to recent lyx, but if we want
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Mon, Mar 03, 2003 at 11:17:25AM +0100, Jean-Marc Lasgouttes
Andre> wrote:
>> We used to have things like handling `explicit' keyword for older
>> c++ compilers (by #define'ing explicit to empty string). This does
>> not apply to
On Mon, Mar 03, 2003 at 11:17:25AM +0100, Jean-Marc Lasgouttes wrote:
> We used to have things like handling `explicit' keyword for older c++
> compilers (by #define'ing explicit to empty string). This does not
> apply to recent lyx, but if we want to reintroduce something like that
> later I'd rat
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Mon, Mar 03, 2003 at 09:44:34AM +0100, Jean-Marc Lasgouttes
Andre> wrote: To be honest, I never understood the rule.
>> The rule is: don't try to understand, just include in
>> every .C file.
Andre> But I have another rule: Do
On Mon, Mar 03, 2003 at 09:44:34AM +0100, Jean-Marc Lasgouttes wrote:
> Andre> To be honest, I never understood the rule.
>
> The rule is: don't try to understand, just include in every
> .C file.
But I have another rule: Do not include anything if you don't need it.
> Then if you do not want t
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Fri, Feb 28, 2003 at 06:11:41PM +0100, Alfredo Braunstein
Andre> wrote:
>> There are still some remaining files which do not include
>> . Are they exceptions to the general rule?
Andre> To be honest, I never understood the rule.
1 - 100 of 127 matches
Mail list logo
