Unsual behavior UI Preference-path (PrefPathsUi.ui)
There is something unusual behaviour of preference path UI (PrefPathsUi), Tools>Preferences>Paths. The shortcut Alt-E (&Example files:) won't go to the example files, but always go to Document templates (above Example files). I don't see any shortcut conflict in this PrefPathsUi, so Alt-E should go to &Example files. I use 1.6.x svn for the id translation, but I tried using several character in the translation version but the same ... it won't go to the "Example files" area. Please let me know if it happens in my computer only. Regards /was/
Re: Svn server shutdown and reemergence
On Fri, Mar 20, 2009 at 02:19, Lars Gullik Bjønnes wrote: > Sorry for being a bit slack about this, lots of work intruding. > > Anyhow, regardless of what we end up doing later: > > The subversion server at aussie will be switched into read-only mode about > midnight CET 20/21 march. (yes less than 24 hours) > > When the next backup round goes I will use that to update the server at > lyx.lyx.org, after tiny bit of verification I will make that live. > This work is now progressing at a steady pace. The svn server at aussie is shutdown (or made read-only). Dns has moved. svn.lyx.org should now be a CNAME for lyx.lyx.org. I have some work to complete at the new server before it goes live, but that will have to wait till tomorrow and a more awake me. The remaining work (for the repo), is to setup hooks, do some test checkouts and switches. -- Lgb
Re: LyX slowness (2) - network usage.
First of all, there was a thread some time ago. In this thread Stefan has explained a bit why it was necessary and when: http://thread.gmane.org/gmane.editors.lyx.devel/114759 . I think I will investigate this point somewhat more. From what I understand in that thread, the point is that we might have several definitions of macro \foo, so that we have to know where they are to know which one to pick. Actually, this would be neatly handled by an integration in updateLabels, since we would know at each instant which definition of a macro is the right one. This is similar to what we do with counters. Since the updateLabels machinery is ran anyway, this would make the cost of macros negligible. JMarc
Small problem AltInstaller
Uwe, I installed LyX with the AltInstaller at the pc at work and I noticed the following: I have two home-directories, one is C:\Documents and Setting\vincent, the other one is on the network and called H:\. Everyone that logs onto this pc gets a home directory at the C:\ drive and everyone has its own home H:\. Now Aspell got installed for all users (I might have chosen this, but I don't remember precisely), but for each user that has a home-directory on the C:\ drive a new folder H:\vincent, etc. was made for Aspell. I hope you can fix it. Vincent
Re: LyX slowness (2) - network usage.
Yes, but the problem is that you CAN'T do this just by comparing strings. In many cases, to be sure, you could tell that the file is loaded by comparing strings. But you can't be sure it isn't loaded just by comparing strings. Maybe it's loaded, but under a different pathname. I'd think that this could be circumvented pretty easily. When the InsetInclude needs to load the file with the "user specified file name" FileName::user_defined, it resolves the "normalized" name, caches it as FileName::normalized and loads the file. Now the file is in the BufferList under the normalized name (and we could make sure that the normalized name is just everywhere internally). loadIfNeeded would then only have to check whether the FileName::normalized is in the BufferList (when it is not empty of course). This can be a simple string comparison. I pretty much think (and Georg sort of agreed) that this was the design behind the FileName class, but things got messed up when using qt-stuff as the real backbone. Vincent
Re: LyX slowness (2) - network usage.
rgheck wrote: > Vincent van Ravesteijn - TNW wrote: >> I might be a bit annoying, but let's pretend we don't know the problem >> with the filesystem checks. Then, how would you explain to someone that >> you're implementing administrative tools, touching many files and >> thinking of all different special cases with the risk you forget one, >> while you can find out whether a file is loaded just by looping over all >> buffers in the memory and comparing a handful of strings to each other. >> As I have said somewhere else, you can probably do very very many string >> comparisons before the user will notice. >> >> > Yes, but the problem is that you CAN'T do this just by comparing > strings. In many cases, to be sure, you could tell that the file is > loaded by comparing strings. But you can't be sure it isn't loaded just > by comparing strings. Maybe it's loaded, but under a different pathname. But you can first compare strings and only do the expensive equivalence test if the strings don't match. loadIfNeeded() can only cause performance problems if it is called very often. If it is called very often, then all needed files will be loaded after few iterations, and the simple string comparison will always succeed. Georg
RE: LyX 1.6.2: possible performance issue inside master document
Vincent van Ravesteijn - TNW wrote: >>> Do we need a new class that we use internally. In this class we store > >>> a filename, which is case-sensitive on case-sensitive filesystem, > that >>> is guaranteed to be a long filename and not a short one (on Windows), > >>> that is not a symlink, that is relative or absolute (pick one or > both). If you do it like that please be careful that the normalized name is only used for checking equivalence. In the past we invested a lot of work to ensure that file names stored in .lyx files stay always exactly like the user entered them (relative, absolute, case etc). This is IMHO important, think e.g. of documents that are both edited on machines with case sensitive and on others with case insensitive file systems. In other cases it is important that relative names stay relative and absolute ones stay absolute. BTW, I am pretty sure that you do only need to check the equivalence of two filenames in a few cases (e.g. when opening .lyx files). For example, if you have the same file in two graphics insets using different names, you do not really need to know that both files are the same. Of course that may result in two conversions, but given the difficulties with the equivalence check and caching it might even be faster accumulated over the whole editing session. Or if the user changes the included file, and e.g. only changes the case, the document should be marked modified. It would be very annoying if LyX was so "clever" to recognize that both names are equivalent and not let the user save the document. I believe that the performance problems could be solved quite easily by basing FileName::operator==() on simple string comparison again and implenting an equivalence() method that is used only when needed. >>This could work, though it looks as if we're duplicating what QFileInfo >>does, and we might run into similar problems about caching to what we >>had before. I don't know---but I think this makes some sense out of why >>they want to return false if the files don't exist. The problem, as I > see >>it, is that QFileInfo objects are getting created so often, which > requires >>filesystem access, even independently of the caching stuff. And I'm not >>sure how that can be avoided. > > Why is the class called FileName by the way ? Because the original purpose of this class was to store file names (and not more). Before this class was introduced, file names were stored as plain strings. Sometimes they were absolute, sometimes relative. To make it worse, the base directory of relative names was not always clear. Therefore that class was introduced, which encapsulated a file name and made sure that the base directory of relative names was always known (and it did some minor other stuff, too). During the transition to unicode it was extended to handle filename encoding conversions, too. > This really sounds like a > class that governs the FileNAME and all related things. And QFileInfo > really sounds like things that have to do with the physical file. Exactly. Unfortunately the current FileName class mixes these things. > Anyway, I want to have a class which can freely be instantiated and > another class with the warning that it can have performance issues > because it's related to files on the disk. We might duplicate things, > but with our own simple FileName class we are _sure_ that we don't > access the disk. By the way, to convert filenames and stuff we still can > use QFileInfo to be cross-platform. We just use it once, and when the > filename is in our own class, we are sure that it has the correct > format. > > That was the idea. What you describe is exactly the orginal idea of the FileName class and can be seen e.g. in the 1.5.x sources. Georg
Re: LyX slowness (2) - network usage.
Vincent van Ravesteijn - TNW wrote: I might be a bit annoying, but let's pretend we don't know the problem with the filesystem checks. Then, how would you explain to someone that you're implementing administrative tools, touching many files and thinking of all different special cases with the risk you forget one, while you can find out whether a file is loaded just by looping over all buffers in the memory and comparing a handful of strings to each other. As I have said somewhere else, you can probably do very very many string comparisons before the user will notice. Yes, but the problem is that you CAN'T do this just by comparing strings. In many cases, to be sure, you could tell that the file is loaded by comparing strings. But you can't be sure it isn't loaded just by comparing strings. Maybe it's loaded, but under a different pathname. Although this will probably be a solution to my problem and it certainly seems reasonable, I'd would also like to see a FileName class that compares filenames (in a cross-platform way) that does not access the filesystem every time. It is very hard for me to see how to do that. Of course, you can check if the filesystem is case sensitive and make use of that information in the string comparisons (as QFileInfo does). But what about absolute and relative paths? What about symlinked files? Worse, symlinked directories that occur in the path name? On my main machine, e.g., /home/rgheck/files/file.lyx and /mnt/mail/files/file.lyx are the same file, because /home/rgheck/files is a symlink to /mnt/mail/files. But not on my laptop. So that's not a cross-platform but a *cross-machine* issue, and I can't see that there's any possible way to deal with it except by asking the OS to help us. Maybe it would be possible to cache that information ourselves somehow. But if we go that way, we accept that it won't work in every case, because we'd be assuming that the answer to the question "Do these two filenames point at the same file?" won't change. Here's another idea: Have each InsetInclude cache a pointer to the buffer in which its child resides. When we call InsetInclude::loadIfNeeded(), we check the buffer list to make sure that Buffer is still open, which is cheap, and if so, just return it. This will work in the great majority of cases. We'd need some kind of way to invalidate the cache when necessary. This would be e.g. when a buffer is saved under a new name. Then an InsetInclude that pointed to it would point to the wrong buffer, and it'd need to be reloaded. Are there other cases? I suppose the same corner cases exist here, too: There could be changes to the underlying filesystem that caused what used to be the right buffer no longer to be. But maybe these are not very plausible. And it would be possible to check for that when LyX wasn't otherwise busy. rh
Re bug 5526
I just wanted to reinforce the comments of Jean-Marc Lasgouttes in reference to bug 5526 (broken screen-recenter) that this bug is quite annoying to emacs users, and is a step backward from the behavior of earlier versions (pre-1.6) of LyX. Dave Raymond
RE: LyX slowness (2) - network usage.
>> As far as I understood, there are links to macros stored in a table. >> This means that the table says that Macro_x is used in paragraph 10, >> position 12 etc. If the document changes, one has to adjust these >> numbers as the location might now be paragraph 11, position 12 after >> a new paragraph is inserted. >> > > But these links are only needed when a macro is changed, right? > Shouldn't the expensive operation (look over all files) be done on > this occasion only? > > >It seems to me that there are two (potential) problems. I've made >suggestions about this elsewhere in the other thread, but let me >repeat them here. >(i) The filesystem checks that are causing the slowdown for Vincent >simply don't need to be done as often as they are. The checks are >generated by a call to loadIfNeeded(). It seems to me that there >are only a few occasions when a file could need to be loaded if it >wasn't already. E.g., initially; if an InsetInclude has been added >or modified; or if the default master has been changed; if a file >has been saved under a new name; if a buffer has been closed. So we >could have some flag, maybe in the BufferList, that meant: you don't >need to check this, nothing has changed. And it could be set and >cleared by e.g. InsetInclude constructors. I don't think there are >that many cases to consider. > >I'd be happy to work on at least the former, if the general idea >seems reasonable to people. > I might be a bit annoying, but let's pretend we don't know the problem with the filesystem checks. Then, how would you explain to someone that you're implementing administrative tools, touching many files and thinking of all different special cases with the risk you forget one, while you can find out whether a file is loaded just by looping over all buffers in the memory and comparing a handful of strings to each other. As I have said somewhere else, you can probably do very very many string comparisons before the user will notice. Although this will probably be a solution to my problem and it certainly seems reasonable, I'd would also like to see a FileName class that compares filenames (in a cross-platform way) that does not access the filesystem every time. >(ii) The updateMacros() call is probably being done too often, and >for similar reasons. It must be possible to have a better sense than >we apparently do of when it needs to be done, and set and clear a >flag that will tell us when it does need to be done. E.g., if a macro >is modified; if a paragraph is added or deleted; etc. We do this kind >of thing for lots of other purposes, e.g., the FitCursor stuff and the >drawing optimizations. First of all, there was a thread some time ago. In this thread Stefan has explained a bit why it was necessary and when: http://thread.gmane.org/gmane.editors.lyx.devel/114759 . I think I will investigate this point somewhat more. >rh Vincent
Re: LyX slowness (2) - network usage.
Jean-Marc Lasgouttes wrote: "Vincent van Ravesteijn - TNW" writes: As far as I understood, there are links to macros stored in a table. This means that the table says that Macro_x is used in paragraph 10, position 12 etc. If the document changes, one has to adjust these numbers as the location might now be paragraph 11, position 12 after a new paragraph is inserted. But these links are only needed when a macro is changed, right? Shouldn't the expensive operation (look over all files) be done on this occasion only? It seems to me that there are two (potential) problems. I've made suggestions about this elsewhere in the other thread, but let me repeat them here. (i) The filesystem checks that are causing the slowdown for Vincent simply don't need to be done as often as they are. The checks are generated by a call to loadIfNeeded(). It seems to me that there are only a few occasions when a file could need to be loaded if it wasn't already. E.g., initially; if an InsetInclude has been added or modified; or if the default master has been changed; if a file has been saved under a new name; if a buffer has been closed. So we could have some flag, maybe in the BufferList, that meant: you don't need to check this, nothing has changed. And it could be set and cleared by e.g. InsetInclude constructors. I don't think there are that many cases to consider. (ii) The updateMacros() call is probably being done too often, and for similar reasons. It must be possible to have a better sense than we apparently do of when it needs to be done, and set and clear a flag that will tell us when it does need to be done. E.g., if a macro is modified; if a paragraph is added or deleted; etc. We do this kind of thing for lots of other purposes, e.g., the FitCursor stuff and the drawing optimizations. I'd be happy to work on at least the former, if the general idea seems reasonable to people. rh
Re: listings doesn't work in beamer
Jürgen Spitzmüller wrote:
> Neal Becker wrote:
>> I can find no way to do this within lyx. I hope for a solution.
>
> It's not possible (apart from using \begin{frame}[fragile]...\end{frame}
> in ERT):
> http://bugzilla.lyx.org/show_bug.cgi?id=3710
>
> Jürgen
AFAICT it's not possible to insert \begin{frame}[fragile]...\end{frame}
either - the only way I could get it to work is to include a file that
contains that.
Re: LyX 1.6.2: possible performance issue inside master document
Helge Hafting wrote: rgheck wrote: Vincent van Ravesteijn - TNW wrote: Maybe it's already clear, Yes, I understand now. How do we solve it then ? Do we need a new class that we use internally. In this class we store a filename, which is case-sensitive on case-sensitive filesystem, that is guaranteed to be a long filename and not a short one (on Windows), that is not a symlink, that is relative or absolute (pick one or both). This could work, though it looks as if we're duplicating what QFileInfo does, and we might run into similar problems about caching to what we had before. I don't know---but I think this makes some sense out of why they want to return false if the files don't exist. The problem, as I see it, is that QFileInfo objects are getting created so often, which requires filesystem access, even independently of the caching stuff. And I'm not sure how that can be avoided. Anyway, here's another idea. Why are we calling loadIfNeeded() every time? It's there that the check is made that the file is loaded in a buffer, which (if I'm remembering right) calls == to see. It seems to me that there are only a few occasions when a file could need to be loaded if it wasn't before. E.g., if an InsetInclude has been added or modified; or if the default master has been changed. So maybe we could have some flag, maybe in the BufferList, that meant: you don't need to check this, nothing has changed. And it could be set and cleared by e.g. InsetInclude constructors. Wouldn't it be better to remove the check completely? Instead of checking if we need to call "loadIfNeeded" all the time - don't. Instead, check (and loasd) only when an insetinclude is changed/modified. That way, the test don't merely get cheaper, the test goes away which is even better. That's roughly my idea, but there are other things that could happen, I think. A child, or master, could be closed for some reason; the master could be saved under a new name; and so forth. So there are two options: (i) Call loadIfNeeded() on all those occasions; (ii) Set a flag on those occasions, which can be checked at the beginning of loadIfNeeded(), and then the check is skipped if it's not set. I prefer (ii) only because I can well imagine other reasons to want to check this flag. (The flag would mean something like: The loaded buffers and/or master-child relationships have been altered.) Richard
Re: LyX slowness (2) - network usage.
Abdelrazak Younes wrote: Last time I touched that part, the full updateLabel() call was done only when a new section or caption was created, not with each keystroke. Even when modifying a section, only the relevant toc item was changed. If this has changed, this means that there's a superfluous additional call somewhere. It's updateMacros() that's the problem, not updateLabels(). rh
Re: TeX capacity exceeded: sorry, main memory [main memory size=1500000]
Jean-Pierre Chrétien wrote:
rgheck writes:
Waluyo Adi Siswanto wrote:
Actually I have a problem (in LyX 1.6.2) when I want to set the page
without number under the Part environment using ERT
\thispagestyle{empty}. The document class is book(koma-script).
[...]
The difference is that hyperref is turned on in the 1.6.2 version. If
you turn it off, you don't get the error.
Sure, but the ERT should not be in the Part style anyway.
Put it alone on a standard style line and compilation works all right.
But then, so far as I can see, the ERT is on the next page, and the
attempt to turn off the page number fails.
Granted, this should really be done in the document class.
rh
RE: LyX slowness (2) - network usage.
>> Guessing ? >> >> I'm pretty sure what the problem causes for me. >> > >OK, I did not mean to upset you... I was under the >impression that some other people not using networked >files had this problem. No, you didn't upset me.. I just sounded like that. Anyway, I'm not sure either why other people are experiencing this problem. Could it be a virus scanner.. which doesn't like many file accesses a second ? >Jmarc Vincent
Re: listings doesn't work in beamer
Neal Becker wrote:
> I can find no way to do this within lyx. I hope for a solution.
It's not possible (apart from using \begin{frame}[fragile]...\end{frame} in
ERT):
http://bugzilla.lyx.org/show_bug.cgi?id=3710
Jürgen
Re: TeX capacity exceeded: sorry, main memory [main memory size=1500000]
rgheck writes:
>
> Waluyo Adi Siswanto wrote:
> > Actually I have a problem (in LyX 1.6.2) when I want to set the page
> > without number under the Part environment using ERT
> > \thispagestyle{empty}. The document class is book(koma-script).
[...]
> The difference is that hyperref is turned on in the 1.6.2 version. If
> you turn it off, you don't get the error.
Sure, but the ERT should not be in the Part style anyway.
Put it alone on a standard style line and compilation works all right.
--
Jean-Pierre
Re: LyX slowness (2) - network usage.
Guessing ? I'm pretty sure what the problem causes for me. OK, I did not mean to upset you... I was under the impression that some other people not using networked files had this problem. JMarc
listings doesn't work in beamer
To do listings (or verbatim) in beamer requires:
\begin{slide}[fragile]
I can find no way to do this within lyx. I hope for a solution.
Re: r28879 - in /lyx-devel/trunk/src/frontends/qt4/ui: Delimi...
Enrico Forestieri wrote: > Jürgen, may I do the same on branch? OK. Jürgen
RE: LyX slowness (2) - network usage.
>> Just any master with a number of childs would do. >> >> But I believe you can't reproduce on Linux, and your files should be >> on a filesystem that has a somewhat slower access than your harddisk. > >I wanted to try on a mac, but I do not have network drives here. We >need a platform where a proper profiling can be done instead of guessing. Guessing ? I'm pretty sure what the problem causes for me. - I can reproduce the problem * on two different PCs, * with two different types of slow filesystems. - I can solve the problem by removing four lines of code (in FileName::==()) that were there to solve 'rare' cases (so disabling those does not change the behaviour in most cases). - I've shown a network access graph that supports the hypothesis of accessing the file system. - Bug 5705 shows exactly the same conditions and result. >Jmarc Vincent
Re: LyX slowness (2) - network usage.
"Vincent van Ravesteijn - TNW" writes: > Just any master with a number of childs would do. > > But I believe you can't reproduce on Linux, and your files should be on > a filesystem that has a somewhat slower access than your harddisk. I wanted to try on a mac, but I do not have network drives here. We need a platform where a proper profiling can be done instead of guessing. JMarc
Re: r28879 - in /lyx-devel/trunk/src/frontends/qt4/ui: Delimi...
On Fri, Mar 20, 2009 at 03:14:17PM -, for...@lyx.org wrote:
> Author: forenr
> Date: Fri Mar 20 16:14:13 2009
> New Revision: 28879
>
> URL: http://www.lyx.org/trac/changeset/28879
> Log:
> More Ui tweaks for Qt 4.2.
Jürgen, may I do the same on branch?
Essentially, this boils down to this kind of mechanical replacement:
-
+
+ 7
+ 0
according to the enums listed in qsizepolicy.h :
enum PolicyFlag {
GrowFlag = 1,
ExpandFlag = 2,
ShrinkFlag = 4,
IgnoreFlag = 8
};
enum Policy {
Fixed = 0,
Minimum = GrowFlag,
Maximum = ShrinkFlag,
Preferred = GrowFlag | ShrinkFlag,
MinimumExpanding = GrowFlag | ExpandFlag,
Expanding = GrowFlag | ShrinkFlag | ExpandFlag,
Ignored = ShrinkFlag | GrowFlag | IgnoreFlag
};
--
Enrico
Re: LyX slowness (2) - network usage.
Vincent van Ravesteijn - TNW wrote: Abdelrazak Younes writes: Last time I touched that part, the full updateLabel() call was done only when a new section or caption was created, not with each keystroke. Even when modifying a section, only the relevant toc item was changed. This is about updateMacros(), not about updateLabels(). Ah, OK, sorry for the confusion. Anyway, as I said multiple times, updateMacros() should be integrated into updateLabels(). There is no reason why a call this should be called at each keystroke. As a first step i would suggest to just put *one* call at the end of updateLabels() and to erase all other calls. As a second step, the macro update mechanism should be integrated in Inset::updateLabel() (for InsetMathMacro and InsetMathHull I assume) and not done independantly. Abdel.
RE: LyX slowness (2) - network usage.
>Abdelrazak Younes writes: >> Last time I touched that part, the full updateLabel() call was done >> only when a new section or caption was created, not with each >> keystroke. Even when modifying a section, only the relevant toc item >> was changed. This is about updateMacros(), not about updateLabels(). >> >> If this has changed, this means that there's a superfluous additional >> call somewhere. > >Do we have a test file? > Just any master with a number of childs would do. But I believe you can't reproduce on Linux, and your files should be on a filesystem that has a somewhat slower access than your harddisk. > Jmarc Vincent
Re: LyX slowness (2) - network usage.
Abdelrazak Younes writes: > Last time I touched that part, the full updateLabel() call was done > only when a new section or caption was created, not with each > keystroke. Even when modifying a section, only the relevant toc item > was changed. > > If this has changed, this means that there's a superfluous additional > call somewhere. Do we have a test file? JMarc
Re: LyX slowness (2) - network usage.
"Vincent van Ravesteijn - TNW" writes: > As far as I understood, there are links to macros stored in a table. > This means that the table says that Macro_x is used in paragraph 10, > position 12 etc. If the document changes, one has to adjust these > numbers as the location might now be paragraph 11, position 12 after a > new paragraph is inserted. But these links are only needed when a macro is changed, right? Shouldn't the expensive operation (look over all files) be done on this occasion only? JMarc
Re: [Cvslog] r28739 - /lyx-devel/trunk/lyx.1in
Am Freitag 20 März 2009 schrieb Jürgen Spitzmüller: > Abdelrazak Younes wrote: > > > No. The changes are all inside cmake, right? Since it does not affect > > > other areas, I guess you can just proceed. However, I'd prefer if you > > > could do it step-by-step. > > > > The guy has done a lot of work Jürgen, > > I know, and I appreciate that. > > > splitting the patches would mean > > a lot of work, I can testify that it works fine in trunk, there is no > > reason it won't work in branch. And the cmake build system has always > > been marked as experimental anyway... > > Of course the effort should be reasonable. Note that I wrote "I prefer". > > Jürgen Thanks Jürgen. I promise to correct any mistake I do :) And yes, it is not so easy to split without headache. Kornel signature.asc Description: This is a digitally signed message part.
Re: [Cvslog] r28739 - /lyx-devel/trunk/lyx.1in
Abdelrazak Younes wrote: > > No. The changes are all inside cmake, right? Since it does not affect > > other areas, I guess you can just proceed. However, I'd prefer if you > > could do it step-by-step. > > > > The guy has done a lot of work Jürgen, I know, and I appreciate that. > splitting the patches would mean > a lot of work, I can testify that it works fine in trunk, there is no > reason it won't work in branch. And the cmake build system has always > been marked as experimental anyway... Of course the effort should be reasonable. Note that I wrote "I prefer". Jürgen
Re: [Cvslog] r28739 - /lyx-devel/trunk/lyx.1in
Jürgen Spitzmüller wrote: Kornel Benko wrote: Jürgen the diff is _big_. Essentially you could have it, if you compare it with trunk. svn diff development/cmake/|wc 11573772 42256 Should I post it? No. The changes are all inside cmake, right? Since it does not affect other areas, I guess you can just proceed. However, I'd prefer if you could do it step-by-step. The guy has done a lot of work Jürgen, splitting the patches would mean a lot of work, I can testify that it works fine in trunk, there is no reason it won't work in branch. And the cmake build system has always been marked as experimental anyway... Abdel. Jürgen
Re: [Cvslog] r28739 - /lyx-devel/trunk/lyx.1in
Kornel Benko wrote: > Jürgen the diff is _big_. Essentially you could have it, if you compare it > with trunk. > > svn diff development/cmake/|wc >11573772 42256 > > Should I post it? No. The changes are all inside cmake, right? Since it does not affect other areas, I guess you can just proceed. However, I'd prefer if you could do it step-by-step. Jürgen
Re: [Cvslog] r28739 - /lyx-devel/trunk/lyx.1in
Am Freitag 20 März 2009 schrieb Jürgen Spitzmüller: > Kornel Benko wrote: > > Looks like nobody else cares. > > I was just too busy. Could you point me again to the relevant diff? > > Jürgen Jürgen the diff is _big_. Essentially you could have it, if you compare it with trunk. svn diff development/cmake/|wc 11573772 42256 Should I post it? Kornel signature.asc Description: This is a digitally signed message part.
Re: Update on aussie phaseout and new server
On Fri, 20 Mar 2009, Lars Gullik Bjønnes wrote: As an aside, it´d be excellent if the VM was running a system that automatically switches the VM to different hardware if the old hardware fails. That´s probably hoping for a lot, but such system exist and will probably be more and more common. I´ve even heard of (coming?) systems that can do switchover of VMs while retaining real-time characteristics. I think that this is a bit high expectations for a free vm. I wasn´t expecting it. Somewhat related to backup. Who will be the contact point with Bonn University? If for instance the VM isn´t running or needs to be restarted or something. We should also document which services we´re using/installing, as a hlep for the future. regards, Christian -- Christian Ridderström Mobile: +46-70 687 39 44
Re: [Cvslog] r28739 - /lyx-devel/trunk/lyx.1in
Kornel Benko wrote: > Looks like nobody else cares. I was just too busy. Could you point me again to the relevant diff? Jürgen
Re: LyX slowness (2) - network usage.
Helge Hafting wrote: Vincent van Ravesteijn - TNW wrote: I'm having real problems working with LyX and child document. It's very very slow when typing text. >> This is a very mysterious mystery. rh A possible explanation for this. For each keystroke, updateMacros() is called, which calls Ouch! Isn't this something that is necessary only if you're actually dealing with a macro? (making one, or filling in parameters)? If so, perhaps check that first and just return if there is nothing macroish to do? InsetInclude::loadIfNeeded(), which then calls theBufferList::getBuffer(). This function iterates over all loaded buffers and if the wanted file is not loaded yet it will be loaded. I have a hard time understanding why any kind of filesystem check might be necessary on _each keystroke_. Move the cursor into a file-backed inset - sure. But not otherwise? The main LyX job is typing text and that ought to work with a minimum of per-keystroke checks. I guess this behaviour is unintentional. Last time I touched that part, the full updateLabel() call was done only when a new section or caption was created, not with each keystroke. Even when modifying a section, only the relevant toc item was changed. If this has changed, this means that there's a superfluous additional call somewhere. Abdel.
Re: [Cvslog] r28739 - /lyx-devel/trunk/lyx.1in
Am Donnerstag 19 März 2009 schrieb Abdelrazak Younes: > On 19/03/2009 07:41, Kornel Benko wrote: > > Am 2009-03-18 schrieb Jean-Marc Lasgouttes: > >> Jean-Marc Lasgouttes writes: > >>> lasgout...@lyx.org writes: > Author: lasgouttes > Date: Mon Mar 9 15:48:17 2009 > New Revision: 28739 > > URL: http://www.lyx.org/trac/changeset/28739 > Log: > more autogenerated strings in lyx man page > >>> > >>> Juergen, can I backport the various changes I did to man pages to > >>> branch? > >> > >> This will require updates to scons and cmake that I am not very sure > >> about. > >> > >> JMarc > > > > No problems for cmake. In the current code there is nothing to do, > > because cmake in branch did not care about manpages. On the other hand, I > > have back-ported everething to branch, waiting since a week to be allowed > > to commit. > > The cmake build has always been experimental so I don't think Juergen > would object, Juergen? > > Abdel. Looks like nobody else cares. Kornel signature.asc Description: This is a digitally signed message part.
RE: LyX 1.6.2: possible performance issue inside master document
>Seems excessive indeed. Ideally, typing text should be fine >even with a "sleep(1)" in every filesystem interface. Just a >slight stop whenever the emergency save happens. That's why I now use a test document that I access via WebDav. It is very rewarding to see the speed up then. >Helge Hafting Vincent
RE: LyX slowness (2) - network usage.
>> For each keystroke, updateMacros() is called, which calls > >Ouch! >Isn't this something that is necessary only if you're actually >dealing with a macro? (making one, or filling in parameters)? >If so, perhaps check that first and just return if there is >nothing macroish to do? As far as I understood, there are links to macros stored in a table. This means that the table says that Macro_x is used in paragraph 10, position 12 etc. If the document changes, one has to adjust these numbers as the location might now be paragraph 11, position 12 after a new paragraph is inserted. >> InsetInclude::loadIfNeeded(), which then calls >> theBufferList::getBuffer(). This function iterates over all loaded >> buffers and if the wanted file is not loaded yet it will be loaded. >> >I have a hard time understanding why any kind of filesystem check might >be necessary on _each keystroke_. Move the cursor into a file-backed >inset - sure. But not otherwise? The main LyX job is typing text and >that ought to work with a minimum of per-keystroke checks. I guess this >behaviour is unintentional. It shouldn't be necessary. It is just checked whether these buffers are already loaded (in an apparently clumsy way). >> As a consequence, having 5 child documents leads to comparing >> 2+3+4+5+6=20 times two filenames. > >And the quadratic behaviour indicates that something else is amiss too. > Well, this could be easier, but a modern pc should be able to compare a lots of strings without any delay. So, this shouldn't be very disastrous. >Much development happens on linux, where excellent file caching hides >this silliness/mistake. (No network access if the process asks about >the same few files over and over.) And a fast processor hides the >actual work in searching the file cache. That might explain it. >It is a good thing some have slow machines or slow filesystems, >catching such things. Perhaps there is too much encapsulation, >hiding details from programmers. If the hidden stuff is well-designed, encapsulation shouldn't be a problem and should make life much easier for the programmer. That's the main reason I would like to redesign this FileName class. It would be nice to provide a simple class that handles all different os'es etc, and that also is optimized not to access the filesystem too often. Of course, the other things might not be perfect, but if the 'hidden' stuff is optimized, then the programmer should not have to think over and over again about the same things in different places. >Helge Hafting Vincent
Re: LyX 1.6.2: possible performance issue inside master document
rgheck wrote: Vincent van Ravesteijn - TNW wrote: Maybe it's already clear, Yes, I understand now. How do we solve it then ? Do we need a new class that we use internally. In this class we store a filename, which is case-sensitive on case-sensitive filesystem, that is guaranteed to be a long filename and not a short one (on Windows), that is not a symlink, that is relative or absolute (pick one or both). This could work, though it looks as if we're duplicating what QFileInfo does, and we might run into similar problems about caching to what we had before. I don't know---but I think this makes some sense out of why they want to return false if the files don't exist. The problem, as I see it, is that QFileInfo objects are getting created so often, which requires filesystem access, even independently of the caching stuff. And I'm not sure how that can be avoided. Anyway, here's another idea. Why are we calling loadIfNeeded() every time? It's there that the check is made that the file is loaded in a buffer, which (if I'm remembering right) calls == to see. It seems to me that there are only a few occasions when a file could need to be loaded if it wasn't before. E.g., if an InsetInclude has been added or modified; or if the default master has been changed. So maybe we could have some flag, maybe in the BufferList, that meant: you don't need to check this, nothing has changed. And it could be set and cleared by e.g. InsetInclude constructors. Wouldn't it be better to remove the check completely? Instead of checking if we need to call "loadIfNeeded" all the time - don't. Instead, check (and loasd) only when an insetinclude is changed/modified. That way, the test don't merely get cheaper, the test goes away which is even better. I don't think there are that many cases to consider. And of course, similar problems could arise elsewhere, and they'd need similar solutions. But it bothers me that we're checking whether every needed file is loaded every time we type a key. Seems excessive indeed. Ideally, typing text should be fine even with a "sleep(1)" in every filesystem interface. Just a slight stop whenever the emergency save happens. We can't assume that filesystem access will be quick. Helge Hafting
Re: LyX slowness (2) - network usage.
Vincent van Ravesteijn - TNW wrote: I'm having real problems working with LyX and child document. It's very very slow when typing text. >> This is a very mysterious mystery. rh A possible explanation for this. For each keystroke, updateMacros() is called, which calls Ouch! Isn't this something that is necessary only if you're actually dealing with a macro? (making one, or filling in parameters)? If so, perhaps check that first and just return if there is nothing macroish to do? InsetInclude::loadIfNeeded(), which then calls theBufferList::getBuffer(). This function iterates over all loaded buffers and if the wanted file is not loaded yet it will be loaded. I have a hard time understanding why any kind of filesystem check might be necessary on _each keystroke_. Move the cursor into a file-backed inset - sure. But not otherwise? The main LyX job is typing text and that ought to work with a minimum of per-keystroke checks. I guess this behaviour is unintentional. As a consequence, having 5 child documents leads to comparing 2+3+4+5+6=20 times two filenames. In FileName::operator==(), two new And the quadratic behaviour indicates that something else is amiss too. Checking if any two files from a set is the same? Shouldn't be necessary except when a new file is added to the set. A one time per file op, rather than a once per keypress op. FileName objects are constructed (lhs and rhs) and in the constructor QFileInfo::isFileExists() is called. This leads thus already to accessing the filesystem 40 times.Then, both QFileInfo objects are refreshed, which makes it 80 times. Having a thesis with 10 chapters in separate child documents, would cause 260 filesystem checks for each character !! Typing at a speed of 10 characters per second, thus leads to 2600 network files to be accessed.. per second ... Time to mess up things ? Much development happens on linux, where excellent file caching hides this silliness/mistake. (No network access if the process asks about the same few files over and over.) And a fast processor hides the actual work in searching the file cache. It is a good thing some have slow machines or slow filesystems, catching such things. Perhaps there is too much encapsulation, hiding details from programmers. A good implementation of LyX ought to have something like the emergency save stuff being the most frequent use of the filesystem when the user is merely typing. Helge Hafting
Re: Branch: Can't typeset greyed-out notes
On 20 mar 2009, at 13.38, BH wrote:
On Fri, Mar 20, 2009 at 2:51 AM, Anders Ekberg wrote:
The typesetting works for me (svn r28869). Compiled with QT443 and
purely
intel (i.e. basically as in the INSTALL-instructions).
In addition to your preamble, I also get:
\usepackage{color}
\usepackage{verbatim}
You must also get a definition of lyxgreyedout, right?
Yes:
%% LyX specific LaTeX commands.
%% The greyedout annotation environment
\newenvironment{lyxgreyedout}{\textcolor[gray]{0.8}\bgroup}{\egroup}
\usepackage{babel}
I of course have color.sty and verbatim.sty in my TeX installation,
and they are recognized by LyX.
Any ideas where I should look to see what's happening?
No idea...
If it can be of any help, this is my shell script for compilation:
#!/bin/sh
DATE=`(set \`date\`; echo $2)`_`(set \`date\`; echo $3)`
VERSION=1.6
svn up
export LDFLAGS="-framework Carbon -framework OpenGL -framework AGL -
framework QuickTime -lz -framework Cocoa"
./autogen.sh
./configure --prefix=/Users/anek/LyX_dev/nightly/LyX_16_$DATE.app --
disable-concept-checks --with-version-suffix=-$VERSION --with-qt4-dir=/
Users/anek/LyX_dev/QT443/ --enable-optimization=-Os --without-x --with-
included-gettext --with-frontend=qt4 --disable-stdlib-debug --without-
aspell --without-pspell --disable-shared --enable-static
make -j3
make install-strip
/Anders
Re: [patch] validate strftime (bug 5827)
On Fri, Mar 20, 2009 at 10:54:46AM +0100, Jürgen Spitzmüller wrote: > The attached patch adds a validator for the date-insert argument, both in the > core (the lfun) and the frontend (as a visual clue in the prefs dialog). I > assume that cygwin is equivalent to unix here, but I haven't verified that. That's correct. -- Enrico
Re: TeX capacity exceeded: sorry, main memory [main memory size=1500000]
Waluyo Adi Siswanto wrote: > It doesn't help. It works if the environment changed to Part* instead of > Part. So in Part* it is possible to have a clean page without page > number, but Part would be difficult. And to me the error message is > unusual as it is pointing to TeX capacity exceeded? > Perhaps for the time being I can use Part* for a quick solution. Try if using Insert>Short Title within Part (where you repeat the Part title, but not the ERT in the shorttitle inset) helps. (BTW I do not get the error; maybe an upgrade of the KOMA package helps as well). Jürgen
Re: Branch: Can't typeset greyed-out notes
On Fri, Mar 20, 2009 at 2:51 AM, Anders Ekberg wrote:
>
> The typesetting works for me (svn r28869). Compiled with QT443 and purely
> intel (i.e. basically as in the INSTALL-instructions).
> In addition to your preamble, I also get:
> \usepackage{color}
> \usepackage{verbatim}
You must also get a definition of lyxgreyedout, right?
I of course have color.sty and verbatim.sty in my TeX installation,
and they are recognized by LyX.
Any ideas where I should look to see what's happening?
Bennett
Re: TeX capacity exceeded: sorry, main memory [main memory size=1500000]
> > > The difference is that hyperref is turned on in the 1.6.2 version. If > you turn it off, you don't get the error. > > rh > It doesn't help. It works if the environment changed to Part* instead of Part. So in Part* it is possible to have a clean page without page number, but Part would be difficult. And to me the error message is unusual as it is pointing to TeX capacity exceeded? Perhaps for the time being I can use Part* for a quick solution. Regards / was
Re: [patch] bug 5851: list child-only branches in the menu
Jürgen Spitzmüller wrote: http://bugzilla.lyx.org/show_bug.cgi?id=5851 Objections? None here. I guess my question is whether Gunter is happy with it. I don't myself need this kind of functionality and am not sure how it should best work. rh
Re: TeX capacity exceeded: sorry, main memory [main memory size=1500000]
Waluyo Adi Siswanto wrote:
Actually I have a problem (in LyX 1.6.2) when I want to set the page
without number under the Part environment using ERT
\thispagestyle{empty}. The document class is book(koma-script).
What a surprise, View PDF, LyX error appears "TeX capacity exceeded:
sorry, main memory [main memory size=150]"
As I remember I did not have a problem in older version (1.5.5). Then
I create a simple example to test the problem (attachment
TestPart-1.5.5.lyx). OK It works perfectly and even this file can be
read by 1.6.2 and see the PDF without error.
To reproduce the error then I create a similar file in 1.6.2, and it
shows the error. (attachement TestPart-1.6.2.lyx). This file cannot
output PDF and shows the error.
The difference is that hyperref is turned on in the 1.6.2 version. If
you turn it off, you don't get the error.
rh
Re: Slowness Question
Liviu Andronic wrote: On Thu, Mar 19, 2009 at 1:36 PM, rgheck wrote: Just a silly question, probably: But (other than Vincent), the people who are experiencing slowness don't have the View Source widget open, do they? I haven't followed the "slowness" discussions, so please ignore if off-toic. There's one behaviour I wanted to report (for either 1.5.7 or 1.6.1). Generally LyX is quite OK on speed, but one specific instance where it gets slow---regarding the responsiveness of the UI---is when tables are used in the document (if of use, I could send certain of my files off-list). As soon as tables are inserted, especially longer tables or several smaller ones, the user interface becomes slow (mostly?) on the parts of the document where the tables are present. The table inset is not optimized for drawing at all. Any keystroke will trigger a redraw of the *full* table. This inset needs major surgery I'm afraid... Abdel.
[patch] validate strftime (bug 5827)
http://bugzilla.lyx.org/show_bug.cgi?id=5827
LyX on Windows crashes if an invalid specifier (e.g., %e) is passed to date-
insert. Moreover, the win32 version of strftime only supports a subset of the
specifiers of unix's strftime (where %e would be valid). This raises the
possibility of incorrect syntax.
The attached patch adds a validator for the date-insert argument, both in the
core (the lfun) and the frontend (as a visual clue in the prefs dialog). I
assume that cygwin is equivalent to unix here, but I haven't verified that.
Moreover, the patch was not tested on Windows yet.
Comments?
Jürgen
Index: src/frontends/qt4/GuiPrefs.cpp
===
--- src/frontends/qt4/GuiPrefs.cpp (Revision 28871)
+++ src/frontends/qt4/GuiPrefs.cpp (Arbeitskopie)
@@ -357,6 +357,35 @@
/
//
+// StrftimeValidator
+//
+/
+
+class StrftimeValidator : public QValidator
+{
+public:
+ StrftimeValidator(QWidget *);
+ QValidator::State validate(QString & input, int & pos) const;
+};
+
+
+StrftimeValidator::StrftimeValidator(QWidget * parent)
+ : QValidator(parent)
+{
+}
+
+
+QValidator::State StrftimeValidator::validate(QString & input, int & /*pos*/) const
+{
+ if (is_valid_strftime(fromqstr(input)))
+ return QValidator::Acceptable;
+ else
+ return QValidator::Intermediate;
+}
+
+
+/
+//
// PrefDate
//
/
@@ -365,11 +394,22 @@
: PrefModule(qt_(catOutput), qt_("Date format"), form)
{
setupUi(this);
+ DateED->setValidator(new StrftimeValidator(DateED));
connect(DateED, SIGNAL(textChanged(QString)),
this, SIGNAL(changed()));
}
+void PrefDate::on_DateED_textChanged(const QString &)
+{
+ QString t = DateED->text();
+ int p = 0;
+ bool valid = DateED->validator()->validate(t, p)
+ == QValidator::Acceptable;
+ setValid(DateLA, valid);
+}
+
+
void PrefDate::apply(LyXRC & rc) const
{
rc.date_insert_format = fromqstr(DateED->text());
@@ -2566,7 +2606,8 @@
addModule(new PrefSpellchecker(this));
addModule(new PrefPrinter(this));
- addModule(new PrefDate(this));
+ PrefDate * dateFormat = new PrefDate(this);
+ addModule(dateFormat);
addModule(new PrefPlaintext(this));
addModule(new PrefLatex(this));
@@ -2589,6 +2630,9 @@
bc().setApply(applyPB);
bc().setCancel(closePB);
bc().setRestore(restorePB);
+
+ // initialize the strftime validator
+ bc().addCheckedLineEdit(dateFormat->DateED);
}
Index: src/frontends/qt4/GuiPrefs.h
===
--- src/frontends/qt4/GuiPrefs.h (Revision 28871)
+++ src/frontends/qt4/GuiPrefs.h (Arbeitskopie)
@@ -177,6 +177,9 @@
virtual void apply(LyXRC & rc) const;
virtual void update(LyXRC const & rc);
+
+private Q_SLOTS:
+ void on_DateED_textChanged(const QString &);
};
Index: src/support/os_cygwin.cpp
===
--- src/support/os_cygwin.cpp (Revision 28871)
+++ src/support/os_cygwin.cpp (Arbeitskopie)
@@ -206,6 +206,23 @@
}
+bool is_valid_strftime(string const & p)
+{
+ string::size_type pos = p.find_first_of('%');
+ while (pos != string::npos) {
+ if (pos + 1 == string::npos)
+ break;
+ if (!containsOnly(p.substr(pos + 1, 1),
+ "aAbBcCdDeEFgGhHIjklmMnOpPrRsStTuUVwWxXyYzZ%+"))
+ return false;
+ if (pos + 2 == string::npos)
+ break;
+ pos = p.find_first_of('%', pos + 2);
+ }
+ return true;
+}
+
+
// returns a string suitable to be passed to popen when
// reading a pipe
char const * popen_read_mode()
Index: src/support/os_unix.cpp
===
--- src/support/os_unix.cpp (Revision 28871)
+++ src/support/os_unix.cpp (Arbeitskopie)
@@ -15,6 +15,7 @@
#include "support/os.h"
#include "support/docstring.h"
#include "support/FileName.h"
+#include "support/lstrings.h"
#ifdef __APPLE__
#include
@@ -96,6 +97,23 @@
}
+bool is_valid_strftime(string const & p)
+{
+ string::size_type pos = p.find_first_of('%');
+ while (pos != string::npos) {
+ if (pos + 1 == string::npos)
+ break;
+ if (!containsOnly(p.substr(pos + 1, 1),
+ "aAbBcCdDeEFgGhHIjklmMnOpPrRsStTuUVwWxXyYzZ%+"))
+ return false;
+ if (pos + 2 == string::npos)
+ break;
+ pos = p.find_first_of('%', pos + 2);
+ }
+ return true;
+}
+
+
char const * popen_read_mode()
{
return "r";
Index: src/support/os.h
===
--- src/support/os.h (Revision 28871)
+++ src/support/os.h (Arbeitskopie)
@@ -74,6 +74,9 @@
*/
std::string latex_path(std::string const & p);
+/// Checks if the format string is suitable on the OS
+bool is_valid_strftime(std::string const & p);
+
/** Returns a string suitable to be passed to
[patch] bug 5851: list child-only branches in the menu
http://bugzilla.lyx.org/show_bug.cgi?id=5851
Objections?
Jürgen
Index: src/insets/InsetBranch.cpp
===
--- src/insets/InsetBranch.cpp (Revision 28871)
+++ src/insets/InsetBranch.cpp (Arbeitskopie)
@@ -84,6 +84,10 @@
docstring const InsetBranch::buttonLabel(BufferView const & bv) const
{
docstring s = _("Branch: ") + params_.branch;
+ Buffer const & realbuffer = *buffer().masterBuffer();
+ BranchList const & branchlist = realbuffer.params().branchlist();
+ if (!branchlist.find(params_.branch))
+ s = _("Branch (child only): ") + params_.branch;
if (!params_.branch.empty()) {
// FIXME UNICODE
ColorCode c = lcolor.getFromLyXName(to_utf8(params_.branch));
Index: src/frontends/qt4/Menus.cpp
===
--- src/frontends/qt4/Menus.cpp (Revision 28871)
+++ src/frontends/qt4/Menus.cpp (Arbeitskopie)
@@ -1037,16 +1037,17 @@
return;
}
- BufferParams const & params = buf->masterBuffer()->params();
- if (params.branchlist().empty()) {
+ BufferParams const & master_params = buf->masterBuffer()->params();
+ BufferParams const & params = buf->params();
+ if (params.branchlist().empty() && master_params.branchlist().empty() ) {
add(MenuItem(MenuItem::Command,
qt_("No Branch in Document!"),
FuncRequest(LFUN_NOACTION)));
return;
}
- BranchList::const_iterator cit = params.branchlist().begin();
- BranchList::const_iterator end = params.branchlist().end();
+ BranchList::const_iterator cit = master_params.branchlist().begin();
+ BranchList::const_iterator end = master_params.branchlist().end();
for (int ii = 1; cit != end; ++cit, ++ii) {
docstring label = cit->branch();
@@ -1058,6 +1059,32 @@
FuncRequest(LFUN_BRANCH_INSERT,
cit->branch(;
}
+
+ if (buf == buf->masterBuffer())
+ return;
+
+ MenuDefinition child_branches;
+
+ BranchList::const_iterator ccit = params.branchlist().begin();
+ BranchList::const_iterator cend = params.branchlist().end();
+
+ for (int ii = 1; ccit != cend; ++ccit, ++ii) {
+ docstring label = ccit->branch();
+ if (ii < 10) {
+ label = convert(ii) + ". " + label
++ char_type('|') + convert(ii);
+ }
+ child_branches.addWithStatusCheck(MenuItem(MenuItem::Command,
+toqstr(label),
+FuncRequest(LFUN_BRANCH_INSERT,
+ ccit->branch(;
+ }
+
+ if (!child_branches.empty()) {
+ MenuItem item(MenuItem::Submenu, qt_("Child Document"));
+ item.setSubmenu(child_branches);
+ add(item);
+ }
}
Re: LyX 1.6.2: possible performance issue inside master document
Hi all, I'm not familar with the coding of LyX in any case - and so don't misinterpret my comment as any kind of paternalism. LyX is a worthy successor of SciWord, open source, and full of excellent ideas and work. I have the same suspicion as Vincent: Each user input inside the master(not only keyboard typing; mouse action, e.g., selecting longer parts of text, does the same!!!) causes some havy checks or updating mechanism related to the child docs. Probably my guess is much too simple: If it is a problem wheather a file is loaded/changed or not (as Vincent mentioned), why not setting a valid-flag as soon as all files are loaded/checked, and or check only files which are not currently loaded or already valid. (Eeach child needs its own flag then). There should be a limited number of user actions, which can made an already checked file invalid. I think a similar mechanism can be applied for each "list" of the outliner (if not already existent). Hard disk: I have the effect already seen on 2 Laptops, and 1 Standard PC (all WinXP). So I don't think it's related to the HD. Additionally, the HD-Light only flashes once (very short) after the first key is pressed and then not again. But typing remains unuseable slow. This hints, that there is a file system access each time I start typing, but then? Processor load while fast typing inside the master: significant higher, but below 50%; does not increase while fast typing; so I assume slowness is not only related to pure CPU usage Memory usage: far below any limit Hope it help's Zardoz -- Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal geschützt? Jetzt absichern: https://homebanking.gmx.net/?mc=m...@footer.hb
