On Sun, Nov 05, 2006 at 05:45:35PM +0100, Georg Baum wrote:
> Am Sonntag, 5. November 2006 17:19 schrieb Enrico Forestieri:
> > where os is an odocstream. If I change these lines to:
> >
> > if (par_begin + 1 == par_end)
> > os << "% Preview source code for current paragraph\n\n";
> > else
> > os << "% Preview source code for selected paragraphs\n\n";
> >
> > i.e., if I don't try to output an integral type to os, then everything
> > works. I don't understand the reason of this. Everything I tried failed.
> > I really don't know anything about facets and char_traits (there's
> > nothing about them in my 1994 book by Stroustrup), so I think I am lost
> > here. Any kind soul has a suggestion on what to do?
>
> If you want to learn more about the locale stuff you can download Appendix
> D of the current edition from Stroustrups web site.
Thanks, I'll try to digest that. At a first glance it seems really
irksome...
> I guess that something happens in operator<<(odocstream, int) that
> invalidates the stream. Therefore the following stuff is not output
> anymore.
I don't see that operator in the LyX sources, so I looked at the compiler
includes. I think that the following (taken from ostream.tcc) is relevant?
Maybe a num_put facet is needed?
template<typename _CharT, typename _Traits>
basic_ostream<_CharT, _Traits>&
basic_ostream<_CharT, _Traits>::
operator<<(long __n)
{
sentry __cerb(*this);
if (__cerb)
{
ios_base::iostate __err = ios_base::iostate(ios_base::goodbit);
try
{
bool __b = false;
const char_type __c = this->fill();
const ios_base::fmtflags __fmt = (this->flags()
& ios_base::basefield);
const __num_put_type& __np = __check_facet(this->_M_num_put);
if ((__fmt & ios_base::oct) || (__fmt & ios_base::hex))
{
const unsigned long __l = static_cast<unsigned long>(__n);
__b = __np.put(*this, *this, __c, __l).failed();
}
else
__b = __np.put(*this, *this, __c, __n).failed();
if (__b)
__err |= ios_base::badbit;
}
catch(...)
{ this->_M_setstate(ios_base::badbit); }
if (__err)
this->setstate(__err);
}
return *this;
}
> I have no idea which facet is involved here, but Step-by-step debugging
> would tell that quickly. Is it still impossible to run gdb?
The point is that I am not able to link with debug info (-g) as the
final link stage fails with a "Memory exhausted" error.
This is what I have:
$ cat /proc/meminfo
total: used: free:
Mem: 267304960 192335872 74969088
Swap: 201326592 24182784 177143808
MemTotal: 261040 kB
MemFree: 73212 kB
MemShared: 0 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 261040 kB
LowFree: 73212 kB
SwapTotal: 196608 kB
SwapFree: 172992 kB
After the failed link, the swap size was enlarged till about 380 Mbytes.
Windows can automatically enlarge its swap file, but I think it doesn't
try (isn't able?) to go above 1.5 times the physical memory. I should
try and see if this can be changed through some preferences (which I
think means tweaking the register).
Thanks for the pointers.
--
Enrico
