trunk does no compile

[Tommaso Cucinotta]

As in the subject:

insets/InsetTabular.cpp: In member function ‘int 
lyx::Tabular::TeXTopHLine(lyx::otexstream, size_t, std::string) const’:
insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator’ 
in 
‘lyx::operator(((lyx::otexstream)((lyx::otexstream*)lyx::operator(((lyx::otexstream)((lyx::otexstream*)lyx::operator(((lyx::otexstream)((lyx::otexstream*)os)), 
((const char*)\\expandafter, (((bool)((const 
lyx::Tabular*)this)-lyx::Tabular::use_booktabs) ? ((const 
char*)\\cmidrule) : ((const char*)\\cline), ((const 
char*)\\expandafter{\\expandafter))  ((c + offset) + 1u)’
./support/docstream.h:154: note: candidates are: lyx::otexstream 
lyx::operator(lyx::otexstream, unsigned int)
./support/docstream.h:152: note: lyx::otexstream 
lyx::operator(lyx::otexstream, int)
./support/docstream.h:150: note: lyx::otexstream 
lyx::operator(lyx::otexstream, double)
./support/docstream.h:148: note: lyx::otexstream 
lyx::operator(lyx::otexstream, char)
./support/docstream.h:146: note: lyx::otexstream 
lyx::operator(lyx::otexstream, const char*) near match
./support/docstream.h:144: note: lyx::otexstream 
lyx::operator(lyx::otexstream, const lyx::docstring) near match


$ g++ --version
g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5

T.

Re: trunk does no compile

[Kornel]

Am Samstag, 29. Januar 2011 schrieb Tommaso Cucinotta:
 insets/InsetTabular.cpp: In member function ‘int 
 lyx::Tabular::TeXTopHLine(lyx::otexstream, size_t, std::string) const’:
 insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator’ 
 in 
 ‘lyx::operator(((lyx::otexstream)((lyx::otexstream*)lyx::operator(((ly
 x::otexstream)((lyx::otexstream*)lyx::operator(((lyx::otexstream)((lyx:
 :otexstream*)os)),  ((const char*)\\expandafter, (((bool)((const

This cured it for me, but I fear it is not the proper c++ patch.

Kornel
Index: src/insets/InsetTabular.cpp
===
--- src/insets/InsetTabular.cpp	(Revision 37360)
+++ src/insets/InsetTabular.cpp	(Arbeitskopie)
@@ -2065,9 +2065,9 @@
 //see http://groups.google.com/group/comp.text.tex/browse_thread/thread/af769424a4a0f289#
 if (lang == slovak || lang == czech)
 	os  \\expandafter  (use_booktabs ? \\cmidrule : \\cline) 
-	 \\expandafter{\\expandafter  c + 1 + offset  \\string-;
+	 \\expandafter{\\expandafter  (int) (c + 1 + offset)  \\string-;
 else
-	os  (use_booktabs ? \\cmidrule{ : \\cline{)  c + 1 + offset  '-';
+	os  (use_booktabs ? \\cmidrule{ : \\cline{)  (int) (c + 1 + offset)  '-';
 
 col_type cstart = c;
 for ( ; c  ncols()  topline[c]; ++c) {}
@@ -2076,7 +2076,7 @@
 	if (column_info[j].alignment == LYX_ALIGN_DECIMAL)
 		++offset;
 
-os  c + offset  } ;
+os  (int) (c + offset)  } ;
 			}
 		}
 	}
@@ -2138,9 +2138,9 @@
 //see http://groups.google.com/group/comp.text.tex/browse_thread/thread/af769424a4a0f289#
 if (lang == slovak || lang == czech)
 	os  \\expandafter  (use_booktabs ? \\cmidrule : \\cline)
-	 \\expandafter{\\expandafter  c + 1 + offset  \\string-;
+	 \\expandafter{\\expandafter  (int) (c + 1 + offset)  \\string-;
 else
-	os  (use_booktabs ? \\cmidrule{ : \\cline{)  c + 1 + offset  '-';
+	os  (use_booktabs ? \\cmidrule{ : \\cline{)  (int) (c + 1 + offset)  '-';
 
 col_type cstart = c;
 for ( ; c  ncols()  bottomline[c]; ++c) {}
@@ -2149,7 +2149,7 @@
 	if (column_info[j].alignment == LYX_ALIGN_DECIMAL)
 		++offset;
 
-os  c + offset  } ;
+os  (int) (c + offset)  } ;
 			}
 		}
 	}
@@ -2256,7 +2256,7 @@
 	// we only need code for the first multirow cell
 	ismultirow = isMultiRow(cell);
 	if (ismultirow) {
-		os  \\multirow{  rowSpan(cell)  }{;
+		os  \\multirow{  (int) rowSpan(cell)  }{;
 		if (!getPWidth(cell).zero())
 			os  from_ascii(getPWidth(cell).asLatexString());
 		else


signature.asc
Description: This is a digitally signed message part.

Re: trunk does no compile

[Peter Kümmel]

On 29.01.2011 13:24, Kornel wrote:
 Am Samstag, 29. Januar 2011 schrieb Tommaso Cucinotta:
 insets/InsetTabular.cpp: In member function ‘int 
 lyx::Tabular::TeXTopHLine(lyx::otexstream, size_t, std::string) const’:
 insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator’ 
 in 
 ‘lyx::operator(((lyx::otexstream)((lyx::otexstream*)lyx::operator(((ly
 x::otexstream)((lyx::otexstream*)lyx::operator(((lyx::otexstream)((lyx:
 :otexstream*)os)),  ((const char*)\\expandafter, (((bool)((const
 
 This cured it for me, but I fear it is not the proper c++ patch.
 
   Kornel

Yes, the cast isn't nice. Does attached patch also fix the problem?
If yes, I think you could commit it.

Peter
Index: src/support/docstream.cpp
===
--- src/support/docstream.cpp	(revision 37360)
+++ src/support/docstream.cpp	(working copy)
@@ -537,8 +537,18 @@
 	return ots;
 }
 
+
+otexstream  operator(otexstream  ots, size_t i)
+{
+	ots.os()  i;
+	ots.canBreakLine(true);
+	ots.protectSpace(false);
+	return ots;
 }
 
+
+}
+
 #if ! defined(USE_WCHAR_T)  defined(__GNUC__)
 // We get undefined references to these virtual methods. This looks like
 // a bug in gcc. The implementation here does not do anything useful, since
Index: src/support/docstream.h
===
--- src/support/docstream.h	(revision 37360)
+++ src/support/docstream.h	(working copy)
@@ -152,6 +152,8 @@
 otexstream  operator(otexstream , int);
 ///
 otexstream  operator(otexstream , unsigned int);
+///
+otexstream  operator(otexstream , size_t);
 
 /// Helper struct for changing stream encoding
 struct SetEnc {

Re: trunk does no compile

[Kornel]

Am Samstag, 29. Januar 2011 schrieb Peter Kümmel:
  This cured it for me, but I fear it is not the proper c++ patch.
 
  
 
Kornel
 
 Yes, the cast isn't nice. Does attached patch also fix the problem?
 If yes, I think you could commit it.
 
 Peter

Yes, it compiles now.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: trunk does no compile

[Jose Quesada]

I can confim that trunk doesn't compile for me either:

insets/InsetTabular.cpp:2259: error: ambiguous overload for ‘operator’ in
‘lyx::operator(((lyx::otexstream)((lyx::otexstream*)os)), ((const
char*)\\multirow{))  lyx::Tabular::rowSpan(cell)’
./support/docstream.h:154: note: candidates are: lyx::otexstream
lyx::operator(lyx::otexstream, unsigned int)
./support/docstream.h:152: note: lyx::otexstream
lyx::operator(lyx::otexstream, int)
./support/docstream.h:150: note: lyx::otexstream
lyx::operator(lyx::otexstream, double)
./support/docstream.h:148: note: lyx::otexstream
lyx::operator(lyx::otexstream, char)
./support/docstream.h:146: note: lyx::otexstream
lyx::operator(lyx::otexstream, const char*) near match
./support/docstream.h:144: note: lyx::otexstream
lyx::operator(lyx::otexstream, const lyx::docstring) near match
make[4]: *** [InsetTabular.o] Error 1
make[4]: Leaving directory `/home/quesada/projIfollow/lyx-devel/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/quesada/projIfollow/lyx-devel/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/quesada/projIfollow/lyx-devel/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/quesada/projIfollow/lyx-devel'
make: *** [all] Error 2

sabayon~/projIfollow/lyx-devel ♪ g++ --version
g++ (Gentoo 4.4.4-r2 p1.3, pie-0.4.5) 4.4.4

Best,
-Jose


On Sat, Jan 29, 2011 at 2:23 PM, Kornel kor...@lyx.org wrote:

  Am Samstag, 29. Januar 2011 schrieb Peter Kümmel:

   This cured it for me, but I fear it is not the proper c++ patch.

  

  

  

 Kornel

 

  Yes, the cast isn't nice. Does attached patch also fix the problem?

  If yes, I think you could commit it.

 

  Peter

 Yes, it compiles now.

  Kornel




-- 
Best,
-Jose

Jose Quesada, PhD.
Research scientist,
Max Planck Institute,
Center for Adaptive Behavior and Cognition,
Berlin
http://www.josequesada.name/
http://twitter.com/Quesada

Re: trunk does no compile

[Enrico Forestieri]

On Sat, Jan 29, 2011 at 02:23:04PM +0100, Kornel wrote:

 Am Samstag, 29. Januar 2011 schrieb Peter Kümmel:
   This cured it for me, but I fear it is not the proper c++ patch.
  
   
  
 Kornel
  
  Yes, the cast isn't nice. Does attached patch also fix the problem?
  If yes, I think you could commit it.

Please, don't. It breaks compilation if size_t is typedef'd to unsigned int.

 Yes, it compiles now.

Kornel, does it compile using the attached patch?

-- 
Enrico
Index: src/support/docstream.cpp
===
--- src/support/docstream.cpp	(revisione 37363)
+++ src/support/docstream.cpp	(copia locale)
@@ -537,6 +537,16 @@ otexstream  operator(otexstream  ots
 	return ots;
 }
 
+
+otexstream  operator(otexstream  ots, unsigned long i)
+{
+	ots.os()  i;
+	ots.canBreakLine(true);
+	ots.protectSpace(false);
+	return ots;
+}
+
+
 }
 
 #if ! defined(USE_WCHAR_T)  defined(__GNUC__)
Index: src/support/docstream.h
===
--- src/support/docstream.h	(revisione 37363)
+++ src/support/docstream.h	(copia locale)
@@ -152,6 +152,8 @@ otexstream  operator(otexstream , do
 otexstream  operator(otexstream , int);
 ///
 otexstream  operator(otexstream , unsigned int);
+///
+otexstream  operator(otexstream , unsigned long);
 
 /// Helper struct for changing stream encoding
 struct SetEnc {

Re: trunk does no compile

[Tommaso Cucinotta]

Il 29/01/2011 15:54, Enrico Forestieri ha scritto:


Please, don't. It breaks compilation if size_t is typedef'd to unsigned int.


I can also share my template-based one, that avoids code replication
and actually turns this burden over the odocstream class itself. Assuming
the latter works fine on all architectures, this one should as well :-).

T.

Re: trunk does no compile

[Tommaso Cucinotta]

Il 29/01/2011 17:07, Tommaso Cucinotta ha scritto:

Il 29/01/2011 15:54, Enrico Forestieri ha scritto:


Please, don't. It breaks compilation if size_t is typedef'd to 
unsigned int.



I can also share my template-based one, that avoids code replication
and actually turns this burden over the odocstream class itself. Assuming
the latter works fine on all architectures, this one should as well :-).

Forgot to attach.

T.
Index: src/support/docstream.h
===
--- src/support/docstream.h	(revisione 37365)
+++ src/support/docstream.h	(copia locale)
@@ -147,11 +147,14 @@
 ///
 otexstream  operator(otexstream , char);
 ///
-otexstream  operator(otexstream , double);
-///
-otexstream  operator(otexstream , int);
-///
-otexstream  operator(otexstream , unsigned int);
+template class Type
+otexstream  operator(otexstream  ots, Type value)
+{
+	ots.os()  value;
+	ots.canBreakLine(true);
+	ots.protectSpace(false);
+	return ots;
+}
 
 /// Helper struct for changing stream encoding
 struct SetEnc {
Index: src/support/docstream.cpp
===
--- src/support/docstream.cpp	(revisione 37365)
+++ src/support/docstream.cpp	(copia locale)
@@ -511,34 +511,8 @@
 }
 
 
-otexstream  operator(otexstream  ots, double d)
-{
-	ots.os()  d;
-	ots.canBreakLine(true);
-	ots.protectSpace(false);
-	return ots;
 }
 
-
-otexstream  operator(otexstream  ots, int i)
-{
-	ots.os()  i;
-	ots.canBreakLine(true);
-	ots.protectSpace(false);
-	return ots;
-}
-
-
-otexstream  operator(otexstream  ots, unsigned int i)
-{
-	ots.os()  i;
-	ots.canBreakLine(true);
-	ots.protectSpace(false);
-	return ots;
-}
-
-}
-
 #if ! defined(USE_WCHAR_T)  defined(__GNUC__)
 // We get undefined references to these virtual methods. This looks like
 // a bug in gcc. The implementation here does not do anything useful, since

Re: trunk does no compile

[Tommaso Cucinotta]

Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto:



I can also share my template-based one, that avoids code replication
and actually turns this burden over the odocstream class itself. 
Assuming

the latter works fine on all architectures, this one should as well :-).


Forgot to attach.


just don't even try it: my own brand new automated tests just started to 
fail
because, with that template-ish thing, at the first attempt of typing a 
character

in text-mode LyX was asserting :-).

I'm using the Enrico's patch that works fine (at least on my 64-bit 
machine).


T.

Re: trunk does no compile

[Kornel]

Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri:
   Yes, the cast isn't nice. Does attached patch also fix the problem?
   If yes, I think you could commit it.
 
 Please, don't. It breaks compilation if size_t is typedef'd to unsigned
 int.
 
  Yes, it compiles now.
 
 Kornel, does it compile using the attached patch?

Yes, this compiles too. Sorry for the delay, was outside.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: trunk does no compile

[Tommaso Cucinotta]

Il 29/01/2011 18:37, Kornel ha scritto:


Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri:

   Yes, the cast isn't nice. Does attached patch also fix the problem?

   If yes, I think you could commit it.



 Please, don't. It breaks compilation if size_t is typedef'd to unsigned

 int.



  Yes, it compiles now.



 Kornel, does it compile using the attached patch?

Yes, this compiles too. Sorry for the delay, was outside.

Kornel



Ok, apart from compiling, is it only me who's experience a crash when
typing any character in text mode (seems it was not at all due to my
template-based patch of docstream.h) ?

$ ./src/lyx
/usr/include/c++/4.4/bits/basic_string.h:745: typename 
_Alloc::rebind_CharT::other::reference std::basic_stringChar, Traits, 
Alloc::operator[](typename _Alloc::rebind_CharT::other::size_type) 
[with _CharT = wchar_t, _Traits = std::char_traitswchar_t, _Alloc = 
std::allocatorwchar_t]: Assertion '__pos  size()' failed.

Annullato

T.

Re: trunk does no compile

[Enrico Forestieri]

On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote:

 Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto:
 
 I can also share my template-based one, that avoids code replication
 and actually turns this burden over the odocstream class itself.
 Assuming
 the latter works fine on all architectures, this one should as well :-).
 
 Forgot to attach.
 
 just don't even try it: my own brand new automated tests just started
 to fail because, with that template-ish thing, at the first attempt of
 typing a character in text-mode LyX was asserting :-).
 
 I'm using the Enrico's patch that works fine (at least on my 64-bit
 machine).

Yet, I think your idea is right for avoiding code duplication. Let's see
whether requiring explicit instantiations works. If yes, adding a
forgotten type would only require adding a single-line instantiation
declaration.

So, does the attach patch work for you?

-- 
Enrico
Index: src/support/docstream.cpp
===
--- src/support/docstream.cpp	(revisione 37365)
+++ src/support/docstream.cpp	(copia locale)
@@ -511,31 +511,19 @@ otexstream  operator(otexstream  ots
 }
 
 
-otexstream  operator(otexstream  ots, double d)
+template typename Type
+otexstream  operator(otexstream  ots, Type value)
 {
-	ots.os()  d;
+	ots.os()  value;
 	ots.canBreakLine(true);
 	ots.protectSpace(false);
 	return ots;
 }
 
-
-otexstream  operator(otexstream  ots, int i)
-{
-	ots.os()  i;
-	ots.canBreakLine(true);
-	ots.protectSpace(false);
-	return ots;
-}
-
-
-otexstream  operator(otexstream  ots, unsigned int i)
-{
-	ots.os()  i;
-	ots.canBreakLine(true);
-	ots.protectSpace(false);
-	return ots;
-}
+template otexstream  operator double(otexstream , double);
+template otexstream  operator int(otexstream , int);
+template otexstream  operator unsigned int(otexstream , unsigned int);
+template otexstream  operator unsigned long(otexstream , unsigned long);
 
 }
 
Index: src/support/docstream.h
===
--- src/support/docstream.h	(revisione 37365)
+++ src/support/docstream.h	(copia locale)
@@ -147,11 +147,8 @@ otexstream  operator(otexstream , ch
 ///
 otexstream  operator(otexstream , char);
 ///
-otexstream  operator(otexstream , double);
-///
-otexstream  operator(otexstream , int);
-///
-otexstream  operator(otexstream , unsigned int);
+template typename Type
+otexstream  operator(otexstream  ots, Type value);
 
 /// Helper struct for changing stream encoding
 struct SetEnc {

Re: trunk does no compile

[Enrico Forestieri]

On Sat, Jan 29, 2011 at 06:37:44PM +0100, Kornel wrote:

 Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri:
Yes, the cast isn't nice. Does attached patch also fix the problem?
If yes, I think you could commit it.
  
  Please, don't. It breaks compilation if size_t is typedef'd to unsigned
  int.
  
   Yes, it compiles now.
  
  Kornel, does it compile using the attached patch?
 
 Yes, this compiles too. Sorry for the delay, was outside.

Thanks Kornel. Please, could you also try the other template-based patch
I just posted?

-- 
Enrico

Re: trunk does no compile

[Kornel]

Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri:
  just don't even try it: my own brand new automated tests just started
  to fail because, with that template-ish thing, at the first attempt of
  typing a character in text-mode LyX was asserting :-).
 
  
 
  I'm using the Enrico's patch that works fine (at least on my 64-bit
  machine).
 
 Yet, I think your idea is right for avoiding code duplication. Let's see
 whether requiring explicit instantiations works. If yes, adding a
 forgotten type would only require adding a single-line instantiation
 declaration.
 
 So, does the attach patch work for you?


overload-2.diff:

Compiles fine too.

Tommaso:
 Ok, apart from compiling, is it only me who's experience a crash when
 typing any character in text mode (seems it was not at all due to my
 template-based patch of docstream.h) ?

I don't get it. You mean TeX-mode? Cannot see any crash here.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: trunk does no compile

[Stephan Witt]

Am 29.01.2011 um 19:12 schrieb Enrico Forestieri:

 On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote:
 
 Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto:
 
 I can also share my template-based one, that avoids code replication
 and actually turns this burden over the odocstream class itself.
 Assuming
 the latter works fine on all architectures, this one should as well :-).
 
 Forgot to attach.
 
 just don't even try it: my own brand new automated tests just started
 to fail because, with that template-ish thing, at the first attempt of
 typing a character in text-mode LyX was asserting :-).
 
 I'm using the Enrico's patch that works fine (at least on my 64-bit
 machine).
 
 Yet, I think your idea is right for avoiding code duplication. Let's see
 whether requiring explicit instantiations works. If yes, adding a
 forgotten type would only require adding a single-line instantiation
 declaration.
 
 So, does the attach patch work for you?

This patch works here too (32 bit on Mac).

Stephan

Re: trunk does no compile

[Enrico Forestieri]

On Sat, Jan 29, 2011 at 08:06:37PM +0100, Stephan Witt wrote:

 Am 29.01.2011 um 19:12 schrieb Enrico Forestieri:
 
  On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote:
  
  Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto:
  
  I can also share my template-based one, that avoids code replication
  and actually turns this burden over the odocstream class itself.
  Assuming
  the latter works fine on all architectures, this one should as well :-).
  
  Forgot to attach.
  
  just don't even try it: my own brand new automated tests just started
  to fail because, with that template-ish thing, at the first attempt of
  typing a character in text-mode LyX was asserting :-).
  
  I'm using the Enrico's patch that works fine (at least on my 64-bit
  machine).
  
  Yet, I think your idea is right for avoiding code duplication. Let's see
  whether requiring explicit instantiations works. If yes, adding a
  forgotten type would only require adding a single-line instantiation
  declaration.
  
  So, does the attach patch work for you?
 
 This patch works here too (32 bit on Mac).

Committed, then.

-- 
Enrico

Re: trunk does no compile

[Enrico Forestieri]

On Sat, Jan 29, 2011 at 07:39:19PM +0100, Kornel wrote:

 overload-2.diff:
 
 Compiles fine too.

Thanks for testing.

 Tommaso:
  Ok, apart from compiling, is it only me who's experience a crash when
  typing any character in text mode (seems it was not at all due to my
  template-based patch of docstream.h) ?
 
 I don't get it. You mean TeX-mode? Cannot see any crash here.

Same here.

-- 
Enrico

Re: trunk does no compile

[Guillaume Pothier]

On 29 January 2011 16:49, Enrico Forestieri for...@lyx.org wrote:
 On Sat, Jan 29, 2011 at 07:39:19PM +0100, Kornel wrote:

 Tommaso:
  Ok, apart from compiling, is it only me who's experience a crash when
  typing any character in text mode (seems it was not at all due to my
  template-based patch of docstream.h) ?

 I don't get it. You mean TeX-mode? Cannot see any crash here.

 Same here.

I'm getting the crash when loading a file:
/usr/include/c++/4.4/bits/basic_string.h:745: typename
_Alloc::rebind_CharT::other::reference std::basic_stringChar,
Traits, Alloc::operator[](typename
_Alloc::rebind_CharT::other::size_type) [with _CharT = wchar_t,
_Traits = std::char_traitswchar_t, _Alloc =
std::allocatorwchar_t]: Assertion '__pos  size()' failed.

Cheers,
g



 --
 Enrico

Re: trunk does no compile

[Kornel]

Am Samstag, 29. Januar 2011 schrieb Guillaume Pothier:
  I don't get it. You mean TeX-mode? Cannot see any crash here.
  
  Same here.
 
 I'm getting the crash when loading a file:

Not here. Insert-File-Plain Text... is ok, and so is ...-Plain Text, Join 
Lines

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: trunk does no compile

[Tommaso Cucinotta]

Il 29/01/2011 19:12, Enrico Forestieri ha scritto:

just don't even try it: my own brand new automated tests just started
to fail because, with that template-ish thing, at the first attempt of
typing a character in text-mode LyX was asserting :-).

I'm using the Enrico's patch that works fine (at least on my 64-bit
machine).

Yet, I think your idea is right for avoiding code duplication. Let's see
whether requiring explicit instantiations works. If yes, adding a
forgotten type would only require adding a single-line instantiation
declaration.

So, does the attach patch work for you?


If it is the same currently committed, then it is sufficient to:
-) create a new file
-) type any letter and kaboom!

(gdb) run
Starting program: /home/tommaso/lyx-trunk-ws/lyx-devel/src/lyx
[Thread debugging using libthread_db enabled]
[New Thread 0x704a3700 (LWP 7933)]
GuiToolbar.cpp(335): Session settings could not be found!. Defaults are 
used instead
/usr/include/c++/4.4/bits/basic_string.h:745: typename 
_Alloc::rebind_CharT::other::reference std::basic_stringChar, Traits, 
Alloc::operator[](typename _Alloc::rebind_CharT::other::size_type) 
[with _CharT = wchar_t, _Traits = std::char_traitswchar_t, _Alloc = 
std::allocatorwchar_t]: Assertion '__pos  size()' failed.


Program received signal SIGABRT, Aborted.
0x75f51ba5 in raise () from /lib/libc.so.6

(gdb) bt
#0  0x75f51ba5 in raise () from /lib/libc.so.6
#1  0x75f556b0 in abort () from /lib/libc.so.6
#2  0x0062c62a in __replacement_assert (this=0x1b6bb68, __pos=1) 
at /usr/include/c++/4.4/x86_64-linux-gnu/bits/c++config.h:284
#3  std::basic_stringwchar_t, std::char_traitswchar_t, 
std::allocatorwchar_t ::operator[] (this=0x1b6bb68, __pos=1) at 
/usr/include/c++/4.4/bits/basic_string.h:745
#4  0x006165de in lyx::Paragraph::isWordSeparator 
(this=0x1b6b000, pos=1) at Paragraph.cpp:2850
#5  0x00619035 in lyx::Paragraph::isMisspelled (this=0x1b6b000, 
pos=1, check_boundary=true) at Paragraph.cpp:3769
#6  0x006786f9 in lyx::Text::dispatch (this=value optimized 
out, cur=..., cmd=value optimized out) at Text3.cpp:2195
#7  0x00985217 in lyx::InsetText::doDispatch (this=0x1b6b5a0, 
cur=..., cmd=...) at insets/InsetText.cpp:290
#8  0x00870cf1 in lyx::Inset::dispatch (this=0x1b6b5a0, cur=..., 
cmd=...) at insets/Inset.cpp:315
#9  0x0071af19 in lyx::Cursor::dispatch (this=0x1b78b78, 
cmd0=...) at Cursor.cpp:370
#10 0x009f1b84 in lyx::frontend::GuiView::dispatchToBufferView 
(this=0x180c940, cmd=..., dr=...) at GuiView.cpp:3029
#11 0x00a0c816 in lyx::frontend::GuiView::dispatch 
(this=0x180c940, cmd=..., dr=...) at GuiView.cpp:3508
#12 0x009cd979 in lyx::frontend::GuiApplication::dispatch 
(this=0x12a1f10, cmd=..., dr=...) at GuiApplication.cpp:1679
#13 0x009c835c in lyx::frontend::GuiApplication::dispatch 
(this=0x12a1f10, cmd=...) at GuiApplication.cpp:1139

#14 0x005b89dd in lyx::dispatch (action=...) at LyX.cpp:1280
#15 0x009c0802 in 
lyx::frontend::GuiApplication::processFuncRequest (this=value optimized 
out, func=...) at GuiApplication.cpp:1815
#16 0x009c74f2 in lyx::frontend::GuiApplication::processKeySym 
(this=0x12a1f10, keysym=..., state=lyx::NoModifier) at 
GuiApplication.cpp:1805
#17 0x00a1be7f in lyx::frontend::GuiWorkArea::processKeySym 
(this=0x1b6e990, key=..., mod=lyx::NoModifier) at GuiWorkArea.cpp:489
#18 0x00a1f490 in lyx::frontend::GuiWorkArea::keyPressEvent 
(this=0x1b6e990, ev=0x7fff9730) at GuiWorkArea.cpp:1011
#19 0x770e9cfa in QWidget::event (this=0x1b6e990, 
event=0x7fff9730) at kernel/qwidget.cpp:8222
#20 0x774b55e6 in QFrame::event (this=0x1b6e990, 
e=0x7fff9730) at widgets/qframe.cpp:557
#21 0x7754371b in QAbstractScrollArea::event (this=0x1b6e990, 
e=0x7fff9730) at widgets/qabstractscrollarea.cpp:996
#22 0x00a1c3fe in lyx::frontend::GuiWorkArea::event 
(this=0x1b6e990, e=0x1efa) at GuiWorkArea.cpp:692
#23 0x77093fdc in QApplicationPrivate::notify_helper 
(this=0x12a9790, receiver=0x1b6e990, e=0x7fff9730) at 
kernel/qapplication.cpp:4396
#24 0x7709b346 in QApplication::notify (this=value optimized 
out, receiver=0x1b6e990, e=0x7fff9730) at kernel/qapplication.cpp:3857
#25 0x009c27ad in lyx::frontend::GuiApplication::notify 
(this=0x1efa, receiver=0x1efa, event=0x6) at GuiApplication.cpp:2193
#26 0x76ba8cdc in QCoreApplication::notifyInternal 
(this=0x12a1f10, receiver=0x1b6e990, event=0x7fff9730) at 
kernel/qcoreapplication.cpp:732
#27 0x771414ba in QKeyMapper::sendKeyEvent (keyWidget=0x1b6e990, 
grab=value optimized out, type=QEvent::KeyPress, code=65, 
modifiers=value optimized out,
text=..., autorepeat=false, count=1, nativeScanCode=38, 
nativeVirtualKey=97, nativeModifiers=16) at kernel/qkeymapper_x11.cpp:1867
#28 0x77143ac0 in QKeyMapperPrivate::translateKeyEvent 

Re: trunk does no compile

[Tommaso Cucinotta]

Il 30/01/2011 01:28, Tommaso Cucinotta ha scritto:


If it is the same currently committed, then it is sufficient to:
-) create a new file
-) type any letter and kaboom!


So, on my system, I need the patch below in order to be able to use LyX 
trunk again (r37368):


Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp(revisione 37368)
+++ src/Paragraph.cpp(copia locale)
@@ -3765,6 +3765,9 @@

 bool Paragraph::isMisspelled(pos_type pos, bool check_boundary) const
 {
+LASSERT(pos =0  pos = size(), /**/);
+if (pos == size())
+return false;
 bool result = 
SpellChecker::misspelled(d-speller_state_.getState(pos));

 if (!result  check_boundary  pos  0  isWordSeparator(pos))
 result = 
SpellChecker::misspelled(d-speller_state_.getState(pos - 1));


I suspect this only masquerades/protects from some bug in the real-time 
spellchecker code, but without it my LyX (trunk) becomes nearly unusable.


T.

Re: trunk does no compile

[Enrico Forestieri]

On Sun, Jan 30, 2011 at 01:28:49AM +0100, Tommaso Cucinotta wrote:

 Il 29/01/2011 19:12, Enrico Forestieri ha scritto:
 just don't even try it: my own brand new automated tests just started
 to fail because, with that template-ish thing, at the first attempt of
 typing a character in text-mode LyX was asserting :-).
 
 I'm using the Enrico's patch that works fine (at least on my 64-bit
 machine).
 Yet, I think your idea is right for avoiding code duplication. Let's see
 whether requiring explicit instantiations works. If yes, adding a
 forgotten type would only require adding a single-line instantiation
 declaration.
 
 So, does the attach patch work for you?
 
 If it is the same currently committed, then it is sufficient to:
 -) create a new file
 -) type any letter and kaboom!

From the backtrace, it is clear that the assertion is unrelated to the
otexstream class and that it only occurs when continuous spell checking
is active. The culprit here is r37363.

Specifically, the assertion is triggered by the following line

char_type const c = d-text_[pos];

in Paragraph::isWordSeparator(). Seemingly, pos points to the position
immediately after the last character in d-text_.

-- 
Enrico

Re: trunk does no compile

[Stephan Witt]

Am 30.01.2011 um 02:23 schrieb Enrico Forestieri:

 On Sun, Jan 30, 2011 at 01:28:49AM +0100, Tommaso Cucinotta wrote:
 
 Il 29/01/2011 19:12, Enrico Forestieri ha scritto:
 just don't even try it: my own brand new automated tests just started
 to fail because, with that template-ish thing, at the first attempt of
 typing a character in text-mode LyX was asserting :-).
 
 I'm using the Enrico's patch that works fine (at least on my 64-bit
 machine).
 Yet, I think your idea is right for avoiding code duplication. Let's see
 whether requiring explicit instantiations works. If yes, adding a
 forgotten type would only require adding a single-line instantiation
 declaration.
 
 So, does the attach patch work for you?
 
 If it is the same currently committed, then it is sufficient to:
 -) create a new file
 -) type any letter and kaboom!
 
 From the backtrace, it is clear that the assertion is unrelated to the
 otexstream class and that it only occurs when continuous spell checking
 is active. The culprit here is r37363.
 
 Specifically, the assertion is triggered by the following line
 
char_type const c = d-text_[pos];
 
 in Paragraph::isWordSeparator(). Seemingly, pos points to the position
 immediately after the last character in d-text_.

Sorry, I was mislead by the test pos == size() at the end of isWordSeparator().
Obviously the author of that test function wants to return true
for end-of-paragraph. But the test for it should come first.

I did an explicitly test of that scenario and it did not crash here.
But it seems I didn't enable the array bounds checker :(

I fixed that with r37369.

Stephan

trunk does no compile

[Tommaso Cucinotta]

As in the subject:

insets/InsetTabular.cpp: In member function ‘int 
lyx::Tabular::TeXTopHLine(lyx::otexstream&, size_t, std::string) const’:
insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator<<’ 
in 
‘lyx::operator<<(((lyx::otexstream&)((lyx::otexstream*)lyx::operator<<(((lyx::otexstream&)((lyx::otexstream*)lyx::operator<<(((lyx::otexstream&)((lyx::otexstream*)os)), 
((const char*)"\\expandafter", (((bool)((const 
lyx::Tabular*)this)->lyx::Tabular::use_booktabs) ? ((const 
char*)"\\cmidrule") : ((const char*)"\\cline"), ((const 
char*)"\\expandafter{\\expandafter")) << ((c + offset) + 1u)’
./support/docstream.h:154: note: candidates are: lyx::otexstream& 
lyx::operator<<(lyx::otexstream&, unsigned int)
./support/docstream.h:152: note: lyx::otexstream& 
lyx::operator<<(lyx::otexstream&, int)
./support/docstream.h:150: note: lyx::otexstream& 
lyx::operator<<(lyx::otexstream&, double)
./support/docstream.h:148: note: lyx::otexstream& 
lyx::operator<<(lyx::otexstream&, char)
./support/docstream.h:146: note: lyx::otexstream& 
lyx::operator<<(lyx::otexstream&, const char*) 
./support/docstream.h:144: note: lyx::otexstream& 
lyx::operator<<(lyx::otexstream&, const lyx::docstring&) 


$ g++ --version
g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5

T.

Re: trunk does no compile

[Kornel]

Am Samstag, 29. Januar 2011 schrieb Tommaso Cucinotta:
> insets/InsetTabular.cpp: In member function ‘int 
> lyx::Tabular::TeXTopHLine(lyx::otexstream&, size_t, std::string) const’:
> insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator<<’ 
> in 
> ‘lyx::operator<<(((lyx::otexstream&)((lyx::otexstream*)lyx::operator<<(((ly
> x::otexstream&)((lyx::otexstream*)lyx::operator<<(((lyx::otexstream&)((lyx:
> :otexstream*)os)),  ((const char*)"\\expandafter", (((bool)((const

This cured it for me, but I fear it is not the proper c++ patch.

Kornel
Index: src/insets/InsetTabular.cpp
===
--- src/insets/InsetTabular.cpp	(Revision 37360)
+++ src/insets/InsetTabular.cpp	(Arbeitskopie)
@@ -2065,9 +2065,9 @@
 //see http://groups.google.com/group/comp.text.tex/browse_thread/thread/af769424a4a0f289#
 if (lang == "slovak" || lang == "czech")
 	os << "\\expandafter" << (use_booktabs ? "\\cmidrule" : "\\cline") 
-	<< "\\expandafter{\\expandafter" << c + 1 + offset << "\\string-";
+	<< "\\expandafter{\\expandafter" << (int) (c + 1 + offset) << "\\string-";
 else
-	os << (use_booktabs ? "\\cmidrule{" : "\\cline{") << c + 1 + offset << '-';
+	os << (use_booktabs ? "\\cmidrule{" : "\\cline{") << (int) (c + 1 + offset) << '-';
 
 col_type cstart = c;
 for ( ; c < ncols() && topline[c]; ++c) {}
@@ -2076,7 +2076,7 @@
 	if (column_info[j].alignment == LYX_ALIGN_DECIMAL)
 		++offset;
 
-os << c + offset << "} ";
+os << (int) (c + offset) << "} ";
 			}
 		}
 	}
@@ -2138,9 +2138,9 @@
 //see http://groups.google.com/group/comp.text.tex/browse_thread/thread/af769424a4a0f289#
 if (lang == "slovak" || lang == "czech")
 	os << "\\expandafter" << (use_booktabs ? "\\cmidrule" : "\\cline")
-	<< "\\expandafter{\\expandafter" << c + 1 + offset << "\\string-";
+	<< "\\expandafter{\\expandafter" << (int) (c + 1 + offset) << "\\string-";
 else
-	os << (use_booktabs ? "\\cmidrule{" : "\\cline{") << c + 1 + offset << '-';
+	os << (use_booktabs ? "\\cmidrule{" : "\\cline{") << (int) (c + 1 + offset) << '-';
 
 col_type cstart = c;
 for ( ; c < ncols() && bottomline[c]; ++c) {}
@@ -2149,7 +2149,7 @@
 	if (column_info[j].alignment == LYX_ALIGN_DECIMAL)
 		++offset;
 
-os << c + offset << "} ";
+os << (int) (c + offset) << "} ";
 			}
 		}
 	}
@@ -2256,7 +2256,7 @@
 	// we only need code for the first multirow cell
 	ismultirow = isMultiRow(cell);
 	if (ismultirow) {
-		os << "\\multirow{" << rowSpan(cell) << "}{";
+		os << "\\multirow{" << (int) rowSpan(cell) << "}{";
 		if (!getPWidth(cell).zero())
 			os << from_ascii(getPWidth(cell).asLatexString());
 		else


signature.asc
Description: This is a digitally signed message part.

Re: trunk does no compile

[Peter Kümmel]

On 29.01.2011 13:24, Kornel wrote:
> Am Samstag, 29. Januar 2011 schrieb Tommaso Cucinotta:
>> insets/InsetTabular.cpp: In member function ‘int 
>> lyx::Tabular::TeXTopHLine(lyx::otexstream&, size_t, std::string) const’:
>> insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator<<’ 
>> in 
>> ‘lyx::operator<<(((lyx::otexstream&)((lyx::otexstream*)lyx::operator<<(((ly
>> x::otexstream&)((lyx::otexstream*)lyx::operator<<(((lyx::otexstream&)((lyx:
>> :otexstream*)os)),  ((const char*)"\\expandafter", (((bool)((const
> 
> This cured it for me, but I fear it is not the proper c++ patch.
> 
>   Kornel

Yes, the cast isn't nice. Does attached patch also fix the problem?
If yes, I think you could commit it.

Peter
Index: src/support/docstream.cpp
===
--- src/support/docstream.cpp	(revision 37360)
+++ src/support/docstream.cpp	(working copy)
@@ -537,8 +537,18 @@
 	return ots;
 }
 
+
+otexstream & operator<<(otexstream & ots, size_t i)
+{
+	ots.os() << i;
+	ots.canBreakLine(true);
+	ots.protectSpace(false);
+	return ots;
 }
 
+
+}
+
 #if ! defined(USE_WCHAR_T) && defined(__GNUC__)
 // We get undefined references to these virtual methods. This looks like
 // a bug in gcc. The implementation here does not do anything useful, since
Index: src/support/docstream.h
===
--- src/support/docstream.h	(revision 37360)
+++ src/support/docstream.h	(working copy)
@@ -152,6 +152,8 @@
 otexstream & operator<<(otexstream &, int);
 ///
 otexstream & operator<<(otexstream &, unsigned int);
+///
+otexstream & operator<<(otexstream &, size_t);
 
 /// Helper struct for changing stream encoding
 struct SetEnc {

Re: trunk does no compile

[Kornel]

Am Samstag, 29. Januar 2011 schrieb Peter Kümmel:
> > This cured it for me, but I fear it is not the proper c++ patch.
> >
> > 
> >
> >   Kornel
> 
> Yes, the cast isn't nice. Does attached patch also fix the problem?
> If yes, I think you could commit it.
> 
> Peter

Yes, it compiles now.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: trunk does no compile

[Jose Quesada]

I can confim that trunk doesn't compile for me either:

insets/InsetTabular.cpp:2259: error: ambiguous overload for ‘operator<<’ in
‘lyx::operator<<(((lyx::otexstream&)((lyx::otexstream*)os)), ((const
char*)"\\multirow{")) << lyx::Tabular::rowSpan(cell)’
./support/docstream.h:154: note: candidates are: lyx::otexstream&
lyx::operator<<(lyx::otexstream&, unsigned int)
./support/docstream.h:152: note: lyx::otexstream&
lyx::operator<<(lyx::otexstream&, int)
./support/docstream.h:150: note: lyx::otexstream&
lyx::operator<<(lyx::otexstream&, double)
./support/docstream.h:148: note: lyx::otexstream&
lyx::operator<<(lyx::otexstream&, char)
./support/docstream.h:146: note: lyx::otexstream&
lyx::operator<<(lyx::otexstream&, const char*) 
./support/docstream.h:144: note: lyx::otexstream&
lyx::operator<<(lyx::otexstream&, const lyx::docstring&) 
make[4]: *** [InsetTabular.o] Error 1
make[4]: Leaving directory `/home/quesada/projIfollow/lyx-devel/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/quesada/projIfollow/lyx-devel/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/quesada/projIfollow/lyx-devel/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/quesada/projIfollow/lyx-devel'
make: *** [all] Error 2

sabayon~/projIfollow/lyx-devel ♪ g++ --version
g++ (Gentoo 4.4.4-r2 p1.3, pie-0.4.5) 4.4.4

Best,
-Jose


On Sat, Jan 29, 2011 at 2:23 PM, Kornel  wrote:

>  Am Samstag, 29. Januar 2011 schrieb Peter Kümmel:
>
> > > This cured it for me, but I fear it is not the proper c++ patch.
>
> > >
>
> > >
>
> > >
>
> > >   Kornel
>
> >
>
> > Yes, the cast isn't nice. Does attached patch also fix the problem?
>
> > If yes, I think you could commit it.
>
> >
>
> > Peter
>
> Yes, it compiles now.
>
>  Kornel
>
>


-- 
Best,
-Jose

Jose Quesada, PhD.
Research scientist,
Max Planck Institute,
Center for Adaptive Behavior and Cognition,
Berlin
http://www.josequesada.name/
http://twitter.com/Quesada

Re: trunk does no compile

[Enrico Forestieri]

On Sat, Jan 29, 2011 at 02:23:04PM +0100, Kornel wrote:

> Am Samstag, 29. Januar 2011 schrieb Peter Kümmel:
> > > This cured it for me, but I fear it is not the proper c++ patch.
> > >
> > > 
> > >
> > >   Kornel
> > 
> > Yes, the cast isn't nice. Does attached patch also fix the problem?
> > If yes, I think you could commit it.

Please, don't. It breaks compilation if size_t is typedef'd to unsigned int.

> Yes, it compiles now.

Kornel, does it compile using the attached patch?

-- 
Enrico
Index: src/support/docstream.cpp
===
--- src/support/docstream.cpp	(revisione 37363)
+++ src/support/docstream.cpp	(copia locale)
@@ -537,6 +537,16 @@ otexstream & operator<<(otexstream & ots
 	return ots;
 }
 
+
+otexstream & operator<<(otexstream & ots, unsigned long i)
+{
+	ots.os() << i;
+	ots.canBreakLine(true);
+	ots.protectSpace(false);
+	return ots;
+}
+
+
 }
 
 #if ! defined(USE_WCHAR_T) && defined(__GNUC__)
Index: src/support/docstream.h
===
--- src/support/docstream.h	(revisione 37363)
+++ src/support/docstream.h	(copia locale)
@@ -152,6 +152,8 @@ otexstream & operator<<(otexstream &, do
 otexstream & operator<<(otexstream &, int);
 ///
 otexstream & operator<<(otexstream &, unsigned int);
+///
+otexstream & operator<<(otexstream &, unsigned long);
 
 /// Helper struct for changing stream encoding
 struct SetEnc {

Re: trunk does no compile

[Tommaso Cucinotta]

Il 29/01/2011 15:54, Enrico Forestieri ha scritto:


Please, don't. It breaks compilation if size_t is typedef'd to unsigned int.


I can also share my template-based one, that avoids code replication
and actually turns this burden over the odocstream class itself. Assuming
the latter works fine on all architectures, this one should as well :-).

T.

Re: trunk does no compile

[Tommaso Cucinotta]

Il 29/01/2011 17:07, Tommaso Cucinotta ha scritto:

Il 29/01/2011 15:54, Enrico Forestieri ha scritto:


Please, don't. It breaks compilation if size_t is typedef'd to 
unsigned int.



I can also share my template-based one, that avoids code replication
and actually turns this burden over the odocstream class itself. Assuming
the latter works fine on all architectures, this one should as well :-).

Forgot to attach.

T.
Index: src/support/docstream.h
===
--- src/support/docstream.h	(revisione 37365)
+++ src/support/docstream.h	(copia locale)
@@ -147,11 +147,14 @@
 ///
 otexstream & operator<<(otexstream &, char);
 ///
-otexstream & operator<<(otexstream &, double);
-///
-otexstream & operator<<(otexstream &, int);
-///
-otexstream & operator<<(otexstream &, unsigned int);
+template 
+otexstream & operator<<(otexstream & ots, Type value)
+{
+	ots.os() << value;
+	ots.canBreakLine(true);
+	ots.protectSpace(false);
+	return ots;
+}
 
 /// Helper struct for changing stream encoding
 struct SetEnc {
Index: src/support/docstream.cpp
===
--- src/support/docstream.cpp	(revisione 37365)
+++ src/support/docstream.cpp	(copia locale)
@@ -511,34 +511,8 @@
 }
 
 
-otexstream & operator<<(otexstream & ots, double d)
-{
-	ots.os() << d;
-	ots.canBreakLine(true);
-	ots.protectSpace(false);
-	return ots;
 }
 
-
-otexstream & operator<<(otexstream & ots, int i)
-{
-	ots.os() << i;
-	ots.canBreakLine(true);
-	ots.protectSpace(false);
-	return ots;
-}
-
-
-otexstream & operator<<(otexstream & ots, unsigned int i)
-{
-	ots.os() << i;
-	ots.canBreakLine(true);
-	ots.protectSpace(false);
-	return ots;
-}
-
-}
-
 #if ! defined(USE_WCHAR_T) && defined(__GNUC__)
 // We get undefined references to these virtual methods. This looks like
 // a bug in gcc. The implementation here does not do anything useful, since

Re: trunk does no compile

[Tommaso Cucinotta]

Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto:



I can also share my template-based one, that avoids code replication
and actually turns this burden over the odocstream class itself. 
Assuming

the latter works fine on all architectures, this one should as well :-).


Forgot to attach.


just don't even try it: my own brand new automated tests just started to 
fail
because, with that template-ish thing, at the first attempt of typing a 
character

in text-mode LyX was asserting :-).

I'm using the Enrico's patch that works fine (at least on my 64-bit 
machine).


T.

Re: trunk does no compile

[Kornel]

Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri:
> > > Yes, the cast isn't nice. Does attached patch also fix the problem?
> > > If yes, I think you could commit it.
> 
> Please, don't. It breaks compilation if size_t is typedef'd to unsigned
> int.
> 
> > Yes, it compiles now.
> 
> Kornel, does it compile using the attached patch?

Yes, this compiles too. Sorry for the delay, was outside.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: trunk does no compile

[Tommaso Cucinotta]

Il 29/01/2011 18:37, Kornel ha scritto:


Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri:

> > > Yes, the cast isn't nice. Does attached patch also fix the problem?

> > > If yes, I think you could commit it.

>

> Please, don't. It breaks compilation if size_t is typedef'd to unsigned

> int.

>

> > Yes, it compiles now.

>

> Kornel, does it compile using the attached patch?

Yes, this compiles too. Sorry for the delay, was outside.

Kornel



Ok, apart from compiling, is it only me who's experience a crash when
typing any character in text mode (seems it was not at all due to my
template-based patch of docstream.h) ?

$ ./src/lyx
/usr/include/c++/4.4/bits/basic_string.h:745: typename 
_Alloc::rebind<_CharT>::other::reference std::basic_string::operator[](typename _Alloc::rebind<_CharT>::other::size_type) 
[with _CharT = wchar_t, _Traits = std::char_traits, _Alloc = 
std::allocator]: Assertion '__pos < size()' failed.

Annullato

T.

Re: trunk does no compile

[Enrico Forestieri]

On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote:

> Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto:
> >
> >>I can also share my template-based one, that avoids code replication
> >>and actually turns this burden over the odocstream class itself.
> >>Assuming
> >>the latter works fine on all architectures, this one should as well :-).
> >
> >Forgot to attach.
> 
> just don't even try it: my own brand new automated tests just started
> to fail because, with that template-ish thing, at the first attempt of
> typing a character in text-mode LyX was asserting :-).
> 
> I'm using the Enrico's patch that works fine (at least on my 64-bit
> machine).

Yet, I think your idea is right for avoiding code duplication. Let's see
whether requiring explicit instantiations works. If yes, adding a
forgotten type would only require adding a single-line instantiation
declaration.

So, does the attach patch work for you?

-- 
Enrico
Index: src/support/docstream.cpp
===
--- src/support/docstream.cpp	(revisione 37365)
+++ src/support/docstream.cpp	(copia locale)
@@ -511,31 +511,19 @@ otexstream & operator<<(otexstream & ots
 }
 
 
-otexstream & operator<<(otexstream & ots, double d)
+template 
+otexstream & operator<<(otexstream & ots, Type value)
 {
-	ots.os() << d;
+	ots.os() << value;
 	ots.canBreakLine(true);
 	ots.protectSpace(false);
 	return ots;
 }
 
-
-otexstream & operator<<(otexstream & ots, int i)
-{
-	ots.os() << i;
-	ots.canBreakLine(true);
-	ots.protectSpace(false);
-	return ots;
-}
-
-
-otexstream & operator<<(otexstream & ots, unsigned int i)
-{
-	ots.os() << i;
-	ots.canBreakLine(true);
-	ots.protectSpace(false);
-	return ots;
-}
+template otexstream & operator<< (otexstream &, double);
+template otexstream & operator<< (otexstream &, int);
+template otexstream & operator<< (otexstream &, unsigned int);
+template otexstream & operator<< (otexstream &, unsigned long);
 
 }
 
Index: src/support/docstream.h
===
--- src/support/docstream.h	(revisione 37365)
+++ src/support/docstream.h	(copia locale)
@@ -147,11 +147,8 @@ otexstream & operator<<(otexstream &, ch
 ///
 otexstream & operator<<(otexstream &, char);
 ///
-otexstream & operator<<(otexstream &, double);
-///
-otexstream & operator<<(otexstream &, int);
-///
-otexstream & operator<<(otexstream &, unsigned int);
+template 
+otexstream & operator<<(otexstream & ots, Type value);
 
 /// Helper struct for changing stream encoding
 struct SetEnc {

Re: trunk does no compile

[Enrico Forestieri]

On Sat, Jan 29, 2011 at 06:37:44PM +0100, Kornel wrote:

> Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri:
> > > > Yes, the cast isn't nice. Does attached patch also fix the problem?
> > > > If yes, I think you could commit it.
> > 
> > Please, don't. It breaks compilation if size_t is typedef'd to unsigned
> > int.
> > 
> > > Yes, it compiles now.
> > 
> > Kornel, does it compile using the attached patch?
> 
> Yes, this compiles too. Sorry for the delay, was outside.

Thanks Kornel. Please, could you also try the other template-based patch
I just posted?

-- 
Enrico

Re: trunk does no compile

[Kornel]

Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri:
> > just don't even try it: my own brand new automated tests just started
> > to fail because, with that template-ish thing, at the first attempt of
> > typing a character in text-mode LyX was asserting :-).
> >
> > 
> >
> > I'm using the Enrico's patch that works fine (at least on my 64-bit
> > machine).
> 
> Yet, I think your idea is right for avoiding code duplication. Let's see
> whether requiring explicit instantiations works. If yes, adding a
> forgotten type would only require adding a single-line instantiation
> declaration.
> 
> So, does the attach patch work for you?


overload-2.diff:

Compiles fine too.

Tommaso:
> Ok, apart from compiling, is it only me who's experience a crash when
> typing any character in text mode (seems it was not at all due to my
> template-based patch of docstream.h) ?

I don't get it. You mean TeX-mode? Cannot see any crash here.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: trunk does no compile

[Stephan Witt]

Am 29.01.2011 um 19:12 schrieb Enrico Forestieri:

> On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote:
> 
>> Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto:
>>> 
 I can also share my template-based one, that avoids code replication
 and actually turns this burden over the odocstream class itself.
 Assuming
 the latter works fine on all architectures, this one should as well :-).
>>> 
>>> Forgot to attach.
>> 
>> just don't even try it: my own brand new automated tests just started
>> to fail because, with that template-ish thing, at the first attempt of
>> typing a character in text-mode LyX was asserting :-).
>> 
>> I'm using the Enrico's patch that works fine (at least on my 64-bit
>> machine).
> 
> Yet, I think your idea is right for avoiding code duplication. Let's see
> whether requiring explicit instantiations works. If yes, adding a
> forgotten type would only require adding a single-line instantiation
> declaration.
> 
> So, does the attach patch work for you?

This patch works here too (32 bit on Mac).

Stephan

Re: trunk does no compile

[Enrico Forestieri]

On Sat, Jan 29, 2011 at 08:06:37PM +0100, Stephan Witt wrote:

> Am 29.01.2011 um 19:12 schrieb Enrico Forestieri:
> 
> > On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote:
> > 
> >> Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto:
> >>> 
>  I can also share my template-based one, that avoids code replication
>  and actually turns this burden over the odocstream class itself.
>  Assuming
>  the latter works fine on all architectures, this one should as well :-).
> >>> 
> >>> Forgot to attach.
> >> 
> >> just don't even try it: my own brand new automated tests just started
> >> to fail because, with that template-ish thing, at the first attempt of
> >> typing a character in text-mode LyX was asserting :-).
> >> 
> >> I'm using the Enrico's patch that works fine (at least on my 64-bit
> >> machine).
> > 
> > Yet, I think your idea is right for avoiding code duplication. Let's see
> > whether requiring explicit instantiations works. If yes, adding a
> > forgotten type would only require adding a single-line instantiation
> > declaration.
> > 
> > So, does the attach patch work for you?
> 
> This patch works here too (32 bit on Mac).

Committed, then.

-- 
Enrico

Re: trunk does no compile

[Enrico Forestieri]

On Sat, Jan 29, 2011 at 07:39:19PM +0100, Kornel wrote:

> overload-2.diff:
> 
> Compiles fine too.

Thanks for testing.

> Tommaso:
> > Ok, apart from compiling, is it only me who's experience a crash when
> > typing any character in text mode (seems it was not at all due to my
> > template-based patch of docstream.h) ?
> 
> I don't get it. You mean TeX-mode? Cannot see any crash here.

Same here.

-- 
Enrico

Re: trunk does no compile

[Guillaume Pothier]

On 29 January 2011 16:49, Enrico Forestieri  wrote:
> On Sat, Jan 29, 2011 at 07:39:19PM +0100, Kornel wrote:
>
>> Tommaso:
>> > Ok, apart from compiling, is it only me who's experience a crash when
>> > typing any character in text mode (seems it was not at all due to my
>> > template-based patch of docstream.h) ?
>>
>> I don't get it. You mean TeX-mode? Cannot see any crash here.
>
> Same here.

I'm getting the crash when loading a file:
/usr/include/c++/4.4/bits/basic_string.h:745: typename
_Alloc::rebind<_CharT>::other::reference std::basic_string::operator[](typename
_Alloc::rebind<_CharT>::other::size_type) [with _CharT = wchar_t,
_Traits = std::char_traits, _Alloc =
std::allocator]: Assertion '__pos < size()' failed.

Cheers,
g


>
> --
> Enrico
>

Re: trunk does no compile

[Kornel]

Am Samstag, 29. Januar 2011 schrieb Guillaume Pothier:
> >> I don't get it. You mean TeX-mode? Cannot see any crash here.
> > 
> > Same here.
> 
> I'm getting the crash when loading a file:

Not here. "Insert->File->Plain Text..." is ok, and so is "...->Plain Text, Join 
Lines...".

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: trunk does no compile

[Tommaso Cucinotta]

Il 29/01/2011 19:12, Enrico Forestieri ha scritto:

just don't even try it: my own brand new automated tests just started
to fail because, with that template-ish thing, at the first attempt of
typing a character in text-mode LyX was asserting :-).

I'm using the Enrico's patch that works fine (at least on my 64-bit
machine).

Yet, I think your idea is right for avoiding code duplication. Let's see
whether requiring explicit instantiations works. If yes, adding a
forgotten type would only require adding a single-line instantiation
declaration.

So, does the attach patch work for you?


If it is the same currently committed, then it is sufficient to:
-) create a new file
-) type any letter and kaboom!

(gdb) run
Starting program: /home/tommaso/lyx-trunk-ws/lyx-devel/src/lyx
[Thread debugging using libthread_db enabled]
[New Thread 0x704a3700 (LWP 7933)]
GuiToolbar.cpp(335): Session settings could not be found!. Defaults are 
used instead
/usr/include/c++/4.4/bits/basic_string.h:745: typename 
_Alloc::rebind<_CharT>::other::reference std::basic_string::operator[](typename _Alloc::rebind<_CharT>::other::size_type) 
[with _CharT = wchar_t, _Traits = std::char_traits, _Alloc = 
std::allocator]: Assertion '__pos < size()' failed.


Program received signal SIGABRT, Aborted.
0x75f51ba5 in raise () from /lib/libc.so.6

(gdb) bt
#0  0x75f51ba5 in raise () from /lib/libc.so.6
#1  0x75f556b0 in abort () from /lib/libc.so.6
#2  0x0062c62a in __replacement_assert (this=0x1b6bb68, __pos=1) 
at /usr/include/c++/4.4/x86_64-linux-gnu/bits/c++config.h:284
#3  std::basic_string::operator[] (this=0x1b6bb68, __pos=1) at 
/usr/include/c++/4.4/bits/basic_string.h:745
#4  0x006165de in lyx::Paragraph::isWordSeparator 
(this=0x1b6b000, pos=1) at Paragraph.cpp:2850
#5  0x00619035 in lyx::Paragraph::isMisspelled (this=0x1b6b000, 
pos=1, check_boundary=true) at Paragraph.cpp:3769
#6  0x006786f9 in lyx::Text::dispatch (this=out>, cur=..., cmd=) at Text3.cpp:2195
#7  0x00985217 in lyx::InsetText::doDispatch (this=0x1b6b5a0, 
cur=..., cmd=...) at insets/InsetText.cpp:290
#8  0x00870cf1 in lyx::Inset::dispatch (this=0x1b6b5a0, cur=..., 
cmd=...) at insets/Inset.cpp:315
#9  0x0071af19 in lyx::Cursor::dispatch (this=0x1b78b78, 
cmd0=...) at Cursor.cpp:370
#10 0x009f1b84 in lyx::frontend::GuiView::dispatchToBufferView 
(this=0x180c940, cmd=..., dr=...) at GuiView.cpp:3029
#11 0x00a0c816 in lyx::frontend::GuiView::dispatch 
(this=0x180c940, cmd=..., dr=...) at GuiView.cpp:3508
#12 0x009cd979 in lyx::frontend::GuiApplication::dispatch 
(this=0x12a1f10, cmd=..., dr=...) at GuiApplication.cpp:1679
#13 0x009c835c in lyx::frontend::GuiApplication::dispatch 
(this=0x12a1f10, cmd=...) at GuiApplication.cpp:1139

#14 0x005b89dd in lyx::dispatch (action=...) at LyX.cpp:1280
#15 0x009c0802 in 
lyx::frontend::GuiApplication::processFuncRequest (this=out>, func=...) at GuiApplication.cpp:1815
#16 0x009c74f2 in lyx::frontend::GuiApplication::processKeySym 
(this=0x12a1f10, keysym=..., state=lyx::NoModifier) at 
GuiApplication.cpp:1805
#17 0x00a1be7f in lyx::frontend::GuiWorkArea::processKeySym 
(this=0x1b6e990, key=..., mod=lyx::NoModifier) at GuiWorkArea.cpp:489
#18 0x00a1f490 in lyx::frontend::GuiWorkArea::keyPressEvent 
(this=0x1b6e990, ev=0x7fff9730) at GuiWorkArea.cpp:1011
#19 0x770e9cfa in QWidget::event (this=0x1b6e990, 
event=0x7fff9730) at kernel/qwidget.cpp:8222
#20 0x774b55e6 in QFrame::event (this=0x1b6e990, 
e=0x7fff9730) at widgets/qframe.cpp:557
#21 0x7754371b in QAbstractScrollArea::event (this=0x1b6e990, 
e=0x7fff9730) at widgets/qabstractscrollarea.cpp:996
#22 0x00a1c3fe in lyx::frontend::GuiWorkArea::event 
(this=0x1b6e990, e=0x1efa) at GuiWorkArea.cpp:692
#23 0x77093fdc in QApplicationPrivate::notify_helper 
(this=0x12a9790, receiver=0x1b6e990, e=0x7fff9730) at 
kernel/qapplication.cpp:4396
#24 0x7709b346 in QApplication::notify (this=out>, receiver=0x1b6e990, e=0x7fff9730) at kernel/qapplication.cpp:3857
#25 0x009c27ad in lyx::frontend::GuiApplication::notify 
(this=0x1efa, receiver=0x1efa, event=0x6) at GuiApplication.cpp:2193
#26 0x76ba8cdc in QCoreApplication::notifyInternal 
(this=0x12a1f10, receiver=0x1b6e990, event=0x7fff9730) at 
kernel/qcoreapplication.cpp:732
#27 0x771414ba in QKeyMapper::sendKeyEvent (keyWidget=0x1b6e990, 
grab=, type=QEvent::KeyPress, code=65, 
modifiers=,
text=..., autorepeat=false, count=1, nativeScanCode=38, 
nativeVirtualKey=97, nativeModifiers=16) at kernel/qkeymapper_x11.cpp:1867
#28 0x77143ac0 in QKeyMapperPrivate::translateKeyEvent 
(this=0x12f5bf0, keyWidget=0x1b6e990, event=, 
grab=250) at kernel/qkeymapper_x11.cpp:1837
#29 0x7711acb4 in 

Re: trunk does no compile

[Tommaso Cucinotta]

Il 30/01/2011 01:28, Tommaso Cucinotta ha scritto:


If it is the same currently committed, then it is sufficient to:
-) create a new file
-) type any letter and kaboom!


So, on my system, I need the patch below in order to be able to use LyX 
trunk again (r37368):


Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp(revisione 37368)
+++ src/Paragraph.cpp(copia locale)
@@ -3765,6 +3765,9 @@

 bool Paragraph::isMisspelled(pos_type pos, bool check_boundary) const
 {
+LASSERT(pos >=0 && pos <= size(), /**/);
+if (pos == size())
+return false;
 bool result = 
SpellChecker::misspelled(d->speller_state_.getState(pos));

 if (!result && check_boundary && pos > 0 && isWordSeparator(pos))
 result = 
SpellChecker::misspelled(d->speller_state_.getState(pos - 1));


I suspect this only masquerades/protects from some bug in the real-time 
spellchecker code, but without it my LyX (trunk) becomes nearly unusable.


T.

Re: trunk does no compile

[Enrico Forestieri]

On Sun, Jan 30, 2011 at 01:28:49AM +0100, Tommaso Cucinotta wrote:

> Il 29/01/2011 19:12, Enrico Forestieri ha scritto:
> >>just don't even try it: my own brand new automated tests just started
> >>to fail because, with that template-ish thing, at the first attempt of
> >>typing a character in text-mode LyX was asserting :-).
> >>
> >>I'm using the Enrico's patch that works fine (at least on my 64-bit
> >>machine).
> >Yet, I think your idea is right for avoiding code duplication. Let's see
> >whether requiring explicit instantiations works. If yes, adding a
> >forgotten type would only require adding a single-line instantiation
> >declaration.
> >
> >So, does the attach patch work for you?
> 
> If it is the same currently committed, then it is sufficient to:
> -) create a new file
> -) type any letter and kaboom!

From the backtrace, it is clear that the assertion is unrelated to the
otexstream class and that it only occurs when continuous spell checking
is active. The culprit here is r37363.

Specifically, the assertion is triggered by the following line

char_type const c = d->text_[pos];

in Paragraph::isWordSeparator(). Seemingly, pos points to the position
immediately after the last character in d->text_.

-- 
Enrico

Re: trunk does no compile

[Stephan Witt]

Am 30.01.2011 um 02:23 schrieb Enrico Forestieri:

> On Sun, Jan 30, 2011 at 01:28:49AM +0100, Tommaso Cucinotta wrote:
> 
>> Il 29/01/2011 19:12, Enrico Forestieri ha scritto:
 just don't even try it: my own brand new automated tests just started
 to fail because, with that template-ish thing, at the first attempt of
 typing a character in text-mode LyX was asserting :-).
 
 I'm using the Enrico's patch that works fine (at least on my 64-bit
 machine).
>>> Yet, I think your idea is right for avoiding code duplication. Let's see
>>> whether requiring explicit instantiations works. If yes, adding a
>>> forgotten type would only require adding a single-line instantiation
>>> declaration.
>>> 
>>> So, does the attach patch work for you?
>> 
>> If it is the same currently committed, then it is sufficient to:
>> -) create a new file
>> -) type any letter and kaboom!
> 
> From the backtrace, it is clear that the assertion is unrelated to the
> otexstream class and that it only occurs when continuous spell checking
> is active. The culprit here is r37363.
> 
> Specifically, the assertion is triggered by the following line
> 
>char_type const c = d->text_[pos];
> 
> in Paragraph::isWordSeparator(). Seemingly, pos points to the position
> immediately after the last character in d->text_.

Sorry, I was mislead by the test pos == size() at the end of isWordSeparator().
Obviously the author of that test function wants to return true
for end-of-paragraph. But the test for it should come first.

I did an explicitly test of that scenario and it did not crash here.
But it seems I didn't enable the array bounds checker :(

I fixed that with r37369.

Stephan

trunk does not compile

[Tommaso Cucinotta]

 CXX GuiView.o
GuiView.cpp: In member function ‘virtual void 
lyx::frontend::GuiView::dispatch(const lyx::FuncRequest, 
lyx::DispatchResult)’:
GuiView.cpp:2997: error: no matching function for call to 
‘lyx::frontend::GuiView::lfunUiToggle(const char [11])’
GuiView.h:300: note: candidates are: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest)
GuiView.cpp:3010: error: no matching function for call to 
‘lyx::frontend::GuiView::lfunUiToggle(std::string)’
GuiView.h:300: note: candidates are: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest)

GuiView.cpp: At global scope:
GuiView.cpp:3126: error: prototype for ‘bool 
lyx::frontend::GuiView::lfunUiToggle(const std::string)’ does not match 
any in class ‘lyx::frontend::GuiView’
GuiView.h:300: error: candidate is: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest)

Re: trunk does not compile

[Vincent van Ravesteijn]

Tommaso Cucinotta schreef:


 CXX GuiView.o
GuiView.cpp: In member function ‘virtual void 
lyx::frontend::GuiView::dispatch(const lyx::FuncRequest, 
lyx::DispatchResult)’:
GuiView.cpp:2997: error: no matching function for call to 
‘lyx::frontend::GuiView::lfunUiToggle(const char [11])’
GuiView.h:300: note: candidates are: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest)
GuiView.cpp:3010: error: no matching function for call to 
‘lyx::frontend::GuiView::lfunUiToggle(std::string)’
GuiView.h:300: note: candidates are: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest)

GuiView.cpp: At global scope:
GuiView.cpp:3126: error: prototype for ‘bool 
lyx::frontend::GuiView::lfunUiToggle(const std::string)’ does not 
match any in class ‘lyx::frontend::GuiView’
GuiView.h:300: error: candidate is: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest)



Fixed.

Vincent

trunk does not compile

[Tommaso Cucinotta]

 CXX GuiView.o
GuiView.cpp: In member function ‘virtual void 
lyx::frontend::GuiView::dispatch(const lyx::FuncRequest&, 
lyx::DispatchResult&)’:
GuiView.cpp:2997: error: no matching function for call to 
‘lyx::frontend::GuiView::lfunUiToggle(const char [11])’
GuiView.h:300: note: candidates are: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest&)
GuiView.cpp:3010: error: no matching function for call to 
‘lyx::frontend::GuiView::lfunUiToggle(std::string&)’
GuiView.h:300: note: candidates are: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest&)

GuiView.cpp: At global scope:
GuiView.cpp:3126: error: prototype for ‘bool 
lyx::frontend::GuiView::lfunUiToggle(const std::string&)’ does not match 
any in class ‘lyx::frontend::GuiView’
GuiView.h:300: error: candidate is: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest&)

Re: trunk does not compile

[Vincent van Ravesteijn]

Tommaso Cucinotta schreef:


 CXX GuiView.o
GuiView.cpp: In member function ‘virtual void 
lyx::frontend::GuiView::dispatch(const lyx::FuncRequest&, 
lyx::DispatchResult&)’:
GuiView.cpp:2997: error: no matching function for call to 
‘lyx::frontend::GuiView::lfunUiToggle(const char [11])’
GuiView.h:300: note: candidates are: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest&)
GuiView.cpp:3010: error: no matching function for call to 
‘lyx::frontend::GuiView::lfunUiToggle(std::string&)’
GuiView.h:300: note: candidates are: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest&)

GuiView.cpp: At global scope:
GuiView.cpp:3126: error: prototype for ‘bool 
lyx::frontend::GuiView::lfunUiToggle(const std::string&)’ does not 
match any in class ‘lyx::frontend::GuiView’
GuiView.h:300: error: candidate is: void 
lyx::frontend::GuiView::lfunUiToggle(const lyx::FuncRequest&)



Fixed.

Vincent

Trunk does not compile

[Kornel Benko]

Hi Abdel,
blame is suggesting, I have to address you ...

[ 62%] Building CXX object 
src/CMakeFiles/lyx.dir/usr/src/lyx/lyx-devel/src/BufferView.o
cd /usr/BUILD/BuildLyx/src  /usr/bin/c++   -DQT_NO_STL -DQT_NO_KEYWORDS 
-DHAVE_GETTEXT -DUSE_HUNSPELL=1 -DENABLE_NLS=1 -
DUSE_ASPELL=1 -DHAVE_ICONV=1 -Wall -Wall -O3 -DNDEBUG 
-I/usr/src/lyx/lyx-devel/po -I/usr/BUILD/BuildLyx -I/usr/src/lyx/lyx-devel/src -
I/usr/BUILD/BuildLyx/src -I/usr/include/qt4 -I/usr/include/qt4/Qt 
-I/usr/share/qt4/mkspecs/default -I/usr/include/qt4/QtCore 
-I/usr/include/qt4/QtGui -
I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtAssistant 
-I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtNetwork 
-I/usr/include/qt4/QtOpenGL -
I/usr/include/qt4/QtSql -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSvg 
-I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest   -o 
CMakeFiles/lyx.dir/usr/src/lyx/lyx-devel/src/BufferView.o -c 
/usr/src/lyx/lyx-devel/src/BufferView.cpp
/usr/src/lyx/lyx-devel/src/BufferView.cpp: In member function ‘bool 
lyx::BufferView::dispatch(const lyx::FuncRequest)’:
/usr/src/lyx/lyx-devel/src/BufferView.cpp:1099: error: variable 
‘std::istringstream ss’ has initializer but incomplete type
make[2]: *** [src/CMakeFiles/lyx.dir/usr/src/lyx/lyx-devel/src/BufferView.o] 
Error 1
make[2]: Leaving directory `/usr/BUILD/BuildLyx'
make[1]: *** [src/CMakeFiles/lyx.dir/all] Error 2
make[1]: Leaving directory `/usr/BUILD/BuildLyx'


Kornel



signature.asc
Description: This is a digitally signed message part.

Trunk does not compile

[Kornel Benko]

Hi Abdel,
"blame" is suggesting, I have to address you ...

[ 62%] Building CXX object 
src/CMakeFiles/lyx.dir/usr/src/lyx/lyx-devel/src/BufferView.o
cd /usr/BUILD/BuildLyx/src && /usr/bin/c++   -DQT_NO_STL -DQT_NO_KEYWORDS 
-DHAVE_GETTEXT -DUSE_HUNSPELL=1 -DENABLE_NLS=1 -
DUSE_ASPELL=1 -DHAVE_ICONV=1 -Wall -Wall -O3 -DNDEBUG 
-I/usr/src/lyx/lyx-devel/po -I/usr/BUILD/BuildLyx -I/usr/src/lyx/lyx-devel/src -
I/usr/BUILD/BuildLyx/src -I/usr/include/qt4 -I/usr/include/qt4/Qt 
-I/usr/share/qt4/mkspecs/default -I/usr/include/qt4/QtCore 
-I/usr/include/qt4/QtGui -
I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtAssistant 
-I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtNetwork 
-I/usr/include/qt4/QtOpenGL -
I/usr/include/qt4/QtSql -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSvg 
-I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest   -o 
CMakeFiles/lyx.dir/usr/src/lyx/lyx-devel/src/BufferView.o -c 
/usr/src/lyx/lyx-devel/src/BufferView.cpp
/usr/src/lyx/lyx-devel/src/BufferView.cpp: In member function ‘bool 
lyx::BufferView::dispatch(const lyx::FuncRequest&)’:
/usr/src/lyx/lyx-devel/src/BufferView.cpp:1099: error: variable 
‘std::istringstream ss’ has initializer but incomplete type
make[2]: *** [src/CMakeFiles/lyx.dir/usr/src/lyx/lyx-devel/src/BufferView.o] 
Error 1
make[2]: Leaving directory `/usr/BUILD/BuildLyx'
make[1]: *** [src/CMakeFiles/lyx.dir/all] Error 2
make[1]: Leaving directory `/usr/BUILD/BuildLyx'


Kornel



signature.asc
Description: This is a digitally signed message part.

Re: boost in trunk does not compile with gcc-4.4

[Helge Hafting]

Abdelrazak Younes wrote:

rgheck wrote:


I reported this a while back, and the advice was to use external boost.


Well even if the advice is true this should be fixed. gcc-4.4 is out so 
we should support it. Maybe it is just a matter of upgrading our 
internal boost?


If external boost works so well, why have internal?

Helge Hafting

Re: boost in trunk does not compile with gcc-4.4

[Abdelrazak Younes]

Helge Hafting wrote:

Abdelrazak Younes wrote:

rgheck wrote:


I reported this a while back, and the advice was to use external boost.


Well even if the advice is true this should be fixed. gcc-4.4 is out 
so we should support it. Maybe it is just a matter of upgrading our 
internal boost?


If external boost works so well, why have internal?


History :-)

Abdel.

Re: boost in trunk does not compile with gcc-4.4

[Jean-Marc Lasgouttes]

Helge Hafting helge.haft...@hist.no writes:

 Abdelrazak Younes wrote:
 rgheck wrote:

 I reported this a while back, and the advice was to use external boost.

 Well even if the advice is true this should be fixed. gcc-4.4 is out
 so we should support it. Maybe it is just a matter of upgrading our
 internal boost?

 If external boost works so well, why have internal?

Because not everybody has the exact right version of boost installed.

JMarc

Re: boost in trunk does not compile with gcc-4.4

[Helge Hafting]

Abdelrazak Younes wrote:

rgheck wrote:


I reported this a while back, and the advice was to use external boost.


Well even if the advice is true this should be fixed. gcc-4.4 is out so 
we should support it. Maybe it is just a matter of upgrading our 
internal boost?


If external boost works so well, why have internal?

Helge Hafting

Re: boost in trunk does not compile with gcc-4.4

[Abdelrazak Younes]

Helge Hafting wrote:

Abdelrazak Younes wrote:

rgheck wrote:


I reported this a while back, and the advice was to use external boost.


Well even if the advice is true this should be fixed. gcc-4.4 is out 
so we should support it. Maybe it is just a matter of upgrading our 
internal boost?


If external boost works so well, why have internal?


History :-)

Abdel.

Re: boost in trunk does not compile with gcc-4.4

[Jean-Marc Lasgouttes]

Helge Hafting  writes:

> Abdelrazak Younes wrote:
>> rgheck wrote:
>>>
>>> I reported this a while back, and the advice was to use external boost.
>>
>> Well even if the advice is true this should be fixed. gcc-4.4 is out
>> so we should support it. Maybe it is just a matter of upgrading our
>> internal boost?
>
> If external boost works so well, why have internal?

Because not everybody has the exact right version of boost installed.

JMarc

boost in trunk does not compile with gcc-4.4

[Abdelrazak Younes]

[  0%] Building CXX object 
src/support/CMakeFiles/support.dir/home/younes/devel/lyx/trunk/src/support/ForkedCalls.o 

cd 
/home/younes/devel/lyx/trunk/development/cmake/qtcreator-build/src/support 
 /usr/bin/c++   -DQT_NO_STL -DQT_NO_KEYWORDS -DHAVE_GETTEXT 
-DENABLE_NLS=1 -DUSE_ASPELL=1 -DHAVE_ICONV=1 -Wall -Wall -O3 -DNDEBUG 
-I/home/younes/devel/lyx/trunk/po 
-I/home/younes/devel/lyx/trunk/development/cmake/qtcreator-build 
-I/home/younes/devel/lyx/trunk/src -I/home/younes/devel/lyx/trunk/boost 
-I/home/younes/devel/lyx/trunk/src/support 
-I/home/younes/devel/lyx/trunk/development/cmake/qtcreator-build/src/support 
-I/home/younes/devel/lyx/trunk/src/support/mythes -I/usr/include/qt4 
-I/usr/include/qt4/Qt -I/usr/share/qt4/mkspecs/default 
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui 
-I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtAssistant 
-I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtNetwork 
-I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtSql 
-I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSvg 
-I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest   
-DBOOST_USER_CONFIG=config.h -o 
CMakeFiles/support.dir/home/younes/devel/lyx/trunk/src/support/ForkedCalls.o 
-c 
/home/younes/devel/lyx/trunk/src/support/ForkedCalls.cpp 

In file included from 
/home/younes/devel/lyx/trunk/boost/boost/mpl/apply.hpp:23,

from 
/home/younes/devel/lyx/trunk/boost/boost/iterator/iterator_facade.hpp:34, 

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/detail/named_slot_map.hpp:19,

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/detail/signal_base.hpp:15,   

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/signal_template.hpp:23,  

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/signal0.hpp:24,  

from 
/home/younes/devel/lyx/trunk/boost/boost/signal.hpp:19,   

from 
/home/younes/devel/lyx/trunk/src/support/ForkedCalls.h:18,

from 
/home/younes/devel/lyx/trunk/src/support/ForkedCalls.cpp:15:  

/home/younes/devel/lyx/trunk/boost/boost/mpl/apply_wrap.hpp:81:31: 
error: missing binary operator before token 
(  

/home/younes/devel/lyx/trunk/boost/boost/mpl/apply_wrap.hpp:173:31: 
error: missing binary operator before token 
( 

In file included from 
/home/younes/devel/lyx/trunk/boost/boost/mpl/bind.hpp:27, 

from 
/home/younes/devel/lyx/trunk/boost/boost/mpl/lambda.hpp:18,   

from 
/home/younes/devel/lyx/trunk/boost/boost/mpl/apply.hpp:25,

from 
/home/younes/devel/lyx/trunk/boost/boost/iterator/iterator_facade.hpp:34, 

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/detail/named_slot_map.hpp:19,

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/detail/signal_base.hpp:15,  

Re: boost in trunk does not compile with gcc-4.4

[rgheck]

I reported this a while back, and the advice was to use external boost.

rh

Re: boost in trunk does not compile with gcc-4.4

[Abdelrazak Younes]

rgheck wrote:


I reported this a while back, and the advice was to use external boost.


Well even if the advice is true this should be fixed. gcc-4.4 is out so 
we should support it. Maybe it is just a matter of upgrading our 
internal boost?


Abdel.

Re: boost in trunk does not compile with gcc-4.4

[Jean-Marc Lasgouttes]

Abdelrazak Younes you...@lyx.org writes:

 rgheck wrote:

 I reported this a while back, and the advice was to use external boost.

 Well even if the advice is true this should be fixed. gcc-4.4 is out
 so we should support it. Maybe it is just a matter of upgrading our
 internal boost?

Yes. We have version 1.36, current version is 1.39. However, do we have
a recipe somewhere on how to upgrade boost?

JMarc

Re: boost in trunk does not compile with gcc-4.4

[Peter Kuemmel]

 Original-Nachricht 
 Datum: Thu, 09 Jul 2009 18:04:51 +0200
 Von: Jean-Marc Lasgouttes lasgout...@lyx.org
 An: Abdelrazak Younes you...@lyx.org
 CC: rgheck rgh...@bobjweil.com, LyX Developers lyx-devel@lists.lyx.org
 Betreff: Re: boost in trunk does not compile with gcc-4.4

 Abdelrazak Younes you...@lyx.org writes:
 
  rgheck wrote:
 
  I reported this a while back, and the advice was to use external boost.
 
  Well even if the advice is true this should be fixed. gcc-4.4 is out
  so we should support it. Maybe it is just a matter of upgrading our
  internal boost?
 
 Yes. We have version 1.36, current version is 1.39. However, do we have
 a recipe somewhere on how to upgrade boost?
 
 JMarc

Last time I did it this way:
http://www.lyx.org/trac/log/lyx-devel/branches/personal/kuemmel/boost_1_36

1. simply overwrite all existing boost files
2. add new boost files
3. maybe remove obsolete boost files
4. fix LyX

To find the new/obsolete files one could remove all files 
but the .svnfolders and then copy the new boost files into /boost, 
a svn status should show all changes.

Peter




-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

boost in trunk does not compile with gcc-4.4

[Abdelrazak Younes]

[  0%] Building CXX object 
src/support/CMakeFiles/support.dir/home/younes/devel/lyx/trunk/src/support/ForkedCalls.o 

cd 
/home/younes/devel/lyx/trunk/development/cmake/qtcreator-build/src/support 
&& /usr/bin/c++   -DQT_NO_STL -DQT_NO_KEYWORDS -DHAVE_GETTEXT 
-DENABLE_NLS=1 -DUSE_ASPELL=1 -DHAVE_ICONV=1 -Wall -Wall -O3 -DNDEBUG 
-I/home/younes/devel/lyx/trunk/po 
-I/home/younes/devel/lyx/trunk/development/cmake/qtcreator-build 
-I/home/younes/devel/lyx/trunk/src -I/home/younes/devel/lyx/trunk/boost 
-I/home/younes/devel/lyx/trunk/src/support 
-I/home/younes/devel/lyx/trunk/development/cmake/qtcreator-build/src/support 
-I/home/younes/devel/lyx/trunk/src/support/mythes -I/usr/include/qt4 
-I/usr/include/qt4/Qt -I/usr/share/qt4/mkspecs/default 
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui 
-I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtAssistant 
-I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtNetwork 
-I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtSql 
-I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSvg 
-I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest   
-DBOOST_USER_CONFIG="" -o 
CMakeFiles/support.dir/home/younes/devel/lyx/trunk/src/support/ForkedCalls.o 
-c 
/home/younes/devel/lyx/trunk/src/support/ForkedCalls.cpp 

In file included from 
/home/younes/devel/lyx/trunk/boost/boost/mpl/apply.hpp:23,

from 
/home/younes/devel/lyx/trunk/boost/boost/iterator/iterator_facade.hpp:34, 

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/detail/named_slot_map.hpp:19,

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/detail/signal_base.hpp:15,   

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/signal_template.hpp:23,  

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/signal0.hpp:24,  

from 
/home/younes/devel/lyx/trunk/boost/boost/signal.hpp:19,   

from 
/home/younes/devel/lyx/trunk/src/support/ForkedCalls.h:18,

from 
/home/younes/devel/lyx/trunk/src/support/ForkedCalls.cpp:15:  

/home/younes/devel/lyx/trunk/boost/boost/mpl/apply_wrap.hpp:81:31: 
error: missing binary operator before token 
"("  

/home/younes/devel/lyx/trunk/boost/boost/mpl/apply_wrap.hpp:173:31: 
error: missing binary operator before token 
"(" 

In file included from 
/home/younes/devel/lyx/trunk/boost/boost/mpl/bind.hpp:27, 

from 
/home/younes/devel/lyx/trunk/boost/boost/mpl/lambda.hpp:18,   

from 
/home/younes/devel/lyx/trunk/boost/boost/mpl/apply.hpp:25,

from 
/home/younes/devel/lyx/trunk/boost/boost/iterator/iterator_facade.hpp:34, 

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/detail/named_slot_map.hpp:19,

from 
/home/younes/devel/lyx/trunk/boost/boost/signals/detail/signal_base.hpp:15,  

Re: boost in trunk does not compile with gcc-4.4

[rgheck]

I reported this a while back, and the advice was to use external boost.

rh

Re: boost in trunk does not compile with gcc-4.4

[Abdelrazak Younes]

rgheck wrote:


I reported this a while back, and the advice was to use external boost.


Well even if the advice is true this should be fixed. gcc-4.4 is out so 
we should support it. Maybe it is just a matter of upgrading our 
internal boost?


Abdel.

Re: boost in trunk does not compile with gcc-4.4

[Jean-Marc Lasgouttes]

Abdelrazak Younes  writes:

> rgheck wrote:
>>
>> I reported this a while back, and the advice was to use external boost.
>
> Well even if the advice is true this should be fixed. gcc-4.4 is out
> so we should support it. Maybe it is just a matter of upgrading our
> internal boost?

Yes. We have version 1.36, current version is 1.39. However, do we have
a recipe somewhere on how to upgrade boost?

JMarc

Re: boost in trunk does not compile with gcc-4.4

[Peter Kuemmel]

 Original-Nachricht 
> Datum: Thu, 09 Jul 2009 18:04:51 +0200
> Von: Jean-Marc Lasgouttes <lasgout...@lyx.org>
> An: Abdelrazak Younes <you...@lyx.org>
> CC: rgheck <rgh...@bobjweil.com>, LyX Developers <lyx-devel@lists.lyx.org>
> Betreff: Re: boost in trunk does not compile with gcc-4.4

> Abdelrazak Younes <you...@lyx.org> writes:
> 
> > rgheck wrote:
> >>
> >> I reported this a while back, and the advice was to use external boost.
> >
> > Well even if the advice is true this should be fixed. gcc-4.4 is out
> > so we should support it. Maybe it is just a matter of upgrading our
> > internal boost?
> 
> Yes. We have version 1.36, current version is 1.39. However, do we have
> a recipe somewhere on how to upgrade boost?
> 
> JMarc

Last time I did it this way:
http://www.lyx.org/trac/log/lyx-devel/branches/personal/kuemmel/boost_1_36

1. simply overwrite all existing boost files
2. add new boost files
3. maybe remove obsolete boost files
4. fix LyX

To find the new/obsolete files one could remove all files 
but the .svnfolders and then copy the new boost files into /boost, 
a svn status should show all changes.

Peter




-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Trunk does not compile

[Kornel Benko]

Hi,
this is on ubuntu 8.10 with gcc 4.3.2.
...
make[4]: Entering directory `/usr/BUILD/BuildLyxConfigure/src'
g++  -g -O   -o lyx main.o ASpell.o SpellBase.o BiblioInfo.o Box.o Dimension.o 
PrinterParams.o Thesaurus.o  liblyxcore.a liblyxmathed.a liblyxinsets.a 
frontends/liblyxfrontends.a frontends/qt4/liblyxqt4.a liblyxgraphics.a 
support/liblyxsupport.a ../boost/liblyxboost.a-laspell   -lz  -lQtCore 
-lQtGui
liblyxcore.a(BufferList.o): In function 
`lyx::BufferList::releaseChild(lyx::Buffer*, lyx::Buffer*)':
/usr/src/lyx/lyx-devel/src/BufferList.cpp:349: undefined reference to 
`lyx::Buffer::parent()'
collect2: ld returned 1 exit status

...
Kornel
-- 
Kornel Benko
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.

Re: Trunk does not compile

[Pavel Sanda]

Kornel Benko wrote:
 Hi,
 this is on ubuntu 8.10 with gcc 4.3.2.
 ...
 make[4]: Entering directory `/usr/BUILD/BuildLyxConfigure/src'
 g++  -g -O   -o lyx main.o ASpell.o SpellBase.o BiblioInfo.o Box.o 
 Dimension.o 
 PrinterParams.o Thesaurus.o  liblyxcore.a liblyxmathed.a liblyxinsets.a 
 frontends/liblyxfrontends.a frontends/qt4/liblyxqt4.a liblyxgraphics.a 
 support/liblyxsupport.a ../boost/liblyxboost.a-laspell   -lz  
 -lQtCore 
 -lQtGui
 liblyxcore.a(BufferList.o): In function 
 `lyx::BufferList::releaseChild(lyx::Buffer*, lyx::Buffer*)':
 /usr/src/lyx/lyx-devel/src/BufferList.cpp:349: undefined reference to 
 `lyx::Buffer::parent()'
 collect2: ld returned 1 exit status

this is a linker problem and i think it will diappear if you make distclean
your tree or do a build from fresh sources.
pavel

Re: Trunk does not compile

[Kornel Benko]

Am Freitag 21 November 2008 schrieb Pavel Sanda:
 this is a linker problem and i think it will diappear if you make distclean
 your tree or do a build from fresh sources.
 pavel

Thanks Pavel. This is not the first time I had to make distclean. I should 
have had remembered.

Kornel

-- 
Kornel Benko
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.

Trunk does not compile

[Kornel Benko]

Hi,
this is on ubuntu 8.10 with gcc 4.3.2.
...
make[4]: Entering directory `/usr/BUILD/BuildLyxConfigure/src'
g++  -g -O   -o lyx main.o ASpell.o SpellBase.o BiblioInfo.o Box.o Dimension.o 
PrinterParams.o Thesaurus.o  liblyxcore.a liblyxmathed.a liblyxinsets.a 
frontends/liblyxfrontends.a frontends/qt4/liblyxqt4.a liblyxgraphics.a 
support/liblyxsupport.a ../boost/liblyxboost.a-laspell   -lz  -lQtCore 
-lQtGui
liblyxcore.a(BufferList.o): In function 
`lyx::BufferList::releaseChild(lyx::Buffer*, lyx::Buffer*)':
/usr/src/lyx/lyx-devel/src/BufferList.cpp:349: undefined reference to 
`lyx::Buffer::parent()'
collect2: ld returned 1 exit status

...
Kornel
-- 
Kornel Benko
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.

Re: Trunk does not compile

[Pavel Sanda]

Kornel Benko wrote:
> Hi,
> this is on ubuntu 8.10 with gcc 4.3.2.
> ...
> make[4]: Entering directory `/usr/BUILD/BuildLyxConfigure/src'
> g++  -g -O   -o lyx main.o ASpell.o SpellBase.o BiblioInfo.o Box.o 
> Dimension.o 
> PrinterParams.o Thesaurus.o  liblyxcore.a liblyxmathed.a liblyxinsets.a 
> frontends/liblyxfrontends.a frontends/qt4/liblyxqt4.a liblyxgraphics.a 
> support/liblyxsupport.a ../boost/liblyxboost.a-laspell   -lz  
> -lQtCore 
> -lQtGui
> liblyxcore.a(BufferList.o): In function 
> `lyx::BufferList::releaseChild(lyx::Buffer*, lyx::Buffer*)':
> /usr/src/lyx/lyx-devel/src/BufferList.cpp:349: undefined reference to 
> `lyx::Buffer::parent()'
> collect2: ld returned 1 exit status

this is a linker problem and i think it will diappear if you make distclean
your tree or do a build from fresh sources.
pavel

Re: Trunk does not compile

[Kornel Benko]

Am Freitag 21 November 2008 schrieb Pavel Sanda:
> this is a linker problem and i think it will diappear if you make distclean
> your tree or do a build from fresh sources.
> pavel

Thanks Pavel. This is not the first time I had to make distclean. I should 
have had remembered.

Kornel

-- 
Kornel Benko
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.

Re: Trunk does not compile

[Tommaso Cucinotta]

In order to compile, I need this, on my system

* Ubuntu Intrepid

*  gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc 
--enable-mpfr --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)

* dpkg -l | grep stdc++
ii  lib32stdc++6  
4.3.2-1ubuntu11   The GNU Standard C++ Library v3 
(32 bit Version)
ii  libstdc++6
4.3.2-1ubuntu11   The GNU Standard C++ Library v3
ii  libstdc++6-4.3-dev
4.3.2-1ubuntu11   The GNU Standard C++ Library v3 
(development files)


   T.

Index: src/frontends/qt4/GuiSendto.cpp
===
--- src/frontends/qt4/GuiSendto.cpp	(revisione 27551)
+++ src/frontends/qt4/GuiSendto.cpp	(copia locale)
@@ -26,6 +26,7 @@
 #include QLineEdit
 #include QListWidget
 #include QPushButton
+#include algorithm
 
 using namespace std;
 using namespace lyx::support;
@@ -207,7 +208,7 @@
 	}
 
 	// Remove repeated formats.
-	sort(to.begin(), to.end());
+	std::sort(to.begin(), to.end());
 	to.erase(unique(to.begin(), to.end()), to.end());
 
 	return to;

Index: src/LyXRC.cpp
===
--- src/LyXRC.cpp	(revisione 27551)
+++ src/LyXRC.cpp	(copia locale)
@@ -18,6 +18,7 @@
 
 #include fstream
 #include iostream
+#include algorithm
 
 #include LyXRC.h
 
@@ -2377,7 +2378,7 @@
 
 		for (; it != end; ++it) {
 			Movers::const_iterator const sysit =
-find_if(sysbegin, sysend, SameMover(*it));
+std::find_if(sysbegin, sysend, SameMover(*it));
 			if (sysit == sysend) {
 string const  fmt = it-first;
 string const  command =

Re: Trunk does not compile

[Jürgen Spitzmüller]

Tommaso Cucinotta wrote:
 In order to compile, I need this, on my system

make distclean should be sufficient.

Jürgen

Re: Trunk does not compile

[Tommaso Cucinotta]

In order to compile, I need this, on my system

* Ubuntu Intrepid

*  gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc 
--enable-mpfr --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)

* dpkg -l | grep stdc++
ii  lib32stdc++6  
4.3.2-1ubuntu11   The GNU Standard C++ Library v3 
(32 bit Version)
ii  libstdc++6
4.3.2-1ubuntu11   The GNU Standard C++ Library v3
ii  libstdc++6-4.3-dev
4.3.2-1ubuntu11   The GNU Standard C++ Library v3 
(development files)


   T.

Index: src/frontends/qt4/GuiSendto.cpp
===
--- src/frontends/qt4/GuiSendto.cpp	(revisione 27551)
+++ src/frontends/qt4/GuiSendto.cpp	(copia locale)
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 using namespace std;
 using namespace lyx::support;
@@ -207,7 +208,7 @@
 	}
 
 	// Remove repeated formats.
-	sort(to.begin(), to.end());
+	std::sort(to.begin(), to.end());
 	to.erase(unique(to.begin(), to.end()), to.end());
 
 	return to;

Index: src/LyXRC.cpp
===
--- src/LyXRC.cpp	(revisione 27551)
+++ src/LyXRC.cpp	(copia locale)
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 
 #include "LyXRC.h"
 
@@ -2377,7 +2378,7 @@
 
 		for (; it != end; ++it) {
 			Movers::const_iterator const sysit =
-find_if(sysbegin, sysend, SameMover(*it));
+std::find_if(sysbegin, sysend, SameMover(*it));
 			if (sysit == sysend) {
 string const & fmt = it->first;
 string const & command =

Re: Trunk does not compile

[Jürgen Spitzmüller]

Tommaso Cucinotta wrote:
> In order to compile, I need this, on my system

make distclean should be sufficient.

Jürgen

Trunk does not compile (client).

[Bo Peng]

g++ -o debug/src/client/client.o -c
-I/home/bpeng/lyx-devel/lyx-1.6-rw/boost -g -O -pthread -DQT_GUI_LIB
-DQT_SHARED -Idebug/src -Isrc -Isrc -I/usr/include -I/usr/include/qt4
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui
src/client/client.cpp
src/client/client.cpp: In function 'int main(int, char**)':
src/client/client.cpp:575: error: 'const class lyx::support::FileName'
has no member named 'string'
scons: *** [debug/src/client/client.o] Error 1
scons: building terminated because of errors.


Bo

Trunk does not compile (client).

[Bo Peng]

g++ -o debug/src/client/client.o -c
-I/home/bpeng/lyx-devel/lyx-1.6-rw/boost -g -O -pthread -DQT_GUI_LIB
-DQT_SHARED -Idebug/src -Isrc -Isrc -I/usr/include -I/usr/include/qt4
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui
src/client/client.cpp
src/client/client.cpp: In function 'int main(int, char**)':
src/client/client.cpp:575: error: 'const class lyx::support::FileName'
has no member named 'string'
scons: *** [debug/src/client/client.o] Error 1
scons: building terminated because of errors.


Bo

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Jean-Marc Lasgouttes]

Stefan Schimanski [EMAIL PROTECTED] writes:

 Why cannot people use qt 4.2 for development? We have had a lot of
 compatibility problems with qt 4.3.

I use Qt4.2 too. Usually problems are noticed pretty fast. What I am
not sure about, though, is whether somebody tests LyX 1.5.x with Qt 4.1.


 Because then I would have used QDrag::start, just to get complains by
 Qt 4.3 people that it does not complile.

I would be surprised.

JMarc

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Richard Heck]

Jean-Marc Lasgouttes wrote:

Because then I would have used QDrag::start, just to get complains by
Qt 4.3 people that it does not complile.



I would be surprised.

  

You'd be surprised if we didn't complain? Are we, as a group, that docile?

rh

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Jean-Marc Lasgouttes]

Richard Heck [EMAIL PROTECTED] writes:

 I would be surprised.

 You'd be surprised if we didn't complain? Are we, as a group, that docile?

No, I'd be surprised that 4.3 cannot accept code that is valid in 4.2.

JMarc

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Richard Heck]

Jean-Marc Lasgouttes wrote:

Richard Heck [EMAIL PROTECTED] writes:

  

I would be surprised.
  


  

You'd be surprised if we didn't complain? Are we, as a group, that docile?



No, I'd be surprised that 4.3 cannot accept code that is valid in 4.2.

  
At least the documentation suggests that QDrag::start() doesn't exist in 
4.3 but has been replaced by QDrag::exec(), which seems to come in two 
versions. I haven't tested, though.


rh

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Jean-Marc Lasgouttes]

Stefan Schimanski <[EMAIL PROTECTED]> writes:

>> Why cannot people use qt 4.2 for development? We have had a lot of
>> compatibility problems with qt 4.3.

I use Qt4.2 too. Usually problems are noticed pretty fast. What I am
not sure about, though, is whether somebody tests LyX 1.5.x with Qt 4.1.


> Because then I would have used QDrag::start, just to get complains by
> Qt 4.3 people that it does not complile.

I would be surprised.

JMarc

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Richard Heck]

Jean-Marc Lasgouttes wrote:

Because then I would have used QDrag::start, just to get complains by
Qt 4.3 people that it does not complile.



I would be surprised.

  

You'd be surprised if we didn't complain? Are we, as a group, that docile?

rh

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Jean-Marc Lasgouttes]

Richard Heck <[EMAIL PROTECTED]> writes:

>> I would be surprised.

> You'd be surprised if we didn't complain? Are we, as a group, that docile?

No, I'd be surprised that 4.3 cannot accept code that is valid in 4.2.

JMarc

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Richard Heck]

Jean-Marc Lasgouttes wrote:

Richard Heck <[EMAIL PROTECTED]> writes:

  

I would be surprised.
  


  

You'd be surprised if we didn't complain? Are we, as a group, that docile?



No, I'd be surprised that 4.3 cannot accept code that is valid in 4.2.

  
At least the documentation suggests that QDrag::start() doesn't exist in 
4.3 but has been replaced by QDrag::exec(), which seems to come in two 
versions. I haven't tested, though.


rh

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[José Matos]

On Saturday 15 March 2008 03:26:59 rgheck wrote:
 (Does F9 include 4.4? That's alpha right now
 anyway)

No. It usually enters rawhide (to be F9 now) when it is in the release 
candidate stage. Since we one month away from F9 planned release I am sure it 
will not come with F9. The scheduled release for F9 is 29 April.

-- 
José Abílio

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[José Matos]

On Saturday 15 March 2008 03:26:59 rgheck wrote:
> (Does F9 include 4.4? That's alpha right now
> anyway)

No. It usually enters rawhide (to be F9 now) when it is in the release 
candidate stage. Since we one month away from F9 planned release I am sure it 
will not come with F9. The scheduled release for F9 is 29 April.

-- 
José Abílio

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Stefan Schimanski]

Am 15.03.2008 um 04:39 schrieb Bo Peng:

What to do about QDrag::exec is another question. Presumably Andre  
will

have a good idea.


Why cannot people use qt 4.2 for development? We have had a lot of
compatibility problems with qt 4.3.


Because then I would have used QDrag::start, just to get complains by  
Qt 4.3 people that it does not complile.


But honestly, switching everybody to 4.2 does not make much sense.  
First some platforms just use 4.3 and it would need manual compiling  
of 4.2 to get it working, possible of course. But then, when we  
release binaries, we might need 4.3 anyway because then we _have_ to  
use the local version. And at least then we would find out about  
incompatibilities which would have been fixed long before otherwise.


Stefan

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Stefan Schimanski]

Am 15.03.2008 um 04:39 schrieb Bo Peng:

What to do about QDrag::exec is another question. Presumably Andre  
will

have a good idea.


Why cannot people use qt 4.2 for development? We have had a lot of
compatibility problems with qt 4.3.


Because then I would have used QDrag::start, just to get complains by  
Qt 4.3 people that it does not complile.


But honestly, switching everybody to 4.2 does not make much sense.  
First some platforms just use 4.3 and it would need manual compiling  
of 4.2 to get it working, possible of course. But then, when we  
release binaries, we might need 4.3 anyway because then we _have_ to  
use the local version. And at least then we would find out about  
incompatibilities which would have been fixed long before otherwise.


Stefan

Trunk does not compile.

[Bo Peng]

src/frontends/qt4/GuiToolbar.cpp: In member function 'void
lyx::frontend::GuiLayoutBox::setIconSize(QSize)':
src/frontends/qt4/GuiToolbar.cpp:663: error: 'WA_MacSmallSize' is not
a member of 'Qt'
src/frontends/qt4/GuiToolbar.cpp:664: error: 'WA_MacNormalSize' is not
a member of 'Qt'

Missing #ifdef mac?

Bo

Re: Trunk does not compile.

[Stefan Schimanski]

Am 14.03.2008 um 23:48 schrieb Bo Peng:


src/frontends/qt4/GuiToolbar.cpp: In member function 'void
lyx::frontend::GuiLayoutBox::setIconSize(QSize)':
src/frontends/qt4/GuiToolbar.cpp:663: error: 'WA_MacSmallSize' is not
a member of 'Qt'
src/frontends/qt4/GuiToolbar.cpp:664: error: 'WA_MacNormalSize' is not
a member of 'Qt'

Missing #ifdef mac?


Ah, I thought it's available on every platform. Will fix it.

Stefan

Trunk does not compile: QDrag::exec is 4.3 only.

[Bo Peng]

src/frontends/qt4/GuiWorkArea.cpp:1478: error: 'class QDrag' has no
member named 'exec'

Should we bump QT requirement to 4.3???

Bo

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[rgheck]

Bo Peng wrote:

src/frontends/qt4/GuiWorkArea.cpp:1478: error: 'class QDrag' has no
member named 'exec'

Should we bump QT requirement to 4.3???

  
Oh, no, not another one of THESE discussions! I think the last time we 
discussed this issue, we came to some kind of agreement that we'd stay 
a version behind what the `cutting edge' people think is stable. Since 
Fedora is at 4.3.3, and we're pretty cutting edge, that seems to argue 
for 4.2 as the requirement. (Does F9 include 4.4? That's alpha right now 
anyway)


What to do about QDrag::exec is another question. Presumably Andre will 
have a good idea.


rh

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[rgheck]

rgheck wrote:

Bo Peng wrote:

src/frontends/qt4/GuiWorkArea.cpp:1478: error: 'class QDrag' has no
member named 'exec'

Should we bump QT requirement to 4.3???

  
Oh, no, not another one of THESE discussions! I think the last time we 
discussed this issue, we came to some kind of agreement that we'd stay 
a version behind what the `cutting edge' people think is stable. 
Since Fedora is at 4.3.3, and we're pretty cutting edge, that seems to 
argue for 4.2 as the requirement. (Does F9 include 4.4? That's alpha 
right now anyway)


What to do about QDrag::exec is another question. Presumably Andre 
will have a good idea.


Actually, this looks pretty simple: What's called exec() in 4.3 is 
pretty much just start() in 4.2. See here: 
http://doc.trolltech.com/4.2/qdrag.html#start. So some sort of 
conditional macro will take care of this.


rh

Re: Trunk does not compile: QDrag::exec is 4.3 only.

[Bo Peng]

  What to do about QDrag::exec is another question. Presumably Andre will
  have a good idea.

Why cannot people use qt 4.2 for development? We have had a lot of
compatibility problems with qt 4.3.

Bo

Trunk does not compile.

[Bo Peng]

src/frontends/qt4/GuiToolbar.cpp: In member function 'void
lyx::frontend::GuiLayoutBox::setIconSize(QSize)':
src/frontends/qt4/GuiToolbar.cpp:663: error: 'WA_MacSmallSize' is not
a member of 'Qt'
src/frontends/qt4/GuiToolbar.cpp:664: error: 'WA_MacNormalSize' is not
a member of 'Qt'

Missing #ifdef mac?

Bo

Re: Trunk does not compile.

[Stefan Schimanski]

Am 14.03.2008 um 23:48 schrieb Bo Peng:


src/frontends/qt4/GuiToolbar.cpp: In member function 'void
lyx::frontend::GuiLayoutBox::setIconSize(QSize)':
src/frontends/qt4/GuiToolbar.cpp:663: error: 'WA_MacSmallSize' is not
a member of 'Qt'
src/frontends/qt4/GuiToolbar.cpp:664: error: 'WA_MacNormalSize' is not
a member of 'Qt'

Missing #ifdef mac?


Ah, I thought it's available on every platform. Will fix it.

Stefan