Re: Beta (status update #3)

Am 03.11.2010 um 01:05 schrieb Pavel Sanda: Stephan Witt wrote: I only introduced the getState() method because I couldn't collect the error message. does it mean we can get rid of this CvsStatus creature and logic around if error messages are caught? I said this to explain why the

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

Le 03/11/2010 00:52, Richard Heck a écrit : That said, it's fine with me if we switch trunk to =Qt 4.4 after the split. +1 JMarc

Re: Beta (status update #3)

Le 03/11/2010 01:23, Pavel Sanda a écrit : for now my plan was to freeze any refactorizing which is for the sake of clean code or good architecture. OTOH, now is a good time for patches that do heavy search and replace or stuff like that. This would help future backporting of trunk fixes.

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

On 11/02/2010 11:50 PM, Pavel Sanda wrote: Peter Kümmel wrote: exclude it just out of lazyness. After all, there might still be some conservative admins out there. well, conservative admins... current release of centos has 4.2.1... Will a conservative admin install LyX 2?

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

On Tue, Nov 02, 2010 at 07:52:05PM -0400, Richard Heck wrote: That said, it's fine with me if we switch trunk to =Qt 4.4 after the split. That is already the case, as it does not compile anymore with Qt 4.4, thanks to the essential export in thread feature. -- Enrico

Re: Beta (status update #3)

Jean-Marc Lasgouttes wrote: Le 03/11/2010 01:23, Pavel Sanda a écrit : for now my plan was to freeze any refactorizing which is for the sake of clean code or good architecture. OTOH, now is a good time for patches that do heavy search and replace or stuff like that. This would help future

Release cycle proposal

On 11/03/2010 12:39 AM, Pavel Sanda wrote: Vincent van Ravesteijn wrote: I wanted to propose to start the 2.0.x branch when you enter the feature-freeze/beta state. This would allow to continue redesigning and refactoring the code, because I stumble on this everytime I try to fix real

Re: Beta (status update #3)

Stephan Witt wrote: The problem with the error messages lead me to the status check implementation. Now it is in place I think it's much better with it then without it. I'd say it should not be dropped. Please, ask your questions you have regarding CvsStatus and I'll explain. the darkest

Re: Release cycle proposal

Abdelrazak Younes wrote: It's the job of the maintainer to recall the relevent developer his duty with regards to the branch bug fixing. And Juergen is very goo at it. Artificially imposing a not convincing. in many bugs its hard to decide whose is in charge and they just stay. limit on

Re: Release cycle proposal

On 11/03/2010 01:27 PM, Pavel Sanda wrote: Abdelrazak Younes wrote: It's the job of the maintainer to recall the relevent developer his duty with regards to the branch bug fixing. And Juergen is very goo at it. Artificially imposing a not convincing. in many bugs its hard to decide

Re: Release cycle proposal

Abdelrazak Younes wrote: there is also compromise possible - we freeze until the horrible number of bugs shrinks somewhat. Do you have numbers? I am not sure trunk is so full of bugs when compared to pre-1.6 or pre-1.5... I am quite sure though that the first 1.5 or 1.6 i see two

Re: RefStyle Patch

Richard Heck a écrit : On 11/02/2010 02:01 PM, Jean-Pierre Chrétien wrote: Jean-Pierre Chrétien a écrit : OK, so, for the time being, anyway, we think refstyle support is complete? Or am I misremembering some other issue? Extra \makeatother/\makeatletter in LaTeXFeatures.cpp and problem

Re: Release cycle proposal

On 11/03/2010 03:17 PM, Pavel Sanda wrote: True but this is a drawback that comes from our linear development model. As soon as we switch to one feature = one branch then citing branch or a tag (don't forget that git tags are real tags) will be just fine. No more needs to cite a commit.

Re: Beta (status update #3)

Am 03.11.2010 um 12:21 schrieb Pavel Sanda: Stephan Witt wrote: The problem with the error messages lead me to the status check implementation. Now it is in place I think it's much better with it then without it. I'd say it should not be dropped. Please, ask your questions you have

import fail on working latex document (ticket #7014)

I have a document from which latex can successfully produce a .dvi file (latex test.tex; latex test.tex). But when I try to import it into lyx (file--Import--Latex(Plain)), lyx produces a lyx file but then hangs forever when it tries to read it. This failure happens on lyx 1.6.7 (windows); 1.6.6

Re: import fail on working latex document (ticket #7014)

Scott Otterson wrote: Like everybody else, I'm hoping for an answer right away: Some colleagues and I are starting work on a paper, and they suspect that me using lyx will cause headaches -- sure enough, I have a problem on the first test. So, any quick workarounds will be greatly

Re: Beta (status update #3)

Am 02.11.2010 um 22:43 schrieb Stephan Witt: Am 02.11.2010 um 19:27 schrieb Pavel Sanda: CVS improvement if info inset output is possible (after review) for 2.0-beta? if its possible to make it simple and stupid using the current philosophy then yes. if you need to redesign things

Re: Release cycle proposal

Am 03.11.2010 um 12:13 schrieb Abdelrazak Younes: People should have two checkout: branch and trunk, period. I have three: * branch, * trunk for work and another * trunk for trying out my patches before posting to list. Stephan

Re: import fail on working latex document (ticket #7014)

They write in latex only (so far), and suspect that lyx will just add overhead when we transfer drafts around. Scott On Wed, Nov 3, 2010 at 4:09 PM, Pavel Sanda sa...@lyx.org wrote: Scott Otterson wrote: Like everybody else, I'm hoping for an answer right away: Some colleagues and I are

Re: import fail on working latex document (ticket #7014)

Scott Otterson wrote: They write in latex only (so far), and suspect that lyx will just add overhead when we transfer drafts around. if they want to stay with latex their suspiction is correct. lyx-latex transfer will most probably become nigthmares for you. pavel

Re: import fail on working latex document (ticket #7014)

On Wed, Nov 3, 2010 at 4:41 PM, Pavel Sanda sa...@lyx.org wrote: Scott Otterson wrote: They write in latex only (so far), and suspect that lyx will just add overhead when we transfer drafts around. if they want to stay with latex their suspiction is correct. lyx-latex transfer will most

Re: RefStyle Patch

Jean-Pierre Chrétien a écrit : Richard Heck a écrit : On 11/02/2010 02:01 PM, Jean-Pierre Chrétien wrote: Jean-Pierre Chrétien a écrit : OK, so, for the time being, anyway, we think refstyle support is complete? Or am I misremembering some other issue? Extra \makeatother/\makeatletter

Re: import fail on working latex document (ticket #7014)

On 11/03/2010 10:55 AM, Scott Otterson wrote: I have a document from which latex can successfully produce a .dvi file (latex test.tex; latex test.tex). But when I try to import it into lyx (file--Import--Latex(Plain)), lyx produces a lyx file but then hangs forever when it tries to read it.

For Branch? r36012 - lyx-devel/trunk/src

On 11/03/2010 04:12 PM, rgh...@lyx.org wrote: Author: rgheck Date: Wed Nov 3 21:12:18 2010 New Revision: 36012 URL: http://www.lyx.org/trac/changeset/36012 Log: Fix bug #7014. The problem here is that we get DEFSKIP if we don't recognize the argument, but that leads to an infinite loop.

Tyo?

Concerning this code in parser_tools.py: def get_value(lines, token, start, end = 0, default = ): get_value(lines, token, start[[, end], default]) - list of strings Return tokens after token for the first line, in lines, where token is the first element. i =

Re: Beta (status update #3)

Stephan Witt wrote: CVS improvement if info inset output is possible (after review) for 2.0-beta? if its possible to make it simple and stupid using the current philosophy then yes. if you need to redesign things around, please let it sleep, its too late. No worry, basically I

Re: Beta (status update #3)

Am 03.11.2010 um 01:05 schrieb Pavel Sanda: > Stephan Witt wrote: >> I only introduced the getState() method because I couldn't collect the error >> message. > > does it mean we can get rid of this CvsStatus creature and logic around if > error > messages are caught? I said this to explain

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

Le 03/11/2010 00:52, Richard Heck a écrit : That said, it's fine with me if we switch trunk to >=Qt 4.4 after the split. +1 JMarc

Re: Beta (status update #3)

Le 03/11/2010 01:23, Pavel Sanda a écrit : for now my plan was to freeze any refactorizing which is for the sake of clean code or good architecture. OTOH, now is a good time for patches that do heavy search and replace or stuff like that. This would help future backporting of trunk fixes.

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

On 11/02/2010 11:50 PM, Pavel Sanda wrote: Peter Kümmel wrote: exclude it just out of lazyness. After all, there might still be some conservative admins out there. well, conservative admins... current release of centos has 4.2.1... Will a conservative admin install LyX 2?

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

On Tue, Nov 02, 2010 at 07:52:05PM -0400, Richard Heck wrote: > That said, it's fine with me if we switch trunk to >=Qt 4.4 after the split. That is already the case, as it does not compile anymore with Qt < 4.4, thanks to the essential export in thread feature. -- Enrico

Re: Beta (status update #3)

Jean-Marc Lasgouttes wrote: > Le 03/11/2010 01:23, Pavel Sanda a écrit : >> for now my plan was to freeze any refactorizing which is for the sake of >> clean >> code or good architecture. > > OTOH, now is a good time for patches that do heavy search and replace or > stuff like that. This would

Release cycle proposal

On 11/03/2010 12:39 AM, Pavel Sanda wrote: Vincent van Ravesteijn wrote: I wanted to propose to start the 2.0.x branch when you enter the feature-freeze/beta state. This would allow to continue redesigning and refactoring the code, because I stumble on this everytime I try to fix real

Re: Beta (status update #3)

Stephan Witt wrote: > The problem with the error messages lead me to the status check > implementation. > Now it is in place I think it's much better with it then without it. > I'd say it should not be dropped. > > Please, ask your questions you have regarding CvsStatus and I'll explain. the

Re: Release cycle proposal

Abdelrazak Younes wrote: > It's the job of the > maintainer to recall the relevent developer his duty with regards to the > branch bug fixing. And Juergen is very goo at it. Artificially imposing a not convincing. in many bugs its hard to decide whose is in charge and they just stay. > limit

Re: Release cycle proposal

On 11/03/2010 01:27 PM, Pavel Sanda wrote: Abdelrazak Younes wrote: It's the job of the maintainer to recall the relevent developer his duty with regards to the branch bug fixing. And Juergen is very goo at it. Artificially imposing a not convincing. in many bugs its hard to decide

Re: Release cycle proposal

Abdelrazak Younes wrote: >> there is also compromise possible - we freeze until the horrible number of >> bugs >> shrinks somewhat. >> > > Do you have numbers? I am not sure trunk is so full of bugs when compared > to pre-1.6 or pre-1.5... I am quite sure though that the first 1.5 or 1.6 i

Re: RefStyle Patch

Richard Heck a écrit : On 11/02/2010 02:01 PM, Jean-Pierre Chrétien wrote: Jean-Pierre Chrétien a écrit : OK, so, for the time being, anyway, we think refstyle support is complete? Or am I misremembering some other issue? Extra \makeatother/\makeatletter in LaTeXFeatures.cpp and problem

Re: Release cycle proposal

On 11/03/2010 03:17 PM, Pavel Sanda wrote: True but this is a drawback that comes from our linear development model. As soon as we switch to "one feature = one branch" then citing branch or a tag (don't forget that git tags are real tags) will be just fine. No more needs to cite a commit.

Re: Beta (status update #3)

Am 03.11.2010 um 12:21 schrieb Pavel Sanda: > Stephan Witt wrote: >> The problem with the error messages lead me to the status check >> implementation. >> Now it is in place I think it's much better with it then without it. >> I'd say it should not be dropped. >> >> Please, ask your questions

import fail on working latex document (ticket #7014)

I have a document from which latex can successfully produce a .dvi file (latex test.tex; latex test.tex). But when I try to import it into lyx (file-->Import-->Latex(Plain)), lyx produces a lyx file but then hangs forever when it tries to read it. This failure happens on lyx 1.6.7 (windows);

Re: import fail on working latex document (ticket #7014)

Scott Otterson wrote: > Like everybody else, I'm hoping for an answer right away: Some colleagues > and I are starting work on a paper, and they suspect that me using lyx will > cause headaches -- sure enough, I have a problem on the first test. So, any > quick workarounds will be greatly

Re: Beta (status update #3)

Am 02.11.2010 um 22:43 schrieb Stephan Witt: > Am 02.11.2010 um 19:27 schrieb Pavel Sanda: > >>> CVS improvement if info inset output is possible (after review) for >>> 2.0-beta? >> >> if its possible to make it simple and stupid using the current philosophy >> then yes. >> if you need to

Re: Release cycle proposal

Am 03.11.2010 um 12:13 schrieb Abdelrazak Younes: > People should have two checkout: branch and trunk, period. I have three: * branch, * trunk for work and another * trunk for trying out my patches before posting to list. Stephan

Re: import fail on working latex document (ticket #7014)

They write in latex only (so far), and suspect that lyx will just add overhead when we transfer drafts around. Scott On Wed, Nov 3, 2010 at 4:09 PM, Pavel Sanda wrote: > Scott Otterson wrote: > > Like everybody else, I'm hoping for an answer right away: Some > colleagues > >

Re: import fail on working latex document (ticket #7014)

Scott Otterson wrote: > They write in latex only (so far), and suspect that lyx will just add > overhead when we transfer drafts around. if they want to stay with latex their suspiction is correct. lyx<->latex transfer will most probably become nigthmares for you. pavel

Re: import fail on working latex document (ticket #7014)

On Wed, Nov 3, 2010 at 4:41 PM, Pavel Sanda wrote: > Scott Otterson wrote: > > They write in latex only (so far), and suspect that lyx will just add > > overhead when we transfer drafts around. > > if they want to stay with latex their suspiction is correct. > lyx<->latex transfer

Re: RefStyle Patch

Jean-Pierre Chrétien a écrit : Richard Heck a écrit : On 11/02/2010 02:01 PM, Jean-Pierre Chrétien wrote: Jean-Pierre Chrétien a écrit : OK, so, for the time being, anyway, we think refstyle support is complete? Or am I misremembering some other issue? Extra \makeatother/\makeatletter

Re: import fail on working latex document (ticket #7014)

On 11/03/2010 10:55 AM, Scott Otterson wrote: I have a document from which latex can successfully produce a .dvi file (latex test.tex; latex test.tex). But when I try to import it into lyx (file-->Import-->Latex(Plain)), lyx produces a lyx file but then hangs forever when it tries to read

For Branch? r36012 - lyx-devel/trunk/src

On 11/03/2010 04:12 PM, rgh...@lyx.org wrote: Author: rgheck Date: Wed Nov 3 21:12:18 2010 New Revision: 36012 URL: http://www.lyx.org/trac/changeset/36012 Log: Fix bug #7014. The problem here is that we get DEFSKIP if we don't recognize the argument, but that leads to an infinite loop.

Tyo?

Concerning this code in parser_tools.py: def get_value(lines, token, start, end = 0, default = ""): """ get_value(lines, token, start[[, end], default]) -> list of strings Return tokens after token for the first line, in lines, where token is the first element.""" i =

Re: Beta (status update #3)

Stephan Witt wrote: > >>> CVS improvement if info inset output is possible (after review) for > >>> 2.0-beta? > >> > >> if its possible to make it simple and stupid using the current philosophy > >> then yes. > >> if you need to redesign things around, please let it sleep, its too late. > > >