Re: about background compilation

On 22.01.2011 18:28, Edwin Leuven wrote: Peter Kümmel<syntheti...@gmx.net> wrote: We use a finished signal already in GuiView: connect(_thread_watcher_, SIGNAL(finished()), this, SLOT(processingThreadFinished())); assume there is also a started().

Re: Global list-getters return a copy: example theConverters()

On 20.01.2011 09:01, Abdelrazak Younes wrote: On 01/19/2011 11:09 PM, Georg Baum wrote: Pavel Sanda wrote: i was looking at your primal converters patch and came to the conclusion that the changes which allowed converters varibale to be local inside buffer could solve rest of the issues.

Re: Global list-getters return a copy: example theConverters()

On 20.01.2011 09:01, Abdelrazak Younes wrote: On 01/19/2011 11:09 PM, Georg Baum wrote: Pavel Sanda wrote: i was looking at your primal converters patch and came to the conclusion that the changes which allowed converters varibale to be local inside buffer could solve rest of the issues.

Re: Global list-getters return a copy: example theConverters()

On 18.01.2011 23:14, Pavel Sanda wrote: Peter Kümmel wrote: From the outside one could only init ad edges, but isn't it only initialized on startup, or when the converters change? hmm, doesnt make sense why it crashed then. i cant dive into the issue more now, sorry. if you are annoyed

Re: r37260 - lyx-devel/trunk/src

On 19.01.2011 15:19, Vincent van Ravesteijn wrote: Op 19-1-2011 15:09, rgh...@lyx.org schreef: Author: rgheck Date: Wed Jan 19 15:09:44 2011 New Revision: 37260 URL: http://www.lyx.org/trac/changeset/37260 Log: Simplify the new graph code just a bit. I followed the Qt convention:

Re: Global list-getters return a copy: example theConverters()

On 19.01.2011 17:24, Pavel Sanda wrote: Peter Kümmel wrote: This solves not the problem you've described because this is more complicated, but at least the locks are gone. i was looking at your primal converters patch and came to the conclusion that the changes which allowed converters

Re: Global list-getters return a copy: example theConverters()

On 19.01.2011 17:34, Richard Heck wrote: On 01/19/2011 11:24 AM, Pavel Sanda wrote: Peter Kümmel wrote: This solves not the problem you've described because this is more complicated, but at least the locks are gone. i was looking at your primal converters patch and came to the conclusion

Re: Global list-getters return a copy: example theConverters()

On 19.01.2011 23:09, Georg Baum wrote: Pavel Sanda wrote: i was looking at your primal converters patch and came to the conclusion that the changes which allowed converters varibale to be local inside buffer could solve rest of the issues. there are more UI entry points into the converters

Re: Global list-getters return a copy: example theConverters()

On 18.01.2011 23:14, Pavel Sanda wrote: Peter Kümmel wrote: From the outside one could only init ad edges, but isn't it only initialized on startup, or when the converters change? hmm, doesnt make sense why it crashed then. i cant dive into the issue more now, sorry. if you are annoyed

Re: r37260 - lyx-devel/trunk/src

On 19.01.2011 15:19, Vincent van Ravesteijn wrote: Op 19-1-2011 15:09, rgh...@lyx.org schreef: Author: rgheck Date: Wed Jan 19 15:09:44 2011 New Revision: 37260 URL: http://www.lyx.org/trac/changeset/37260 Log: Simplify the new graph code just a bit. I followed the Qt convention:

Re: Global list-getters return a copy: example theConverters()

On 19.01.2011 17:24, Pavel Sanda wrote: Peter Kümmel wrote: This solves not the problem you've described because this is more complicated, but at least the locks are gone. i was looking at your primal converters patch and came to the conclusion that the changes which allowed converters

Re: Global list-getters return a copy: example theConverters()

On 19.01.2011 17:34, Richard Heck wrote: On 01/19/2011 11:24 AM, Pavel Sanda wrote: Peter Kümmel wrote: This solves not the problem you've described because this is more complicated, but at least the locks are gone. i was looking at your primal converters patch and came to the conclusion

Re: Global list-getters return a copy: example theConverters()

On 19.01.2011 23:09, Georg Baum wrote: Pavel Sanda wrote: i was looking at your primal converters patch and came to the conclusion that the changes which allowed converters varibale to be local inside buffer could solve rest of the issues. there are more UI entry points into the converters

CMake Ubuntu packages

CMake has CPack to generate .deb and other packages, but does anybody know the relation to the packages for Ubuntu, often found in ppa repositories? Are both identical? Could they also be generated by cmake? And do we have a ppa for LyX2 beta/rc? Wouldn't this be a nice idea? Peter

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 20:52, Pavel Sanda wrote: Peter Kümmel wrote: threads should be no problem. And making Graph const correct could be done by simply cache all results. still you need write access for the first run. Yes, but at that moment the chance is high to be single threaded

Re: Global list-getters return a copy: example theConverters()

Now living with the locks in Graph, what about applying a similar patch to have the const correctness. I would change the patch so theConverters() will return a const ref not only a ref: /// The global instance. /// Implementation is in LyX.cpp. -extern Converters theConverters(); +extern

Re: CMake Ubuntu packages

On 18.01.2011 14:13, Kornel wrote: Am Dienstag, 18. Januar 2011 schrieb Peter Kümmel: CMake has CPack to generate .deb and other packages, but does anybody know the relation to the packages for Ubuntu, often found in ppa repositories? Are both identical? Could they also be generated by cmake

Re: Global list-getters return a copy: example theConverters()

On 18.01.2011 14:44, Richard Heck wrote: On 01/18/2011 05:11 AM, Peter Kümmel wrote: Now living with the locks in Graph, what about applying a similar patch to have the const correctness. I would change the patch so theConverters() will return a const ref not only a ref: If that's all

Re: r37243 - in lyx-devel/trunk/src: . frontends/qt4

On 18.01.2011 15:11, Vincent van Ravesteijn wrote: Note that this is only an issue because your preferences file was out of date, in the sense that it doesn't have a Format 1 tag at the beginning. But, as far as this issue is concerned, you can also simply put the \path_prefix line into a

Re: Global list-getters return a copy: example theConverters()

On 18.01.2011 19:23, Pavel Sanda wrote: Peter Kümmel wrote: Now living with the locks in Graph, what about applying hm. but didnt we agreed that locks in graph should be killed? Did we? We need locks OK, but where? I don't see much problems locking Graph, because it doesn't call much other

Re: Global list-getters return a copy: example theConverters()

On 18.01.2011 20:04, Pavel Sanda wrote: Peter Kümmel wrote: On 18.01.2011 19:23, Pavel Sanda wrote: Peter Kümmel wrote: Now living with the locks in Graph, what about applying hm. but didnt we agreed that locks in graph should be killed? Did we? well, maybe not. so lets discuss

Re: Global list-getters return a copy: example theConverters()

On 18.01.2011 21:32, Pavel Sanda wrote: Peter Kümmel wrote: my understanding was that the key problem is shared graph member of converters class and nowhere else. do we agree here? I don't know if Graph is used nowhere else, it happens so much even when one only presses a key. - all

Re: Global list-getters return a copy: example theConverters()

No, I think the locked Graph (current trunk) is the solution to the problem. What are your reasons to be skeptical about it? i got this feeling when you described conflict scenario on converters. which i imagined as something like 1: if (Q.empty) 2:Q.generate_paths(); 3: return Q.graph()

CMake Ubuntu packages

CMake has CPack to generate .deb and other packages, but does anybody know the relation to the packages for Ubuntu, often found in ppa repositories? Are both identical? Could they also be generated by cmake? And do we have a ppa for LyX2 beta/rc? Wouldn't this be a nice idea? Peter

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 20:52, Pavel Sanda wrote: Peter Kümmel wrote: threads should be no problem. And making Graph const correct could be done by simply cache all results. still you need write access for the first run. Yes, but at that moment the chance is high to be single threaded

Re: Global list-getters return a copy: example theConverters()

Now living with the locks in Graph, what about applying a similar patch to have the const correctness. I would change the patch so theConverters() will return a const ref not only a ref: /// The global instance. /// Implementation is in LyX.cpp. -extern Converters & theConverters(); +extern

Re: CMake Ubuntu packages

On 18.01.2011 14:13, Kornel wrote: Am Dienstag, 18. Januar 2011 schrieb Peter Kümmel: CMake has CPack to generate .deb and other packages, but does anybody know the relation to the packages for Ubuntu, often found in ppa repositories? Are both identical? Could they also be generated by cmake

Re: Global list-getters return a copy: example theConverters()

On 18.01.2011 14:44, Richard Heck wrote: On 01/18/2011 05:11 AM, Peter Kümmel wrote: Now living with the locks in Graph, what about applying a similar patch to have the const correctness. I would change the patch so theConverters() will return a const ref not only a ref: If that's all

Re: r37243 - in lyx-devel/trunk/src: . frontends/qt4

On 18.01.2011 15:11, Vincent van Ravesteijn wrote: Note that this is only an issue because your preferences file was out of date, in the sense that it doesn't have a "Format 1" tag at the beginning. But, as far as this issue is concerned, you can also simply put the \path_prefix line into a

Re: Global list-getters return a copy: example theConverters()

On 18.01.2011 19:23, Pavel Sanda wrote: Peter Kümmel wrote: Now living with the locks in Graph, what about applying hm. but didnt we agreed that locks in graph should be killed? Did we? We need locks OK, but where? I don't see much problems locking Graph, because it doesn't call much other

Re: Global list-getters return a copy: example theConverters()

On 18.01.2011 20:04, Pavel Sanda wrote: Peter Kümmel wrote: On 18.01.2011 19:23, Pavel Sanda wrote: Peter Kümmel wrote: Now living with the locks in Graph, what about applying hm. but didnt we agreed that locks in graph should be killed? Did we? well, maybe not. so lets discuss

Re: Global list-getters return a copy: example theConverters()

On 18.01.2011 21:32, Pavel Sanda wrote: Peter Kümmel wrote: my understanding was that the key problem is shared graph member of converters class and nowhere else. do we agree here? I don't know if Graph is used nowhere else, it happens so much even when one only presses a key. - all

Re: Global list-getters return a copy: example theConverters()

No, I think the locked Graph (current trunk) is the solution to the problem. What are your reasons to be skeptical about it? i got this feeling when you described conflict scenario on converters. which i imagined as something like 1: if (Q.empty) 2:Q.generate_paths(); 3: return Q.graph()

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 00:01, Peter Kümmel wrote: Graph has a container with pointers (vertices_) but now copy constructor, this could not work. Checked this again and I was wrong, the pointers must be to internal objects which are copied by value (there's nor new in Graph.cpp, not API with a pointer

Re: r37222 - in lyx-devel/trunk/src: . support

Found another way to crash lyx: Call utf8_to_ucs4 via getStatus and getPath, but it is not obvious why it crashes here. See attechments. Peter LyX.exe!std::basic_stringunsigned int,std::char_traitsunsigned int,std::allocatorunsigned int ::_Eos(unsigned int _Newsize) Zeile 1954 C++

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 11:39, Pavel Sanda wrote: Peter Kümmel wrote: Found another way to crash lyx: Call utf8_to_ucs4 via getStatus and getPath, but it is not obvious why it crashes here. See attechments. what was the scenario, which revision of the tree? pavel HEAD without the locks in Graph.cpp

Re: r37222 - in lyx-devel/trunk/src: . support

HEAD without the locks in Graph.cpp It's a typical race condition, see output with attached patch: 184 74127768 size 1 , thread: 186 74127768 size 1 , thread: 36 19714232 size 0 , thread: This means line 184: thread 74127768 checks if Q is not empty enter the while loop line 186: Q is

Global list-getters return a copy: example theConverters()

Attached a patch which introduces a value semantic for the Converter list. theConverters now doesn't return a reference any more but a copy of the list. This way we could remove the locks in Graph.cpp. The returned Converters is const, so the compiler shows up the places where we touch the

Re: Global list-getters return a copy: example theConverters()

On 16.01.2011 13:40, Peter Kümmel wrote: Attached a patch which introduces a value semantic for the Converter list. theConverters now doesn't return a reference any more but a copy of the list. This way we could remove the locks in Graph.cpp. The returned Converters is const, so the compiler

Re: Make lyx more easy to be configed as portable program

On 15.01.2011 20:31, Joost Verburg wrote: On 1/14/2011 11:23 PM, Pavel Sanda wrote: unless somebody is going to make detail review, this is too late for 2.0. it can bring regressions since the code touches common routine... Some time ago I mentioned this exact same issue on the devel list. It

Re: Global list-getters return a copy: example theConverters()

On 16.01.2011 20:06, Richard Heck wrote: On 01/16/2011 07:40 AM, Peter Kümmel wrote: Attached a patch which introduces a value semantic for the Converter list. theConverters now doesn't return a reference any more but a copy of the list. This way we could remove the locks in Graph.cpp

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 20:01, Richard Heck wrote: On 01/16/2011 06:08 AM, Peter Kümmel wrote: HEAD without the locks in Graph.cpp It's a typical race condition, see output with attached patch: I'm no expert on this stuff, but it looks to me as if the locks are needed, unless we start copying

Re: Make lyx more easy to be configed as portable program

On 17.01.2011 03:01, Enrico Forestieri wrote: On Mon, Jan 17, 2011 at 08:45:45AM +0800, hzluo wrote: In addition to this exact path_prefix problem, it causes another problem on Windows: If the external uitility is a .bat/.cmd wrapper, it will fail. For example, ps2pdf13 is a wrapper in gs/lib

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 00:01, Peter Kümmel wrote: Graph has a container with pointers (vertices_) but now copy constructor, this could not work. Checked this again and I was wrong, the pointers must be to internal objects which are copied by value (there's nor "new" in Graph.cp

Re: r37222 - in lyx-devel/trunk/src: . support

Found another way to crash lyx: Call utf8_to_ucs4 via getStatus and getPath, but it is not obvious why it crashes here. See attechments. Peter LyX.exe!std::basic_string,std::allocator >::_Eos(unsigned int _Newsize) Zeile 1954 C++ LyX.exe!std::basic_string,std::allocator

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 11:39, Pavel Sanda wrote: Peter Kümmel wrote: Found another way to crash lyx: Call utf8_to_ucs4 via getStatus and getPath, but it is not obvious why it crashes here. See attechments. what was the scenario, which revision of the tree? pavel HEAD without the locks in Graph.cpp

Re: r37222 - in lyx-devel/trunk/src: . support

HEAD without the locks in Graph.cpp It's a typical race condition, see output with attached patch: 184 74127768 size 1 , thread: 186 74127768 size 1 , thread: 36 19714232 size 0 , thread: This means line 184: thread 74127768 checks if Q is not empty > enter the while loop line 186: Q is

Global list-getters return a copy: example theConverters()

Attached a patch which introduces a value semantic for the Converter list. theConverters now doesn't return a reference any more but a copy of the list. This way we could remove the locks in Graph.cpp. The returned Converters is const, so the compiler shows up the places where we touch the

Re: Global list-getters return a copy: example theConverters()

On 16.01.2011 13:40, Peter Kümmel wrote: Attached a patch which introduces a value semantic for the Converter list. theConverters now doesn't return a reference any more but a copy of the list. This way we could remove the locks in Graph.cpp. The returned Converters is const, so the compiler

Re: Make lyx more easy to be configed as portable program

On 15.01.2011 20:31, Joost Verburg wrote: On 1/14/2011 11:23 PM, Pavel Sanda wrote: unless somebody is going to make detail review, this is too late for 2.0. it can bring regressions since the code touches common routine... Some time ago I mentioned this exact same issue on the devel list. It

Re: Global list-getters return a copy: example theConverters()

On 16.01.2011 20:06, Richard Heck wrote: On 01/16/2011 07:40 AM, Peter Kümmel wrote: Attached a patch which introduces a value semantic for the Converter list. theConverters now doesn't return a reference any more but a copy of the list. This way we could remove the locks in Graph.cpp

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 20:01, Richard Heck wrote: On 01/16/2011 06:08 AM, Peter Kümmel wrote: HEAD without the locks in Graph.cpp It's a typical race condition, see output with attached patch: I'm no expert on this stuff, but it looks to me as if the locks are needed, unless we start copying

Re: Make lyx more easy to be configed as portable program

On 17.01.2011 03:01, Enrico Forestieri wrote: On Mon, Jan 17, 2011 at 08:45:45AM +0800, hzluo wrote: In addition to this exact path_prefix problem, it causes another problem on Windows: If the external uitility is a .bat/.cmd wrapper, it will fail. For example, ps2pdf13 is a wrapper in gs/lib

Re: r37222 - in lyx-devel/trunk/src: . support

On 15.01.2011 22:20, Pavel Sanda wrote: kuem...@lyx.org wrote: Author: kuemmel Date: Sat Jan 15 22:06:28 2011 New Revision: 37222 URL: http://www.lyx.org/trac/changeset/37222 Log: Fix crash on Windows: 1. open LYX 2. CRTL-N 3. CRTL-D hold D -- crash Graph must be thread save to fix this.

Re: r37222 - in lyx-devel/trunk/src: . support

On 15.01.2011 22:54, Pavel Sanda wrote: Peter Kümmel wrote: When a thread enters a function which another thread is busy on it hangs in the lock, if it wouldn't wait the the chaos would become even worse. The mutex only guaranties that one operation is finished before the next starts. yep, i

Re: r37222 - in lyx-devel/trunk/src: . support

On 15.01.2011 23:40, Pavel Sanda wrote: Peter Kümmel wrote: OK, when we really need a graph objects for each thread, then my patch is wrong. looking at the code it seems, that each export routine has its own local path variable. thats good. then we share converters var which has internal

Re: r37222 - in lyx-devel/trunk/src: . support

On 15.01.2011 23:46, Peter Kümmel wrote: On 15.01.2011 23:40, Pavel Sanda wrote: Peter Kümmel wrote: OK, when we really need a graph objects for each thread, then my patch is wrong. looking at the code it seems, that each export routine has its own local path variable. thats good. then we

Re: r37222 - in lyx-devel/trunk/src: . support

On 15.01.2011 23:40, Pavel Sanda wrote: Peter Kümmel wrote: OK, when we really need a graph objects for each thread, then my patch is wrong. looking at the code it seems, that each export routine has its own local path variable. thats good. then we share converters var which has internal

Re: r37224 - lyx-devel/trunk/src/frontends/qt4

On 15.01.2011 23:55, Pavel Sanda wrote: kuem...@lyx.org wrote: Author: kuemmel Date: Sat Jan 15 23:39:46 2011 New Revision: 37224 URL: http://www.lyx.org/trac/changeset/37224 Log: start the timer in the correct thread Modified: lyx-devel/trunk/src/frontends/qt4/GuiProgress.cpp

Re: r37224 - lyx-devel/trunk/src/frontends/qt4

On 16.01.2011 00:12, Pavel Sanda wrote: Peter Kümmel wrote: But it was not this commit, checked it, also 37223 doesn't work ;) i know, thats why btw :) pavel In lyx 1.6.7 it also looks like this: ../../src/BufferView.cpp(1083): action[84] arg[j] x[0] y[0] button[0] ../../src/insets

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 00:25, Pavel Sanda wrote: Peter Kümmel wrote: On 15.01.2011 23:40, Pavel Sanda wrote: Peter Kümmel wrote: OK, when we really need a graph objects for each thread, then my patch is wrong. looking at the code it seems, that each export routine has its own local path variable

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 00:41, Pavel Sanda wrote: Peter Kümmel wrote: Peter, i dont understand one thing. if i try to reproduce Liviu's problems, i see that view buttons get disabled when the export is done. that means that we actually prohibit more threads to run together. But we update the status bar

Re: r37222 - in lyx-devel/trunk/src: . support

Found something, attached two backtraces from two threads. Peter [Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für ntdll.dll] ntdll.dll!7731f861() ntdll.dll!77338c44() msvcr100d.dll!_unlock(int

Re: r37222 - in lyx-devel/trunk/src: . support

On 15.01.2011 22:20, Pavel Sanda wrote: kuem...@lyx.org wrote: Author: kuemmel Date: Sat Jan 15 22:06:28 2011 New Revision: 37222 URL: http://www.lyx.org/trac/changeset/37222 Log: Fix crash on Windows: 1. open LYX 2. CRTL-N 3. CRTL-D hold D --> crash Graph must be thread save to fix this.

Re: r37222 - in lyx-devel/trunk/src: . support

On 15.01.2011 22:54, Pavel Sanda wrote: Peter Kümmel wrote: When a thread enters a function which another thread is busy on it hangs in the lock, if it wouldn't wait the the chaos would become even worse. The mutex only guaranties that one operation is finished before the next starts. yep, i

Re: r37222 - in lyx-devel/trunk/src: . support

On 15.01.2011 23:40, Pavel Sanda wrote: Peter Kümmel wrote: OK, when we really need a graph objects for each thread, then my patch is wrong. looking at the code it seems, that each export routine has its own local path variable. thats good. then we share converters var which has internal

Re: r37222 - in lyx-devel/trunk/src: . support

On 15.01.2011 23:46, Peter Kümmel wrote: On 15.01.2011 23:40, Pavel Sanda wrote: Peter Kümmel wrote: OK, when we really need a graph objects for each thread, then my patch is wrong. looking at the code it seems, that each export routine has its own local path variable. thats good. then we

Re: r37222 - in lyx-devel/trunk/src: . support

On 15.01.2011 23:40, Pavel Sanda wrote: Peter Kümmel wrote: OK, when we really need a graph objects for each thread, then my patch is wrong. looking at the code it seems, that each export routine has its own local path variable. thats good. then we share converters var which has internal

Re: r37224 - lyx-devel/trunk/src/frontends/qt4

On 15.01.2011 23:55, Pavel Sanda wrote: kuem...@lyx.org wrote: Author: kuemmel Date: Sat Jan 15 23:39:46 2011 New Revision: 37224 URL: http://www.lyx.org/trac/changeset/37224 Log: start the timer in the correct thread Modified: lyx-devel/trunk/src/frontends/qt4/GuiProgress.cpp

Re: r37224 - lyx-devel/trunk/src/frontends/qt4

On 16.01.2011 00:12, Pavel Sanda wrote: Peter Kümmel wrote: But it was not this commit, checked it, also 37223 doesn't work ;) i know, thats why "btw" :) pavel In lyx 1.6.7 it also looks like this: ../../src/BufferView.cpp(1083): action[84] arg[j] x[0] y[0] button[0] ../../

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 00:25, Pavel Sanda wrote: Peter Kümmel wrote: On 15.01.2011 23:40, Pavel Sanda wrote: Peter Kümmel wrote: OK, when we really need a graph objects for each thread, then my patch is wrong. looking at the code it seems, that each export routine has its own local path variable

Re: r37222 - in lyx-devel/trunk/src: . support

On 16.01.2011 00:41, Pavel Sanda wrote: Peter Kümmel wrote: Peter, i dont understand one thing. if i try to reproduce Liviu's problems, i see that view buttons get disabled when the export is done. that means that we actually prohibit more threads to run together. But we update the status bar

Re: r37222 - in lyx-devel/trunk/src: . support

Found something, attached two backtraces from two threads. Peter [Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für ntdll.dll] ntdll.dll!7731f861() ntdll.dll!77338c44() msvcr100d.dll!_unlock(int

Re: Font spacing issue again

See ticket http://www.lyx.org/trac/ticket/6920 There are three solutions: 1) compute the metrics 8 times for a word of 8 letters 2) draw letter by letter all the times. 3) or rely on more on Qt widgets (i.e. use QTextEdit) instead on doing our thing. 1) would be costly in terms of

Re: Font spacing issue again

>>> See ticket http://www.lyx.org/trac/ticket/6920 > There are three solutions: > > 1) compute the metrics 8 times for a word of 8 letters > 2) draw letter by letter all the times. > 3) or rely on more on Qt widgets (i.e. use QTextEdit) instead on doing > our thing. > > 1) would be costly in

Re: r37132 - lyx-devel/branches/BRANCH_1_6_X/development/cmake/src

On 07.01.2011 09:19, Abdelrazak Younes wrote: On 01/06/2011 09:15 PM, Peter Kuemmel wrote: But ATMit is mixed in the cmake files, and in lyx's code also tabs are used. Peter Mixing is a consequence having tab stop != indent. Kornel I've no problem switching to spaces. Do you prefer

Re: r37132 - lyx-devel/branches/BRANCH_1_6_X/development/cmake/src

On 07.01.2011 09:19, Abdelrazak Younes wrote: > On 01/06/2011 09:15 PM, Peter Kuemmel wrote: But ATMit is mixed in the cmake files, and in lyx's code also tabs are used. Peter >>> Mixing is a consequence having tab stop != indent. >>> >>> Kornel >> I've no problem switching

Re: Font spacing issue again

On 06.01.2011 22:02, BH wrote: On Thu, Jan 6, 2011 at 3:55 PM, Stephan Witt st.w...@gmx.net wrote: Am 06.01.2011 um 19:21 schrieb BH: On Thu, Jan 6, 2011 at 12:03 PM, Stephan Witt st.w...@gmx.net wrote: Am 06.01.2011 um 16:13 schrieb BH: Yes -- current svn with Qt-4.7.1 (Carbon, 32 bit).

Re: Font spacing issue again

On 06.01.2011 22:18, Peter Kümmel wrote: On 06.01.2011 22:02, BH wrote: On Thu, Jan 6, 2011 at 3:55 PM, Stephan Witt st.w...@gmx.net wrote: Am 06.01.2011 um 19:21 schrieb BH: On Thu, Jan 6, 2011 at 12:03 PM, Stephan Witt st.w...@gmx.net wrote: Am 06.01.2011 um 16:13 schrieb BH: Yes

Re: Font spacing issue again

On 06.01.2011 22:02, BH wrote: > On Thu, Jan 6, 2011 at 3:55 PM, Stephan Witt wrote: >> Am 06.01.2011 um 19:21 schrieb BH: >> >>> On Thu, Jan 6, 2011 at 12:03 PM, Stephan Witt wrote: Am 06.01.2011 um 16:13 schrieb BH: >>> >>> Yes -- current svn with

Re: Font spacing issue again

On 06.01.2011 22:18, Peter Kümmel wrote: > On 06.01.2011 22:02, BH wrote: >> On Thu, Jan 6, 2011 at 3:55 PM, Stephan Witt <st.w...@gmx.net> wrote: >>> Am 06.01.2011 um 19:21 schrieb BH: >>> >>>> On Thu, Jan 6, 2011 at 12:03 PM, Stephan Witt <st.w

Re: [patch] LuaTeX

Now having Lua in TeX we should also embedded it in LyX and replace all Python scripts with Lua. Lua is the future! ;) Peter

Re: [patch] LuaTeX

On 23.11.2010 22:53, Peter Kümmel wrote: Now having Lua in TeX we should also embedded it in LyX and replace all Python scripts with Lua. Lua is the future! ;) Enrico, shouldn't we replace all QProcess/multithreaded code by Lua coroutines (co-operative multitasking)? I'm sure, you are eager

Re: [patch] LuaTeX

On 23.11.2010 22:53, Peter Kümmel wrote: Now having Lua in TeX we should also embedded it in LyX and replace all Python scripts with Lua. Lua is the future! ;) And we should do it immediately before the LyX 2.0.0 release. Peter

Re: [patch] LuaTeX

On 23.11.2010 23:38, Enrico Forestieri wrote: On Tue, Nov 23, 2010 at 10:58:52PM +0100, Peter Kümmel wrote: On 23.11.2010 22:53, Peter Kümmel wrote: Now having Lua in TeX we should also embedded it in LyX and replace all Python scripts with Lua. Lua is the future! ;) Enrico, shouldn't we

Re: [patch] LuaTeX

Now having Lua in TeX we should also embedded it in LyX and replace all Python scripts with Lua. Lua is the future! ;) Peter

Re: [patch] LuaTeX

On 23.11.2010 22:53, Peter Kümmel wrote: > Now having Lua in TeX we should also embedded it in LyX and replace all > Python scripts with Lua. > Lua is the future! ;) Enrico, shouldn't we replace all QProcess/multithreaded code by Lua coroutines (co-operative multitasking)? I'm

Re: [patch] LuaTeX

On 23.11.2010 22:53, Peter Kümmel wrote: > Now having Lua in TeX we should also embedded it in LyX and replace all > Python scripts with Lua. > Lua is the future! ;) And we should do it immediately before the LyX 2.0.0 release. > Peter >

Re: [patch] LuaTeX

On 23.11.2010 23:38, Enrico Forestieri wrote: > On Tue, Nov 23, 2010 at 10:58:52PM +0100, Peter Kümmel wrote: >> On 23.11.2010 22:53, Peter Kümmel wrote: >>> Now having Lua in TeX we should also embedded it in LyX and replace all >>> Python scripts with Lua. >>>

Re: Build error on Windows - ambiguous

On 19.11.2010 22:41, Joost Verburg wrote: On 11/19/2010 10:21 AM, Jim Oldfield wrote: I'm trying to build LyX on Windows, using lyx-2.0.0beta1.tar.gz and the instructions in INSTALL.WIN32. That info is a little outdated. I recommend using MSVC 2010 with CMake. The new dependencies are

Re: Build error on Windows - ambiguous

On 19.11.2010 22:41, Joost Verburg wrote: On 11/19/2010 10:21 AM, Jim Oldfield wrote: I'm trying to build LyX on Windows, using lyx-2.0.0beta1.tar.gz and the instructions in INSTALL.WIN32. That info is a little outdated. I recommend using MSVC 2010 with CMake. The new dependencies are

Re: Build error on Windows - ambiguous

On 19.11.2010 22:41, Joost Verburg wrote: > On 11/19/2010 10:21 AM, Jim Oldfield wrote: >> I'm trying to build LyX on Windows, using lyx-2.0.0beta1.tar.gz and the >> instructions in INSTALL.WIN32. > > That info is a little outdated. I recommend using MSVC 2010 with CMake. > The new dependencies

Re: Build error on Windows - ambiguous

On 19.11.2010 22:41, Joost Verburg wrote: > On 11/19/2010 10:21 AM, Jim Oldfield wrote: >> I'm trying to build LyX on Windows, using lyx-2.0.0beta1.tar.gz and the >> instructions in INSTALL.WIN32. > > That info is a little outdated. I recommend using MSVC 2010 with CMake. > The new dependencies

Re: r36170 - lyx-devel/trunk

On 10.11.2010 16:46, Enrico Forestieri wrote: On Mon, Nov 08, 2010 at 06:09:08PM +0100, Enrico Forestieri wrote: On Mon, Nov 08, 2010 at 09:48:29AM +0100, Peter Kümmel wrote: The 100% cpu for when previewing is fixed now. (Maybe a bug in the Buffer function). Hmm... I don't see any

Re: r36170 - lyx-devel/trunk

On 11.11.2010 00:51, Enrico Forestieri wrote: On Wed, Nov 10, 2010 at 11:39:14PM +0100, Peter Kümmel wrote: r36235: Isn't it enough to move the gv_-processingThreadStarted() call? I think it is cleaner to clearly show what is the code which is not used. And I still wonder why you use Qt

Re: r36170 - lyx-devel/trunk

On 10.11.2010 16:46, Enrico Forestieri wrote: > On Mon, Nov 08, 2010 at 06:09:08PM +0100, Enrico Forestieri wrote: >> On Mon, Nov 08, 2010 at 09:48:29AM +0100, Peter Kümmel wrote: >>> The 100% cpu for when previewing is fixed now. (Maybe a bug in the Buffer >>> function

Re: r36170 - lyx-devel/trunk

On 11.11.2010 00:51, Enrico Forestieri wrote: > On Wed, Nov 10, 2010 at 11:39:14PM +0100, Peter Kümmel wrote: >> r36235: Isn't it enough to move the gv_->processingThreadStarted() call? > > I think it is cleaner to clearly show what is the code which is not used. > >>

Re: r36170 - lyx-devel/trunk

On 08.11.2010 02:17, Enrico Forestieri wrote: On Mon, Nov 08, 2010 at 01:42:35AM +0100, Peter Kümmel wrote: On 08.11.2010 01:15, Enrico Forestieri wrote: On Mon, Nov 08, 2010 at 12:41:28AM +0100, Pavel Sanda wrote: Enrico Forestieri wrote: #ifdefs where placed without care. My feeling

Re: Compilation warnings with r36207

On 08.11.2010 09:13, Jean-Pierre Chrétien wrote: Hello, Here is what I see (Debina lenny, Qt 4.4.3) g++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -I../../boost -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -Wextra -Wall-g -O -MT ForkedCalls.o -MD

Re: r36170 - lyx-devel/trunk

On 08.11.2010 02:17, Enrico Forestieri wrote: On Mon, Nov 08, 2010 at 01:42:35AM +0100, Peter Kümmel wrote: On 08.11.2010 01:15, Enrico Forestieri wrote: On Mon, Nov 08, 2010 at 12:41:28AM +0100, Pavel Sanda wrote: Enrico Forestieri wrote: #ifdefs where placed without care. My feeling

<    3   4   5   6   7   8   9   10   11   12   >