Re: [Bug 3974] crash with user defined external templates
Bernhard Roider [EMAIL PROTECTED] writes: Does the new libFileSearch have to build a vectorpair? We do not really care about user_lyxdir and such identifiers, IMO. This used is only for the message. Good point, but I suspect an enum would be better, and could be used to put the messages in a better shape. insist on keeping this, a mapstring, FileName would make more sense. That was also my first thought when i implemented this method, but with that approach we lose the order of the entries, which is essential for the logic. Good point too. I am not sure the notion of build_dir is useful anymore, I don't know that either but i added it because it is used in the other libFileSearch method too. Good idea. I think we need some kind of information for the user what is happening in this case, because if there is a problem because of one template hides another one the user should be able to find a hint about what's going on. I agree with that, but people who launch LyX from a GUI will not see anything, so it is no of much use as it is. JMarc
Re: [Bug 3974] crash with user defined external templates
Bernhard Roider <[EMAIL PROTECTED]> writes: >> Does the new libFileSearch have to build a vector>? We do not >> really care about "user_lyxdir" and such identifiers, IMO. > > This used is only for the message. Good point, but I suspect an enum would be better, and could be used to put the messages in a better shape. >> insist on keeping this, a mapwould make more sense. > > That was also my first thought when i implemented this method, but > with that approach we lose the order of the entries, which is > essential for the logic. Good point too. >> I am not sure the notion of build_dir is useful anymore, > > I don't know that either but i added it because it is used in the > other libFileSearch method too. Good idea. > I think we need some kind of information for the user what is > happening in this case, because if there is a problem because of one > template hides another one the user should be able to find a hint > about what's going on. I agree with that, but people who launch LyX from a GUI will not see anything, so it is no of much use as it is. JMarc
Re: [Bug 3974] crash with user defined external templates
Bernhard Roider wrote: ... We have to decide what is our policy for handling stuff in system dir vs stuff in .lyx. We cannot decide file by file whether in one case the system version is read, but not in the other. The behaviour should be predictable. ... So what's the opinion now? JMarc? Others? Again, my opinion is that your patch does the right thing (preference of user_lyxdir over build_lyxdir over system_lyxdir). Any objections? If not, I'd say put your fix in branch and trunk. Jürgen
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Again, my opinion is that your patch does the right thing (preference of user_lyxdir over build_lyxdir over system_lyxdir). Any objections? If not, I'd say put your fix in branch and trunk. I lost the patch. Where is it? JMarc
Re: [Bug 3974] crash with user defined external templates
Jean-Marc Lasgouttes wrote: I lost the patch. Where is it? http://bugzilla.lyx.org/attachment.cgi?id=1959action=view Jürgen
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: I lost the patch. Where is it? http://bugzilla.lyx.org/attachment.cgi?id=1959action=view I have not see this patch before actually. Does the new libFileSearch have to build a vectorpair? We do not really care about user_lyxdir and such identifiers, IMO. If we insist on keeping this, a mapstring, FileName would make more sense. Other than that, this new function looks useful. So the new behaviour would be to merge the three template files (BTW, I am not sure the notion of build_dir is useful anymore, but this is a separate discussion). The code as it is written makes sense, but I do not like outputting error messages to the console. They should be turned into debug messages (if we keep them). Instead we could mark in the GUI where each template comes from. JMarc
Re: [Bug 3974] crash with user defined external templates
Jean-Marc Lasgouttes schrieb: [EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: I lost the patch. Where is it? http://bugzilla.lyx.org/attachment.cgi?id=1959action=view I have not see this patch before actually. Does the new libFileSearch have to build a vectorpair? We do not really care about user_lyxdir and such identifiers, IMO. This used is only for the message. insist on keeping this, a mapstring, FileName would make more sense. That was also my first thought when i implemented this method, but with that approach we lose the order of the entries, which is essential for the logic. Other than that, this new function looks useful. So the new behaviour would be to merge the three template files (BTW, I am not sure the notion of build_dir is useful anymore, I don't know that either but i added it because it is used in the other libFileSearch method too. separate discussion). The code as it is written makes sense, but I do not like outputting error messages to the console. They should be turned into debug messages (if we keep them). Instead we could mark in the GUI where each template comes from. I think we need some kind of information for the user what is happening in this case, because if there is a problem because of one template hides another one the user should be able to find a hint about what's going on. bernhard
Re: [Bug 3974] crash with user defined external templates
Bernhard Roider wrote: > > ... We have to decide what is our policy > > for handling stuff in system dir vs stuff in .lyx. We cannot decide > > file by file whether in one case the system version is read, but not > > in the other. The behaviour should be predictable. ... > > So what's the opinion now? JMarc? Others? Again, my opinion is that your patch does the right thing (preference of user_lyxdir over build_lyxdir over system_lyxdir). Any objections? If not, I'd say put your fix in branch and trunk. Jürgen
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Again, my opinion is that your patch does the right thing (preference of > user_lyxdir over build_lyxdir over system_lyxdir). > > Any objections? If not, I'd say put your fix in branch and trunk. I lost the patch. Where is it? JMarc
Re: [Bug 3974] crash with user defined external templates
Jean-Marc Lasgouttes wrote: > I lost the patch. Where is it? http://bugzilla.lyx.org/attachment.cgi?id=1959=view Jürgen
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Jean-Marc Lasgouttes wrote: >> I lost the patch. Where is it? > > http://bugzilla.lyx.org/attachment.cgi?id=1959=view I have not see this patch before actually. Does the new libFileSearch have to build a vector>? We do not really care about "user_lyxdir" and such identifiers, IMO. If we insist on keeping this, a mapwould make more sense. Other than that, this new function looks useful. So the new behaviour would be to merge the three template files (BTW, I am not sure the notion of build_dir is useful anymore, but this is a separate discussion). The code as it is written makes sense, but I do not like outputting error messages to the console. They should be turned into debug messages (if we keep them). Instead we could mark in the GUI where each template comes from. JMarc
Re: [Bug 3974] crash with user defined external templates
Jean-Marc Lasgouttes schrieb: [EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: I lost the patch. Where is it? http://bugzilla.lyx.org/attachment.cgi?id=1959=view I have not see this patch before actually. Does the new libFileSearch have to build a vector>? We do not really care about "user_lyxdir" and such identifiers, IMO. This used is only for the message. insist on keeping this, a mapwould make more sense. That was also my first thought when i implemented this method, but with that approach we lose the order of the entries, which is essential for the logic. Other than that, this new function looks useful. So the new behaviour would be to merge the three template files (BTW, I am not sure the notion of build_dir is useful anymore, I don't know that either but i added it because it is used in the other libFileSearch method too. separate discussion). The code as it is written makes sense, but I do not like outputting error messages to the console. They should be turned into debug messages (if we keep them). Instead we could mark in the GUI where each template comes from. I think we need some kind of information for the user what is happening in this case, because if there is a problem because of one template hides another one the user should be able to find a hint about what's going on. bernhard
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] schrieb: http://bugzilla.lyx.org/show_bug.cgi?id=3974 --- Additional Comments From [EMAIL PROTECTED] 2007-09-10 11:34 --- So, Bernhard, what shall we do with this? Postpone to 1.5.3? When i posted the patch to the devel-list there was this comment from JMarc: ... We have to decide what is our policy for handling stuff in system dir vs stuff in .lyx. We cannot decide file by file whether in one case the system version is read, but not in the other. The behaviour should be predictable. ... So what's the opinion now? JMarc? Others? bernhard ps: as i have nearly no time to do active development i think you should decide what to do.
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] schrieb: http://bugzilla.lyx.org/show_bug.cgi?id=3974 --- Additional Comments From [EMAIL PROTECTED] 2007-09-10 11:34 --- So, Bernhard, what shall we do with this? Postpone to 1.5.3? When i posted the patch to the devel-list there was this comment from JMarc: ... We have to decide what is our policy for handling stuff in system dir vs stuff in .lyx. We cannot decide file by file whether in one case the system version is read, but not in the other. The behaviour should be predictable. ... So what's the opinion now? JMarc? Others? bernhard ps: as i have nearly no time to do active development i think you should decide what to do.
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] schrieb: http://bugzilla.lyx.org/show_bug.cgi?id=3974 --- Additional Comments From [EMAIL PROTECTED] 2007-09-10 11:34 --- So, Bernhard, what shall we do with this? Postpone to 1.5.3? When i posted the patch to the devel-list there was this comment from JMarc: ... We have to decide what is our policy for handling stuff in system dir vs stuff in .lyx. We cannot decide file by file whether in one case the system version is read, but not in the other. The behaviour should be predictable. ... So what's the opinion now? JMarc? Others? bernhard ps: as i have nearly no time to do active development i think you should decide what to do.
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] schrieb: > http://bugzilla.lyx.org/show_bug.cgi?id=3974 > > > > > > --- Additional Comments From [EMAIL PROTECTED] 2007-09-10 11:34 --- > So, Bernhard, what shall we do with this? Postpone to 1.5.3? > > When i posted the patch to the devel-list there was this comment from JMarc: > ... We have to decide what is our policy > for handling stuff in system dir vs stuff in .lyx. We cannot decide > file by file whether in one case the system version is read, but not > in the other. The behaviour should be predictable. ... So what's the opinion now? JMarc? Others? bernhard ps: as i have nearly no time to do active development i think you should decide what to do.
[patch] fix bug 3974: crash with user defined external templates
Hello, the crash occured because ControlExternal::getTemplate() is called with the index -1 which produces an invalid iterator that is accessed afterwards. Bernhard Index: src/frontends/controllers/ControlExternal.cpp === --- src/frontends/controllers/ControlExternal.cpp (revision 18994) +++ src/frontends/controllers/ControlExternal.cpp (working copy) @@ -135,7 +135,9 @@ external::TemplateManager::Templates::const_iterator i1 = external::TemplateManager::get().getTemplates().begin(); - advance(i1, i); + if (i = 0) { + advance(i1, i); + } return i1-second; }
Re: [patch] fix bug 3974: crash with user defined external templates
Bernhard == Bernhard Roider [EMAIL PROTECTED] writes: Bernhard Hello, the crash occured because Bernhard ControlExternal::getTemplate() is called with the index -1 Bernhard which produces an invalid iterator that is accessed Bernhard afterwards. Why does having user defined templates trigger the bug? JMarc
Re: [patch] fix bug 3974: crash with user defined external templates
Jean-Marc Lasgouttes schrieb: Bernhard == Bernhard Roider [EMAIL PROTECTED] writes: Bernhard Hello, the crash occured because Bernhard ControlExternal::getTemplate() is called with the index -1 Bernhard which produces an invalid iterator that is accessed Bernhard afterwards. Why does having user defined templates trigger the bug? I don't know but debugging showed that behavior. bernhard
Re: [patch] fix bug 3974: crash with user defined external templates
Jean-Marc Lasgouttes schrieb: Bernhard == Bernhard Roider [EMAIL PROTECTED] writes: Bernhard Hello, the crash occured because Bernhard ControlExternal::getTemplate() is called with the index -1 Bernhard which produces an invalid iterator that is accessed Bernhard afterwards. Why does having user defined templates trigger the bug? Ok, now i think i know why: In InsetExternal.cpp the line string defaultTemplateName = RasterImage; seems to define the default template which is missing when having user defined templates, because then the system defined templates are not loaded. I have a patch that makes lyx load system and user defined templates. if there is no bug# for that i will create one, because it is really necessary IMHO. bernhard
[patch] fix bug 3974: crash with user defined external templates
Hello, the crash occured because ControlExternal::getTemplate() is called with the index -1 which produces an invalid iterator that is accessed afterwards. Bernhard Index: src/frontends/controllers/ControlExternal.cpp === --- src/frontends/controllers/ControlExternal.cpp (revision 18994) +++ src/frontends/controllers/ControlExternal.cpp (working copy) @@ -135,7 +135,9 @@ external::TemplateManager::Templates::const_iterator i1 = external::TemplateManager::get().getTemplates().begin(); - advance(i1, i); + if (i >= 0) { + advance(i1, i); + } return i1->second; }
Re: [patch] fix bug 3974: crash with user defined external templates
> "Bernhard" == Bernhard Roider <[EMAIL PROTECTED]> writes: Bernhard> Hello, the crash occured because Bernhard> ControlExternal::getTemplate() is called with the index -1 Bernhard> which produces an invalid iterator that is accessed Bernhard> afterwards. Why does having user defined templates trigger the bug? JMarc
Re: [patch] fix bug 3974: crash with user defined external templates
Jean-Marc Lasgouttes schrieb: "Bernhard" == Bernhard Roider <[EMAIL PROTECTED]> writes: Bernhard> Hello, the crash occured because Bernhard> ControlExternal::getTemplate() is called with the index -1 Bernhard> which produces an invalid iterator that is accessed Bernhard> afterwards. Why does having user defined templates trigger the bug? I don't know but debugging showed that behavior. bernhard
Re: [patch] fix bug 3974: crash with user defined external templates
Jean-Marc Lasgouttes schrieb: "Bernhard" == Bernhard Roider <[EMAIL PROTECTED]> writes: Bernhard> Hello, the crash occured because Bernhard> ControlExternal::getTemplate() is called with the index -1 Bernhard> which produces an invalid iterator that is accessed Bernhard> afterwards. Why does having user defined templates trigger the bug? Ok, now i think i know why: In InsetExternal.cpp the line string defaultTemplateName = "RasterImage"; seems to define the default template which is missing when having user defined templates, because then the system defined templates are not loaded. I have a patch that makes lyx load system and user defined templates. if there is no bug# for that i will create one, because it is really necessary IMHO. bernhard