Re: New filedialog
On 06-Mar-2001 Edwin Leuven wrote: Perhaps I should just keep my big mouth shut. Why I think you're principally right! But think of this in developement. While a tree is in development a lot of internal changes happen and noone is using all of the frontends just the default frontend. Maybe one day the default frontend will be Qt2, you never know and then the changes will be applied to that frontend so that we can alos have a visual feedback AND compile the code. Then it is the work of the GUI-porters to change their code so that when we freeze the code (and at this time no interface changes are allowed!!!) to adapt their ports to the new interfaces. So you don't have to monitor it all the time, you just have to look at it when you decide you want to get your port up-to-date! This happens with a lot of programms which have an external accessible API (think of them as plugins). ps. don't take me wrong it is nothing personal, I think everyone is doing a great job. Never! You're doing a great job too :) Jrgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jrgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "The C Programming Language -- A language which combines the flexibility of assembly language with the power of assembly language."
Re: ButtonController questions
On Mon, 5 Mar 2001, Angus Leeming wrote: Please enlighten me why you think you have to implement it the way you suggest. Ok, here goes. If I leave out the all important line in ButtonController::input(): if (ButtonPolicy::SMI_NOOP == in) return; then the up,down,add,delete buttons in the Citation dialog become active when a entry is clicked on in the two browsers. I think this occurs because their state is controlled by the dialog rather than by the ButtonController, but I'm not sure about this. In that case I suggest you put the above line in nextState() where it belongs but also keep it in Citation with a comment saying that it shouldn't really be there because the up,down,add,delete buttons are mishandled (or at least handled by the dialog). That way everyone should get what is needed -- if you don't have it in nextState() what will happen when someone calls with SMI_NOOP? Undefined. Of course, you could always extend ButtonController so that it can control _everything_, but that's definitely your baby not mine! What? You want me to come up with solutions to problems _and_ implement them too! ;-) Incidentally, this stuff is now in BRANCH_MVC. Wait a day or so and it'll be in HEAD, so you won't need to check out anything to experiment. From the glimpses I've had I like it a lot. A whole lot. Allan. (ARRae)
Re: Menu Separator aka lyxarrow
On Tue, Mar 06, 2001 at 01:17:25PM -0800, [EMAIL PROTECTED] wrote: ... Date: Tue, 6 Mar 2001 13:17:25 -0800 (PST) From: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] To: LyX Developer List [EMAIL PROTECTED] Subject: Re: Menu Separator aka lyxarrow In-Reply-To: [EMAIL PROTECTED] On Tue, 6 Mar 2001, John Levon wrote: Why do we have this ? It seems a bit ad hoc. Is it just for the convenience of the doc writers or something ? Put on your asbestos suit! John Weiss is going to hunt you down and smack you with his small fish :-) (Find a message from him and look at his signature.) We had a big row about this a couple of years ago when we discussed the proper format for the "arrow" to be used in the documentation for things like File-Open. I don't remember exactly how we settled on that particular rotated triangle, but it was deemed Holy and Pure, and thus became policy. While it is certainly crucial for the LyX documentors (who number approximately 0.1 right now), any software documentation should take advantage of it. Whatever you do to it, it should be representable in both the LyX window and the printed documentation in an obvious, common way (no ERT, etc.) and should be obvious as something which ties menu panels together. This particular triangle is used in a number of desktops to indicate that there is another menu lurking underneath an item. I would argue that it should stay in the special character menu, but if you can come up with a better name, feel free. Mike Agree! I used it in the doc for faxview. ... -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq
Re: Menu Separator aka lyxarrow
On Tue, 6 Mar 2001 [EMAIL PROTECTED] wrote: On Tue, 6 Mar 2001, John Levon wrote: Why do we have this ? It seems a bit ad hoc. Is it just for the convenience of the doc writers or something ? Put on your asbestos suit! /me steps backwards slowly ;) john -- "We might be in for more rain than maybe we're going to get." - Henry Blofeld
Re: credits
Edwin Leuven [EMAIL PROTECTED] writes: | ps. Lars: in case you think that it is a good idea, perhaps you give | me write | access to www-devel so I can stop bugging john who usually does this | for me :) Perhaps I should do that... :-) Lgb
Re: unknown action and keys
John Levon [EMAIL PROTECTED] writes: | Pressing any normal key for entering text gives lyxfunc::getStatus() fits | setting the minibuffer to "unknown action". I can't grok this. | | | WorkArea: Key is `s' [115] | WorkArea: Keysym is `s' [115] | Workarea Diff: 2441 | KeySym is s[115] State is [0] | action first set to [-1] | meta_fake_bit is [0] | action now set to [-1] | Key [-1][s] This looks correct. | | Is this the meaning of the cryptic : | | 559 // We cannot use this function here nor this. Lgb
Re: unknown action and keys
On 6 Mar 2001, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | Pressing any normal key for entering text gives lyxfunc::getStatus() fits | setting the minibuffer to "unknown action". I can't grok this. Try typing a space twice, and try reading the helpful message in the minibuffer. You will see what I mean, it is immediately overwritten by the "Unknown Action" message produced in lyxfunc.C:getStatus() | meta_fake_bit is [0] | action now set to [-1] | Key [-1][s] This looks correct. | | Is this the meaning of the cryptic : | | 559 // We cannot use this function here nor this. Me neither ! This is in lyxfunc.C, what is the meaning of the comment ? thanks john -- "We might be in for more rain than maybe we're going to get." - Henry Blofeld
Re: unknown action and keys
John Levon [EMAIL PROTECTED] writes: | | Is this the meaning of the cryptic : | | | | 559 // We cannot use this function here | | nor this. | | Me neither ! This is in lyxfunc.C, what is the meaning of the | | comment ? if getStatus(...) Disable is true then the lyxfunc is disabled and we cannot use it. so we just exit. Lgb
Re: unknown action and keys
On 7 Mar 2001, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | | Is this the meaning of the cryptic : | | | | 559 // We cannot use this function here | | nor this. | | Me neither ! This is in lyxfunc.C, what is the meaning of the | | comment ? if getStatus(...) Disable is true then the lyxfunc is disabled and we cannot use it. so we just exit. Lgb Oh, I see what it means now. Thanks. Can you reproduce the problem I mention ? I think it's what Michael is referring to in https://sourceforge.net/tracker/index.php?func=detailaid=404575group_id=15212atid=115212 thanks john -- "We might be in for more rain than maybe we're going to get." - Henry Blofeld
Re: Some small memory leaks ..
Henner Zeller [EMAIL PROTECTED] writes: | Anyway, I just have a small note: I was curious and looked for memory | leaks using the LeakTracer by Erwin Andreasen Can you redo this now with current cvs? I belive that most of them should be fixed now. (I know there are some I did not fix...) Lgb
Re: New graphics inset core dump
This is just an assert I placed that goes off, this means that some assumption of mine is incorrect. The assumption is that the callers will destroy all information in the graphics cache, this is not so apparently. The quick fix is to destory everything on destruction, Actually this is done already by the shared_ptr, the assert can be removed. I'm applying the fix now. * John Levon [EMAIL PROTECTED] [010306 21:56]: 1) create an empty file test.png 2) graphics-insert for this file 3) quit lyx it will coredump on quit john -- "If one tells the truth, one is sure, sooner or later, to be found out." - Oscar Wilde -- Baruch Even http://baruch.ev-en.org/
Assert to print a message
Hello, I believe we should add a printing to the Assert definition so that it will be obvious when a core dump is caused by some assert, it would be great if it included the line and file of the assert, and it would be best if it printed the assert condition itself, but I do not know how to achieve that in C++. Should I provide a patch for this? -- Baruch Even http://baruch.ev-en.org/
Re: Assert to print a message
On Wed, 7 Mar 2001, Baruch Even wrote:
Hello,
I believe we should add a printing to the Assert definition so that it
will be obvious when a core dump is caused by some assert, it would be
great if it included the line and file of the assert, and it would be
best if it printed the assert condition itself, but I do not know how to
achieve that in C++.
Is :
#define assert(a) \
if (!(a)) \
printf("%s failed\n", #a);
some sort of GNU extension ? Even if so it would be good to add this
if GNUC is defined ...
thanks
john
Re: Assert to print a message
Baruch Even [EMAIL PROTECTED] writes: | Hello, | | I believe we should add a printing to the Assert definition so that it | will be obvious when a core dump is caused by some assert, it would be | great if it included the line and file of the assert, and it would be | best if it printed the assert condition itself, but I do not know how to | achieve that in C++. | | Should I provide a patch for this? then you have to use a macro. why can't you use the debugger? Lgb
Re: Assert to print a message
On 7 Mar 2001, Lars Gullik Bjønnes wrote: Baruch Even [EMAIL PROTECTED] writes: | Hello, | | I believe we should add a printing to the Assert definition so that it | will be obvious when a core dump is caused by some assert, it would be | great if it included the line and file of the assert, and it would be | best if it printed the assert condition itself, but I do not know how to | achieve that in C++. | | Should I provide a patch for this? then you have to use a macro. I don't see the harm in such a macro in thise small case, at much greater convenience ... why can't you use the debugger? debuggers are awkward, slow, and a real pain. I don't like debuggers personally, even for just a stack trace john -- "Faced with the prospect of rereading this book, I would rather have my brains ripped out by a plastic fork." - Charles Cooper on "Business at the Speed of Thought"
Re: Assert to print a message
* Lars Gullik Bjnnes [EMAIL PROTECTED] [010307 14:59]: Baruch Even [EMAIL PROTECTED] writes: | Hello, | | I believe we should add a printing to the Assert definition so that it | will be obvious when a core dump is caused by some assert, it would be | great if it included the line and file of the assert, and it would be | best if it printed the assert condition itself, but I do not know how to | achieve that in C++. | | Should I provide a patch for this? then you have to use a macro. I dont mind even placing in Assert() a line that does: lyxerr "ASSERT Failed!\n"; This will suffice. why can't you use the debugger? It's not a question of using the debugger, this is just to make bug reports (like John's latest bug finding in IG) more sensible. Learning that it was a core dump doesn't help me to understand it. Knowing it's an assert that failed will give me more clues to decipher the reason. In this case the problem was trivial enough to find, in other cases it might not be so trivial. -- Baruch Even http://baruch.ev-en.org/
Re: Assert to print a message
John Levon [EMAIL PROTECTED] writes:
| On 7 Mar 2001, Lars Gullik Bjnnes wrote:
|
| Baruch Even [EMAIL PROTECTED] writes:
|
| | Hello,
| |
| | I believe we should add a printing to the Assert definition so that it
| | will be obvious when a core dump is caused by some assert, it would be
| | great if it included the line and file of the assert, and it would be
| | best if it printed the assert condition itself, but I do not know how to
| | achieve that in C++.
| |
| | Should I provide a patch for this?
|
| then you have to use a macro.
|
| I don't see the harm in such a macro in thise small case, at much greater
| convenience ...
#define LYX_ASSERT(x) Assert(x, __FILE__, __LINE__)
templateclass A
inline
void Assert(A assertion, char const * fil, char const * lin)
{
if (!assertion) {
cerr "Assertion in " fil "at line " lin endl;
::emergencySave();
lyx::abort();
}
}
perhaps.
I am not sure if I like it.
Lgb
Re: Assert to print a message
On Wed, 7 Mar 2001, Baruch Even wrote: Learning that it was a core dump doesn't help me to understand it. Knowing it's an assert that failed will give me more clues to decipher the reason. Then JOhn should have provided a backtrace as well which would have shown immediately that it was an Assert and where. Allan. (ARRae)
Re: Assert to print a message
On Wed, 7 Mar 2001, Allan Rae wrote: Then JOhn should have provided a backtrace as well which would have shown immediately that it was an Assert and where. Allan. (ARRae) I didn't see the point in this case, he had to repeat it anyway to check his fix fixed it. john -- "Faced with the prospect of rereading this book, I would rather have my brains ripped out by a plastic fork." - Charles Cooper on "Business at the Speed of Thought"
Exceptions .. ?
Hi, Sorry if I ask dumb questions. I've seen, that the code is compiled with -fno-exceptions. Is this, because some systems/compilers do not yet support exceptions well ? I think that exceptions can help make code better readable and I'd suggest using them if possible (since programmers tend to be used to java as well, this is probably not a big proglem). Ah, by the way, what was the deal to use 'char const *' instead of 'const char *' ? I know, the former is probably a bit more correct from the thinking, but whereever you look, 'const char *' is used .. so it bocomes more confusing. And it is less confusing if you actually have a const pointer to a const string 'const char * const' .. just curious, -hen (and I should really work on my diploma thesis ..)
RE: [PATCH] FileDialog
On 06-Mar-2001 John Levon wrote: cvs add lib/images/file-open.xpm src/frontends/FileDialog.h src/frontends/xforms/FileDialog.C src/frontends/xforms/form_filedialog.* src/frontends/xforms/FormFiledialog.* src/frontends/xforms/forms/form_filedialog.fd src/frontends/kde/File* cvs delete lib/images/buffer-open.xpm src/filedlg.C src/filedlg.h Applied! Jrgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jrgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Remember: Silly is a state of Mind, Stupid is a way of Life. -- Dave Butler
Re: Assert to print a message
* Lars Gullik Bjnnes [EMAIL PROTECTED] [010307 16:28]:
John Levon [EMAIL PROTECTED] writes:
| On 7 Mar 2001, Lars Gullik Bjnnes wrote:
|
| Baruch Even [EMAIL PROTECTED] writes:
|
| | Hello,
| |
| | I believe we should add a printing to the Assert definition so that it
| | will be obvious when a core dump is caused by some assert, it would be
| | great if it included the line and file of the assert, and it would be
| | best if it printed the assert condition itself, but I do not know how to
| | achieve that in C++.
| |
| | Should I provide a patch for this?
|
| then you have to use a macro.
|
| I don't see the harm in such a macro in thise small case, at much greater
| convenience ...
#define LYX_ASSERT(x) Assert(x, __FILE__, __LINE__)
templateclass A
inline
void Assert(A assertion, char const * fil, char const * lin)
{
if (!assertion) {
cerr "Assertion in " fil "at line " lin endl;
::emergencySave();
lyx::abort();
}
}
perhaps.
I am not sure if I like it.
What about a simple;
cerr "Assertion failed, quitting.\n" endl;
This will provide the needed info that the exit is from an assert
without going through the hoops of using a macro to provide the line and
file.
--
Baruch Even
http://baruch.ev-en.org/
Re: Exceptions .. ?
Henner Zeller [EMAIL PROTECTED] writes: | Hi, | Sorry if I ask dumb questions. I've seen, that the code is compiled with | -fno-exceptions. Is this, because some systems/compilers do not yet | support exceptions well ? I think that exceptions can help make code | better readable and I'd suggest using them if possible (since programmers | tend to be used to java as well, this is probably not a big proglem). So far exception support in various compiler have been bery bad, thing are beginning to look up now, so eventually we will begin to use exceptions in LyX as well. | Ah, by the way, what was the deal to use 'char const *' instead of | 'const char *' ? I know, the former is probably a bit more correct from | the thinking, but whereever you look, 'const char *' is used .. so it | bocomes more confusing. And it is less confusing if you actually have a | const pointer to a const string 'const char * const' .. You read it from right to left "pointer to const char" Lgb
Re: Assert to print a message
"Baruch" == Baruch Even [EMAIL PROTECTED] writes: Baruch This will provide the needed info that the exit is from an Baruch assert without going through the hoops of using a macro to Baruch provide the line and file. It seems to me that it says "aborted" instead of "segmentation fault" in this case. JMarc
Re: Assert to print a message
* Jean-Marc Lasgouttes [EMAIL PROTECTED] [010307 16:49]: "Baruch" == Baruch Even [EMAIL PROTECTED] writes: Baruch This will provide the needed info that the exit is from an Baruch assert without going through the hoops of using a macro to Baruch provide the line and file. It seems to me that it says "aborted" instead of "segmentation fault" in this case. It says "aborted (core dump)" Not very helpful, anyhow I'm not going to press this, it's pretty minor and is only of help for the initial diagnosis of what may be the problem before I fire up the debugger. But I still think it might be a usefull thing. -- Baruch Even http://baruch.ev-en.org/
Re: Exceptions .. ?
I think that exceptions can help make code better readable and I'd suggest using them if possible (since programmers tend to be used to you mean 'necessary', do you? java as well, this is probably not a big proglem). Java programmers tend to be a problem ;-} Seriously, as long as you don't need a feature, don't use it. Ah, by the way, what was the deal to use 'char const *' instead of 'const char *' ? I know, the former is probably a bit more correct from the thinking, but whereever you look, 'const char *' is used .. so it bocomes more confusing. As you noticed there are some tiny advantages for 'T const *', so there seems to be no reason _not_ to use it. Personally I don't have problems with 'const T *', since that's the way I am writing my own code. If you work on different projects you need to get used to different styles anyway... I doubt people would be amused if I'd try to force them to switch over to my "own" indentation and bracketing style ;-} The big deal is 'uniformity'. Code should be uniform throughout a project - or at least throughout large parts of a project. Once the rules are set, people are expected to stick to them - unless there are obviously wrong or outdated. And I doubt there are many rules used in the newer parts of LyX that are _obviously_ wrong... And it is less confusing if you actually have a const pointer to a const string 'const char * const' .. You are not supposed to use char * for strings anyway, and I am not aware of similar contructs for other types used in LyX. (and I should really work on my diploma thesis ..) Oh come on... Friday is the day of complaints ;-) Andre' -- Andr Pnitz [EMAIL PROTECTED]
Re: Some small memory leaks ..
HI,
On 7 Mar 2001, Lars Gullik Bjnnes wrote:
LGBn| Can you redo this now with current cvs? I belive that most of them
LGBn| should be fixed now. (I know there are some I did not fix...)
Starting and stopping an empty lyx now causes only 852 Bytes memory leak;
The last thing is interesting: there is a delete called on a object not
allocated with new; I assume the FD_KeyMap is allocated with some xforms
means and then assigned a scoped_ptr ? Anyway, it _can_ be dangerous to
allocate someting with malloc() and free it with 'delete'.
report from LeakTracer as follows:
#-- Leak: counted 5x / total Size: 20
0x80b2eee is in kb_keymap::defkey(kb_sequence *, int, int) (kbmap.C:223).
222 } else {
223 (*newone).table = new kb_keymap;
#-- Leak: counted 1x / total Size: 252
0x80bfaed is in LyXGUI::LyXGUI(LyX *, int *, char **, bool) (lyx_gui.C:154).
153 // Initialize the LyXColorHandler
154 lyxColorHandler = new LyXColorHandler;
#-- Leak: counted 19x / total Size: 224
0x80c09f3 is in flyx_ident_extract(char const *) (lyx_gui_misc.C:209).
208
209 char * sb = new char[se - sc + 1];
#-- Leak: counted 1x / total Size: 4
0x80c181b is in LyX::LyX(int *, char **) (../src/lyx_main.C:81).
80 // Global bindings (this must be done as early as possible.) (Lgb)
81 toplevel_keymap = new kb_keymap;
#-- Leak: counted 11x / total Size: 132
0x81c9fee is in Menubar::Pimpl::makeMenubar(Menu const ) (Menubar_pimpl.C:135).
134
135 ItemInfo * iteminfo = new ItemInfo(this,
#-- Leak: counted 11x / total Size: 220
0x81ca003 is in Menubar::Pimpl::makeMenubar(Menu const ) (Menubar_pimpl.C:135).
134
135 ItemInfo * iteminfo = new ItemInfo(this,
#-- delete on not allocated memory: counted 1x
0x8223386 is in boost::scoped_ptrFD_KeyMap::~scoped_ptr(void)
(../boost/boost/smart_ptr.hpp:87).
86explicit scoped_ptr( T* p=0 ) : ptr(p) {} // never throws
87~scoped_ptr() { delete ptr; }
---
Re: Some small memory leaks ..
Henner Zeller [EMAIL PROTECTED] writes:
| HI,
| On 7 Mar 2001, Lars Gullik Bjnnes wrote:
| LGBn| Can you redo this now with current cvs? I belive that most of them
| LGBn| should be fixed now. (I know there are some I did not fix...)
|
| Starting and stopping an empty lyx now causes only 852 Bytes memory leak;
|
| The last thing is interesting: there is a delete called on a object not
| allocated with new; I assume the FD_KeyMap is allocated with some xforms
| means and then assigned a scoped_ptr ? Anyway, it _can_ be dangerous to
| allocate someting with malloc() and free it with 'delete'.
You are right, I saw this and then "fixed" it.
| report from LeakTracer as follows:
|
|
| #-- Leak: counted 5x / total Size: 20
| 0x80b2eee is in kb_keymap::defkey(kb_sequence *, int, int) (kbmap.C:223).
| 222 } else {
| 223 (*newone).table = new kb_keymap;
Fixed.
| #-- Leak: counted 1x / total Size: 252
| 0x80bfaed is in LyXGUI::LyXGUI(LyX *, int *, char **, bool) (lyx_gui.C:154).
| 153 // Initialize the LyXColorHandler
| 154 lyxColorHandler = new LyXColorHandler;
Fixed.
| #-- Leak: counted 19x / total Size: 224
| 0x80c09f3 is in flyx_ident_extract(char const *) (lyx_gui_misc.C:209).
| 208
| 209 char * sb = new char[se - sc + 1];
Hmm this is harder...
I am not sure where we should delete this.
| #-- Leak: counted 1x / total Size: 4
| 0x80c181b is in LyX::LyX(int *, char **) (../src/lyx_main.C:81).
| 80// Global bindings (this must be done as early as possible.) (Lgb)
| 81toplevel_keymap = new kb_keymap;
Fixed.
| #-- Leak: counted 11x / total Size: 132
| 0x81c9fee is in Menubar::Pimpl::makeMenubar(Menu const ) (Menubar_pimpl.C:135).
| 134
| 135 ItemInfo * iteminfo = new ItemInfo(this,
Fixed.
| #-- Leak: counted 11x / total Size: 220
| 0x81ca003 is in Menubar::Pimpl::makeMenubar(Menu const ) (Menubar_pimpl.C:135).
| 134
| 135 ItemInfo * iteminfo = new ItemInfo(this,
Fixed.
| #-- delete on not allocated memory: counted 1x
| 0x8223386 is in boost::scoped_ptrFD_KeyMap::~scoped_ptr(void)
|(../boost/boost/smart_ptr.hpp:87).
| 86 explicit scoped_ptr( T* p=0 ) : ptr(p) {} // never throws
| 87 ~scoped_ptr() { delete ptr; }
| ---
This is probably the FD_keymap.
Fixed.
Just give me time to commit and then you can do this check again :-)
Lgb
Re: [PATCH] FileDialog
On Tue, 6 Mar 2001, Angus Leeming wrote: On Tuesday 06 March 2001 16:43, John Levon wrote: I was going to come out against encoding the different file selection operations in the controller, but now I'm not so sure. Maybe you're right. And yes, we probably should have a controller like that... I'm not sure if it's the right thing to do here either, but Matthias Ettrich really must have struck a chord with me when he complained about how much each frontend had to implement. Just chewing the cud here... Na. We're following a sensible development cycle: implement something with what facilities and manpower we have see some common areas isolate those areas and extract to common support code write all new stuff using that better idea goto 1 Simple iteration. Not a waterfall model but closer to the extreme programming model. The overall abstraction remains the same (give or take a little) and its the implementation that evolves. You don't end up throwing away much code since it forms the basis for the common code when extracted. All Matthias (actually Asger I would argue) did is bring the consideration of separation of VC sooner. Allan. (ARRae)
namespaces
Does the fact that "boost::scoped_ptrs" etc are now appearing everywhere mean
that we are now using namespaces officially and that I can write (for
example):
namespace frontends {
namespace citation {
...
}
}
?
Angus
Re: namespaces
On Wed, 7 Mar 2001, Angus Leeming wrote:
Does the fact that "boost::scoped_ptrs" etc are now appearing everywhere mean
that we are now using namespaces officially and that I can write (for
example):
namespace frontends {
namespace citation {
...
}
}
You could but why would you need namespace citation?
Just to bundle the view and controller sections?
Seems a bit of overkill.
Just the frontend namespace should be enough.
Although, I think (instant thought -- just add water) that maybe a
namespace frontend ... I don't know I've lost the thought now...
maybe I just thought better of it. Maybe I'm tired. Maybe I'm turning
into a Morlock. (I think I spelled that right -- and no I didn't mispell
Worlock)
Allan. (ARRae)
Cite bug
Small glitch in the citation dialog: OK/apply not enabled when "text after" field is changed. This leads to frustrating work-arounds. 1.1.6fix1 on RH 6.2 from rpm Offtopic comment - I think the project would be well served to change the default bg color. That pasty beige makes the whole interface look dingy. I final hit a threshold of pain and went in and changed it to white. The effect makes the project come across much more clean. Anyway, my $.02 Thanks for great work...
Re: [PATCH] FileDialog
Na. We're following a sensible development cycle: implement something with what facilities and manpower we have see some common areas isolate those areas and extract to common support code write all new stuff using that better idea goto 1 Alan, just tell me when you want break you out of that infinite loop. ;-) gr.ed.
Re: namespaces
Does the fact that "boost::scoped_ptrs" etc are now appearing everywhere mean that we are now using namespaces officially You could but why would you need namespace citation? Maybe we should have some rules fixed first... like 'no caps' in the names or how much should go in a namespace and so on... Andre' -- Andr Pnitz [EMAIL PROTECTED]
Re: Cite bug
On Wed, Mar 07, 2001 at 12:09:32PM -0600, Brett Jones wrote: Small glitch in the citation dialog: OK/apply not enabled when "text after" field is changed. This leads to frustrating work-arounds. 1.1.6fix1 on RH 6.2 from rpm This has been fixed in the CVS. For the meantime, a simple workaround is to hit enter after changing the "text after" field.
Re: [PATCH] FileDialog
On Wed, 7 Mar 2001, Edwin Leuven wrote: Na. We're following a sensible development cycle: implement something with what facilities and manpower we have see some common areas isolate those areas and extract to common support code write all new stuff using that better idea goto 1 Alan, just tell me when you want break you out of that infinite loop. ;-) Never. When has any software project every reached perfection? Also don't be fooled into thinking that the loop takes the same length of time on each iteration. Also be aware that a loop that initially was restricted to getting XForms out of the core has now evolved into refining the implementations of multiple ports. We haven't finished yet. I'm sure we'll have another refinement or two as we as approach perfection (asymptotically) especially once we get started on non-X based systems and the curses/slang/whatever text system gets going. Allan. (ARRae)
Re: New filedialog
On 06-Mar-2001 Edwin Leuven wrote: > Perhaps I should just keep my big mouth shut. Why I think you're principally right! But think of this in developement. While a tree is in development a lot of internal changes happen and noone is using all of the frontends just the default frontend. Maybe one day the default frontend will be Qt2, you never know and then the changes will be applied to that frontend so that we can alos have a visual feedback AND compile the code. Then it is the work of the GUI-porters to change their code so that when we freeze the code (and at this time no interface changes are allowed!!!) to adapt their ports to the new interfaces. So you don't have to monitor it all the time, you just have to look at it when you decide you want to get your port up-to-date! This happens with a lot of programms which have an external accessible API (think of them as plugins). > ps. don't take me wrong it is nothing personal, I think everyone is doing a > great job. Never! You're doing a great job too :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "The C Programming Language -- A language which combines the flexibility of assembly language with the power of assembly language."
Re: ButtonController questions
On Mon, 5 Mar 2001, Angus Leeming wrote: > > Please enlighten me why you think you have to implement it the way you > > suggest. > > Ok, here goes. If I leave out the all important line in > ButtonController::input(): > > if (ButtonPolicy::SMI_NOOP == in) return; > > then the up,down,add,delete buttons in the Citation dialog become active when > a entry is clicked on in the two browsers. I think this occurs because their > state is controlled by the dialog rather than by the ButtonController, but > I'm not sure about this. In that case I suggest you put the above line in nextState() where it belongs but also keep it in Citation with a comment saying that it shouldn't really be there because the up,down,add,delete buttons are mishandled (or at least handled by the dialog). That way everyone should get what is needed -- if you don't have it in nextState() what will happen when someone calls with SMI_NOOP? Undefined. > Of course, you could always extend ButtonController so that it can control > _everything_, but that's definitely your baby not mine! What? You want me to come up with solutions to problems _and_ implement them too! ;-) > Incidentally, this stuff is now in BRANCH_MVC. Wait a day or so and it'll be > in HEAD, so you won't need to check out anything to experiment. >From the glimpses I've had I like it a lot. A whole lot. Allan. (ARRae)
Re: Menu Separator aka lyxarrow
On Tue, Mar 06, 2001 at 01:17:25PM -0800, [EMAIL PROTECTED] wrote: ... > Date: Tue, 6 Mar 2001 13:17:25 -0800 (PST) > From: <[EMAIL PROTECTED]> > X-Sender: <[EMAIL PROTECTED]> > To: LyX Developer List <[EMAIL PROTECTED]> > Subject: Re: Menu Separator aka lyxarrow > In-Reply-To: <[EMAIL PROTECTED]> > > On Tue, 6 Mar 2001, John Levon wrote: > > Why do we have this ? It seems a bit ad hoc. Is it just for > > the convenience of the doc writers or something ? > > Put on your asbestos suit! John Weiss is going to hunt you down and smack > you with his small fish :-) (Find a message from him and look at his > signature.) > > We had a big row about this a couple of years ago when we discussed the > proper format for the "arrow" to be used in the documentation for things > like File->Open. I don't remember exactly how we settled on that > particular rotated triangle, but it was deemed Holy and Pure, and thus > became policy. While it is certainly crucial for the LyX documentors (who > number approximately 0.1 right now), any software documentation should > take advantage of it. > > Whatever you do to it, it should be representable in both the LyX window > and the printed documentation in an obvious, common way (no ERT, etc.) > and should be obvious as something which ties menu panels together. This > particular triangle is used in a number of desktops to indicate that there > is another menu lurking underneath an item. I would argue that it should > stay in the special character menu, but if you can come up with a better > name, feel free. > > Mike Agree! I used it in the doc for faxview. ... -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq
Re: Menu Separator aka lyxarrow
On Tue, 6 Mar 2001 [EMAIL PROTECTED] wrote: > On Tue, 6 Mar 2001, John Levon wrote: > > Why do we have this ? It seems a bit ad hoc. Is it just for > > the convenience of the doc writers or something ? > > Put on your asbestos suit! /me steps backwards slowly ;) john -- "We might be in for more rain than maybe we're going to get." - Henry Blofeld
Re: credits
Edwin Leuven <[EMAIL PROTECTED]> writes: | ps. Lars: in case you think that it is a good idea, perhaps you give | me write | access to www-devel so I can stop bugging john who usually does this | for me :) Perhaps I should do that... :-) Lgb
Re: unknown action and keys
John Levon <[EMAIL PROTECTED]> writes: | Pressing any normal key for entering text gives lyxfunc::getStatus() fits | setting the minibuffer to "unknown action". I can't grok this. | | | WorkArea: Key is `s' [115] | WorkArea: Keysym is `s' [115] | Workarea Diff: 2441 | KeySym is s[115] State is [0] | action first set to [-1] | meta_fake_bit is [0] | action now set to [-1] | Key [-1][s] This looks correct. | | Is this the meaning of the cryptic : | | 559 // We cannot use this function here nor this. Lgb
Re: unknown action and keys
On 6 Mar 2001, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | Pressing any normal key for entering text gives lyxfunc::getStatus() fits > | setting the minibuffer to "unknown action". > > I can't grok this. Try typing a space twice, and try reading the helpful message in the minibuffer. You will see what I mean, it is immediately overwritten by the "Unknown Action" message produced in lyxfunc.C:getStatus() > | meta_fake_bit is [0] > | action now set to [-1] > | Key [-1][s] > This looks correct. > | > | Is this the meaning of the cryptic : > | > | 559 // We cannot use this function here > > nor this. Me neither ! This is in lyxfunc.C, what is the meaning of the comment ? thanks john -- "We might be in for more rain than maybe we're going to get." - Henry Blofeld
Re: unknown action and keys
John Levon <[EMAIL PROTECTED]> writes: | > | Is this the meaning of the cryptic : | > | | > | 559 // We cannot use this function here | > | > nor this. | | Me neither ! This is in lyxfunc.C, what is the meaning of the | > | comment ? if getStatus(...) & Disable is true then the lyxfunc is disabled and we cannot use it. so we just exit. Lgb
Re: unknown action and keys
On 7 Mar 2001, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | > | Is this the meaning of the cryptic : > | > | > | > | 559 // We cannot use this function here > | > > | > nor this. > | > | Me neither ! This is in lyxfunc.C, what is the meaning of the > | > | comment ? > > if getStatus(...) & Disable is true then the lyxfunc is disabled and > we cannot use it. so we just exit. > > Lgb Oh, I see what it means now. Thanks. Can you reproduce the problem I mention ? I think it's what Michael is referring to in https://sourceforge.net/tracker/index.php?func=detail=404575_id=15212=115212 thanks john -- "We might be in for more rain than maybe we're going to get." - Henry Blofeld
Re: Some small memory leaks ..
Henner Zeller <[EMAIL PROTECTED]> writes: | Anyway, I just have a small note: I was curious and looked for memory | leaks using the LeakTracer by Erwin Andreasen Can you redo this now with current cvs? I belive that most of them should be fixed now. (I know there are some I did not fix...) Lgb
Re: New graphics inset core dump
This is just an assert I placed that goes off, this means that some assumption of mine is incorrect. The assumption is that the callers will destroy all information in the graphics cache, this is not so apparently. The quick fix is to destory everything on destruction, Actually this is done already by the shared_ptr, the assert can be removed. I'm applying the fix now. * John Levon <[EMAIL PROTECTED]> [010306 21:56]: > > 1) create an empty file test.png > 2) graphics-insert for this file > 3) quit lyx > > it will coredump on quit > > john > > -- > "If one tells the truth, one is sure, sooner or later, to be found out." > - Oscar Wilde -- Baruch Even http://baruch.ev-en.org/
Assert to print a message
Hello, I believe we should add a printing to the Assert definition so that it will be obvious when a core dump is caused by some assert, it would be great if it included the line and file of the assert, and it would be best if it printed the assert condition itself, but I do not know how to achieve that in C++. Should I provide a patch for this? -- Baruch Even http://baruch.ev-en.org/
Re: Assert to print a message
On Wed, 7 Mar 2001, Baruch Even wrote:
> Hello,
>
> I believe we should add a printing to the Assert definition so that it
> will be obvious when a core dump is caused by some assert, it would be
> great if it included the line and file of the assert, and it would be
> best if it printed the assert condition itself, but I do not know how to
> achieve that in C++.
Is :
#define assert(a) \
if (!(a)) \
printf("%s failed\n", #a);
some sort of GNU extension ? Even if so it would be good to add this
if GNUC is defined ...
thanks
john
Re: Assert to print a message
Baruch Even <[EMAIL PROTECTED]> writes: | Hello, | | I believe we should add a printing to the Assert definition so that it | will be obvious when a core dump is caused by some assert, it would be | great if it included the line and file of the assert, and it would be | best if it printed the assert condition itself, but I do not know how to | achieve that in C++. | | Should I provide a patch for this? then you have to use a macro. why can't you use the debugger? Lgb
Re: Assert to print a message
On 7 Mar 2001, Lars Gullik Bjønnes wrote: > Baruch Even <[EMAIL PROTECTED]> writes: > > | Hello, > | > | I believe we should add a printing to the Assert definition so that it > | will be obvious when a core dump is caused by some assert, it would be > | great if it included the line and file of the assert, and it would be > | best if it printed the assert condition itself, but I do not know how to > | achieve that in C++. > | > | Should I provide a patch for this? > > then you have to use a macro. I don't see the harm in such a macro in thise small case, at much greater convenience ... > why can't you use the debugger? debuggers are awkward, slow, and a real pain. I don't like debuggers personally, even for just a stack trace john -- "Faced with the prospect of rereading this book, I would rather have my brains ripped out by a plastic fork." - Charles Cooper on "Business at the Speed of Thought"
Re: Assert to print a message
* Lars Gullik Bjønnes <[EMAIL PROTECTED]> [010307 14:59]: > Baruch Even <[EMAIL PROTECTED]> writes: > > | Hello, > | > | I believe we should add a printing to the Assert definition so that it > | will be obvious when a core dump is caused by some assert, it would be > | great if it included the line and file of the assert, and it would be > | best if it printed the assert condition itself, but I do not know how to > | achieve that in C++. > | > | Should I provide a patch for this? > > then you have to use a macro. I dont mind even placing in Assert() a line that does: lyxerr << "ASSERT Failed!\n"; This will suffice. > why can't you use the debugger? It's not a question of using the debugger, this is just to make bug reports (like John's latest bug finding in IG) more sensible. Learning that it was a core dump doesn't help me to understand it. Knowing it's an assert that failed will give me more clues to decipher the reason. In this case the problem was trivial enough to find, in other cases it might not be so trivial. -- Baruch Even http://baruch.ev-en.org/
Re: Assert to print a message
John Levon <[EMAIL PROTECTED]> writes:
| On 7 Mar 2001, Lars Gullik Bjønnes wrote:
|
| > Baruch Even <[EMAIL PROTECTED]> writes:
| >
| > | Hello,
| > |
| > | I believe we should add a printing to the Assert definition so that it
| > | will be obvious when a core dump is caused by some assert, it would be
| > | great if it included the line and file of the assert, and it would be
| > | best if it printed the assert condition itself, but I do not know how to
| > | achieve that in C++.
| > |
| > | Should I provide a patch for this?
| >
| > then you have to use a macro.
|
| I don't see the harm in such a macro in thise small case, at much greater
| convenience ...
#define LYX_ASSERT(x) Assert(x, __FILE__, __LINE__)
template
inline
void Assert(A assertion, char const * fil, char const * lin)
{
if (!assertion) {
cerr << "Assertion in " << fil << "at line " << lin << endl;
::emergencySave();
lyx::abort();
}
}
perhaps.
I am not sure if I like it.
Lgb
Re: Assert to print a message
On Wed, 7 Mar 2001, Baruch Even wrote: > Learning that it was a core dump doesn't help me to understand it. > Knowing it's an assert that failed will give me more clues to decipher > the reason. Then JOhn should have provided a backtrace as well which would have shown immediately that it was an Assert and where. Allan. (ARRae)
Re: Assert to print a message
On Wed, 7 Mar 2001, Allan Rae wrote: > Then JOhn should have provided a backtrace as well which would have shown > immediately that it was an Assert and where. > > Allan. (ARRae) I didn't see the point in this case, he had to repeat it anyway to check his fix fixed it. john -- "Faced with the prospect of rereading this book, I would rather have my brains ripped out by a plastic fork." - Charles Cooper on "Business at the Speed of Thought"
Exceptions .. ?
Hi, Sorry if I ask dumb questions. I've seen, that the code is compiled with -fno-exceptions. Is this, because some systems/compilers do not yet support exceptions well ? I think that exceptions can help make code better readable and I'd suggest using them if possible (since programmers tend to be used to java as well, this is probably not a big proglem). Ah, by the way, what was the deal to use 'char const *' instead of 'const char *' ? I know, the former is probably a bit more correct from the thinking, but whereever you look, 'const char *' is used .. so it bocomes more confusing. And it is less confusing if you actually have a const pointer to a const string 'const char * const' .. just curious, -hen (and I should really work on my diploma thesis ..)
RE: [PATCH] FileDialog
On 06-Mar-2001 John Levon wrote: > cvs add lib/images/file-open.xpm src/frontends/FileDialog.h > src/frontends/xforms/FileDialog.C src/frontends/xforms/form_filedialog.* > src/frontends/xforms/FormFiledialog.* src/frontends/xforms/forms/form_filedialog.fd > src/frontends/kde/File* > > cvs delete lib/images/buffer-open.xpm src/filedlg.C src/filedlg.h Applied! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Remember: Silly is a state of Mind, Stupid is a way of Life. -- Dave Butler
Re: Assert to print a message
* Lars Gullik Bjønnes <[EMAIL PROTECTED]> [010307 16:28]:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | On 7 Mar 2001, Lars Gullik Bjønnes wrote:
> |
> | > Baruch Even <[EMAIL PROTECTED]> writes:
> | >
> | > | Hello,
> | > |
> | > | I believe we should add a printing to the Assert definition so that it
> | > | will be obvious when a core dump is caused by some assert, it would be
> | > | great if it included the line and file of the assert, and it would be
> | > | best if it printed the assert condition itself, but I do not know how to
> | > | achieve that in C++.
> | > |
> | > | Should I provide a patch for this?
> | >
> | > then you have to use a macro.
> |
> | I don't see the harm in such a macro in thise small case, at much greater
> | convenience ...
>
> #define LYX_ASSERT(x) Assert(x, __FILE__, __LINE__)
>
> template
> inline
> void Assert(A assertion, char const * fil, char const * lin)
> {
> if (!assertion) {
> cerr << "Assertion in " << fil << "at line " << lin << endl;
> ::emergencySave();
> lyx::abort();
> }
> }
>
>
> perhaps.
>
> I am not sure if I like it.
What about a simple;
cerr << "Assertion failed, quitting.\n" << endl;
This will provide the needed info that the exit is from an assert
without going through the hoops of using a macro to provide the line and
file.
--
Baruch Even
http://baruch.ev-en.org/
Re: Exceptions .. ?
Henner Zeller <[EMAIL PROTECTED]> writes: | Hi, | Sorry if I ask dumb questions. I've seen, that the code is compiled with | -fno-exceptions. Is this, because some systems/compilers do not yet | support exceptions well ? I think that exceptions can help make code | better readable and I'd suggest using them if possible (since programmers | tend to be used to java as well, this is probably not a big proglem). So far exception support in various compiler have been bery bad, thing are beginning to look up now, so eventually we will begin to use exceptions in LyX as well. | Ah, by the way, what was the deal to use 'char const *' instead of | 'const char *' ? I know, the former is probably a bit more correct from | the thinking, but whereever you look, 'const char *' is used .. so it | bocomes more confusing. And it is less confusing if you actually have a | const pointer to a const string 'const char * const' .. You read it from right to left "pointer to const char" Lgb
Re: Assert to print a message
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: Baruch> This will provide the needed info that the exit is from an Baruch> assert without going through the hoops of using a macro to Baruch> provide the line and file. It seems to me that it says "aborted" instead of "segmentation fault" in this case. JMarc
Re: Assert to print a message
* Jean-Marc Lasgouttes <[EMAIL PROTECTED]> [010307 16:49]: > > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: > > Baruch> This will provide the needed info that the exit is from an > Baruch> assert without going through the hoops of using a macro to > Baruch> provide the line and file. > > It seems to me that it says "aborted" instead of "segmentation fault" > in this case. It says "aborted (core dump)" Not very helpful, anyhow I'm not going to press this, it's pretty minor and is only of help for the initial diagnosis of what may be the problem before I fire up the debugger. But I still think it might be a usefull thing. -- Baruch Even http://baruch.ev-en.org/
Re: Exceptions .. ?
> I think that exceptions can help make code better readable and I'd > suggest using them if possible (since programmers tend to be used to you mean 'necessary', do you? > java as well, this is probably not a big proglem). Java programmers tend to be a problem ;-} Seriously, as long as you don't need a feature, don't use it. > Ah, by the way, what was the deal to use 'char const *' instead of > 'const char *' ? I know, the former is probably a bit more correct from > the thinking, but whereever you look, 'const char *' is used .. so it > bocomes more confusing. As you noticed there are some tiny advantages for 'T const *', so there seems to be no reason _not_ to use it. Personally I don't have problems with 'const T *', since that's the way I am writing my own code. If you work on different projects you need to get used to different styles anyway... I doubt people would be amused if I'd try to force them to switch over to my "own" indentation and bracketing style ;-} The big deal is 'uniformity'. Code should be uniform throughout a project - or at least throughout large parts of a project. Once the rules are set, people are expected to stick to them - unless there are obviously wrong or outdated. And I doubt there are many rules used in the newer parts of LyX that are _obviously_ wrong... > And it is less confusing if you actually have a const pointer to a > const string 'const char * const' .. You are not supposed to use char * for strings anyway, and I am not aware of similar contructs for other types used in LyX. > (and I should really work on my diploma thesis ..) Oh come on... Friday is the day of complaints ;-) Andre' -- André Pönitz [EMAIL PROTECTED]
Re: Some small memory leaks ..
HI,
On 7 Mar 2001, Lars Gullik Bjønnes wrote:
LGBn| Can you redo this now with current cvs? I belive that most of them
LGBn| should be fixed now. (I know there are some I did not fix...)
Starting and stopping an empty lyx now causes only 852 Bytes memory leak;
The last thing is interesting: there is a delete called on a object not
allocated with new; I assume the FD_KeyMap is allocated with some xforms
means and then assigned a scoped_ptr ? Anyway, it _can_ be dangerous to
allocate someting with malloc() and free it with 'delete'.
report from LeakTracer as follows:
#-- Leak: counted 5x / total Size: 20
0x80b2eee is in kb_keymap::defkey(kb_sequence *, int, int) (kbmap.C:223).
222 } else {
223 (*newone).table = new kb_keymap;
#-- Leak: counted 1x / total Size: 252
0x80bfaed is in LyXGUI::LyXGUI(LyX *, int *, char **, bool) (lyx_gui.C:154).
153 // Initialize the LyXColorHandler
154 lyxColorHandler = new LyXColorHandler;
#-- Leak: counted 19x / total Size: 224
0x80c09f3 is in flyx_ident_extract(char const *) (lyx_gui_misc.C:209).
208
209 char * sb = new char[se - sc + 1];
#-- Leak: counted 1x / total Size: 4
0x80c181b is in LyX::LyX(int *, char **) (../src/lyx_main.C:81).
80 // Global bindings (this must be done as early as possible.) (Lgb)
81 toplevel_keymap = new kb_keymap;
#-- Leak: counted 11x / total Size: 132
0x81c9fee is in Menubar::Pimpl::makeMenubar(Menu const &) (Menubar_pimpl.C:135).
134
135 ItemInfo * iteminfo = new ItemInfo(this,
#-- Leak: counted 11x / total Size: 220
0x81ca003 is in Menubar::Pimpl::makeMenubar(Menu const &) (Menubar_pimpl.C:135).
134
135 ItemInfo * iteminfo = new ItemInfo(this,
#-- delete on not allocated memory: counted 1x
0x8223386 is in boost::scoped_ptr::~scoped_ptr(void)
(../boost/boost/smart_ptr.hpp:87).
86explicit scoped_ptr( T* p=0 ) : ptr(p) {} // never throws
87~scoped_ptr() { delete ptr; }
---
Re: Some small memory leaks ..
Henner Zeller <[EMAIL PROTECTED]> writes:
| HI,
| On 7 Mar 2001, Lars Gullik Bjønnes wrote:
| LGBn| Can you redo this now with current cvs? I belive that most of them
| LGBn| should be fixed now. (I know there are some I did not fix...)
|
| Starting and stopping an empty lyx now causes only 852 Bytes memory leak;
|
| The last thing is interesting: there is a delete called on a object not
| allocated with new; I assume the FD_KeyMap is allocated with some xforms
| means and then assigned a scoped_ptr ? Anyway, it _can_ be dangerous to
| allocate someting with malloc() and free it with 'delete'.
You are right, I saw this and then "fixed" it.
| report from LeakTracer as follows:
|
|
| #-- Leak: counted 5x / total Size: 20
| 0x80b2eee is in kb_keymap::defkey(kb_sequence *, int, int) (kbmap.C:223).
| 222 } else {
| 223 (*newone).table = new kb_keymap;
Fixed.
| #-- Leak: counted 1x / total Size: 252
| 0x80bfaed is in LyXGUI::LyXGUI(LyX *, int *, char **, bool) (lyx_gui.C:154).
| 153 // Initialize the LyXColorHandler
| 154 lyxColorHandler = new LyXColorHandler;
Fixed.
| #-- Leak: counted 19x / total Size: 224
| 0x80c09f3 is in flyx_ident_extract(char const *) (lyx_gui_misc.C:209).
| 208
| 209 char * sb = new char[se - sc + 1];
Hmm this is harder...
I am not sure where we should delete this.
| #-- Leak: counted 1x / total Size: 4
| 0x80c181b is in LyX::LyX(int *, char **) (../src/lyx_main.C:81).
| 80// Global bindings (this must be done as early as possible.) (Lgb)
| 81toplevel_keymap = new kb_keymap;
Fixed.
| #-- Leak: counted 11x / total Size: 132
| 0x81c9fee is in Menubar::Pimpl::makeMenubar(Menu const &) (Menubar_pimpl.C:135).
| 134
| 135 ItemInfo * iteminfo = new ItemInfo(this,
Fixed.
| #-- Leak: counted 11x / total Size: 220
| 0x81ca003 is in Menubar::Pimpl::makeMenubar(Menu const &) (Menubar_pimpl.C:135).
| 134
| 135 ItemInfo * iteminfo = new ItemInfo(this,
Fixed.
| #-- delete on not allocated memory: counted 1x
| 0x8223386 is in boost::scoped_ptr::~scoped_ptr(void)
|(../boost/boost/smart_ptr.hpp:87).
| 86 explicit scoped_ptr( T* p=0 ) : ptr(p) {} // never throws
| 87 ~scoped_ptr() { delete ptr; }
| ---
This is probably the FD_keymap.
Fixed.
Just give me time to commit and then you can do this check again :-)
Lgb
Re: [PATCH] FileDialog
On Tue, 6 Mar 2001, Angus Leeming wrote: > On Tuesday 06 March 2001 16:43, John Levon wrote: > > I was going to come out against encoding the different file selection > operations > > in the controller, but now I'm not so sure. Maybe you're right. And yes, we > probably > > should have a controller like that... > > I'm not sure if it's the right thing to do here either, but Matthias Ettrich > really must have struck a chord with me when he complained about how much > each frontend had to implement. Just chewing the cud here... Na. We're following a sensible development cycle: implement something with what facilities and manpower we have see some common areas isolate those areas and extract to common support code write all new stuff using that better idea goto 1 Simple iteration. Not a waterfall model but closer to the extreme programming model. The overall abstraction remains the same (give or take a little) and its the implementation that evolves. You don't end up throwing away much code since it forms the basis for the common code when extracted. All Matthias (actually Asger I would argue) did is bring the consideration of separation of VC sooner. Allan. (ARRae)
namespaces
Does the fact that "boost::scoped_ptrs" etc are now appearing everywhere mean
that we are now using namespaces officially and that I can write (for
example):
namespace frontends {
namespace citation {
...
}
}
?
Angus
Re: namespaces
On Wed, 7 Mar 2001, Angus Leeming wrote:
> Does the fact that "boost::scoped_ptrs" etc are now appearing everywhere mean
> that we are now using namespaces officially and that I can write (for
> example):
>
> namespace frontends {
> namespace citation {
> ...
>
> }
> }
You could but why would you need namespace citation?
Just to bundle the view and controller sections?
Seems a bit of overkill.
Just the frontend namespace should be enough.
Although, I think (instant thought -- just add water) that maybe a
namespace frontend ... I don't know I've lost the thought now...
maybe I just thought better of it. Maybe I'm tired. Maybe I'm turning
into a Morlock. (I think I spelled that right -- and no I didn't mispell
Worlock)
Allan. (ARRae)
Cite bug
Small glitch in the citation dialog: OK/apply not enabled when "text after" field is changed. This leads to frustrating work-arounds. 1.1.6fix1 on RH 6.2 from rpm Offtopic comment - I think the project would be well served to change the default bg color. That pasty beige makes the whole interface look dingy. I final hit a threshold of pain and went in and changed it to white. The effect makes the project come across much more clean. Anyway, my $.02 Thanks for great work...
Re: [PATCH] FileDialog
> Na. We're following a sensible development cycle: > implement something with what facilities and manpower we have > see some common areas > isolate those areas and extract to common support code > write all new stuff using that better idea > goto 1 > Alan, just tell me when you want break you out of that infinite loop. ;-) gr.ed.
Re: namespaces
> > Does the fact that "boost::scoped_ptrs" etc are now appearing > > everywhere mean that we are now using namespaces officially > You could but why would you need namespace citation? Maybe we should have some rules fixed first... like 'no caps' in the names or how much should go in a namespace and so on... Andre' -- André Pönitz [EMAIL PROTECTED]
Re: Cite bug
On Wed, Mar 07, 2001 at 12:09:32PM -0600, Brett Jones wrote: > Small glitch in the citation dialog: OK/apply not enabled when "text > after" field is changed. This leads to frustrating work-arounds. > 1.1.6fix1 on RH 6.2 from rpm This has been fixed in the CVS. For the meantime, a simple workaround is to hit enter after changing the "text after" field.
Re: [PATCH] FileDialog
On Wed, 7 Mar 2001, Edwin Leuven wrote: > > Na. We're following a sensible development cycle: > > implement something with what facilities and manpower we have > > see some common areas > > isolate those areas and extract to common support code > > write all new stuff using that better idea > > goto 1 > > > > Alan, just tell me when you want break you out of that infinite loop. ;-) Never. When has any software project every reached perfection? Also don't be fooled into thinking that the loop takes the same length of time on each iteration. Also be aware that a loop that initially was restricted to getting XForms out of the core has now evolved into refining the implementations of multiple ports. We haven't finished yet. I'm sure we'll have another refinement or two as we as approach perfection (asymptotically) especially once we get started on non-X based systems and the curses/slang/whatever text system gets going. Allan. (ARRae)
