Re: Did something happen to cvs?

On 9/11/05 2:36 PM, Helge Hafting [EMAIL PROTECTED] wrote: I remember cvs went down a few weeks ago. There seems to be lot of development going on now, biut I still get this: $ cvs up /cvs/lyx: no such repository Should I change something? I couldn't find any new information about

Re: Did something happen to cvs?

On 9/11/05 2:36 PM, "Helge Hafting" <[EMAIL PROTECTED]> wrote: > I remember cvs went down a few weeks ago. > > There seems to be lot of development going on now, biut I still get > this: > $ cvs up > /cvs/lyx: no such repository > > Should I change something? I couldn't find any new

Fix MSVC build with removal of QPreambleDialogBase.ui

Could this patch be applied to development/win32/lyx.vcproj and committed, please? This updates the MSVC build per Michael's recent change. Thanks Rob Index: ./development/win32/lyx.vcproj === RCS file:

Fix MSVC build with removal of QPreambleDialogBase.ui

Could this patch be applied to development/win32/lyx.vcproj and committed, please? This updates the MSVC build per Michael's recent change. Thanks Rob Index: ./development/win32/lyx.vcproj === RCS file:

MSVC build break in ControlTexinfo.C

I get this: ControlTexinfo.C \lyx\lyx-devel\src\frontends\controllers\ControlTexinfo.C(61) : error C2039: 'sort' : is not a member of 'std' \lyx\lyx-devel\src\frontends\controllers\ControlTexinfo.C(61) : error C3861: 'sort': identifier not found, even with argument-dependent lookup I had to do

Re: MSVC build break in ControlTexinfo.C

Lars Gullik Bjønnes [EMAIL PROTECTED] writes: to get sort? can you try to include algorithm instead. #include algorithm Yes, that works. Thanks Rob

MSVC build break in ControlTexinfo.C

I get this: ControlTexinfo.C \lyx\lyx-devel\src\frontends\controllers\ControlTexinfo.C(61) : error C2039: 'sort' : is not a member of 'std' \lyx\lyx-devel\src\frontends\controllers\ControlTexinfo.C(61) : error C3861: 'sort': identifier not found, even with argument-dependent lookup I had to do

Re: MSVC build break in ControlTexinfo.C

Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > to get sort? > > can you try to include instead. > > #include > Yes, that works. Thanks Rob

Update to MSVC lyx.vcproj

The files src/insets/updatableinset.Ch were recently removed from the build. Could this patch to development/win32/lyx.vcproj please be applied? Thanks Rob lyx.vcproj.diff Description: lyx.vcproj.diff

Update to MSVC lyx.vcproj

The files src/insets/updatableinset.Ch were recently removed from the build. Could this patch to development/win32/lyx.vcproj please be applied? Thanks Rob lyx.vcproj.diff Description: lyx.vcproj.diff

Re: LyX 1.4 crashes on Windows/MinGW

Angus Leeming [EMAIL PROTECTED] writes: Michael Schmitt wrote: Has anybody ever tried to compile LyX 1.4 on Windows? Asger ported LyX 1.4 to MSVC and Visual Studio back in January. Rob Bearman uses it to compile the whole tree in about 15 minutes. I understand that he uses it in anger

Re: LyX 1.4 crashes on Windows/MinGW

Angus Leeming <[EMAIL PROTECTED]> writes: > > Michael Schmitt wrote: > > Has anybody ever tried to compile LyX 1.4 on Windows? > > Asger ported LyX 1.4 to MSVC and Visual Studio back in January. Rob Bearman > uses it to compile the whole tree in about 15 minutes.

RE: Re: On a useful Acroread wrapper for Windows

Asger Ottar Alstrup wrote: Angus Leeming wrote: My reading the WinMain docs at http://msdn.microsoft.com/library/en-us/winui/winui/windowsuse rinterface/windowing/windows/windowreference/windowfunctions/winmain.asp tells me that it should... Any clues? Well, on that

RE: Re: On a useful Acroread wrapper for Windows

> Asger Ottar Alstrup wrote: > > Angus Leeming wrote: > > > >> My reading the WinMain docs at > >> > http://msdn.microsoft.com/library/en-us/winui/winui/windowsuse rinterface/windowing/windows/windowreference/windowfunctions/winmain.asp > >> > >> tells me that it should... > >> > >> Any clues?

RE: [PATCH] reduce drastically number of calls to LyXText::getFont

Bennett == Bennett Helm [EMAIL PROTECTED] writes: Bennett From what I can tell, it comes down to this. Rob is using Bennett Mac OS X 10.4 (=Darwin 8.0.0), whereas I use 10.3.9 (= Darwin Bennett 7.9.0). Do you use the same Qt version? Is it compiled in the same way? Qt version

RE: [PATCH] reduce drastically number of calls to LyXText::getFont

> >> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes: > > > > Bennett> From what I can tell, it comes down to this. Rob is using > > Bennett> Mac OS X 10.4 (=Darwin 8.0.0), whereas I use > 10.3.9 (= Darwin > > Bennett> 7.9.0). > > > > Do you use the same Qt version? Is it compiled in

Re: [PATCH] reduce drastically number of calls to LyXText::getFont

On 6/10/05 9:36 AM, Bennett Helm [EMAIL PROTECTED] wrote: But, frankly, the difference in speed introduced with the fontcache patch is trivial compared to the slowness of lyx-140 overall: it really is unusable on the Mac, and something else must account for the slowness. I'd love to help

Re: [PATCH] reduce drastically number of calls to LyXText::getFont

On 6/10/05 12:32 PM, Bennett Helm [EMAIL PROTECTED] wrote: I have a 512MB iMac G4 (1.25GHz); it's surely not my hardware that's the issue. Perhaps it's the configuration. Here's what I've got (compiled with gcc-3.3): ./configure --with-frontend=qt --without-x

Re: [PATCH] reduce drastically number of calls to LyXText::getFont

On 6/10/05 9:36 AM, "Bennett Helm" <[EMAIL PROTECTED]> wrote: > But, frankly, the difference in speed introduced with the fontcache > patch is trivial compared to the slowness of lyx-140 overall: it really > is unusable on the Mac, and something else must account for the > slowness. > > I'd love

Re: [PATCH] reduce drastically number of calls to LyXText::getFont

On 6/10/05 12:32 PM, "Bennett Helm" <[EMAIL PROTECTED]> wrote: > I have a 512MB iMac G4 (1.25GHz); it's surely not my hardware that's > the issue. > > Perhaps it's the configuration. Here's what I've got (compiled with > gcc-3.3): > > ./configure --with-frontend=qt --without-x >

RE: Re: [Cvslog] lyx-devel src/: ChangeLog lyxsocket.C

. Rob Bearman has been pretty quick to tell us of problems in the past. -- Angus MSVC has no complaints. Thanks Rob

RE: Re: [Cvslog] lyx-devel src/: ChangeLog lyxsocket.C

t; Probably, but let's see if this code compiles with MSVC > first. Rob Bearman > has been pretty quick to tell us of problems in the past. > > -- > Angus > > MSVC has no complaints. Thanks Rob

Mac build problem

Does anyone else see this? Fresh CVS check out/build. OS X 10.4. I've built successfully on Tiger before. g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -I../../../src -I../../../src/frontends -I../../../images -I/Users/robbear/dev/qt-mac-free-3.3.4/include

Re: Mac build problem

On 5/31/05 12:43 PM, Angus Leeming [EMAIL PROTECTED] wrote: Rob Bearman wrote: Does anyone else see this? Fresh CVS check out/build. OS X 10.4. I've built successfully on Tiger before. Nope. But different Qt versions may behave differently. QBibtexDialog.C:153: error: could not convert

Mac build problem

Does anyone else see this? Fresh CVS check out/build. OS X 10.4. I've built successfully on Tiger before. g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -I../../../src -I../../../src/frontends -I../../../images -I/Users/robbear/dev/qt-mac-free-3.3.4/include

Re: Mac build problem

On 5/31/05 12:43 PM, "Angus Leeming" <[EMAIL PROTECTED]> wrote: > Rob Bearman wrote: >> Does anyone else see this? Fresh CVS check out/build. OS X 10.4. I've built >> successfully on Tiger before. > > Nope. But different Qt versions may behave differently. &g

Re: Working LyX icons on Windows, but...

On 5/22/05 12:43 PM, Angus Leeming [EMAIL PROTECTED] wrote: Next problem. The lyx shortcut and lyx entry in the start menu are present only for the user who installed lyx. (In this case the administrator.) How do I get the installer to do so for all users? I guess that this is another

Re: Working LyX icons on Windows, but...

On 5/22/05 12:43 PM, "Angus Leeming" <[EMAIL PROTECTED]> wrote: > Next problem. The lyx shortcut and lyx entry in the start menu are present > only for the user who installed lyx. (In this case the administrator.) How > do I get the installer to do so for all users? I guess that this is another >

Re: tex2lyx roundtrip problem

On 5/18/05 12:20 AM, Georg Baum [EMAIL PROTECTED] wrote: Rob Bearman wrote: The problem seems to be tex2lyx's insertion of \begin_layout Standard before the enumeration inside the box inset. Yes. The attached fix is going in now. Georg Is there a requirement that a comment character

Re: tex2lyx roundtrip problem

On 5/18/05 12:20 AM, "Georg Baum" <[EMAIL PROTECTED]> wrote: > Rob Bearman wrote: > >> The problem seems to be tex2lyx's insertion of "\begin_layout Standard" >> before the enumeration inside the box inset. > > Yes. The attached fix is g

tex2lyx roundtrip problem

1. Load test.lyx which has a box inset with an enumeration inside it 2. Export it to LaTex (test.tex) 3. Run tex2lyx on test.tex, creating tex2lyx_output.lyx When tex2lyx_output.lyx is loaded in LyX, the box inset starts with a blank line which disappears once the cursor is moved into the inset.

tex2lyx roundtrip problem

1. Load test.lyx which has a box inset with an enumeration inside it 2. Export it to LaTex (test.tex) 3. Run tex2lyx on test.tex, creating tex2lyx_output.lyx When tex2lyx_output.lyx is loaded in LyX, the box inset starts with a blank line which disappears once the cursor is moved into the inset.

Re: [rework docs] first snapshot of Userguide available

On 5/16/05 1:36 AM, Angus Leeming [EMAIL PROTECTED] wrote: Rob Bearman wrote: p.s. Angus, I noticed, that you added some patches to compile LyX with MSVC. Could you post an instruction for the compilation of LyX 1.4CVS with MSVC. Instructions for compiling with Visual Studio.NET 2003 exist

RE: LyX frontends

QSettings gives us e.g. (transparent) access to the Windows registry, where all the Window native programs put there configuration stuff and everybody expects it. When not using Qt we've a choice of either programming this access ourselves or remain some kind of sevond class citizen by doing

Re: [rework docs] first snapshot of Userguide available

On 5/16/05 1:36 AM, "Angus Leeming" <[EMAIL PROTECTED]> wrote: > Rob Bearman wrote: >>> p.s. Angus, I noticed, that you added some patches to compile LyX with >>> MSVC. Could you post an instruction for the compilation of LyX 1.4CVS >>> with MSVC.

RE: LyX frontends

> QSettings gives us e.g. (transparent) access to the Windows registry, > where all the Window native programs put there configuration stuff and > "everybody" expects it. When not using Qt we've a choice of either > programming this access ourselves or remain some kind of sevond class > citizen by

Re: [rework docs] first snapshot of Userguide available

On 5/15/05 11:59 AM, Uwe Stöhr [EMAIL PROTECTED] wrote: p.s. Angus, I noticed, that you added some patches to compile LyX with MSVC. Could you post an instruction for the compilation of LyX 1.4CVS with MSVC. Instructions for compiling with Visual Studio.NET 2003 exist in

Re: [rework docs] first snapshot of Userguide available

On 5/15/05 11:59 AM, "Uwe Stöhr" <[EMAIL PROTECTED]> wrote: > p.s. Angus, I noticed, that you added some patches to compile LyX with > MSVC. Could you post an instruction for the compilation of LyX 1.4CVS > with MSVC. Instructions for compiling with Visual Studio.NET 2003 exist in

RE: lengthvalidator.*

Btw, I keep getting errors wrt some missing boost header (something with detaisl/msvc/while.hpp or such in the path) when I try to compile LyX with MSVC. Have you ever seen such problem? Andre' No, I never have. I've been building successfully on three separate machines. Thanks Rob

RE: lengthvalidator.*

> Btw, I keep getting errors wrt some missing boost header > (something with > detaisl/msvc/while.hpp or such in the path) when I try to compile LyX > with MSVC. > > Have you ever seen such problem? > > Andre' No, I never have. I've been building successfully on three separate machines.

RE: lengthvalidator.*

Multiply defined symbols? Just remove lengthvalidator.* -- Angus Could the attached patch to development/win32/lyx.vcproj be applied, please? This takes care of the lengthvalidator/validator changes for the MSVC build. Thanks Rob lyx.vcproj.diff Description: lyx.vcproj.diff

Crash on collapse/expand collapsable inset

Launch LyX, create new file, insert box inset (or perhaps any collapsable inset), click on button to collapse, click on it again. This crashes LyX. A portion of the Windows stack trace included. I see this on both Windows and Mac. lyx.exe!lyx::support::abort() Line 23 C++

MSVC build warning

In case this is of concern... \lyx\lyx-devel\src\mover.C(82) : warning C4172: returning address of local variable or temporary Mover const Movers::operator()(string const fmt) const { SpecialsMap::const_iterator const it = specials_.find(fmt); return (it == specials_.end()) ?

RE: lengthvalidator.*

> Multiply defined symbols? Just remove lengthvalidator.* > > -- > Angus > Could the attached patch to development/win32/lyx.vcproj be applied, please? This takes care of the lengthvalidator/validator changes for the MSVC build. Thanks Rob lyx.vcproj.diff Description: lyx.vcproj.diff

Crash on collapse/expand collapsable inset

Launch LyX, create new file, insert box inset (or perhaps any collapsable inset), click on button to collapse, click on it again. This crashes LyX. A portion of the Windows stack trace included. I see this on both Windows and Mac. lyx.exe!lyx::support::abort() Line 23 C++

MSVC build warning

In case this is of concern... \lyx\lyx-devel\src\mover.C(82) : warning C4172: returning address of local variable or temporary Mover const & Movers::operator()(string const & fmt) const { SpecialsMap::const_iterator const it = specials_.find(fmt); return (it == specials_.end()) ?

Re: Windows file copy in fs_extras.c

Rob Bearman wrote: In other words, noclobber is the same as bFailIfExists. When noclobber==FALSE, you want the copy to overwrite. Instead, the current code fails the copy. Good spot! I take it LyX chewed up something it shouldn't have done? I found it while playing with Save

Re: Windows file copy in fs_extras.c

> Rob Bearman wrote: > >> In other words, "noclobber" is the same as "bFailIfExists." When >> noclobber==FALSE, you want the copy to overwrite. Instead, the current >> code fails the copy. > > Good spot! I take it LyX chewed up something

Windows file copy in fs_extras.c

In src/support/fs_extras.C, shouldn't it be thus: void copy_file(path const source, path const target, bool noclobber) { #ifdef BOOST_POSIX ... #endif #ifdef BOOST_WINDOWS - if (::CopyFile(source.string().c_str(), target.string().c_str(), !noclobber) == 0) { + if

Windows file copy in fs_extras.c

In src/support/fs_extras.C, shouldn't it be thus: void copy_file(path const & source, path const & target, bool noclobber) { #ifdef BOOST_POSIX ... #endif #ifdef BOOST_WINDOWS - if (::CopyFile(source.string().c_str(), target.string().c_str(), !noclobber) == 0) { + if

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

Based on yesterday's changes, could this patch be committed please? It contains the updates to config.h and lyx.vcproj in the development\win32 directory. Thanks Rob msvc.diff Description: msvc.diff

RE: Compiling RunCommand with MSVC

Rob, it seems that popen et al. are all documented members of the Windows API, so I fail to see why you need to disable (win32_kludge.diff) RunCommand in src/support/filetools.C. The one possible problem seems to be that popen and pclose are documented as having a _ prefix. Do you

RE: Compiling temname.C on MSVC

Rob, same idea but this time for tempname.C. It appears from the docs that we just need a few underscores. Does the attached patch enable you to compile? mktemp: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/vclib/html/_crt__mktemp.2c_._wmktemp.asp Equivalent

RE: RE: Compiling temname.C on MSVC

And is this definition telling the truth? Ie, do you have the mktemp function as well as the _mktemp function? Yes.

RE: RE: Compiling temname.C on MSVC

And is this definition telling the truth? Ie, do you have the mktemp function as well as the _mktemp function? I should note that for filetools.C, I must prepend the underscore on popen and pclose. That might not have been clear since I stated that the existing kludge isn't necessary. Thanks

RE: RE: RE: Compiling temname.C on MSVC

I propose to modify configure.ac as attached so that running autogen.sh produces the also attached changes to the generated src/config.h.in. You don't actually run autogen.sh at all of course, but I anticipate that you'd use these config.h.in changes as a template with which to modify

RE: RE: RE: Compiling temname.C on MSVC

Does this work for you? (Everything is, of course, fine here.) If so, please post your local changes to config.h and I'll update development/Win32 accordingly. (I'll remove win32_kludge.diff also.) -- Angus Here's the patch to config.h. Everything builds fine, and it's nice to see

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

Based on yesterday's changes, could this patch be committed please? It contains the updates to config.h and lyx.vcproj in the development\win32 directory. Thanks Rob msvc.diff Description: msvc.diff

RE: Compiling RunCommand with MSVC

> Rob, > > it seems that popen et al. are all documented members of the > Windows API, > so I fail to see why you need to disable (win32_kludge.diff) > RunCommand in > src/support/filetools.C. The one possible problem seems to be > that popen > and pclose are documented as having a _

RE: Compiling temname.C on MSVC

> Rob, > > same idea but this time for tempname.C. It appears from the > docs that we > just need a few underscores. Does the attached patch enable > you to compile? > > mktemp: > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/vclib/html/_crt__mktemp.2c_._wmktemp.asp >

RE: RE: Compiling temname.C on MSVC

> And is this definition telling the truth? Ie, do you have the mktemp > function as well as the _mktemp function? Yes.

RE: RE: Compiling temname.C on MSVC

> And is this definition telling the truth? Ie, do you have the mktemp > function as well as the _mktemp function? I should note that for filetools.C, I must prepend the underscore on popen and pclose. That might not have been clear since I stated that the existing kludge isn't necessary.

RE: RE: RE: Compiling temname.C on MSVC

> I propose to modify configure.ac as attached so that running > autogen.sh produces the also attached changes to the generated > src/config.h.in. You don't actually run autogen.sh at all of > course, but I > anticipate that you'd use these config.h.in changes as a > template with > which to

RE: RE: RE: Compiling temname.C on MSVC

> Does this work for you? (Everything is, of course, fine here.) > > If so, please post your local changes to config.h and I'll update > development/Win32 accordingly. (I'll remove win32_kludge.diff also.) > > -- > Angus > Here's the patch to config.h. Everything builds fine, and it's nice

RE: On compiling LyX 1.4 on Windows with MSVC.

the changes I've just committed will probably break your build. To help you resurrect things, I attach the current config.h.in from which config.h is generated. I also attach the changes from the previous config.h.in. The new macros HAVE_DUP2, HAVE_SELECT, HAVE_SOCKET and USE_ISPELL

RE: On compiling LyX 1.4 on Windows with MSVC.

In case you're interested in my config.h and if it helps resolve any confusion from my previous message, I'm including that here for your reference. Thanks Rob config.h Description: config.h

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

Looking at your error messages below, I'm frankly surprised by things going wrong in lyxserver.C Why are you compiling code invoking mkfifo and fcntl. Is HAVE_MKFIFO defined? I'm only using what was defined in the original commit of config.h (I've always depended on the kindness of

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

How interesting! HAVE_SELECT and HAVE_SOCKET are definitely not defined using mingw/minsys. HAVE_DUP2 is defined on mingw/minsys (my very bad), so we really need another test to prevent USE_ISPELL from being defined. I'll think on it. Looking at your error messages below, I'm frankly

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

I think that you should modify your config.h so that HAVE_SYS_TIME_H is not defined... Ok... --- src/frontends/LyXView.C 2005/04/26 10:30:22 1.52 +++ src/frontends/LyXView.C 2005/04/26 15:39:37 @@ -39,8 +39,10 @@ #include boost/bind.hpp +#ifndef _WIN32 #ifdef

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

Looking at the other bits of win32_kludge.diff, can you confirm that 'time' and 'isalpha' are not in namespace std? Correct. I goofed. 'isalpha' *is* in namespace std.

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

Looking at the other bits of win32_kludge.diff, can you confirm that 'time' and 'isalpha' are not in namespace std? Correct. I goofed. 'isalpha' *is* in namespace std. Argh. The compiler doesn't agree with the docs and says isalpha is not a member of std. I verified the

RE: RE: RE: On compiling LyX 1.4 on Windows with MSVC.

Please add these (with appropriate define/undef) to your config.h: /* Define to 1 if you have the sys/utime.h header file. */ /* #undef HAVE_SYS_UTIME_H */ /* Define to 1 if you have the utime.h header file. */ #define HAVE_UTIME_H 1 and check that the attached rob.diff does the job. (It

RE: On compiling LyX 1.4 on Windows with MSVC.

Anyway, I read it that win32_kludge.diff should now be something like the attached. Correct? Angus Yes, that's just what I have. Rob

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

Rob, what happens if you define CXX_GLOBAL_CSTD in your config.h ? Does it mean you no longer need these two kludges, or does it break things elsewhere? Index: src/DepTable.C === RCS file:

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

Given that we have: src/frontends/qt2/QLyXKeySym.C: typedef mapstring, QTextCodec * EncodingMap; EncodingMap encoding_map; The change below is obviously an improvement, even though there's no reason why a sane compiler shouldn't compile the original too. Nonetheless, can I ask

RE: On compiling LyX 1.4 on Windows with MSVC.

> the changes I've just committed will probably break your > build. To help you > resurrect things, I attach the current config.h.in from which > config.h is > generated. I also attach the changes from the previous > config.h.in. The > new macros HAVE_DUP2, HAVE_SELECT, HAVE_SOCKET and

RE: On compiling LyX 1.4 on Windows with MSVC.

In case you're interested in my config.h and if it helps resolve any confusion from my previous message, I'm including that here for your reference. Thanks Rob config.h Description: config.h

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

> Looking at your error messages below, I'm frankly surprised > by things going > wrong in lyxserver.C Why are you compiling code invoking > mkfifo and fcntl. > Is HAVE_MKFIFO defined? I'm only using what was defined in the original commit of config.h (I've always depended on the kindness of

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

> How interesting! HAVE_SELECT and HAVE_SOCKET are definitely > not defined > using mingw/minsys. > > HAVE_DUP2 is defined on mingw/minsys (my very bad), so we really need > another test to prevent USE_ISPELL from being defined. I'll > think on it. > > Looking at your error messages below, I'm

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

> I think that you should modify your config.h so that > HAVE_SYS_TIME_H is not > defined... Ok... > > --- src/frontends/LyXView.C 2005/04/26 10:30:22 1.52 > +++ src/frontends/LyXView.C 2005/04/26 15:39:37 > @@ -39,8 +39,10 @@ > > #include > > +#ifndef _WIN32 > #ifdef

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

> > Looking at the other bits of win32_kludge.diff, can you > > confirm that 'time' > > and 'isalpha' are not in namespace std? > > > > Correct. I goofed. 'isalpha' *is* in namespace std.

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

> > > Looking at the other bits of win32_kludge.diff, can you > > > confirm that 'time' > > > and 'isalpha' are not in namespace std? > > > > > > > Correct. > > I goofed. 'isalpha' *is* in namespace std. > Argh. The compiler doesn't agree with the docs and says isalpha is not a member of

RE: RE: RE: On compiling LyX 1.4 on Windows with MSVC.

> Please add these (with appropriate define/undef) to your config.h: > > /* Define to 1 if you have the header file. */ > /* #undef HAVE_SYS_UTIME_H */ > /* Define to 1 if you have the header file. */ > #define HAVE_UTIME_H 1 > > and check that the attached rob.diff does the job. (It may be >

RE: On compiling LyX 1.4 on Windows with MSVC.

> Anyway, I read it that win32_kludge.diff should now be something like > the attached. Correct? > > Angus > > Yes, that's just what I have. Rob

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

> Rob, what happens if you define CXX_GLOBAL_CSTD in your config.h ? > Does it mean you no longer need these two kludges, or does it > break things > elsewhere? > > Index: src/DepTable.C > === > RCS file:

RE: RE: On compiling LyX 1.4 on Windows with MSVC.

> Given that we have: > src/frontends/qt2/QLyXKeySym.C: > typedef map EncodingMap; > EncodingMap encoding_map; > > The change below is obviously an improvement, even though > there's no reason > why a sane compiler shouldn't compile the original too. > >

Unattended memory leak

Bring up LyX, create a new document, then do nothing but watch the Mem Usage column under the Windows task manager. LyX gobbles up 4k every five seconds or so. I've left LyX running unattended and wondered why the thing always seems to crash when I come back to it. This probably explains it.

RE: Unattended memory leak

Rob, you are using Qt/Windows Free Edition, aren't you? I am quite sure that the problem in within the Qt library, not within LyX. However, the Qt/Win Free guys have done a good job in fixing memory leaks and other bugs (e.g., the library used to cause 100% CPU usage after a few

RE: RE: Unattended memory leak

If you can report these problems on the mailing list (mirrored on gmane at gmane.comp.kde.devel.cygwin), that'd be great! Especially if you can create a small standalone program demonstrating the problem. -- Angus It's quite possible that I'm mistaken about having the latest CVS of Qt -

RE: Unattended memory leak

Yes, that's what I'm using (http://kde-cygwin.sourceforge.net/qt3-win32/compile-net.php from Asger's notes in the development\win32\readme.txt). As far as I can tell, I've got the latest of that branch, anyway - a cvs diff shows no changes. Should I be using something else? cvs diff

Unattended memory leak

Bring up LyX, create a new document, then do nothing but watch the Mem Usage column under the Windows task manager. LyX gobbles up 4k every five seconds or so. I've left LyX running unattended and wondered why the thing always seems to crash when I come back to it. This probably explains it.

RE: Unattended memory leak

> Rob, you are using Qt/Windows Free Edition, aren't you? I am > quite sure > that the problem in within the Qt library, not within LyX. > However, the > Qt/Win Free guys have done a good job in fixing memory leaks > and other > bugs (e.g., the library used to cause 100% CPU usage after a

RE: RE: Unattended memory leak

> If you can report these problems on the mailing list > (mirrored on gmane at > gmane.comp.kde.devel.cygwin), that'd be great! Especially if you can > create a small standalone program demonstrating the problem. > > -- > Angus It's quite possible that I'm mistaken about having the latest CVS

RE: Unattended memory leak

> > Yes, that's what I'm using > > (http://kde-cygwin.sourceforge.net/qt3-win32/compile-net.php from > > Asger's notes in the development\win32\readme.txt). As far as I can > > tell, I've got the latest of that branch, anyway - a cvs > diff shows no > > changes. Should I be using something else?

RE: lyx-devel src/: Bidi.C Bidi.h ChangeLog coordcache.C coord ...

CVSROOT: /usr/local/lyx/cvsroot Module name: lyx-devel Repository: lyx-devel/src/support/ Changes by: [EMAIL PROTECTED] 05/04/26 12:30:24 Modified files: lyx-devel/src/: Bidi.C Bidi.h ChangeLog coordcache.C coordcache.h ispell.C lyxserver.C

RE: RE: lyx-devel src/: Bidi.C Bidi.h ChangeLog coordcache.C coord ...

Many thanks for bearing with me through this, Rob. I hope that the next commit will remove ispell.C, lyxserver.C, lyxsocket.C, client/client.C, support/os_win32.C and support/socktools.C from the kludge.diff file entirely. If we could make the kludge file go away altogether, I'd be

Menu pulldown results in blank taskbar buttons - LyX Windows

On Windows, I noticed that menu invocation results in the appearance of a new blank taskbar button which goes away as soon as the menu is released. Hierarchical menus result in even more blank taskbar buttons, again going away once the submenu is released. This does not happen with Ruurd's

RE: lyx-devel src/: Bidi.C Bidi.h ChangeLog coordcache.C coord ...

> CVSROOT: /usr/local/lyx/cvsroot > Module name: lyx-devel > Repository: lyx-devel/src/support/ > Changes by: [EMAIL PROTECTED] 05/04/26 12:30:24 > > Modified files: > lyx-devel/src/: Bidi.C Bidi.h ChangeLog coordcache.C > coordcache.h ispell.C

RE: RE: lyx-devel src/: Bidi.C Bidi.h ChangeLog coordcache.C coord ...

> Many thanks for bearing with me through this, Rob. I hope > that the next > commit will remove ispell.C, lyxserver.C, lyxsocket.C, > client/client.C, > support/os_win32.C and support/socktools.C from the kludge.diff file > entirely. If we could make the kludge file go away altogether, I'd

Menu pulldown results in blank taskbar buttons - LyX Windows

On Windows, I noticed that menu invocation results in the appearance of a new blank taskbar button which goes away as soon as the menu is released. Hierarchical menus result in even more blank taskbar buttons, again going away once the submenu is released. This does not happen with Ruurd's

  1   2   >