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: Precedence parenthesis (or not) (was Re: Tabular issues)
On Wed, 10 Jan 2001, Asger K. Alstrup Nielsen wrote: > On 9 Jan 2001, Lars Gullik Bjønnes wrote: > > - () mithout meaning hides () that are really needed. > > Parenthesis are needed if the author feels they are needed. And then, they > are really needed. It's as simply as that. > > Come on, Lars. Code is for communication between humans, not machines. > That's why we don't use binary codes. > > You should write the code such that humans can understand it, > and that involves proactively using parenthesis when there is > some doubt to the meaning, or you generally feel that it can improve the > understanding. A comment or two before the groups of conditions can also help make sense of what's going on and may help avoid the situation we had with the '\n' after tables where someone cut a conditional in half with a preprocessor directive because they didn't understand what was going on. There was a comment in that case but it seems it was either ignored or the person decided they understood what was going on better than the person who wrote the comment. (There's still a problem with '\n' after tables in floats but that may be easier to fix (or even disappear) once NEW_INSETS is the default) Anyway, grouping conditions together with a () is all well and good but a comment explaining why they are grouped is even more useful. Allan. (ARRae)
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: 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
Precedence parenthesis (or not) (was Re: Tabular issues)
On 9 Jan 2001, Lars Gullik Bjønnes wrote: > I will remove () that has no value when I see them. > > - two points: > - () without meaning kindo shows that the coder does not know the > precedence rules I'm sure you don't know all of them well enough to securely disambiguify any given C++ expression I might throw at you. > - () without meaning makes the code harder to understand Look deep into your heart. You know there is meaning to the "superfluous" parenthesis, and Juergen is not using too many parentheses. He might be making lots of other bug^t^t^tfeatures, but don't attack him for being trigger happy with the curves. > - () mithout meaning hides () that are really needed. Parenthesis are needed if the author feels they are needed. And then, they are really needed. It's as simply as that. Come on, Lars. Code is for communication between humans, not machines. That's why we don't use binary codes. You should write the code such that humans can understand it, and that involves proactively using parenthesis when there is some doubt to the meaning, or you generally feel that it can improve the understanding. I know the precendence rules for C++ about 90%, and others know them 80%. You might know them 95%, but the thing is that the common ground for all of us might be as low as 70%. (Actually I expect it to be lower.) Therefore, it is a good idea to use parenthesis when you feel that it can increase the communication between *humans*. (That includes communicating with yourself.) On top of this, add the fact that different programming languages have different precedence rules. There is no *natural right way* to unambiguously define the precendence rules globally once and for all for all operators. Therefore, we should not let our communication be ruled by the whims of one particular language designer. His decision is not the best, or the only one. (This is particularly so in the case of C++, for which the precedence rules completely suck.) So when you say that you want to undiscriminatingly remove the "redundant" parentheses, you might at best be targeting the communication to you only. Maybe it's better to ensure the communication with the rest of the team? I'm sure Juergen's code is not as convulted that you can't understand what is going on, even with a few parenthesis where you feel they are redudant. Greets, Asger
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: 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&bug_id=124363&group_id=15212) Juergen made a lot of changes to the tabular code, so I guess that this bug has been fixed.
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.
Patch
* src/insets/insettext.C (LocalDispatch): Add handling of LFUN_BREAKPARAGRAPHKEEPLAYOUT. patch.gz
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&bug_id=124363&group_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
Re: table insets
On Wed, Jan 10, 2001 at 04:45:21PM +0100, Lars Gullik Bj&resh;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.
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
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: lyxformat 2,17
Ralf Corsepius <[EMAIL PROTECTED]> writes: | Having set LANG=german, lyx-1.1.6pre3 and lyx-devel/head-branch | generate: | | #LyX 1.1 created this file. For more info see http://www.lyx.org/ | \lyxformat 2,17 | \textclass article | \language english | | Having set LANG=C: | #LyX 1.1 created this file. For more info see http://www.lyx.org/ | \lyxformat 2.17 | \textclass article | \language english | | This means the lyxformat float is stored in internationalized form | once again. This is bad... In 1.2.x we will switch to an int or string format on the version number. Lgb
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
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: | > "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
> "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
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: 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: 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
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
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
On Wed, Jan 10, 2001 at 11:54:36AM +0100, Lars Gullik Bj&resh;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;
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...
small patch to FormPrint
Adds a Browse button, so that user can choose file to print to more easily. A patch.diff.bz2
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
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
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: 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
> "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
> "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: 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)
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
> "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?
JMarc
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
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
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
> "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: 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
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
