Re: 1.1.6pre3 crash on opening doc - update
Ben Cazzolato [EMAIL PROTECTED] writes:
| JM,
|
| Could you do something like
|
| frame 6
| print *(name.rep)
|
| I'd be interested to see what the string from which the extension
| sought is. I suspect that rfind is to blame, however.
|
|
| (gdb) frame 6
| #6 0x81d3111 in GetExtension (name=@0x84b3d18) at filetools.C:985
| 985 in filetools.C
| (gdb) print *(name.rep)
| $1 = {sz = 0, ref = 3019, res = 1, s = 0x836e988 ""}
| (gdb)
I give GetExtension the blame...
| Does this help?
Yes, it seems that GetExtension cannot handle finding the extension in
an empty string.
Lgb
Re: Crash bug in LyX 1.1.6pre3
Ben Stanley [EMAIL PROTECTED] writes: | Lyx crashed all by itself while I was off doing something else (on another | desktop). Here's the stack trace from the core dump: Yes, a crash in XForms. What 0.89 version are you using? (look in the header file for the subversion number) Lgb
Re: 1.1.6pre3 crash on opening doc - update
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Ben Cazzolato [EMAIL PROTECTED] writes: | JM, | |
Lars Could you do something like | | frame 6 | print
Lars *(name.rep) | | I'd be interested to see what the string
Lars from which the extension | sought is. I suspect that rfind is
Lars to blame, however. | | | (gdb) frame 6 | #6 0x81d3111 in
Lars GetExtension (name=@0x84b3d18) at filetools.C:985 | 985 in
Lars filetools.C | (gdb) print *(name.rep) | $1 = {sz = 0, ref =
Lars 3019, res = 1, s = 0x836e988 ""} | (gdb)
Lars I give GetExtension the blame...
Lars | Does this help?
Lars Yes, it seems that GetExtension cannot handle finding the
Lars extension in an empty string.
In fact, it seems that lyxstring::rfind(char, size_type=npos) is to
blame (as you can see in the trace, it returns large values which are
not string::npos).
JMarc
Re: 1.1.6pre3 crash on opening doc - update
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
|
| Lars Ben Cazzolato [EMAIL PROTECTED] writes: | JM, | |
| Lars Could you do something like | | frame 6 | print
| Lars *(name.rep) | | I'd be interested to see what the string
| Lars from which the extension | sought is. I suspect that rfind is
| Lars to blame, however. | | | (gdb) frame 6 | #6 0x81d3111 in
| Lars GetExtension (name=@0x84b3d18) at filetools.C:985 | 985 in
| Lars filetools.C | (gdb) print *(name.rep) | $1 = {sz = 0, ref =
| Lars 3019, res = 1, s = 0x836e988 ""} | (gdb)
|
| Lars I give GetExtension the blame...
|
| Lars | Does this help?
|
| Lars Yes, it seems that GetExtension cannot handle finding the
| Lars extension in an empty string.
|
| In fact, it seems that lyxstring::rfind(char, size_type=npos) is to
| blame (as you can see in the trace, it returns large values which are
| not string::npos).
I must admit that I cannot see how rfind fails.
lyxstring::size_type lyxstring::rfind(value_type c, size_type i) const
{
size_type ii = min(rep-sz - 1, i);
for (size_type t = ii; t != 0; --t) {
if (rep-s[t] == c) return t;
}
return npos;
}
Hmm, well actually I see how it can fail... and we are lucky that it
does not crash.
When running rfind on an empty string with i == npos, ii wil be set to
-1. -1 != 0 so the loop runs... and then som unknown negative value is
converted into an unsigned char and we have a large value that looks
almost like npos.
I guess the fix is to have "...; t 0; ..." in the test.
Do we have the same problem in the other rfind's?
Lgb
Re: 1.1.6pre3 crash on opening doc - update
[EMAIL PROTECTED] (Lars Gullik Bjnnes) writes:
| lyxstring::size_type lyxstring::rfind(value_type c, size_type i) const
| {
| size_type ii = min(rep-sz - 1, i);
| for (size_type t = ii; t != 0; --t) {
| if (rep-s[t] == c) return t;
| }
| return npos;
| }
|
|
| Hmm, well actually I see how it can fail... and we are lucky that it
| does not crash.
|
| When running rfind on an empty string with i == npos, ii wil be set to
| -1. -1 != 0 so the loop runs... and then som unknown negative value is
| converted into an unsigned char and we have a large value that looks
| almost like npos.
|
| I guess the fix is to have "...; t 0; ..." in the test.
I belive this will have the same problem as the current code: the
first char in a string will never be tested.
"...; t = 0; ..." should be correct.
Lgb
Re: 1.1.6pre3 crash on opening doc - update
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars "...; t = 0; ..." should be correct. Yes, it seems reasonable. JMarc
rfind and lyxstring
None om my compiler uses lyxstring anymore so I'd be grateful if someone could test the current cvs. Lgb
Re: 1.1.6pre3 crash on opening doc - update
On 10 Jan 2001, Jean-Marc Lasgouttes wrote:
"Ben" == Ben Cazzolato [EMAIL PROTECTED] writes:
Ben (gdb) frame 6 #6 0x81d3111 in GetExtension (name=@0x84b3d18) at
Ben filetools.C:985 985 in filetools.C (gdb) print *(name.rep) $1 =
Ben {sz = 0, ref = 3019, res = 1, s = 0x836e988 ""} (gdb)
Ben Does this help?
Yes, it did really. Another question: do you have an empty image (no
file) in your document? Or is there another reason why GetExtension()
is called with an empty string?
I suspect he was trying the newfound trick of leaving off the extension
from the figure to try to support generation of PDF and ps from the one
file (since pdflatex prefers png files and we still insist on writing the
extension into the file).
Allan. (ARRae)
Re: 1.1.6pre3 crash on opening doc - update
"Allan" == Allan Rae [EMAIL PROTECTED] writes: Allan I suspect he was trying the newfound trick of leaving off the Allan extension from the figure to try to support generation of PDF Allan and ps from the one file (since pdflatex prefers png files and Allan we still insist on writing the extension into the file). This would not account for passing an empty string to GetExtension(), unless there is another bug somewhere... JMarc
Re: rfind and lyxstring
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars None om my compiler uses lyxstring anymore so I'd be grateful if
Lars someone could test the current cvs.
cxx makes a very resonable objection:
cxx: Warning: ../../../lyx-devel/src/support/lyxstring.C, line 1031: pointless
comparison of unsigned integer with zero
for (size_type t = ii; t = 0; --t) {
-^
What about returning npos if the string is empty?
JMarc
Re: 1.1.6pre3 crash on opening doc - update
On 10 Jan 2001, Jean-Marc Lasgouttes wrote: "Allan" == Allan Rae [EMAIL PROTECTED] writes: Allan I suspect he was trying the newfound trick of leaving off the Allan extension from the figure to try to support generation of PDF Allan and ps from the one file (since pdflatex prefers png files and Allan we still insist on writing the extension into the file). This would not account for passing an empty string to GetExtension(), unless there is another bug somewhere... Probably right, but you at least now have one possible code path to look at. Allan. (ARRae)
Re: rfind and lyxstring
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| cxx makes a very resonable objection:
|
| cxx: Warning: ../../../lyx-devel/src/support/lyxstring.C, line 1031: pointless
| comparison of unsigned integer with zero
| for (size_type t = ii; t = 0; --t) {
| -^
|
| What about returning npos if the string is empty?
What about using this:
int ii = min(rep-sz - 1, i);
for (int t = ii; t = 0; --t) {
if (rep-s[t] == c) return t;
}
return npos;
Actually this will not work...
our npos is too big...
I don't like to special case rep-sz == 0, but it seems that will be
the easiest solution.
Then I end up with something like:
size_type const sz = rep-sz;
if (!sz) return npos;
size_type ii = min(sz - 1, i);
for (int t = ii; t = 0; --t) {
if (rep-s[t] == c) return t;
}
return npos;
This can still fail but only for strings that are _very_ large.
Can you test it.
Lgb
Re: Bug in citation dialog
Allan Rae [EMAIL PROTECTED] wrote: To fix this bug we need to extend the ButtonController a little. However, this demonstrates the power of Asger's Model/View/Controller separation; the bug is present in many dialogs but correct the controller and all the GUI's benefit. Ok, I know. ButtonController is Xforms-specific at the moment, but it should be made generic. How generic? All of the code in BC is xforms specific. That's the point of the Policy and Controller separation. Perhaps you just want an abstract base class? Things became a little clearer with sleep! an astract base class for BC and for View is exactly what I want. I'll get back to reading this fully later tonight (better go do some work soon) but maybe you should ask: Why does input() say the inputs are invalid when Dekel clicks on a key? AFAI can see input should be returning true not false. This is correct. I have almost certainly got mixed up here, trying not to activate the buttons by simply clicking on the keys. The bug is mine! However, the point of the previous mail was to extend the ButtonController to get the behaviour I want and that still holds. Anyway as I said, I'll reread your proposal later tonight and comment again then. Please do. I value the input. Angus
lyx-1.1.6pre3 bug: crash on formula in table
lyx-1.1.6pre3 xforms 0.88 Start a new table, insert a formula into a table field (C-m) - crash! lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' under the Help menu and then send us a full bug report. Thanks! lyx: Attempting to save document newfile1.lyx as... /home/bpc/ugunt/newfile1.lyx.emergency Save seems successful. Phew. Bye. Abbruch Ulrich
small patch to FormPrint
Adds a Browse button, so that user can choose file to print to more easily. A patch.diff.bz2
Re: rfind and lyxstring
On Wed, Jan 10, 2001 at 11:54:36AM +0100, Lars Gullik Bjnnes wrote:
Then I end up with something like:
size_type const sz = rep-sz;
if (!sz) return npos;
size_type ii = min(sz - 1, i);
for (int t = ii; t = 0; --t) {
^^^ this should be t = 0
if (rep-s[t] == c) return t;
}
return npos;
Can you test it.
This works, but I would write
if (rep-sz 1) return npos;
size_type ii = min(rep-sz - 1, i);
do {
if (rep-s[ii] == c) return ii;
} while (ii-- 0);
return npos;
And for lyxstring::rfind(lyxstring const a, size_type) I would write
if (rep-sz a.length()) return npos;
...
Actually, it appears that lyxstring::rfind(lyxstring const a, size_type)
is completely broken...
Compilation problem using xlC
-- Kian H Low Chemical Engineering, UCL, Torrington Place, London WC1E 7JE U.K. 020 76793836 / 020 85208975(H) http://www.chemeng.ucl.ac.uk/ Hi, Has anyone compiled Lyx 1.1.5 using cc/xlC for AIX 4.3.2? Configuration is okay but for compilation I keep getting 'Unable to retrieve message errors' for all the source files in src except bmtable.c and tex-strings.C. Can someone please help or give suggestion? the compiler flags are: cc -O2 -qarch=com xlC -g -- Kian H Low Chemical Engineering, UCL, Torrington Place, London WC1E 7JE U.K. 020 76793836 / 020 85208975(H) http://www.chemeng.ucl.ac.uk/
Re: rfind and lyxstring
Dekel Tsur [EMAIL PROTECTED] writes:
| On Wed, Jan 10, 2001 at 11:54:36AM +0100, Lars Gullik Bjnnes wrote:
| Then I end up with something like:
|
| size_type const sz = rep-sz;
| if (!sz) return npos;
|
| size_type ii = min(sz - 1, i);
| for (int t = ii; t = 0; --t) {
|^^^ this should be t = 0
|
| if (rep-s[t] == c) return t;
| }
| return npos;
|
| Can you test it.
|
| This works, but I would write
|
| if (rep-sz 1) return npos;
| size_type ii = min(rep-sz - 1, i);
| do {
| if (rep-s[ii] == c) return ii;
| } while (ii-- 0);
| return npos;
I have never been very fond of do while, but this for version is not
overly pretty.
if (rep-sz == 0) return npos;
size_type ii = min(rep-sz - 1, i) + 1;
for (; ii--;)
if (rep-s[ii] == c) return ii;
return npos;
I think I prefere this, yours with a small minor change.
size_type const sz = rep-sz;
if (!sz) return npos;
size_type ii = min(sz - 1, i);
do {
if (rep-s[ii] == c) return ii;
} while (ii--);
return npos;
| And for lyxstring::rfind(lyxstring const a, size_type) I would write
| if (rep-sz a.length()) return npos;
| ...
|
| Actually, it appears that lyxstring::rfind(lyxstring const a, size_type)
| is completely broken...
Possibly, but let's not change this now... we can wait until it bite
or fix1.
Lgb
Re: rfind and lyxstring
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel This works, but I would write I commited something like what you wrote, and it seems to work. Dekel And for lyxstring::rfind(lyxstring const a, size_type) I Dekel would write if (rep-sz a.length()) return npos; ... Dekel Actually, it appears that lyxstring::rfind(lyxstring const a, Dekel size_type) is completely broken... It looks suspicious... Fortunately, a grep shows that we do not use it :) JMarc
Re: rfind and lyxstring
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars I think I prefere this, yours with a small minor change. This is exactly what I commited! I knew you would prefer it :) JMarc
Re: Tabular issues
On Mon, Jan 08, 2001 at 05:07:32PM +0100, Jean-Marc Lasgouttes wrote: What about the fact that keyword are in mixed-case? Is this considered good xml practice? I seem to remember that xml is case-sensitive. Since we just changed the new tabular format, and we have two read methods for the new and the "old new" formats (ReadNew, ReadOld), it is easy to change the tags to lowercase in the new format, if it is wanted.
Re: Tabular issues
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel On Mon, Jan 08, 2001 at 05:07:32PM +0100, Jean-Marc Lasgouttes Dekel wrote: What about the fact that keyword are in mixed-case? Is this considered good xml practice? I seem to remember that xml is case-sensitive. Dekel Since we just changed the new tabular format, and we have two Dekel read methods for the new and the "old new" formats (ReadNew, Dekel ReadOld), it is easy to change the tags to lowercase in the new Dekel format, if it is wanted. My question was also to know whether it is wanted. Remember I no nearly nothing about xml. JMarc
Re: Tabular issues
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: | | Dekel On Mon, Jan 08, 2001 at 05:07:32PM +0100, Jean-Marc Lasgouttes | Dekel wrote: | What about the fact that keyword are in mixed-case? Is this | considered good xml practice? I seem to remember that xml is | case-sensitive. | | Dekel Since we just changed the new tabular format, and we have two | Dekel read methods for the new and the "old new" formats (ReadNew, | Dekel ReadOld), it is easy to change the tags to lowercase in the new | Dekel format, if it is wanted. | | My question was also to know whether it is wanted. Remember I no | nearly nothing about xml. I think we should go for lowercase. Lgb
Re: Tabular issues
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars I think we should go for lowercase. I think so... Now, who will do the change if Juergen is not available? JMarc
Re: Tabular issues
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars I think we should go for lowercase. | | I think so... Now, who will do the change if Juergen is not available? should be easy enough.. .I'll do it. Lgb
table insets
are enumerate, list, etc. intentionally disabled in cell insets in a table ? thanks john -- "It is well to remember, my son, that the entire population of the universe, with one trifling exception, is composed of others." - John Andrew Holmes
Re: table insets
John Levon [EMAIL PROTECTED] writes: | are enumerate, list, etc. intentionally disabled in cell insets in a table | ? yes, I belive so. Lgb
Re: table insets
On Wed, Jan 10, 2001 at 04:45:21PM +0100, Lars Gullik Bjnnes wrote: John Levon [EMAIL PROTECTED] writes: | are enumerate, list, etc. intentionally disabled in cell insets in a table | ? yes, I belive so. No, you can have them if you have a fixed width column.
Re: table insets
On Wed, 10 Jan 2001, Dekel Tsur wrote: On Wed, Jan 10, 2001 at 04:45:21PM +0100, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | are enumerate, list, etc. intentionally disabled in cell insets in a table | ? yes, I belive so. No, you can have them if you have a fixed width column. which has a rendering bug, namely if you click on a different cell of a fixed width column, the red box around the cell inset isn't removed from the old cell. I couldn't reproduce the old bug though (http://sourceforge.net/bugs/?func=detailbugbug_id=124363group_id=15212) john -- "It is well to remember, my son, that the entire population of the universe, with one trifling exception, is composed of others." - John Andrew Holmes
Patch
* src/insets/insettext.C (LocalDispatch): Add handling of LFUN_BREAKPARAGRAPHKEEPLAYOUT. patch.gz
Re: The only good bug is a dead bug (1.1.5fix3, status update #2)
"John" == John Levon [EMAIL PROTECTED] writes: - crash when changing layout http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg13171.html John In 1.1.6 I can only get crashes from this by saving (either John save, or save-while-quitting, or emergency save). A pure virtual John function gets called. My debugging efforts failed miserable at John this one :( I can shed more light on this one. When changing the layout to a command-type layout, the display attribute of insets is reset to false (around text.C:1044), where the inset here is a formula macro. Then, in InsetFormula::display(bool), it seems that for whatever unknown reason, the math inset is cloned and the deleted (??). This means that the pointer to the macro inset contained in the math macro table is now broken, and that anything can happen later. There was another problem which cause the instant crash referred to in the bug report, but I fixed this one. So, I know why it happens, but I really do not know what we want to do about it. JMarc PS: you may want to add this comment to the bug repository. PPS: am I allowed to add bugs there? I see there is a jmarc user.
Re: table insets
On Wed, Jan 10, 2001 at 05:03:19PM +, John Levon wrote: which has a rendering bug, namely if you click on a different cell of a fixed width column, the red box around the cell inset isn't removed from the old cell. I couldn't reproduce the old bug though (http://sourceforge.net/bugs/?func=detailbugbug_id=124363group_id=15212) Juergen made a lot of changes to the tabular code, so I guess that this bug has been fixed.
Re: Bug in citation dialog
[Extending the ButtonController to be a generic controller, which can handle activation and deactivation of elements in the GUI according to when different criteria are valid.] It is an admirable goal to pursuit, but my experience is that it is fairly difficult to design a truly generic Controller class across different toolkits. This is so, because you have to design the Controller to work with very few behavioural guarantees. For instance, with some toolkits, the changing of an input box can trigger a callback, but in this callback, it is not possible to get the contents of the input box in this callback -- it is not updated until after the callback returns. Now, this should not put you off. I only want to warn you that it might be a longer journey that you plan. The best advise I can give is to design as you go: Only implement what is needed for the toolkit at hand, and when another one is to be assimilated, have a look to see if it is possible. If it is, great. If not, refactor it to handle the new toolkit. It would be a mistake to think that you can design it to encompass all strange toolkits from the start. Greets, Asger
Re: 1.1.6pre3 crash on opening doc - update
Allan I suspect he was trying the newfound trick of leaving off the extension from the figure to try to support generation of PDF and ps from the one file (since pdflatex prefers png files and we still insist on writing the extension into the file). Not that I'm aware of. The file was written under Lyx 1.1.5 and I didn't realise that feature was available then. Ben
Re: 1.1.6pre3 crash on opening doc - update
JM
Ben (gdb) frame 6 #6 0x81d3111 in GetExtension (name=@0x84b3d18) at
Ben filetools.C:985 985 in filetools.C (gdb) print *(name.rep) $1 =
Ben {sz = 0, ref = 3019, res = 1, s = 0x836e988 ""} (gdb)
Ben Does this help?
Yes, it did really. Another question: do you have an empty image (no
file) in your document? Or is there another reason why GetExtension()
is called with an empty string?
Hmmm, I hope not since it is the final copy of a consulting report.
I do have the habit of commenting out figures that I don't wan't in the final
report but are still useful for my information. Can't recall if that is the
case here.
I guess regardless it still shouldn't happen. It was fine with version 1.1.5
so it has to do with the recent changes. I have had no problem with any other
file. The only thing diffferent with this one is that I was using the RCS.
Don't know if this is responsible?
Ben
Re: [BUG] lyx1.1.6pre3 stops PS rendering
John Levon wrote: On Tue, 9 Jan 2001, Ben Stanley wrote: John Levon wrote: On Wed, 3 Jan 2001, Ben Stanley wrote: Hi, I tried out 1.1.6pre3 briefly, and noticed that the old bug to do with preview postscript images is still there... When I load my thesis, LyX will render some of the pictures, but not others. Which pictures are rendered changes randomly. The pictures that are rendered are often rendered with different colour depths from time to time. After loading, try doing nothing (i.e. wait for LyX to finish rendering). Does leaving it help ? Yes, But not always. Sometimes I can leave it alone, and I get no pictures at all. Do you restart LyX each time ? Once you have moved once, then xforms is confused for the rest of the lyx session. I usually have to re-size my LyX window to be able to work with the thesis - it's default size is too small! So, my usual routine is to start LyX, resize the window to take up the full screen vertically (which reveals that xforms has difficulty keeping up with the resizing, and often misses the last update...), and then load my thesis. If I don't move the window around, then... If I start up LyX on my thesis, and don't move or re-size the window, but I scroll around in the document while it's rendering (in particular, if I jump to the end where I'm working), then the ps rendering seems to stop pretty reliably. If I start up LyX on my thesis, and don't move or re-size the window, and don't scroll around until all the gs processes have finished, then all of the pictures render (and there's about 80 of them...). GNU Ghostscript 5.50 (2000-2-13) so it is not the 6.50 bug john -- "It is well to remember, my son, that the entire population of the universe, with one trifling exception, is composed of others." - John Andrew Holmes -- Ben Stanley |barf [ba:rf] 2. "He suggested using FORTRAN, PhD Student | and everybody barfed." - From the Shogakukan SITACS| DICTIONARY OF NEW ENGLISH (Second Edition) University of Wollongong | Australia |http://www.uow.edu.au/~bds02
Re: 1.1.6pre3 crash on opening doc - update
Ben Cazzolato <[EMAIL PROTECTED]> writes:
| JM,
|
| > Could you do something like
| >
| > frame 6
| > print *(name.rep)
| >
| > I'd be interested to see what the string from which the extension
| > sought is. I suspect that rfind is to blame, however.
|
|
| (gdb) frame 6
| #6 0x81d3111 in GetExtension (name=@0x84b3d18) at filetools.C:985
| 985 in filetools.C
| (gdb) print *(name.rep)
| $1 = {sz = 0, ref = 3019, res = 1, s = 0x836e988 ""}
| (gdb)
I give GetExtension the blame...
| Does this help?
Yes, it seems that GetExtension cannot handle finding the extension in
an empty string.
Lgb
Re: Crash bug in LyX 1.1.6pre3
Ben Stanley <[EMAIL PROTECTED]> writes: | Lyx crashed all by itself while I was off doing something else (on another | desktop). Here's the stack trace from the core dump: Yes, a crash in XForms. What 0.89 version are you using? (look in the header file for the subversion number) Lgb
Re: 1.1.6pre3 crash on opening doc - update
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Ben Cazzolato <[EMAIL PROTECTED]> writes: | JM, | |
Lars> > Could you do something like | > | > frame 6 | > print
Lars> *(name.rep) | > | > I'd be interested to see what the string
Lars> from which the extension | > sought is. I suspect that rfind is
Lars> to blame, however. | | | (gdb) frame 6 | #6 0x81d3111 in
Lars> GetExtension (name=@0x84b3d18) at filetools.C:985 | 985 in
Lars> filetools.C | (gdb) print *(name.rep) | $1 = {sz = 0, ref =
Lars> 3019, res = 1, s = 0x836e988 ""} | (gdb)
Lars> I give GetExtension the blame...
Lars> | Does this help?
Lars> Yes, it seems that GetExtension cannot handle finding the
Lars> extension in an empty string.
In fact, it seems that lyxstring::rfind(char, size_type=npos) is to
blame (as you can see in the trace, it returns large values which are
not string::npos).
JMarc
Re: 1.1.6pre3 crash on opening doc - update
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Ben Cazzolato <[EMAIL PROTECTED]> writes: | JM, | |
| Lars> > Could you do something like | > | > frame 6 | > print
| Lars> *(name.rep) | > | > I'd be interested to see what the string
| Lars> from which the extension | > sought is. I suspect that rfind is
| Lars> to blame, however. | | | (gdb) frame 6 | #6 0x81d3111 in
| Lars> GetExtension (name=@0x84b3d18) at filetools.C:985 | 985 in
| Lars> filetools.C | (gdb) print *(name.rep) | $1 = {sz = 0, ref =
| Lars> 3019, res = 1, s = 0x836e988 ""} | (gdb)
|
| Lars> I give GetExtension the blame...
|
| Lars> | Does this help?
|
| Lars> Yes, it seems that GetExtension cannot handle finding the
| Lars> extension in an empty string.
|
| In fact, it seems that lyxstring::rfind(char, size_type=npos) is to
| blame (as you can see in the trace, it returns large values which are
| not string::npos).
I must admit that I cannot see how rfind fails.
lyxstring::size_type lyxstring::rfind(value_type c, size_type i) const
{
size_type ii = min(rep->sz - 1, i);
for (size_type t = ii; t != 0; --t) {
if (rep->s[t] == c) return t;
}
return npos;
}
Hmm, well actually I see how it can fail... and we are lucky that it
does not crash.
When running rfind on an empty string with i == npos, ii wil be set to
-1. -1 != 0 so the loop runs... and then som unknown negative value is
converted into an unsigned char and we have a large value that looks
almost like npos.
I guess the fix is to have "...; t > 0; ..." in the test.
Do we have the same problem in the other rfind's?
Lgb
Re: 1.1.6pre3 crash on opening doc - update
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| lyxstring::size_type lyxstring::rfind(value_type c, size_type i) const
| {
| size_type ii = min(rep->sz - 1, i);
| for (size_type t = ii; t != 0; --t) {
| if (rep->s[t] == c) return t;
| }
| return npos;
| }
|
|
| Hmm, well actually I see how it can fail... and we are lucky that it
| does not crash.
|
| When running rfind on an empty string with i == npos, ii wil be set to
| -1. -1 != 0 so the loop runs... and then som unknown negative value is
| converted into an unsigned char and we have a large value that looks
| almost like npos.
|
| I guess the fix is to have "...; t > 0; ..." in the test.
I belive this will have the same problem as the current code: the
first char in a string will never be tested.
"...; t >= 0; ..." should be correct.
Lgb
Re: 1.1.6pre3 crash on opening doc - update
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> "...; t >= 0; ..." should be correct. Yes, it seems reasonable. JMarc
rfind and lyxstring
None om my compiler uses lyxstring anymore so I'd be grateful if someone could test the current cvs. Lgb
Re: 1.1.6pre3 crash on opening doc - update
On 10 Jan 2001, Jean-Marc Lasgouttes wrote:
> > "Ben" == Ben Cazzolato <[EMAIL PROTECTED]> writes:
>
> Ben> (gdb) frame 6 #6 0x81d3111 in GetExtension (name=@0x84b3d18) at
> Ben> filetools.C:985 985 in filetools.C (gdb) print *(name.rep) $1 =
> Ben> {sz = 0, ref = 3019, res = 1, s = 0x836e988 ""} (gdb)
>
> Ben> Does this help?
>
> Yes, it did really. Another question: do you have an empty image (no
> file) in your document? Or is there another reason why GetExtension()
> is called with an empty string?
I suspect he was trying the newfound trick of leaving off the extension
from the figure to try to support generation of PDF and ps from the one
file (since pdflatex prefers png files and we still insist on writing the
extension into the file).
Allan. (ARRae)
Re: 1.1.6pre3 crash on opening doc - update
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> I suspect he was trying the newfound trick of leaving off the Allan> extension from the figure to try to support generation of PDF Allan> and ps from the one file (since pdflatex prefers png files and Allan> we still insist on writing the extension into the file). This would not account for passing an empty string to GetExtension(), unless there is another bug somewhere... JMarc
Re: rfind and lyxstring
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> None om my compiler uses lyxstring anymore so I'd be grateful if
Lars> someone could test the current cvs.
cxx makes a very resonable objection:
cxx: Warning: ../../../lyx-devel/src/support/lyxstring.C, line 1031: pointless
comparison of unsigned integer with zero
for (size_type t = ii; t >= 0; --t) {
-^
What about returning npos if the string is empty?
JMarc
Re: 1.1.6pre3 crash on opening doc - update
On 10 Jan 2001, Jean-Marc Lasgouttes wrote: > > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: > > Allan> I suspect he was trying the newfound trick of leaving off the > Allan> extension from the figure to try to support generation of PDF > Allan> and ps from the one file (since pdflatex prefers png files and > Allan> we still insist on writing the extension into the file). > > This would not account for passing an empty string to GetExtension(), > unless there is another bug somewhere... Probably right, but you at least now have one possible code path to look at. Allan. (ARRae)
Re: rfind and lyxstring
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| cxx makes a very resonable objection:
|
| cxx: Warning: ../../../lyx-devel/src/support/lyxstring.C, line 1031: pointless
| comparison of unsigned integer with zero
| for (size_type t = ii; t >= 0; --t) {
| -^
|
| What about returning npos if the string is empty?
What about using this:
int ii = min(rep->sz - 1, i);
for (int t = ii; t >= 0; --t) {
if (rep->s[t] == c) return t;
}
return npos;
Actually this will not work...
our npos is too big...
I don't like to special case rep->sz == 0, but it seems that will be
the easiest solution.
Then I end up with something like:
size_type const sz = rep->sz;
if (!sz) return npos;
size_type ii = min(sz - 1, i);
for (int t = ii; t <= 0; --t) {
if (rep->s[t] == c) return t;
}
return npos;
This can still fail but only for strings that are _very_ large.
Can you test it.
Lgb
Re: Bug in citation dialog
Allan Rae <[EMAIL PROTECTED]> wrote: > > To fix this bug we need to extend the ButtonController a little. However, > > this demonstrates the power of > > Asger's Model/View/Controller separation; the bug is present in many > > dialogs but correct the controller and all the GUI's benefit. Ok, I know. > > ButtonController is Xforms-specific at the moment, but it should be made > > generic. > > How generic? All of the code in BC is xforms specific. That's the point > of the Policy and Controller separation. Perhaps you just want an > abstract base class? Things became a little clearer with sleep! an astract base class for BC and for View is exactly what I want. > I'll get back to reading this fully later tonight (better go do some work > soon) but maybe you should ask: > >Why does input() say the inputs are invalid when Dekel clicks on a key? > > AFAI can see input should be returning true not false. This is correct. I have almost certainly got mixed up here, trying not to activate the buttons by simply clicking on the keys. The bug is mine! However, the point of the previous mail was to extend the ButtonController to get the behaviour I want and that still holds. > Anyway as I said, I'll reread your proposal later tonight and comment > again then. Please do. I value the input. Angus
lyx-1.1.6pre3 bug: crash on formula in table
lyx-1.1.6pre3 xforms 0.88 Start a new table, insert a formula into a table field (C-m) -> crash! lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' under the Help menu and then send us a full bug report. Thanks! lyx: Attempting to save document newfile1.lyx as... /home/bpc/ugunt/newfile1.lyx.emergency Save seems successful. Phew. Bye. Abbruch Ulrich
small patch to FormPrint
Adds a Browse button, so that user can choose file to print to more easily. A patch.diff.bz2
Re: rfind and lyxstring
On Wed, Jan 10, 2001 at 11:54:36AM +0100, Lars Gullik Bjnnes wrote:
> Then I end up with something like:
>
> size_type const sz = rep->sz;
> if (!sz) return npos;
>
> size_type ii = min(sz - 1, i);
> for (int t = ii; t <= 0; --t) {
^^^ this should be t >= 0
> if (rep->s[t] == c) return t;
> }
> return npos;
>
> Can you test it.
This works, but I would write
if (rep->sz < 1) return npos;
size_type ii = min(rep->sz - 1, i);
do {
if (rep->s[ii] == c) return ii;
} while (ii-- > 0);
return npos;
And for lyxstring::rfind(lyxstring const & a, size_type) I would write
if (rep->sz < a.length()) return npos;
...
Actually, it appears that lyxstring::rfind(lyxstring const & a, size_type)
is completely broken...
Compilation problem using xlC
-- Kian H Low Chemical Engineering, UCL, Torrington Place, London WC1E 7JE U.K. 020 76793836 / 020 85208975(H) http://www.chemeng.ucl.ac.uk/ Hi, Has anyone compiled Lyx 1.1.5 using cc/xlC for AIX 4.3.2? Configuration is okay but for compilation I keep getting 'Unable to retrieve message errors' for all the source files in src except bmtable.c and tex-strings.C. Can someone please help or give suggestion? the compiler flags are: cc -O2 -qarch=com xlC -g -- Kian H Low Chemical Engineering, UCL, Torrington Place, London WC1E 7JE U.K. 020 76793836 / 020 85208975(H) http://www.chemeng.ucl.ac.uk/
Re: rfind and lyxstring
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Wed, Jan 10, 2001 at 11:54:36AM +0100, Lars Gullik Bjønnes wrote:
| > Then I end up with something like:
| >
| > size_type const sz = rep->sz;
| > if (!sz) return npos;
| >
| > size_type ii = min(sz - 1, i);
| > for (int t = ii; t <= 0; --t) {
|^^^ this should be t >= 0
|
| > if (rep->s[t] == c) return t;
| > }
| > return npos;
| >
| > Can you test it.
|
| This works, but I would write
|
| if (rep->sz < 1) return npos;
| size_type ii = min(rep->sz - 1, i);
| do {
| if (rep->s[ii] == c) return ii;
| } while (ii-- > 0);
| return npos;
I have never been very fond of do while, but this for version is not
overly pretty.
if (rep->sz == 0) return npos;
size_type ii = min(rep->sz - 1, i) + 1;
for (; ii--;)
if (rep->s[ii] == c) return ii;
return npos;
I think I prefere this, yours with a small minor change.
size_type const sz = rep->sz;
if (!sz) return npos;
size_type ii = min(sz - 1, i);
do {
if (rep->s[ii] == c) return ii;
} while (ii--);
return npos;
| And for lyxstring::rfind(lyxstring const & a, size_type) I would write
| if (rep->sz < a.length()) return npos;
| ...
|
| Actually, it appears that lyxstring::rfind(lyxstring const & a, size_type)
| is completely broken...
Possibly, but let's not change this now... we can wait until it bite
or fix1.
Lgb
Re: rfind and lyxstring
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> This works, but I would write I commited something like what you wrote, and it seems to work. Dekel> And for lyxstring::rfind(lyxstring const & a, size_type) I Dekel> would write if (rep->sz < a.length()) return npos; ... Dekel> Actually, it appears that lyxstring::rfind(lyxstring const & a, Dekel> size_type) is completely broken... It looks suspicious... Fortunately, a grep shows that we do not use it :) JMarc
Re: rfind and lyxstring
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I think I prefere this, yours with a small minor change. This is exactly what I commited! I knew you would prefer it :) JMarc
Re: Tabular issues
On Mon, Jan 08, 2001 at 05:07:32PM +0100, Jean-Marc Lasgouttes wrote: > What about the fact that keyword are in mixed-case? Is this considered > good xml practice? I seem to remember that xml is case-sensitive. Since we just changed the new tabular format, and we have two read methods for the new and the "old new" formats (ReadNew, ReadOld), it is easy to change the tags to lowercase in the new format, if it is wanted.
Re: Tabular issues
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> On Mon, Jan 08, 2001 at 05:07:32PM +0100, Jean-Marc Lasgouttes Dekel> wrote: >> What about the fact that keyword are in mixed-case? Is this >> considered good xml practice? I seem to remember that xml is >> case-sensitive. Dekel> Since we just changed the new tabular format, and we have two Dekel> read methods for the new and the "old new" formats (ReadNew, Dekel> ReadOld), it is easy to change the tags to lowercase in the new Dekel> format, if it is wanted. My question was also to know whether it is wanted. Remember I no nearly nothing about xml. JMarc
Re: Tabular issues
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: | | Dekel> On Mon, Jan 08, 2001 at 05:07:32PM +0100, Jean-Marc Lasgouttes | Dekel> wrote: | >> What about the fact that keyword are in mixed-case? Is this | >> considered good xml practice? I seem to remember that xml is | >> case-sensitive. | | Dekel> Since we just changed the new tabular format, and we have two | Dekel> read methods for the new and the "old new" formats (ReadNew, | Dekel> ReadOld), it is easy to change the tags to lowercase in the new | Dekel> format, if it is wanted. | | My question was also to know whether it is wanted. Remember I no | nearly nothing about xml. I think we should go for lowercase. Lgb
Re: Tabular issues
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I think we should go for lowercase. I think so... Now, who will do the change if Juergen is not available? JMarc
Re: Tabular issues
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> I think we should go for lowercase. | | I think so... Now, who will do the change if Juergen is not available? should be easy enough.. .I'll do it. Lgb
table insets
are enumerate, list, etc. intentionally disabled in cell insets in a table ? thanks john -- "It is well to remember, my son, that the entire population of the universe, with one trifling exception, is composed of others." - John Andrew Holmes
Re: table insets
John Levon <[EMAIL PROTECTED]> writes: | are enumerate, list, etc. intentionally disabled in cell insets in a table | ? yes, I belive so. Lgb
Re: table insets
On Wed, Jan 10, 2001 at 04:45:21PM +0100, Lars Gullik Bjnnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | are enumerate, list, etc. intentionally disabled in cell insets in a table > | ? > > yes, I belive so. No, you can have them if you have a fixed width column.
Re: table insets
On Wed, 10 Jan 2001, Dekel Tsur wrote: > On Wed, Jan 10, 2001 at 04:45:21PM +0100, Lars Gullik Bjønnes wrote: > > John Levon <[EMAIL PROTECTED]> writes: > > > > | are enumerate, list, etc. intentionally disabled in cell insets in a table > > | ? > > > > yes, I belive so. > > No, you can have them if you have a fixed width column. > which has a rendering bug, namely if you click on a different cell of a fixed width column, the red box around the cell inset isn't removed from the old cell. I couldn't reproduce the old bug though (http://sourceforge.net/bugs/?func=detailbug_id=124363_id=15212) john -- "It is well to remember, my son, that the entire population of the universe, with one trifling exception, is composed of others." - John Andrew Holmes
Patch
* src/insets/insettext.C (LocalDispatch): Add handling of LFUN_BREAKPARAGRAPHKEEPLAYOUT. patch.gz
Re: The only good bug is a dead bug (1.1.5fix3, status update #2)
> "John" == John Levon <[EMAIL PROTECTED]> writes: >> - crash when changing layout >> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg13171.html John> In 1.1.6 I can only get crashes from this by saving (either John> save, or save-while-quitting, or emergency save). A pure virtual John> function gets called. My debugging efforts failed miserable at John> this one :( I can shed more light on this one. When changing the layout to a command-type layout, the display attribute of insets is reset to false (around text.C:1044), where the inset here is a formula macro. Then, in InsetFormula::display(bool), it seems that for whatever unknown reason, the math inset is cloned and the deleted (??). This means that the pointer to the macro inset contained in the math macro table is now broken, and that anything can happen later. There was another problem which cause the instant crash referred to in the bug report, but I fixed this one. So, I know why it happens, but I really do not know what we want to do about it. JMarc PS: you may want to add this comment to the bug repository. PPS: am I allowed to add bugs there? I see there is a jmarc user.
Re: table insets
On Wed, Jan 10, 2001 at 05:03:19PM +, John Levon wrote: > which has a rendering bug, namely if you click on a different cell of a > fixed width column, the red box around the cell inset isn't removed from > the old cell. > > I couldn't reproduce the old bug though > (http://sourceforge.net/bugs/?func=detailbug_id=124363_id=15212) Juergen made a lot of changes to the tabular code, so I guess that this bug has been fixed.
Re: Bug in citation dialog
[Extending the ButtonController to be a generic controller, which can handle activation and deactivation of elements in the GUI according to when different criteria are valid.] It is an admirable goal to pursuit, but my experience is that it is fairly difficult to design a truly generic Controller class across different toolkits. This is so, because you have to design the Controller to work with very few behavioural guarantees. For instance, with some toolkits, the changing of an input box can trigger a callback, but in this callback, it is not possible to get the contents of the input box in this callback -- it is not updated until after the callback returns. Now, this should not put you off. I only want to warn you that it might be a longer journey that you plan. The best advise I can give is to design as you go: Only implement what is needed for the toolkit at hand, and when another one is to be assimilated, have a look to see if it is possible. If it is, great. If not, refactor it to handle the new toolkit. It would be a mistake to think that you can design it to encompass all strange toolkits from the start. Greets, Asger
Re: 1.1.6pre3 crash on opening doc - update
Allan > I suspect he was trying the newfound trick of leaving off the extension > from the figure to try to support generation of PDF and ps from the one > file (since pdflatex prefers png files and we still insist on writing the > extension into the file). Not that I'm aware of. The file was written under Lyx 1.1.5 and I didn't realise that feature was available then. Ben
Re: 1.1.6pre3 crash on opening doc - update
JM
> Ben> (gdb) frame 6 #6 0x81d3111 in GetExtension (name=@0x84b3d18) at
> Ben> filetools.C:985 985 in filetools.C (gdb) print *(name.rep) $1 =
> Ben> {sz = 0, ref = 3019, res = 1, s = 0x836e988 ""} (gdb)
>
> Ben> Does this help?
>
> Yes, it did really. Another question: do you have an empty image (no
> file) in your document? Or is there another reason why GetExtension()
> is called with an empty string?
Hmmm, I hope not since it is the final copy of a consulting report.
I do have the habit of commenting out figures that I don't wan't in the final
report but are still useful for my information. Can't recall if that is the
case here.
I guess regardless it still shouldn't happen. It was fine with version 1.1.5
so it has to do with the recent changes. I have had no problem with any other
file. The only thing diffferent with this one is that I was using the RCS.
Don't know if this is responsible?
Ben
Re: [BUG] lyx1.1.6pre3 stops PS rendering
John Levon wrote: > On Tue, 9 Jan 2001, Ben Stanley wrote: > > > John Levon wrote: > > > > > On Wed, 3 Jan 2001, Ben Stanley wrote: > > > > > > > > > > > Hi, > > > > > > > > I tried out 1.1.6pre3 briefly, and noticed that the old bug to do with > > > > preview postscript images is still there... > > > > > > > > When I load my thesis, LyX will render some of the pictures, but not others. > > > > Which pictures are rendered changes randomly. The pictures that are rendered > > > > are often rendered with different colour depths from time to time. > > > > > > > > > > After loading, try doing nothing (i.e. wait for LyX to finish > > > rendering). Does leaving it help ? > > > > Yes, But not always. Sometimes I can leave it alone, and I get no pictures at > > all. > > > > Do you restart LyX each time ? Once you have moved once, then xforms is > confused for the rest of the lyx session. I usually have to re-size my LyX window to be able to work with the thesis - it's default size is too small! So, my usual routine is to start LyX, resize the window to take up the full screen vertically (which reveals that xforms has difficulty keeping up with the resizing, and often misses the last update...), and then load my thesis. If I don't move the window around, then... If I start up LyX on my thesis, and don't move or re-size the window, but I scroll around in the document while it's rendering (in particular, if I jump to the end where I'm working), then the ps rendering seems to stop pretty reliably. If I start up LyX on my thesis, and don't move or re-size the window, and don't scroll around until all the gs processes have finished, then all of the pictures render (and there's about 80 of them...). > > > > GNU Ghostscript 5.50 (2000-2-13) > > so it is not the 6.50 bug > > john > > -- > "It is well to remember, my son, that the entire population of the > universe, with one trifling exception, is composed of others." > - John Andrew Holmes -- Ben Stanley |barf [ba:rf] 2. "He suggested using FORTRAN, PhD Student | and everybody barfed." - From the Shogakukan SITACS| DICTIONARY OF NEW ENGLISH (Second Edition) University of Wollongong | Australia |http://www.uow.edu.au/~bds02
