Re: Beta (status update #3)

Le 06/11/2010 01:16, Pavel Sanda a écrit : I've sent a note to JMarc asking a few questions. Once I'm absolutely sure what I need to do, then it will be fairly quick. i will be really happy if we can freeze this sunday. any news from this front? I committed the code from Richard after a

Re: Beta (status update #3)

Vincent van Ravesteijn wrote: I would still like to move renamebuffer from guiview to buffer. Vincent this is the last item before freeze, which i would be happy to announce tomorrow night - if possible. pavel

Re: Beta (status update #3)

Le 06/11/2010 01:16, Pavel Sanda a écrit : I've sent a note to JMarc asking a few questions. Once I'm absolutely sure what I need to do, then it will be fairly quick. i will be really happy if we can freeze this sunday. any news from this front? I committed the code from Richard after a

Re: Beta (status update #3)

Vincent van Ravesteijn wrote: > I would still like to move renamebuffer from guiview to buffer. Vincent this is the last item before freeze, which i would be happy to announce tomorrow night - if possible. pavel

Re: Beta (status update #3)

Hi, Gregory Jefferis wrote: 3. Gregory, you didn't replied to us. you have only very limited time frame to do so, otherwise things in 2.0 might by undesirable for you. short resume for things we need before releasing beta a) - Richard has some pending work on lyx2lyx which will finish

Re: Beta (status update #3)

Stephan Witt wrote: crashes. The culprit is the owner_-setBusy(false); in VCS::doVCCommand(). The cursor cannot be changed when the buffer load is in progress - it seems. the problem is that setBusy not only changes hourglass cursor but also tries to start/stop blinking cursor inside workarea.

Re: Beta (status update #3)

Now I've finished the patch and have a fundamental problem: When a document contains vcs buffer-info insets like vcs-author the reload crashes. The culprit is the owner_-setBusy(false); in VCS::doVCCommand(). The cursor cannot be changed when the buffer load is in progress - it seems. I

Re: Beta (status update #3)

Richard Heck wrote: On 11/01/2010 09:20 AM, Pavel Sanda wrote: hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? I've sent a note to JMarc asking a few questions. Once I'm absolutely sure

Re: Beta (status update #3)

Am 05.11.2010 um 21:27 schrieb Vincent van Ravesteijn: Now I've finished the patch and have a fundamental problem: When a document contains vcs buffer-info insets like vcs-author the reload crashes. The culprit is the owner_-setBusy(false); in VCS::doVCCommand(). The cursor cannot be changed

Re: Beta (status update #3)

Hi, Gregory Jefferis wrote: 3. Gregory, you didn't replied to us. you have only very limited time frame to do so, otherwise things in 2.0 might by undesirable for you. short resume for things we need before releasing beta a) - Richard has some pending work on lyx2lyx which will finish

Re: Beta (status update #3)

Stephan Witt wrote: > crashes. The culprit is the owner_->setBusy(false); in VCS::doVCCommand(). > The cursor cannot be changed when the buffer load is in progress - it seems. the problem is that setBusy not only changes hourglass cursor but also tries to start/stop blinking cursor inside

Re: Beta (status update #3)

> Now I've finished the patch and have a fundamental problem: > When a document contains vcs buffer-info insets like vcs-author the reload > crashes. The culprit is the owner_->setBusy(false); in VCS::doVCCommand(). > The cursor cannot be changed when the buffer load is in progress - it seems. > I

Re: Beta (status update #3)

Richard Heck wrote: > On 11/01/2010 09:20 AM, Pavel Sanda wrote: >> hi, >> >> 1. Richard, whats the status of a)? i'm basically waiting only for this. >> could you give it top priority on your list if its not fixed yet? >> >> > I've sent a note to JMarc asking a few questions. Once I'm

Re: Beta (status update #3)

Am 05.11.2010 um 21:27 schrieb Vincent van Ravesteijn: >> Now I've finished the patch and have a fundamental problem: >> When a document contains vcs buffer-info insets like vcs-author the reload >> crashes. The culprit is the owner_->setBusy(false); in VCS::doVCCommand(). >> The cursor cannot

Re: Beta (status update #3)

Am 04.11.2010 um 00:32 schrieb Pavel Sanda: 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,

Re: Beta (status update #3)

Stephan Witt wrote: It's used in SVN::checkOut() too. And it's the result of scanLogFile parser and not a filename. I think, the general problem is the switch from std::string to docstring and vice versa. It is std::string what is used for interface of VCS classes. but the alerts use

Re: Beta (status update #3)

Am 04.11.2010 um 14:45 schrieb Pavel Sanda: Stephan Witt wrote: string CVS::revisionInfo(LyXVC::RevisionInfo const info) { - if (info == LyXVC::File) - return version_; + if (!version_.empty()) { + if (rev_author_cache_.empty()) { + if

Re: Beta (status update #3)

Stephan Witt wrote: I'll use an explicit getRevisionInfo() success state flag and return string() instead. Ok? not sure what exactly do you mean :) That's how I understood your comment, but the new patch is not ready... Like that: i'm basically happy that the duplicated strings

Re: Beta (status update #3)

Am 04.11.2010 um 16:15 schrieb Pavel Sanda: Stephan Witt wrote: I'll use an explicit getRevisionInfo() success state flag and return string() instead. Ok? not sure what exactly do you mean :) That's how I understood your comment, but the new patch is not ready... Like that: i'm

Re: Beta (status update #3)

Am 04.11.2010 um 16:52 schrieb Stephan Witt: Am 04.11.2010 um 16:15 schrieb Pavel Sanda: Stephan Witt wrote: I'll use an explicit getRevisionInfo() success state flag and return string() instead. Ok? not sure what exactly do you mean :) That's how I understood your comment, but the

Re: Beta (status update #3)

Am 04.11.2010 um 00:32 schrieb Pavel Sanda: > 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

Re: Beta (status update #3)

Stephan Witt wrote: > It's used in SVN::checkOut() too. > And it's the result of scanLogFile parser and not a filename. > I think, the general problem is the switch from std::string to docstring and > vice versa. > It is std::string what is used for interface of VCS classes. but the alerts > use

Re: Beta (status update #3)

Am 04.11.2010 um 14:45 schrieb Pavel Sanda: > Stephan Witt wrote: string CVS::revisionInfo(LyXVC::RevisionInfo const info) { - if (info == LyXVC::File) - return version_; + if (!version_.empty()) { + if (rev_author_cache_.empty()) { +

Re: Beta (status update #3)

Stephan Witt wrote: > >> I'll use an explicit getRevisionInfo() success state flag and return > >> string() instead. Ok? > > > > not sure what exactly do you mean :) > > That's how I understood your comment, but the new patch is not ready... > > Like that: > i'm basically happy that the

Re: Beta (status update #3)

Am 04.11.2010 um 16:15 schrieb Pavel Sanda: > Stephan Witt wrote: I'll use an explicit getRevisionInfo() success state flag and return string() instead. Ok? >>> >>> not sure what exactly do you mean :) >> >> That's how I understood your comment, but the new patch is not ready... >>

Re: Beta (status update #3)

Am 04.11.2010 um 16:52 schrieb Stephan Witt: > Am 04.11.2010 um 16:15 schrieb Pavel Sanda: > >> Stephan Witt wrote: > I'll use an explicit getRevisionInfo() success state flag and return > string() instead. Ok? not sure what exactly do you mean :) >>> >>> That's how 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 why the

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: 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

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: 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

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: 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: 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: 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

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: 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

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: 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. > > >

Re: Beta (status update #3)

Am 01.11.2010 um 23:42 schrieb Pavel Sanda: Stephan Witt wrote: Sorry, I went out and could not answer :-) 1) I have a patch at hand to add the ability to collect stderr in system call and to simplify the stdout collection too. This patch doesn't change the current interface but adds a

Re: Beta (status update #3)

Am 02.11.2010 um 07:31 schrieb Stephan Witt: Am 01.11.2010 um 23:42 schrieb Pavel Sanda: Stephan Witt wrote: 3) Want the readFile() issue fixed. is this beta1 critical stuf? After my last commit in readFile() it's only the issue with file_found_hook being called with the wrong

Re: Beta (status update #3)

After my last commit in readFile() it's only the issue with file_found_hook being called with the wrong file name in case of autosave and emergency. I'd like to fix it before (2) or maybe Vincent does it... For users of VCS I'd rate it as a serious problem - but not critical. To

Re: Beta (status update #3)

Am 02.11.2010 um 10:22 schrieb Vincent van Ravesteijn: After my last commit in readFile() it's only the issue with file_found_hook being called with the wrong file name in case of autosave and emergency. I'd like to fix it before (2) or maybe Vincent does it... For users of

Re: Beta (status update #3)

Yes. Ive got something. Wait Op 1 nov 2010 14:21 schreef Pavel Sanda sa...@lyx.org: hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? 2. Vincent could you put in the pending patch for b? 3.

Re: Beta (status update #3)

Stephan Witt wrote: if you have the patch already feel free to post it, but... I'll attach it - so you get the idea. I want to 1) catch the output of failing system calls to display them in error message dialog 2) eventually be able to pass it up to caller for parsing it 3) simplify

Re: Beta (status update #3)

Vincent van Ravesteijn wrote: Yes. Ive got something. Wait can you share your timetable? pavel

Re: Beta (status update #3)

Am 02.11.2010 um 13:44 schrieb Pavel Sanda: Stephan Witt wrote: if you have the patch already feel free to post it, but... I'll attach it - so you get the idea. I want to 1) catch the output of failing system calls to display them in error message dialog 2) eventually be able to pass

Re: Beta (status update #3)

Stephan Witt wrote: Where did you draw the line exactly? :-) thats difficult to describe exactly :) when you asked about some cvs improvements i thought you just want to replace few cvs parameters and perhaphs push one two new commands, give it testing and check the documentation. that was what

Re: Beta (status update #3)

When starts the 2.1 cycle, by the way? After 2.0 final release? Would 2.0 be a branch then? we should wait for for x.y.1 so people focus on bugfixing little more. iirc this was the case for previous releases too. pavel I wanted to propose to start the 2.0.x branch when you enter the

Re: Beta (status update #3)

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 problems in the codebase. we can discuss it.

Re: Beta (status update #3)

Am 02.11.2010 um 19:27 schrieb Pavel Sanda: Stephan Witt wrote: Where did you draw the line exactly? :-) thats difficult to describe exactly :) Wow, long text... when you asked about some cvs improvements i thought you just want to replace few cvs parameters and perhaphs push one two

Re: Beta (status update #3)

On 11/02/2010 02:31 AM, Stephan Witt wrote: After my last commit in readFile() it's only the issue with file_found_hook being called with the wrong file name in case of autosave and emergency. I'd like to fix it before (2) or maybe Vincent does it... For users of VCS I'd rate it as a serious

Re: Beta (status update #3)

After my last commit in readFile() it's only the issue with file_found_hook being called with the wrong file name in case of autosave and emergency. I'd like to fix it before (2) or maybe Vincent does it... For users of VCS I'd rate it as a serious problem - but not critical. To

Re: Beta (status update #3)

On 11/02/2010 02:31 AM, Stephan Witt wrote: Am 01.11.2010 um 23:42 schrieb Pavel Sanda: Stephan Witt wrote: Sorry, I went out and could not answer :-) 1) I have a patch at hand to add the ability to collect stderr in system call and to simplify the stdout collection too. This patch

Re: Beta (status update #3)

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? When starts the 2.1 cycle, by the way? After 2.0 final release? Would 2.0 be a

Re: Beta (status update #3)

On 11/02/2010 07:39 PM, 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)

It gets called again in readfile, but then with the wrong name. As discussed in another thread we can use a single call only and use d-filename. Op 3 nov 2010 01:06 schreef Richard Heck rgh...@comcast.net: On 11/02/2010 02:31 AM, Stephan Witt wrote: After my last commit in readFile() it's

Re: Beta (status update #3)

Richard Heck wrote: There's a difference between refactoring because we think the code is ugly or hard to understand, and refactoring that is necessary to fix a problem the right way. Freeze means none of the former. The latter sort of thing can be considered on a case-by-case basis. I.e.,

Re: Beta (status update #3)

I would still like to move renamebuffer from guiview to buffer. Fix the vc problems and I'll quit the refactoring for a while. Next fun project would be to add testcode for the buffer class. This can be done in trunk as it won't be compiled for a release. The features I am preparing still: - add

Re: Beta (status update #3)

On 11/01/2010 09:20 AM, Pavel Sanda wrote: hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? I've sent a note to JMarc asking a few questions. Once I'm absolutely sure what I need to do, then it

Re: Beta (status update #3)

Richard Heck wrote: One other issue, by the way, which maybe isn't essential for beta1: I've written the python for the LFUN and preferences conversion routines, i dont think this is essential issue. pavel

Re: Beta (status update #3)

Am 01.11.2010 um 23:42 schrieb Pavel Sanda: > Stephan Witt wrote: >> Sorry, I went out and could not answer :-) >> >> 1) I have a patch at hand to add the ability to collect stderr in system call >> and to simplify the stdout collection too. This patch doesn't change the >> current interface but

Re: Beta (status update #3)

Am 02.11.2010 um 07:31 schrieb Stephan Witt: > Am 01.11.2010 um 23:42 schrieb Pavel Sanda: > >> Stephan Witt wrote: >> >>> 3) Want the readFile() issue fixed. >> >> is this beta1 critical stuf? > > After my last commit in readFile() it's "only" the issue with file_found_hook > being called

Re: Beta (status update #3)

> After my last commit in readFile() it's "only" the issue with file_found_hook being called with the wrong file name in case of autosave and emergency. > I'd like to fix it before (2) or maybe Vincent does it... > For users of VCS I'd rate it as a serious problem - but not critical. To

Re: Beta (status update #3)

Am 02.11.2010 um 10:22 schrieb Vincent van Ravesteijn: > >> > >> After my last commit in readFile() it's "only" the issue with >> file_found_hook being called with the wrong file name in case of autosave >> and emergency. >> >> > >> I'd like to fix it before (2) or maybe Vincent does it...

Re: Beta (status update #3)

Yes. Ive got something. Wait Op 1 nov 2010 14:21 schreef "Pavel Sanda" : hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? 2. Vincent could you put in the pending patch for b? 3.

Re: Beta (status update #3)

Stephan Witt wrote: > > if you have the patch already feel free to post it, but... > > I'll attach it - so you get the idea. > > I want to > 1) catch the output of failing system calls to display them in error message > dialog > 2) eventually be able to pass it up to caller for parsing it > 3)

Re: Beta (status update #3)

Vincent van Ravesteijn wrote: > Yes. Ive got something. Wait can you share your timetable? pavel

Re: Beta (status update #3)

Am 02.11.2010 um 13:44 schrieb Pavel Sanda: > Stephan Witt wrote: >>> if you have the patch already feel free to post it, but... >> >> I'll attach it - so you get the idea. >> >> I want to >> 1) catch the output of failing system calls to display them in error message >> dialog >> 2)

Re: Beta (status update #3)

Stephan Witt wrote: > Where did you draw the line exactly? :-) thats difficult to describe exactly :) when you asked about some cvs improvements i thought you just want to replace few cvs parameters and perhaphs push one two new commands, give it testing and check the documentation. that was what

Re: Beta (status update #3)

When starts the 2.1 cycle, by the way? After 2.0 final release? Would 2.0 be a branch then? we should wait for for x.y.1 so people focus on bugfixing little more. iirc this was the case for previous releases too. pavel I wanted to propose to start the 2.0.x branch when you enter the

Re: Beta (status update #3)

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 > problems in the codebase. we can discuss

Re: Beta (status update #3)

Am 02.11.2010 um 19:27 schrieb Pavel Sanda: > Stephan Witt wrote: >> Where did you draw the line exactly? :-) > > thats difficult to describe exactly :) Wow, long text... > when you asked about some cvs improvements i thought you just want to replace > few cvs parameters and perhaphs push one

Re: Beta (status update #3)

On 11/02/2010 02:31 AM, Stephan Witt wrote: After my last commit in readFile() it's "only" the issue with file_found_hook being called with the wrong file name in case of autosave and emergency. I'd like to fix it before (2) or maybe Vincent does it... For users of VCS I'd rate it as a

Re: Beta (status update #3)

After my last commit in readFile() it's "only" the issue with file_found_hook being called with the wrong file name in case of autosave and emergency. I'd like to fix it before (2) or maybe Vincent does it... For users of VCS I'd rate it as a serious problem - but not critical. To

Re: Beta (status update #3)

On 11/02/2010 02:31 AM, Stephan Witt wrote: Am 01.11.2010 um 23:42 schrieb Pavel Sanda: Stephan Witt wrote: Sorry, I went out and could not answer :-) 1) I have a patch at hand to add the ability to collect stderr in system call and to simplify the stdout collection too. This patch

Re: Beta (status update #3)

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? > >> When starts the 2.1 cycle, by the way? After 2.0 final release? > >> Would 2.0

Re: Beta (status update #3)

On 11/02/2010 07:39 PM, 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)

It gets called again in readfile, but then with the wrong name. As discussed in another thread we can use a single call only and use d->filename. Op 3 nov 2010 01:06 schreef "Richard Heck" : On 11/02/2010 02:31 AM, Stephan Witt wrote: > > > After my last commit in readFile()

Re: Beta (status update #3)

Richard Heck wrote: > There's a difference between refactoring because we think the code is ugly > or hard to understand, and refactoring that is necessary to fix a problem > the right way. Freeze means none of the former. The latter sort of thing > can be considered on a case-by-case basis.

Re: Beta (status update #3)

I would still like to move renamebuffer from guiview to buffer. Fix the vc problems and I'll quit the refactoring for a while. Next fun project would be to add testcode for the buffer class. This can be done in trunk as it won't be compiled for a release. The features I am preparing still: - add

Re: Beta (status update #3)

On 11/01/2010 09:20 AM, Pavel Sanda wrote: hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? I've sent a note to JMarc asking a few questions. Once I'm absolutely sure what I need to do, then it

Re: Beta (status update #3)

Richard Heck wrote: > One other issue, by the way, which maybe isn't essential for beta1: I've > written the python for the LFUN and preferences conversion routines, i dont think this is essential issue. pavel

Beta (status update #3)

hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? 2. Vincent could you put in the pending patch for b? 3. Gregory, you didn't replied to us. you have only very limited time frame to do so, otherwise

Re: Beta (status update #3)

On 11/01/2010 09:20 AM, Pavel Sanda wrote: hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? Will do. rh

Re: Beta (status update #3)

Hi Pavel et al., On 2010-01-11 13:20, Pavel Sanda sa...@lyx.org wrote: 3. Gregory, you didn't replied to us. you have only very limited time frame to do so, otherwise things in 2.0 might by undesirable for you. short resume for things we need before releasing beta a) - Richard has

Re: Beta (status update #3)

Gregory Jefferis wrote: looks like it has addressed my concern. good news, thanks pavel

Re: Beta (status update #3)

Richard Heck wrote: On 11/01/2010 09:20 AM, Pavel Sanda wrote: hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? Will do. great. anybody around having something more to be push in before

Re: Beta (status update #3)

Am 01.11.2010 um 16:48 schrieb Pavel Sanda: Richard Heck wrote: On 11/01/2010 09:20 AM, Pavel Sanda wrote: hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? Will do. great. anybody

Re: Beta (status update #3)

Stephan Witt wrote: Sorry, I went out and could not answer :-) 1) I have a patch at hand to add the ability to collect stderr in system call and to simplify the stdout collection too. This patch doesn't change the current interface but adds a second one. VCS is more clean with that. The

Beta (status update #3)

hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? 2. Vincent could you put in the pending patch for b? 3. Gregory, you didn't replied to us. you have only very limited time frame to do so, otherwise

Re: Beta (status update #3)

On 11/01/2010 09:20 AM, Pavel Sanda wrote: hi, 1. Richard, whats the status of a)? i'm basically waiting only for this. could you give it top priority on your list if its not fixed yet? Will do. rh

Re: Beta (status update #3)

Hi Pavel et al., On 2010-01-11 13:20, "Pavel Sanda" wrote: > 3. Gregory, you didn't replied to us. you have only very limited time frame >to do so, otherwise things in 2.0 might by undesirable for you. > > > >> short resume for things we need before releasing beta >> a) -

Re: Beta (status update #3)

Gregory Jefferis wrote: > looks like it has > addressed my concern. good news, thanks pavel

Re: Beta (status update #3)

Richard Heck wrote: > On 11/01/2010 09:20 AM, Pavel Sanda wrote: >> hi, >> >> 1. Richard, whats the status of a)? i'm basically waiting only for this. >> could you give it top priority on your list if its not fixed yet? >> >> > Will do. great. anybody around having something more to be push

Re: Beta (status update #3)

Am 01.11.2010 um 16:48 schrieb Pavel Sanda: > Richard Heck wrote: >> On 11/01/2010 09:20 AM, Pavel Sanda wrote: >>> hi, >>> >>> 1. Richard, whats the status of a)? i'm basically waiting only for this. >>> could you give it top priority on your list if its not fixed yet? >>> >>> >> Will do. >

Re: Beta (status update #3)

Stephan Witt wrote: > Sorry, I went out and could not answer :-) > > 1) I have a patch at hand to add the ability to collect stderr in system call > and to simplify the stdout collection too. This patch doesn't change the > current interface but adds a second one. VCS is more clean with that. >