Richard Heck <[EMAIL PROTECTED]> writes:
> I'll commit this. I take it that's a sort of OK.
You forgot to update status.15x.
JMarc
> I'll commit this. I take it that's a sort of OK.
Thanks. I will close the bug after I (re)test it under windows.
Bo
Richard Heck <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Richard Heck <[EMAIL PROTECTED]> writes:
>>
>>> I'll commit this. I take it that's a sort of OK.
>>>
>> You forgot to update status.15x.
>>
> Sorry, I'm not used to doing that yet.
No problem it is my (temporary)
Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
I'll commit this. I take it that's a sort of OK.
You forgot to update status.15x.
Sorry, I'm not used to doing that yet.
Richard
--
==
Richard G Hec
Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
Here is the most up-to-date version of the patch, with all comments
and such. Bo and I agree it should go into both trunk and branch, as
it solves the problem. ;-) We need one more OK.
Am I right that the changes to se
Richard Heck <[EMAIL PROTECTED]> writes:
> Here is the most up-to-date version of the patch, with all comments
> and such. Bo and I agree it should go into both trunk and branch, as
> it solves the problem. ;-) We need one more OK.
Am I right that the changes to setBuffer are not really needed? W
Bo Peng wrote:
On 8/2/07, Richard Heck <[EMAIL PROTECTED]> wrote:
Here is the most up-to-date version of the patch, with all comments and
such. Bo and I agree it should go into both trunk and branch, as it
solves the problem. ;-) We need one more OK.
+ //Now that all the
On 8/2/07, Richard Heck <[EMAIL PROTECTED]> wrote:
>
> Here is the most up-to-date version of the patch, with all comments and
> such. Bo and I agree it should go into both trunk and branch, as it
> solves the problem. ;-) We need one more OK.
+ //Now that all the updating of the old
Here is the most up-to-date version of the patch, with all comments and
such. Bo and I agree it should go into both trunk and branch, as it
solves the problem. ;-) We need one more OK.
Richard
--
==
Richard G Heck, Jr
Professor
Richard Heck wrote:
Abdelrazak Younes wrote:
Hi Richard,
I've done that and did a bit more simplifications. Patch attached
(not tested yet).
Here is a patch that actually compiles and works for all use cases.
Whoops. I just committed the other one, per your suggestion. If you want
to revert
Abdelrazak Younes wrote:
Hi Richard,
I've done that and did a bit more simplifications. Patch attached
(not tested yet).
Here is a patch that actually compiles and works for all use cases.
Whoops. I just committed the other one, per your suggestion. If you want
to revert and commit this one,
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
The attached patch builds on Abdel's earlier work and, I think,
solves the remaining problems. Whether this is the best way to do
it, I'm not sure. Abdel was talking about a more major
re-organization of the code, but may
Abdelrazak Younes wrote:
Richard Heck wrote:
The attached patch builds on Abdel's earlier work and, I think, solves
the remaining problems. Whether this is the best way to do it, I'm not
sure. Abdel was talking about a more major re-organization of the
code, but maybe that could wait.
Mayb
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
The attached patch builds on Abdel's earlier work and, I think,
solves the remaining problems. Whether this is the best way to do it,
I'm not sure. Abdel was talking about a more major re-organization of
the code, but maybe that
Abdelrazak Younes wrote:
Richard Heck wrote:
The attached patch builds on Abdel's earlier work and, I think,
solves the remaining problems. Whether this is the best way to do it,
I'm not sure. Abdel was talking about a more major re-organization of
the code, but maybe that could wait.
Maybe y
Richard Heck wrote:
The attached patch builds on Abdel's earlier work and, I think, solves
the remaining problems. Whether this is the best way to do it, I'm not
sure. Abdel was talking about a more major re-organization of the code,
but maybe that could wait.
Maybe yes.
What I've done i
The attached patch builds on Abdel's earlier work and, I think, solves
the remaining problems. Whether this is the best way to do it, I'm not
sure. Abdel was talking about a more major re-organization of the code,
but maybe that could wait.
What I've done is add an optional argument to LFUN_
Abdelrazak Younes wrote:
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
What follows has to be const_cast(buffer).dispatch().
No, I want rather to use the global dispatch method. So that would be:
+lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN,
MSVC chose this one
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
What follows has to be const_cast(buffer).dispatch().
No, I want rather to use the global dispatch method. So that would be:
+lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN,
MSVC chose this one automatically for me but
Abdelrazak Younes wrote:
Richard Heck wrote:
What follows has to be const_cast(buffer).dispatch().
No, I want rather to use the global dispatch method. So that would be:
+lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN,
MSVC chose this one automatically for me but I'll do the change
a
Abdelrazak Younes wrote:
Richard Heck wrote:
What follows has to be const_cast(buffer).dispatch().
No, I want rather to use the global dispatch method. So that would be:
+lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN,
MSVC chose this one automatically for me but I'll do the change
a
Richard Heck wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is
called from LyXView::loadLyXFile(), anyway, all the child doc stuff
could be moved there. But I don't know this code terribly well. Abd
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is
called from LyXView::loadLyXFile(), anyway, all the child doc stuff
could be moved there. But I don't know this code terribly well. Abdel?
Very good analysis Ric
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is
called from LyXView::loadLyXFile(), anyway, all the child doc stuff
could be moved there. But I don't know this code terribly well. Abdel?
Very good analysi
Abdelrazak Younes wrote:
Richard Heck wrote:
Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is
called from LyXView::loadLyXFile(), anyway, all the child doc stuff
could be moved there. But I don't know this code terribly well. Abdel?
Very good analysis Richard! The solution is
Richard Heck wrote:
Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is
called from LyXView::loadLyXFile(), anyway, all the child doc stuff
could be moved there.
Of course you are right but I don't want to do that now because it will
involves much more intrusive changes in Bu
Abdelrazak Younes wrote:
Richard Heck wrote:
Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is
called from LyXView::loadLyXFile(), anyway, all the child doc stuff
could be moved there. But I don't know this code terribly well. Abdel?
Very good analysis Richard! The solution
Stefan Schimanski wrote:
Tried it a bit with child documents. Looks fine.
OK, thanks.
Abdel.
Richard Heck wrote:
Idea for fix: Since the buffer_func.cpp version of loadLyXFile() is
called from LyXView::loadLyXFile(), anyway, all the child doc stuff
could be moved there. But I don't know this code terribly well. Abdel?
Very good analysis Richard! The solution is to use the LFUN instead
Richard Heck wrote:
Richard Heck wrote:
Second problem: Now, with the TOC open, close the master document.
BOOM. Backtrace below. I'm guessing that the problem here is related
to the first problem. This bug may have been revealed by my "don't
close buffer dependent dialogs" patch:
http://w
Richard Heck wrote:
Abdelrazak Younes wrote:
I won't be able to commit it this week-end so could anyone show a
little bit of interest please?
I've patched and am compiling now.
This patch does fix that crash, but I'm seeing some other odd behavior,
and I'm getting another crash. I don't know t
Tried it a bit with child documents. Looks fine.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Abdelrazak Younes wrote:
I won't be able to commit it this week-end so could anyone show a
little bit of interest please?
I've patched and am compiling now.
Me too.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
On Friday 15 June 2007 18:57:44 Richard Heck wrote:
> I've patched and am compiling now.
>
> rh
If it fixes the crash you have my OK. :-)
--
José Abílio
Abdelrazak Younes wrote:
I won't be able to commit it this week-end so could anyone show a
little bit of interest please?
I've patched and am compiling now.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http
Abdelrazak Younes wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=3860
SVN Log:
Polish the Toc and labels updating when loading a child document. Fix
Bug 3860: Toc crash when loading a child documents.
* BufferView::loadLyXFile(): simplify, transfer last part to
LyXView::loadLyXFile
http://bugzilla.lyx.org/show_bug.cgi?id=3860
SVN Log:
Polish the Toc and labels updating when loading a child document. Fix
Bug 3860: Toc crash when loading a child documents.
* BufferView::loadLyXFile(): simplify, transfer last part to
LyXView::loadLyXFile()
* LyXView:
- setBuffer
On Fri, Dec 14, 2001 at 11:51:32AM +0100, Juergen Vigna wrote:
> Well it seems Andre's disease is highly infective, the only missing thing
> is the starting 'Hrmpf' on sending the real patch!
But it looks like our "computing center" (I wonder where they got that name
from...) is actively tring to
On 14-Dec-2001 John Levon wrote:
>> But sadly the unattached fix doesn't work for me.
>
> frankly pathetic. here you go, since you whiny types seem to need patches ...
Well it seems Andre's disease is highly infective, the only missing thing
is the starting 'Hrmpf' on sending the real patch!
On Fri, Dec 14, 2001 at 10:13:43AM +0100, Jean-Marc Lasgouttes wrote:
> > "John" == John Levon <[EMAIL PROTECTED]> writes:
>
> John> frankly pathetic. here you go, since you whiny types seem to
> John> need patches ...
>
> If I may whine, not that you left some debug statements in there.
y
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> frankly pathetic. here you go, since you whiny types seem to
John> need patches ...
If I may whine, not that you left some debug statements in there.
JMarc
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> frankly pathetic. here you go, since you whiny types seem to
John> need patches ...
I don't need patches, I don't have bugs.
Applied anyway.
JMarc
On Fri, Dec 14, 2001 at 05:42:29PM +1000, Allan Rae wrote:
> My case is a multipart document and chapters are in separate docs. So
> this is the same as an empty doc?
dunno, does the current document not contain any entries ?
> But sadly the unattached fix doesn't work for me.
frankly pathetic
On Fri, 14 Dec 2001, John Levon wrote:
> > > Anyone else noticed a crash when opening a TOC dialog in current CVS?
> it crashes on an empty document. fix attached.
My case is a multipart document and chapters are in separate docs. So
this is the same as an empty doc?
But sadly the unattached fi
> > Anyone else noticed a crash when opening a TOC dialog in current CVS?
it crashes on an empty document. fix attached.
regards
john
--
"Of all manifestations of power, restraint impresses the most."
- Thucydides
Allan Rae wrote:
> Anyone else noticed a crash when opening a TOC dialog in current CVS?
no problem here, latest cvs
Herbert
--
http://www.lyx.org/help/
On Fri, Dec 14, 2001 at 03:33:42PM +1000, Allan Rae wrote:
> Anyone else noticed a crash when opening a TOC dialog in current CVS?
looks like my bad code. will fix ...
john
--
"Of all manifestations of power, restraint impresses the most."
- Thucydides
Anyone else noticed a crash when opening a TOC dialog in current CVS?
Allan. (ARRae)
On Thu, Jun 07, 2001 at 03:13:24PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Hansen <[EMAIL PROTECTED]> writes:
>
> Martin> My lyx version is 1.1.5fix1 When i open the accompanying FAQ,
> Martin> and the click on the toc menu lyx crashes and closes. And the
> Martin> terminal
> "Martin" == Martin Hansen <[EMAIL PROTECTED]> writes:
Martin> My lyx version is 1.1.5fix1 When i open the accompanying FAQ,
Martin> and the click on the toc menu lyx crashes and closes. And the
Martin> terminal where lyx is started from says:
I believe it is fixed in more recent LyX versio
My lyx version is 1.1.5fix1
When i open the accompanying FAQ, and the click on the toc menu lyx
crashes and closes.
And the terminal where lyx is started from says:
_
lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX.
51 matches
Mail list logo
