Re: default_language?
Dekel Tsur <[EMAIL PROTECTED]> writes: | I've fixed this (the fix is a patch I sent with a different mail). I'll have a look at that. | > default_langage is set to american in langinit in language.c. It | > should probably be set to the "" language instead. | | No So what should it be? | > Agree. One more thing is that the usedlanguages in LaTeXFeatures is | > currently stored in a std::set, that is not good since they then will | > be sorted. This should change to a std::vector. | | This is ok, as I don't put the main language of the document into | UsedLanguages, so the language of the document always appear last. | The ordering of the rest of the languages is not important (I think). And then the smaller container should be used, and that is probably a vector that often has only 3 bytes overhead. Lgb
Re: std::getline
Andre Poenitz <[EMAIL PROTECTED]> writes: | egcs-2.91.66 does not like it. | | If I remove the 'using std::getline' lines, everything is fine. | Does this mean we even don't support egcs anymore? What was the error again? I am pretty sure that the reason for the error is getline(istream &, lyxstring); and since we typedef lyxstring string the std::string makes this ambigous. the solution is probably to only have "using std::getline" if the systems string is used. Can you give a dump of the actuall errors again? Lgb
Re: patch
Allan Rae <[EMAIL PROTECTED]> writes: | If you ignore the optimisation possibilities and look at it purely as info | for other programmers -- making it obvious that it should never be | necessary to change the values being passed. They are const. They are passed by value, and for PODs const or non-const makes no difference. Adding the const qualifier will just be confusing. For more complex objects like string passing by reference will be a gain. You can pass as value if you want to, but then you will not be taking advantage of the _significant_ optimization that pass by reference gives. | If they | were strings I would have used "string const &" but a "int const &" costs | more than passing by value. So I used "int const" to convey the | information that the parameters are not changed -- having already applied | the optimisation of passing the ints by value instead of by reference. | | So IMO, Bullets.h is wrong and Bullets.C is right. No. btw. Did you notice that Bullets.C compiled without a warning? This implies that foo(int) and foo(const int) practically have the same qualification. Don't add confusion by using foo(const int). Lgb
Re: "rae" branch comments
On Thu, 4 May 2000, Angus Leeming wrote: > Hello, Allan. I think I'll be back on board real soon now. It must feel like > the Marie Celeste at present! Yes, I'm not even there! [...XTL.. I know I'm on the list...] > I've been looking at the stuff in the "rae" branch. > > Point 1 > = > You could clean up the code enormously with a single statement > #ifndef MB > typedef auto_mem_buffer lyx_mem_buffer; > #else > typedef mem_buffer lyx_mem_buffer; > #endif > whether or not auto_mem_buffer becomes the standard. No. That's what I did at first. The result being you have to include all the xtl headers in every header file that mentions mem_buffer. The existing choice of mem buffer type is temporary only -- mainly to show how different the code looks and why I wrote the auto_mem_buffer in the first place. So the mem_buffer choice will be gone RSN. > Point 2 > = > I think PrinterParams is made ridiculously convoluted by insisting > that "from_page", "to_page" and "count_copies" are strings not ints. > Moreover, it seems to defy C++'s principles of encapsulation. Perhaps > xforms does return character strings, but that's why this sort of > thing should be hidden "North of the Border" in the frontends/xforms > classes. The rest of the code shouldn't know about such things. > > Make them ints and you loose the need for testInvariant() which does no more > than check they're unsigned ints anyway. > > I know, you're going to talk about other (hypothetical) frontends messing > things up. I think that if you make the interface clear, you minimise the > chances of this happening. The code I removed by using strings instead of ints was even uglier than the use of strings. testInvariant, isn't really necessary anyway, it's part of my plan to push self testing into everything. They could be switched back to ints at some stage. Right now I wanted it working. Strings provided the cleanest way of doing that fix for the time being. > Point 3 > = > I've read and re-read your mail explaining why we need the Connection > data in frontends/xforms/FormFoo.[Ch] and I still don't get it. I > guess I need a concrete example to show thick old me. The fact is, the > code as it stands works perfectly without them; they're nothing but > code bloat and, as such, should be culled ruthlessly ;-) Look at the code in UpdateAllVisibleBufferDependentPopups() and HideAllBufferDependentPopups() in lyx_gui_misc.C. That code is replaced by dynamic lists of Connections. The dialogs disconnect themselves when they are not visible -- the only way they can do that is to keep their half of the Connection in a local variable. If a dialog connects and then never removes itself from the global hideAll() signal it will always be called -- much like what happens now in HideAllBufferDependentPopups() -- even though it's already hidden. Same arguements for the update connections. > Apart from that, I'm pretty happy (big grin). I would note, however, > that I think that introducing derived classes in frontends/xforms NOW > would make things much, much easier. You've been testing xtl/sigc++ > proof of concept using two dialogs; I think that this should be > continued with the derived classes. Well we could at least add the derived classes as we bring in new dialogs into the gui-indep code. However,... Trying to update my branch again is proving to be as big a hassle as it did last time (see the archive, msg09017, I think). The 15 files with conflicts I mentioned this time last week also removed _all_ the new files in my tree. I've once again been experimenting with different forms of cvs update calls to try to keep the new code around with not much success. I'll have another go over the weekend or next week. I'm now convinced that cvs was never meant to allow you to merge changes from the main trunk into a branch -- only the other way, and only for short term branches. With the main trunk changing rapidly as it is at the moment the merging process is totally ugly. Allan. (ARRae)
Re: patch
On 4 May 2000, Lars Gullik Bjønnes wrote: > "Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes: > | For instance, > | the const-version can in a few lucky cases result in more optimized > | code. > > This is not even micro-optimization, closer to nano-optimization. And > as such pointless. If you ignore the optimisation possibilities and look at it purely as info for other programmers -- making it obvious that it should never be necessary to change the values being passed. They are const. If they were strings I would have used "string const &" but a "int const &" costs more than passing by value. So I used "int const" to convey the information that the parameters are not changed -- having already applied the optimisation of passing the ints by value instead of by reference. So IMO, Bullets.h is wrong and Bullets.C is right. Allan. (ARRae)
Re: default_language?
On Thu, May 04, 2000 at 03:21:00PM +0200, Lars Gullik Bj&resh;nnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | I noticed that with latest cvs, if I create a document in french, then
> | the header of the file says
> |
> | \documentclass[american,french]{book}
> |
> | Where does this american come from?
I've fixed this (the fix is a patch I sent with a different mail).
> default_langage is set to american in langinit in language.c. It
> should probably be set to the "" language instead.
No
> Agree. One more thing is that the usedlanguages in LaTeXFeatures is
> currently stored in a std::set, that is not good since they then will
> be sorted. This should change to a std::vector.
This is ok, as I don't put the main language of the document into
UsedLanguages, so the language of the document always appear last.
The ordering of the rest of the languages is not important (I think).
Re: 1.1.5pre2 anything missing?
On Thu, May 04, 2000 at 06:05:04PM +0200, Lars Gullik Bj&resh;nnes wrote: > > Any special issues that need to be resolved before 1.1.5pre2? The \protected_separator issue...
Re: Patch (bug fix)
On Thu, May 04, 2000 at 02:56:39PM +0200, Jean-Marc Lasgouttes wrote: > > Could re-re-redo your patch? (I know it's a pain...) The place with a conflict was in the insettext. Since it isn't being used currently, I just removed the new code from there. The following patch also fixes the "american" language problem. patch.gz
std::getline
egcs-2.91.66 does not like it. If I remove the 'using std::getline' lines, everything is fine. Does this mean we even don't support egcs anymore? Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: Layout menu patch
On Wed, Apr 26, 2000 at 03:27:46PM +0200, Jean-Marc Lasgouttes wrote: > That's great too. I applied it and it really looks good. Small nits: > > - when using deep depth, could there be cases where the lines and the > text collide? The lines could maybe be changed to use less space (if > their intent remains clear) There is enough room for 5 lines. However, when you are using nested environments, the left margin usually increases, so this shouldn't be a problem. > - the lines can potentially collide with the '!' of marginpars. I > think this '!' should go away, unless somebody find it useful. I > find confusing myself. I don't like it either. > - When the text is in footnotes, the bars should probably be inside > the footnote box (how difficult is this?). And it should be possible > to have at the same time bars for the main text and the note > (although latex has some problems with that). Done it. A patch is attached. patch.gz
Re: reLyX Makefile.am question
My bad. I made the changes to get reLyX to install because it used not to. I started again with the Makefile.am in CVS and everything works perfectly. Sorry for wasting bandwidth :( All I can say in my defence is that install-data-local, libinstalldirs used not to called. Now they are. Anyway. Many thanks for your help. Angus JMarc> Angus> Comparing my sources to those in CVS, I came across this patch JMarc> Angus> I submitted some time ago, but which was rejected because I set JMarc> Angus> DESTDIR explicitly. (the remainder of the patch should still be JMarc> Angus> applied because the makefile does not use libinstalldirs or JMarc> Angus> install-data-local). JMarc> I did not remove those targets because I don't know what they do and JMarc> feared they might be called by the lib/ makefile, for example. JMarc> Angus> I submitted this patch because LyX wasn't installing reLyX JMarc> Angus> correctly. Its rejection is fair enough. My question, however JMarc> Angus> concerns the ChangeLog entries below. What is going on, JMarc> Angus> Jean-Marc, and what do I need to do to fix things. JMarc> I added an empty entry for DESTDIR because that is what the default JMarc> value is supposed to be. A typical use of DESTDIR is to set it to JMarc> /tmp, so than insallation is done in /tmp/usr/local..., so that you JMarc> can test what happens. It should certainly not be set to JMarc> /usr/local/share/lyx/. JMarc> What problem do you have? JMarc> JMarc
Re: Compile error in table.h
> would this work? > array = vector(10, someStruct(someVar)); Why shouldn't it work? Have you tried it? Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: lyx-1.1.5pre1 on Solaris 2.6 with Sun CC 5.0
Jochen Kmietsch <[EMAIL PROTECTED]> writes: | Hello ! | | Argh... | | CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ | -I/usr/local/include -I/usr/openwin/include -O -c formula.C -o formula.o | "../../src/lyxparagraph.h", line 528: Error: LyXParagraph::InsetTable is not | accessible from LyXParagraph::matchIT. | "../../src/lyxparagraph.h", line 535: Error: LyXParagraph::InsetTable is not | accessible from LyXParagraph::matchIT. Hmm, this actually seems to be correct... just after InsetTable in lyxparagraph.h can you try to add a friend struct mathIT; there? | "formula.C", line 255: Warning: size hides MathedInset::size. fixed. Lgb
Re: CVS problem
"Lars Gullik Bjønnes" wrote: > > "Garst R. Reese" <[EMAIL PROTECTED]> writes: > > | cvs [update aborted]: cannot open .new.configure: Permission denied > | Garst > > Looks wierd. > > Can you try a clean checkout? > > Lgb my bad. I had touched some files as root.
1.1.5pre2 anything missing?
Any special issues that need to be resolved before 1.1.5pre2? Lgb
Re: binding in lyxrc files.
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> But not the real reason! The intention behind using std::map was
| Lars> to get only unique command sequences (strings), a std::map gives
| Lars> that for free. I did not think about the order issue then.
|
| OK. However, there is already code in kbmap.C which checks that.
|
| Lars> The bindings map does not mean to stay | around forever.
|
| Lars> s/mean/need ?
|
| Almost. it was s/does not mean/is not meant/
|
| Lars> the global variable. by having it stay forever we can easily
| Lars> dump all keybindings to a file.
|
| But you do not put the bindings read from the bind files in this map.
| And dumping is probably better done from toplevel_keymap. As it is,
| you have two data structures in memory which hold the same information
| (plus the hard-coded part of lyxrc, of course). It does not make much
| sense...
if we change the map to a vector and allow dublicate entries we will
be able to dump the excact same bindings as the user sees... (what a
weird sentence)
| You mean you plan to eventually remove this global variable?
| Otherwise, why not access it from lyxrc.C? (as is already done, btw).
|
| Lars> I never got eny real explanation for that. So you think we
| Lars> should have user-definable dead keys. To me that does not make
| Lars> sense. (i.e. redefine dead_acute)
|
| No, I think we should have a way to obtain the _default_ X deadkeys,
| meaning not redefining anything. Then the deadkeys will be handled by
| the code which is already in LyXLookup (it's like the compose key). It
| does not seem so outlandish that some people would like their dead keys to
| work the same way in emacs and LyX? LyX should not be too
| obstructive, IMO.
Do as you wish.
I have only seen this issue when it comes to people that are using
kbmaps to circumvent the X keyhandling.
| Lars> Anyway all the variables in LyXRc should be moved to the private
| Lars> section and accessor functions should be created, that would
| Lars> solve your pimpl proplem too.
|
| I do not see the use of doing that. According to
| http://www.peerdirect.com/resources/gotw024a.html
| only private functions/memeber should go there. What the point of
| accessing lyxrc.printer() instead of lyxrc.printer? LyXRC is almost a
| pure struct, after all.
You have not read enough of the GotW's... all variables should be
private is a mantra that is used quite often.
pimpl's do not work very well with public variables.
I think we should (as Asger has been hinting about earlier) do
something like:
template
class Variable {
public:
...
fromString(string const &);
string toString() const;
void setVal(T const &);
T const & val() const;
private:
...
};
and have a map of
map AllVariables;
or something similar to this.
Then it would be very easy to have a generic "set-variable" or
"variable-set" lyxfunc to control all variables.
"variable-new" to create new variables.
"variable-describe"
etc...
Let's look at this in 1.1.6cvs.
Lgb
Re: lyx 1.1.4-fix3 on Solaris with Sun CC
Jochen Kmietsch <[EMAIL PROTECTED]> writes: | Hello ! | | It's the guy with the picky compiler again :) | | Making all in insets | /bin/sh ../../libtool --mode=compile CC -DHAVE_CONFIG_H -I. -I. -I../../src | -I./../ -I/usr/local/include-I/usr/openwin/include -O -c figinset.C | CC -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I/usr/local/include | -I/usr/openwin/include -O -c figinset.C -o figinset.o | "../../src/insets/insetbib.h", line 132: Warning: InsetBibtex::display hides | the virtual function Inset::display(bool). This first one is bogus, and plain wrong. | "figinset.C", line 897: Error: errno is not defined. Where is it defined then? what is it called in cerrno? Is it in namespace std? | "figinset.C", line 2056: Warning: pflags hides InsetFig::pflags. This could be a real one. Fixed it. Lgb
lyx-1.1.5pre1 on Solaris 2.6 with Sun CC 5.0
Hello ! Argh... CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I/usr/local/include -I/usr/openwin/include -O -c formula.C -o formula.o "../../src/lyxparagraph.h", line 528: Error: LyXParagraph::InsetTable is not accessible from LyXParagraph::matchIT. "../../src/lyxparagraph.h", line 535: Error: LyXParagraph::InsetTable is not accessible from LyXParagraph::matchIT. "formula.C", line 255: Warning: size hides MathedInset::size. 2 Error(s) and 1 Warning(s) detected. *** Error code 1 What can I do about this ? Jochen -- It's raining, .SQZ the animals into the .ARC !
Re: CVS problem
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | cvs [update aborted]: cannot open .new.configure: Permission denied | Garst Looks wierd. Can you try a clean checkout? Lgb
Re: binding in lyxrc files.
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> But not the real reason! The intention behind using std::map was Lars> to get only unique command sequences (strings), a std::map gives Lars> that for free. I did not think about the order issue then. OK. However, there is already code in kbmap.C which checks that. Lars> The bindings map does not mean to stay | around forever. Lars> s/mean/need ? Almost. it was s/does not mean/is not meant/ Lars> the global variable. by having it stay forever we can easily Lars> dump all keybindings to a file. But you do not put the bindings read from the bind files in this map. And dumping is probably better done from toplevel_keymap. As it is, you have two data structures in memory which hold the same information (plus the hard-coded part of lyxrc, of course). It does not make much sense... Lars> | Lars> | - this adds some ugliness in lyx_main.C, that I'd Lars> rather see | Lars> hidden in | lyxrc or keymaps. | | Lars> What Lars> where? Some of this is historical baggage. The problem is | Lars> Lars> the global vairables. | | I was referring to the loop Lars> doing the actual bindings in LyX::LyX. Lars> it is there because of the global variable toplevel_keymap. You mean you plan to eventually remove this global variable? Otherwise, why not access it from lyxrc.C? (as is already done, btw). Lars> I never got eny real explanation for that. So you think we Lars> should have user-definable dead keys. To me that does not make Lars> sense. (i.e. redefine dead_acute) No, I think we should have a way to obtain the _default_ X deadkeys, meaning not redefining anything. Then the deadkeys will be handled by the code which is already in LyXLookup (it's like the compose key). It does not seem so outlandish that some people would like their dead keys to work the same way in emacs and LyX? LyX should not be too obstructive, IMO. Lars> Anyway all the variables in LyXRc should be moved to the private Lars> section and accessor functions should be created, that would Lars> solve your pimpl proplem too. I do not see the use of doing that. According to http://www.peerdirect.com/resources/gotw024a.html only private functions/memeber should go there. What the point of accessing lyxrc.printer() instead of lyxrc.printer? LyXRC is almost a pure struct, after all. JMarc
Re: Compile error in table.h
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 04-May-2000 Lars Gullik Bjønnes wrote: | > | > a vector > might work, or a Matrix class that build | > upon this. | > | | Row and Column Data is now a vector, but can you tell me how I do address | a stuff like the above? How do I do a v.push_back() for example? why do you want a push_back? access: vector > table(10, vector(10, cellstruct(...)); would be a way to set it up, then table[column][row] to access cells. Lgb
Re: Compile error in table.h
Angus Leeming <[EMAIL PROTECTED]> writes: | André> > Correct code, therefore, is | André> > array = someStruct[10]; | André> > initialise(array); | | André> What about | André>array = vector(10, initial_value); | | would this work? | array = vector(10, someStruct(someVar)); yes, that would work. Lgb
lyx 1.1.4-fix3 on Solaris with Sun CC
Hello ! It's the guy with the picky compiler again :) Making all in insets /bin/sh ../../libtool --mode=compile CC -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I/usr/local/include-I/usr/openwin/include -O -c figinset.C CC -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I/usr/local/include -I/usr/openwin/include -O -c figinset.C -o figinset.o "../../src/insets/insetbib.h", line 132: Warning: InsetBibtex::display hides the virtual function Inset::display(bool). "figinset.C", line 897: Error: errno is not defined. "figinset.C", line 2056: Warning: pflags hides InsetFig::pflags. 1 Error(s) and 2 Warning(s) detected. *** Error code 1 make: Fatal error: Command failed for target `figinset.lo' Current working directory /rzdist/tex/Sources/lyx-1.1.4/src/insets Solaris 2.6, Sun CC 5.0. What can I do about this ? Jochen --
Re: binding in lyxrc files.
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> handling, and | saw several things: | | - the bindings are not | Lars> saved in a map. Lars did you do this just for | | Lars> s/not/now? | | Indeed. | | Lars> O(log n) instead of O(n). | | That's a good reason. But not the real reason! The intention behind using std::map was to get only unique command sequences (strings), a std::map gives that for free. I did not think about the order issue then. | Lars> Ok this can be fixed by providing a more clever comparison | Lars> operator (functor). Was this any different earlier? (before | Lars> kbmap rewrite) | | What worries me is that you do not know in which order the binding | will be done (am I wrong?). Why not have a simple queue of | (kmap,function)? the uniqness problem. with some additional code the std::map can be replaced with a vector or a deque. | Lars> | - the bindings member creates duplicates templates, for no | Lars> apparent | gain (and I do not see how to `pimpl' it cleanly) | | Lars> What template? What do you want to pimpl? kb_keymap? | | The map in lyxrc. lyxrc.h is included in a lot of | places and most of these places could not care less of this bindings | stuff. In fact, I do not understand why the bindings map (assuming it | actually is useful) is not local to defaultKeyBindings(), which could | do the bind loop by itself. The bindings map does not mean to stay | around forever. s/mean/need ? the global variable. by having it stay forever we can easily dump all keybindings to a file. | Lars> | - this adds some ugliness in lyx_main.C, that I'd rather see | Lars> hidden in | lyxrc or keymaps. | | Lars> What where? Some of this is historical baggage. The problem is | Lars> the global vairables. | | I was referring to the loop doing the actual bindings in LyX::LyX. it is there because of the global variable toplevel_keymap. | Lars> | - you do the bindings as early as possible. Is there a reason | Lars> for | that? Can I move at least the deadkey bindings until after | Lars> lyxrc has | been read? | | Lars> Why? We want the hardcoded bindings to go in first. | | I'd like to render the bindings of X deadkeys to LyX deadkeys optional | (remember the messages from a while ago). This means that I have to | defer this part of the bindings until after lyxrc has been read. I never got eny real explanation for that. So you think we should have user-definable dead keys. To me that does not make sense. (i.e. redefine dead_acute) | Another soltion would be to do all the default bindings after lyxrc | has been read, but only for keys that have not yet been bound. nah. Anyway all the variables in LyXRc should be moved to the private section and accessor functions should be created, that would solve your pimpl proplem too. Lgb
Re: Compile error in table.h
On 04-May-2000 Lars Gullik Bjønnes wrote: > > a vector > might work, or a Matrix class that build > upon this. > Row and Column Data is now a vector, but can you tell me how I do address a stuff like the above? How do I do a v.push_back() for example? Any idea? Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug To teach is to learn. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
CVS problem
cvs [update aborted]: cannot open .new.configure: Permission denied Garst
"rae" branch comments
Hello, Allan. I think I'll be back on board real soon now. It must feel like the Marie Celeste at present! Relevant news: * José (Orlando Pereira --- XTL) seems to like my changes, suggesting that an official xtl release working on 64-bit machines will be available soon... * I've submitted a bunch of patches to the head branch of CVS that allow me to compile with DEC cxx and with DEC's std::string. They too appear to have been accepted. Once they're in (don't worry, I'll tell you when!), can you update the "rae" branch so that we're working from a common (working) code base? I've been looking at the stuff in the "rae" branch. Point 1 = You could clean up the code enormously with a single statement #ifndef MB typedef auto_mem_buffer lyx_mem_buffer; #else typedef mem_buffer lyx_mem_buffer; #endif whether or not auto_mem_buffer becomes the standard. Point 2 = I think PrinterParams is made ridiculously convoluted by insisting that "from_page", "to_page" and "count_copies" are strings not ints. Moreover, it seems to defy C++'s principles of encapsulation. Perhaps xforms does return character strings, but that's why this sort of thing should be hidden "North of the Border" in the frontends/xforms classes. The rest of the code shouldn't know about such things. Make them ints and you loose the need for testInvariant() which does no more than check they're unsigned ints anyway. I know, you're going to talk about other (hypothetical) frontends messing things up. I think that if you make the interface clear, you minimise the chances of this happening. Point 3 = I've read and re-read your mail explaining why we need the Connection data in frontends/xforms/FormFoo.[Ch] and I still don't get it. I guess I need a concrete example to show thick old me. The fact is, the code as it stands works perfectly without them; they're nothing but code bloat and, as such, should be culled ruthlessly ;-) Apart from that, I'm pretty happy (big grin). I would note, however, that I think that introducing derived classes in frontends/xforms NOW would make things much, much easier. You've been testing xtl/sigc++ proof of concept using two dialogs; I think that this should be continued with the derived classes. Just my 2c-worth. Angus
Re: binding in lyxrc files.
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> handling, and | saw several things: | | - the bindings are not Lars> saved in a map. Lars did you do this just for Lars> s/not/now? Indeed. Lars> O(log n) instead of O(n). That's a good reason. Lars> Ok this can be fixed by providing a more clever comparison Lars> operator (functor). Was this any different earlier? (before Lars> kbmap rewrite) What worries me is that you do not know in which order the binding will be done (am I wrong?). Why not have a simple queue of (kmap,function)? Lars> | - the bindings member creates duplicates templates, for no Lars> apparent | gain (and I do not see how to `pimpl' it cleanly) Lars> What template? What do you want to pimpl? kb_keymap? The map in lyxrc. lyxrc.h is included in a lot of places and most of these places could not care less of this bindings stuff. In fact, I do not understand why the bindings map (assuming it actually is useful) is not local to defaultKeyBindings(), which could do the bind loop by itself. The bindings map does not mean to stay around forever. Lars> | - this adds some ugliness in lyx_main.C, that I'd rather see Lars> hidden in | lyxrc or keymaps. Lars> What where? Some of this is historical baggage. The problem is Lars> the global vairables. I was referring to the loop doing the actual bindings in LyX::LyX. Lars> | - you do the bindings as early as possible. Is there a reason Lars> for | that? Can I move at least the deadkey bindings until after Lars> lyxrc has | been read? Lars> Why? We want the hardcoded bindings to go in first. I'd like to render the bindings of X deadkeys to LyX deadkeys optional (remember the messages from a while ago). This means that I have to defer this part of the bindings until after lyxrc has been read. Another soltion would be to do all the default bindings after lyxrc has been read, but only for keys that have not yet been bound. JMarc
Re: Compile error in table.h
André> > Correct code, therefore, is André> >array = someStruct[10]; André> >initialise(array); André> What about André> array = vector(10, initial_value); would this work? array = vector(10, someStruct(someVar)); ie, use a non-default constructor to initialise the vector. This is exactly what Jürgen is trying to do. Angus
Re: tiny tth patch
On Thu, May 04, 2000 at 03:01:50PM +0200, Jean-Marc Lasgouttes wrote: > > "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes: > > Jose> Personally I like this approach more then the other you > Jose> propose. It is more general. I know this since I had the same > Jose> problem with both linuxdoc and docbook html support, there I > Jose> also need the file name without extension. > > Jose> For the moment I have postponed that, but I see now that the > Jose> best solution is to add this variable instead of adding to the > Jose> code more one special case. > > We should standardize a bit the variable names available for all > commands. I have plan for a Variables class that could be used to set > variables and do the substitutions in a nice uniform way, but of > course I never find the time to do it. That makes sense. :) > Therefore I think that having this feature in LyX in a general way > would be a good idea, but adding it for such or such command line > because it will be useful for a particular program is a bad idea, IMO. The proposed variable is a natural extension from the existing. The way I argued is that there are several cases for docbook and linuxdoc, independently of the program used where that variable is very handy. An example: As default (it can be configured) the html backend for docbook (sgmltools) creates a directory with the name stripped from the original document. Where the presence of the variable would very usefull for directory, postprocessing. I need to do this somes times as for example it isn't defined a index.html link, or for example I want to apply tidy (clean the resulting html) for all the files in that directory. Of course, I can create a program that wraps this, but that can also be defined for tth. ;) The same post processing argument applies to hevea and html2latex. > JMarc -- José
Re: Compile error in table.h
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars> | > Correct code, therefore, is | Lars> | > array = someStruct[10]; | Lars> | > initialise(array); | Lars> | > ? | | Lars> | > Angus (living and learning) | | Lars> | Well me too (good living and a bit learning ;) | | Lars> You really should get a C++ book... | | Having a book is one thing. Knowing everything in it would leave no room to | learn. So you are saying that is is better not to have a book since you then can ask questions and learn from others effort? And if you learn everything in one book, get another! Excellent books: The C++ programming language 3rd edition. Exceptional C++ [...] Ruminations on C++ Lgb
Re: binding in lyxrc files.
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I was looking at add an lyxrc option \handle_x_deadkeys which could be | set to false for people who want the normal dead keys handling, and | saw several things: | | - the bindings are not saved in a map. Lars did you do this just for s/not/now? O(log n) instead of O(n). besides | fun, or is there a real reason? The problem is that it makes things | a bit unpredictible, for example: | | # the second overrides the first | \bind "M-C-a" "foo" | \bind "M-C-a" "bar" | | # the first is kept, since bind() does not override | \bind "M-C-a" "foo" | \bind "C-M-a" "bar" Ok this can be fixed by providing a more clever comparison operator (functor). Was this any different earlier? (before kbmap rewrite) | - the bindings member creates duplicates templates, for no apparent | gain (and I do not see how to `pimpl' it cleanly) What template? What do you want to pimpl? kb_keymap? | - this adds some ugliness in lyx_main.C, that I'd rather see hidden in | lyxrc or keymaps. What where? Some of this is historical baggage. The problem is the global vairables. | - you do the bindings as early as possible. Is there a reason for | that? Can I move at least the deadkey bindings until after lyxrc has | been read? Why? We want the hardcoded bindings to go in first. Lgb
RE: default_language?
On 04-May-2000 Jean-Marc Lasgouttes wrote:
>
> I noticed that with latest cvs, if I create a document in french, then
> the header of the file says
>
> \documentclass[american,french]{book}
>
> Where does this american come from? It does not make sense, since my
> document is french only? All it does is load an extra language
> definition, which will not be used.
>
> I am not sure whether it has ill effects, but it does certainly not
> look good.
>
I've also had a look in the save file and there the language also is
set to american but I left it to default! This is neighter nice, cause
my default language may not BE american!
Jürgen
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug
You will be misunderstood by everyone.
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Compile error in table.h
Lars> | > Correct code, therefore, is Lars> | > array = someStruct[10]; Lars> | > initialise(array); Lars> | > ? Lars> | > Angus (living and learning) Lars> | Well me too (good living and a bit learning ;) Lars> You really should get a C++ book... Having a book is one thing. Knowing everything in it would leave no room to learn. A.
binding in lyxrc files.
I was looking at add an lyxrc option \handle_x_deadkeys which could be set to false for people who want the normal dead keys handling, and saw several things: - the bindings are not saved in a map. Lars did you do this just for fun, or is there a real reason? The problem is that it makes things a bit unpredictible, for example: # the second overrides the first \bind "M-C-a" "foo" \bind "M-C-a" "bar" # the first is kept, since bind() does not override \bind "M-C-a" "foo" \bind "C-M-a" "bar" - the bindings member creates duplicates templates, for no apparent gain (and I do not see how to `pimpl' it cleanly) - this adds some ugliness in lyx_main.C, that I'd rather see hidden in lyxrc or keymaps. - you do the bindings as early as possible. Is there a reason for that? Can I move at least the deadkey bindings until after lyxrc has been read? JMarc
Re: default_language?
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> btw. is the first or last language int the opt arg that will be Lars> the default language of the document? I tried it out and it seems that it is the last. JMarc
Re: default_language?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Hello,
|
| I noticed that with latest cvs, if I create a document in french, then
| the header of the file says
|
| \documentclass[american,french]{book}
|
| Where does this american come from?
default_langage is set to american in langinit in language.c. It
should probably be set to the "" language instead.
| It does not make sense, since my
| document is french only? All it does is load an extra language
| definition, which will not be used.
|
| I am not sure whether it has ill effects, but it does certainly not
| look good.
Agree. One more thing is that the usedlanguages in LaTeXFeatures is
currently stored in a std::set, that is not good since they then will
be sorted. This should change to a std::vector.
btw. is the first or last language int the opt arg that will be the
default language of the document?
Lgb
string incompatibles (was Re: patch)
Angus Leeming <[EMAIL PROTECTED]> writes: | It allows the head branch of CVS to be compiled with DEC cxx and DEC's | implementation of std::string. (Does little more than replace string::clear() | with string::erase().) The bastring in gcc 2.x.x has wrong prototypes for some of the compare methods. ../../../src/support/lstrings.C:136: no matching function for call to `basic_str ing,__default_alloc_template >::compare (int, unsigned int &, const char *&, unsigned int &) const' I will add a check for this in lyxinclude.m4 Lgb
default_language?
Hello,
I noticed that with latest cvs, if I create a document in french, then
the header of the file says
\documentclass[american,french]{book}
Where does this american come from? It does not make sense, since my
document is french only? All it does is load an extra language
definition, which will not be used.
I am not sure whether it has ill effects, but it does certainly not
look good.
JMarc
Re: Patch (bug fix)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Lars> So that means that if the command is robust we don't need Lars> a | Lars> \protect even if it is in a moving argument? | | Lars> That's it. Why protect something which is robust, after all? Lars> And then we are back at my point that need_protect is not a very Lars> good name, as that implies that a protect is always needed. Lars> moving_arg might be better. Isee what you mean. I should have used MovingArg as name in the layout file when I introduced it. Do you think we should change the layout format to make things clearer? Also, fragile should be replaced by moving_arg for all insets. JMarc
Re: tiny tth patch
> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes: Jose> Personally I like this approach more then the other you Jose> propose. It is more general. I know this since I had the same Jose> problem with both linuxdoc and docbook html support, there I Jose> also need the file name without extension. Jose> For the moment I have postponed that, but I see now that the Jose> best solution is to add this variable instead of adding to the Jose> code more one special case. We should standardize a bit the variable names available for all commands. I have plan for a Variables class that could be used to set variables and do the substitutions in a nice uniform way, but of course I never find the time to do it. Therefore I think that having this feature in LyX in a general way would be a good idea, but adding it for such or such command line because it will be useful for a particular program is a bad idea, IMO. JMarc
Re: Compile error in table.h
Juergen Vigna <[EMAIL PROTECTED]> writes: | > You really should get a C++ book... | > | > Lgb | | I know you told me all the time :), but I have you to ask so why spend | the money ;) (and I hate reading manuals or standarts) I think I will answer this friday. Lgb
Re: Patch (bug fix)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> So that means that if the command is robust we don't need a | Lars> \protect even if it is in a moving argument? | | That's it. Why protect something which is robust, after all? And then we are back at my point that need_protect is not a very good name, as that implies that a protect is always needed. moving_arg might be better. Lgb
Re: Patch (bug fix)
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> I used style.isCommand() because it was used in Dekel> SimpleTeXSpecialChars() (in other words, LyX currently put Dekel> \protect in the argument of any command). As you suggested, it Dekel> should be style.needprotect, so I've changed it, and also Dekel> renamed the 'fragile' variable to 'need_protect'. Dekel, I began to apply the patch, but due to Juergen latest changes it does not work anymore. I tried to correct it myself, but get lost pretty easily :( Could re-re-redo your patch? (I know it's a pain...) JMarc
Re: gearing up for prerelease
> "Garst" == Garst R Reese <[EMAIL PROTECTED]> writes: Garst> setting --with-lyxname="lyxd" name to lyxd still puts the Garst> binary in /usr/local/bin/lyx, but does create the Garst> /usr/local/share/lyxd This is a BUG :) Garst Lars, I finally took a look and don't know what to do. How can I force automake to install (or build) lyx under the name $(PACKAGE)? I tried the following, which (not surprisingly) is refused by automake: [...] bin_PROGRAMS = $(PACKAGE) $(PACKAGE)_DEPENDENCIES = mathed/libmathed.la insets/libinsets.la support/libsupport.la $(PACKAGE)_LDADD = $(lyx_DEPENDENCIES) @INTLLIBS@ $(LYX_LIBS) [...] automake does not want to see variable names here. Do you have another idea? JMarc
Re: Compile error in table.h
On 04-May-2000 Lars Gullik Bjønnes wrote: > Juergen Vigna <[EMAIL PROTECTED]> writes: > >| On 04-May-2000 Angus Leeming wrote: >| > >| > Correct code, therefore, is >| > array = someStruct[10]; >| > initialise(array); >| > ? >| > >| > Angus (living and learning) >| >| Well me too (good living and a bit learning ;) > > You really should get a C++ book... > > Lgb I know you told me all the time :), but I have you to ask so why spend the money ;) (and I hate reading manuals or standarts) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug new, adj.: Different color from previous model. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Patch (bug fix)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> So that means that if the command is robust we don't need a Lars> \protect even if it is in a moving argument? That's it. Why protect something which is robust, after all? JMarc
Re: Patch (bug fix)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Dekel Tsur <[EMAIL PROTECTED]> writes: | As you suggested, it | Lars> should be style.needprotect, so I've changed it, | and also | Lars> renamed the 'fragile' variable to 'need_protect'. | | Lars> Not sure about this one. Oh, I agree that the name should | Lars> change. 'need_protect' seems to demand a '\protect' and I don't | Lars> think this is always the case even in a moving argument. | Lars> Jean-Marc care to comment? | | need_protect is supposed to demand a \protect before fragile commands. | It means that the paragraph is a moving argument. | | Is that clearer? So that means that if the command is robust we don't need a \protect even if it is in a moving argument? Lgb
Re: Patch (bug fix)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Dekel Tsur <[EMAIL PROTECTED]> writes: | As you suggested, it Lars> should be style.needprotect, so I've changed it, | and also Lars> renamed the 'fragile' variable to 'need_protect'. Lars> Not sure about this one. Oh, I agree that the name should Lars> change. 'need_protect' seems to demand a '\protect' and I don't Lars> think this is always the case even in a moving argument. Lars> Jean-Marc care to comment? need_protect is supposed to demand a \protect before fragile commands. It means that the paragraph is a moving argument. Is that clearer? JMarc
Re: reLyX Makefile.am question
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Comparing my sources to those in CVS, I came across this patch Angus> I submitted some time ago, but which was rejected because I set Angus> DESTDIR explicitly. (the remainder of the patch should still be Angus> applied because the makefile does not use libinstalldirs or Angus> install-data-local). I did not remove those targets because I don't know what they do and feared they might be called by the lib/ makefile, for example. Angus> I submitted this patch because LyX wasn't installing reLyX Angus> correctly. Its rejection is fair enough. My question, however Angus> concerns the ChangeLog entries below. What is going on, Angus> Jean-Marc, and what do I need to do to fix things. I added an empty entry for DESTDIR because that is what the default value is supposed to be. A typical use of DESTDIR is to set it to /tmp, so than insallation is done in /tmp/usr/local..., so that you can test what happens. It should certainly not be set to /usr/local/share/lyx/. What problem do you have? JMarc
Re: Compile error in table.h
> Aa! So my compiler is correct! I must say though that this is bad design by > the standards commitee, (IMHO of course). > > Correct code, therefore, is > array = someStruct[10]; > initialise(array); > ? What about array = vector(10, initial_value); Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: Compile error in table.h
> Why does it work then? Can we use another construct, I'm thinking about > a vector or something like this. I just need a construct where I can insert > elments in the middle too (not just at the end or the beginning). You could use a std::vector. Insertion is O(n) but that definitely does not matter in your case, since there are just a few items in the vector anyway. I'd suggest to make a typedef somewhere in your class, so if necessity arises you'd have to chane just one line. That's the fun part of the STL. Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: using std::foo patch
> > I used your clear->erase patch. Ok then I'll change this and commit it soon! Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug If I told you you had a beautiful body, would you hold it against me? -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Compile error in table.h
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 04-May-2000 Angus Leeming wrote: | > | > Correct code, therefore, is | > array = someStruct[10]; | > initialise(array); | > ? | > | > Angus (living and learning) | | Well me too (good living and a bit learning ;) You really should get a C++ book... Lgb
Re: using std::foo patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> No problems so far. I had been using it to write some
Angus> documentation, but loading Customization.lyx and pressing
Angus> pagedown works fine too.
Angus> I do get some warning messages in the shell, however. Are they
Angus> related? These are the ONLY messages I get in the shell.
Angus> LyX: Token `\ldots{}' is in free space paragraph layout!
Angus> [around line 5754 of file
Angus> /usr/local/share/lyx/doc/Customization.lyx] LyX: Token
Angus> `\ldots{}' is in free space paragraph layout! [around line 6832
Angus> of file /usr/local/share/lyx/doc/Customization.lyx]
I corrected those in lyxodc, but forgot to commit the change.
Angus> I can only suggest that perhaps there's something else in your
Angus> tree that wasn't in yesterday's CVS? What did you do to get
Angus> table.C/tabular.C to compile?
I used your clear->erase patch.
JMarc
Re: Compile error in table.h
On 04-May-2000 Angus Leeming wrote: > > Correct code, therefore, is > array = someStruct[10]; > initialise(array); > ? > > Angus (living and learning) Well me too (good living and a bit learning ;) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug A compliment is something like a kiss through a veil. -- Victor Hugo -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: using std::foo patch
No problems so far. I had been using it to write some documentation,
but loading Customization.lyx and pressing pagedown works fine too.
I do get some warning messages in the shell, however. Are they related? These
are the ONLY messages I get in the shell.
LyX: Token `\ldots{}' is in free space paragraph layout! [around line 5754 of file
/usr/local/share/lyx/doc/Customization.lyx]
LyX: Token `\ldots{}' is in free space paragraph layout! [around line 6832 of file
/usr/local/share/lyx/doc/Customization.lyx]
I can only suggest that perhaps there's something else in your tree that wasn't
in yesterday's CVS? What did you do to get table.C/tabular.C to compile?
Angus
JMarc> Angus> The attached std-patch allows compilation with dec cxx -std
JMarc> Angus> strict_ansi. It does no more than declare use std::foo in a few
JMarc> Angus> files.
JMarc>
JMarc> I already had that in my tree. I'll commit soon.
JMarc>
JMarc> Angus> Together with the other patches I've submitted today, (and
JMarc> Angus> which Jean-Marc says he'll submit tomorrow I see) these will
JMarc> Angus> allow the head branch of CVS to be compiled using dec's
JMarc> Angus> std::string with dec cxx -std strict ansi.
JMarc>
JMarc> And does it run? Here, loading Customization.lyx and pressing pagedown
JMarc> results in core dump in the code which displays the font info in
JMarc> minibuffer.
Re: Compile error in table.h
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars> | but what I really would like to know is WHY does the constructor not | Lars> | work? | | Lars> You cannot use a constructor on an array allocation. | | Aa! So my compiler is correct! I must say though that this is bad design by | the standards commitee, (IMHO of course). C heritage. If you want other constructors than the default one use a stl container. | | Correct code, therefore, is | array = someStruct[10]; | initialise(array); Yes. Just as in C. Lgb
Re: Compile error in table.h
Lars> | but what I really would like to know is WHY does the constructor not Lars> | work? Lars> You cannot use a constructor on an array allocation. Aa! So my compiler is correct! I must say though that this is bad design by the standards commitee, (IMHO of course). Correct code, therefore, is array = someStruct[10]; initialise(array); ? Angus (living and learning)
Re: using std::foo patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> The attached std-patch allows compilation with dec cxx -std Angus> strict_ansi. It does no more than declare use std::foo in a few Angus> files. I already had that in my tree. I'll commit soon. Angus> Together with the other patches I've submitted today, (and Angus> which Jean-Marc says he'll submit tomorrow I see) these will Angus> allow the head branch of CVS to be compiled using dec's Angus> std::string with dec cxx -std strict ansi. And does it run? Here, loading Customization.lyx and pressing pagedown results in core dump in the code which displays the font info in minibuffer. JMarc
Re: Compile error in table.h
Juergen Vigna <[EMAIL PROTECTED]> writes: | > performs the | > | > if (inset != NULL) ... | > | > internally so it is _never_ needed to do | > | > if (inset) delete inset; | > | > That code construct just shows that you don't know what delete is | > doing. | > | | Well you are right I didn't know this :) | | >| but what I really would like to know is WHY does the constructor not | >| work? | > | > You cannot use a constructor on an array allocation. | > | | Why does it work then? I'd say by coincidence. | Can we use another construct, I'm thinking about | a vector or something like this. I just need a construct where I can insert | elments in the middle too (not just at the end or the beginning). a vector > might work, or a Matrix class that build upon this. | I just need some help to be able to use STL containers, but I would like | to change the code to use them! Good. Lgb
Re: Compile error in table.h
> performs the > > if (inset != NULL) ... > > internally so it is _never_ needed to do > > if (inset) delete inset; > > That code construct just shows that you don't know what delete is > doing. > Well you are right I didn't know this :) >| but what I really would like to know is WHY does the constructor not >| work? > > You cannot use a constructor on an array allocation. > Why does it work then? Can we use another construct, I'm thinking about a vector or something like this. I just need a construct where I can insert elments in the middle too (not just at the end or the beginning). I just need some help to be able to use STL containers, but I would like to change the code to use them! Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug No excellent soul is exempt from a mixture of madness. -- Aristotle -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Compile error in table.h
Juergen Vigna <[EMAIL PROTECTED]> writes:
| >| if (inset) delete inset;
| >| inset = new InsetText(buf);
This would also casue a segfault if the inset is not set.
(0 is ok)
| >| }
| >
| > No, that should be:
| >
| > void LyXTable::cellstruct::setBuffer(Buffer * buf)
| > {
| > delete inset;
| > inset = new InsetText(buf);
| > }
| >
| > Lgb
|
| Now this would result in a segfault (as inset was not yet
|allocated),
Only if the inset is completely unset.
delete inset;
performs the
if (inset != NULL) ...
internally so it is _never_ needed to do
if (inset) delete inset;
That code construct just shows that you don't know what delete is
doing.
| but what I really would like to know is WHY does the constructor not
| work?
You cannot use a constructor on an array allocation.
Lgb
[Fwd: Help]
dear sir, what must I do that upgrade my LyX 1.0.3 to LyX 1.1.5Pre1? FreeBSD 3.3 Stable I've unpacked and begun "make install",it was writenn "don't how make" I 've begun "./configure",I've got next that libXpm and libxforms(libforms) is not on this operating system. I check and find taht all libs was installed.Libforms 0.88 What can I do? Yours sincerelly Alex
Re: patch
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I Lars> am a bit surprised by the following: | -Bullet::Bullet(const int Lars> f, const int c, const int s) | +Bullet::Bullet(int f, int c, int Lars> s) Lars> Bullet.C was wrong the header file is right. Lars> | Also, this | -// need to make the c++ compiler fint the Lars> correct version of abs. | +// need to make the c++ compiler find Lars> the correct version of abs. | // This is at least true for g++. Lars> | +#ifdef __GNUG__ | using std::abs; | +#endif | is not right, Lars> since one should never condition on compilers (against | Lars> autoconf philosophy). The best is probably to add the proper | Lars> definitions in cheaders/cmath. Lars> It is also possible that ::abs would work. I added the C++ definition of abs() in the cmath header. Lars> | I also tried to find in the list archive which string method Lars> of gcc | 2.x.y was supposed to have arguments in the wrong Lars> order, and could not | find it. Lars, any clue? Lars> was it one of the replace methods? or insert? Well both cxx and gcc have replace(pos,n,string), which I believe are correct. They also have insert(pos, string, pos, n), which seems correct too. JMarc
Re: Compile error in table.h
On 04-May-2000 Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
>| Sorry. That should be:
>|
>| void LyXTable::cellstruct::setBuffer(Buffer * buf)
>| {
>| if (inset) delete inset;
>| inset = new InsetText(buf);
>| }
>
> No, that should be:
>
> void LyXTable::cellstruct::setBuffer(Buffer * buf)
> {
> delete inset;
> inset = new InsetText(buf);
> }
>
> Lgb
Now this would result in a segfault (as inset was not yet allocated),
but what I really would like to know is WHY does the constructor not
work?
Jürgen
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug
The degree of technical confidence is inversely proportional to the
level of management.
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: wish list
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Allan Rae <[EMAIL PROTECTED]> writes: | A different Lars> colour with the pretty 3d boxes that we had in the old tree. | Lars> (I know, the 3d boxes are dependent on the Painter so I'll have Lars> to wait | for those) Lars> What do you mean? We have been using the Painter for some months Lars> now... The only difference IMO is that they are darker. JMarc
Re: Feature request -- launch external-editor
Jules Bean <[EMAIL PROTECTED]> writes: | Since it is still sometimes necessary to do, e.g., search-and-replace | in an external editor, how about a lyx command which saves the current | document, spawns an external editor, waits for the editor to complete, | and then reloads the document? I don't like this idea. It makes the lyx format way too visible. Do this manually if you want to do it. Lgb
Re: patch
Allan Rae <[EMAIL PROTECTED]> writes: | Unless you want to be sure that no-one tries to modify their values. | Somewhere along the line the header and implementation have gotten out of | sync. I forgot to fix the .C file when fixing the header. Lgb
Re: patch
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| > JMarc> I am a bit surprised by the following:
| > JMarc> -Bullet::Bullet(const int f, const int c, const int s)
| > JMarc> +Bullet::Bullet(int f, int c, int s)
| >
| > Whoa! Aren't f, c and s passed by value here, so it makes no sense to declare
| > them const anyway?
|
| If you do
|
| int foo(int const bar) {
| bar = 1; // Illegal
| }
|
| If you do
|
| int foo(int bar) {
| bar = 1; // Legal
| }
|
| Such a thing makes sense in a few isolated cases.
And those cases are so few that I won't allow such code unless you
have a real good reason for it.
| For instance,
| the const-version can in a few lucky cases result in more optimized
| code.
This is not even micro-optimization, closer to nano-optimization. And
as such pointless.
Lgb
Re: patch
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I am a bit surprised by the following: | -Bullet::Bullet(const int f, const int c, const int s) | +Bullet::Bullet(int f, int c, int s) Bullet.C was wrong the header file is right. | Also, this | -// need to make the c++ compiler fint the correct version of abs. | +// need to make the c++ compiler find the correct version of abs. | // This is at least true for g++. | +#ifdef __GNUG__ | using std::abs; | +#endif | is not right, since one should never condition on compilers (against | autoconf philosophy). The best is probably to add the proper | definitions in cheaders/cmath. It is also possible that ::abs would work. | I also tried to find in the list archive which string method of gcc | 2.x.y was supposed to have arguments in the wrong order, and could not | find it. Lars, any clue? was it one of the replace methods? or insert? Lgb
Re: Compile error in table.h
Angus Leeming <[EMAIL PROTECTED]> writes:
| Sorry. That should be:
|
| void LyXTable::cellstruct::setBuffer(Buffer * buf)
| {
| if (inset) delete inset;
| inset = new InsetText(buf);
| }
No, that should be:
void LyXTable::cellstruct::setBuffer(Buffer * buf)
{
delete inset;
inset = new InsetText(buf);
}
Lgb
Re: patch
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> On Wed, 3 May 2000, Angus Leeming wrote: JMarc> I am a bit surprised by the following: -Bullet::Bullet(const JMarc> int f, const int c, const int s) +Bullet::Bullet(int f, int c, JMarc> int s) >> Whoa! Aren't f, c and s passed by value here, so it makes no sense >> to declare them const anyway? Allan> Unless you want to be sure that no-one tries to modify their Allan> values. Somewhere along the line the header and implementation Allan> have gotten out of sync. I'll fix that. JMarc
Re: wish list
Allan Rae <[EMAIL PROTECTED]> writes: | I (one day) want to add the option of document scope selection of a | citation package (harvard.sty etc.) and then have a corresponding menu in | the citation dialog for the various forms of citation that package | provides (citeyear, citeauthor and so on). These options should be | defined in a layout file (well, a data file, not necessarily a real layout | file). What does harvard.sty support that natbib.sty don't? Natbib seems to be the more general approach and the one that we should choose. Lgb
Re: wish list
Allan Rae <[EMAIL PROTECTED]> writes: | A different colour with the pretty 3d boxes that we had in the old tree. | (I know, the 3d boxes are dependent on the Painter so I'll have to wait | for those) What do you mean? We have been using the Painter for some months now... Lgb
RE: CVS update: lyx-devel
On 04-May-2000 [EMAIL PROTECTED] wrote: > Log Message: > Commiting my changes till now. Mainly (only?) changes to make text-insets and > tabular insets work. After all the complaints about the tabular-save format > I redid it completely, have a look ;) I commited this changes to have them in the main tree and so that you all can have a look at what I do with tabular-insets. The new Read and Write routine are completed so that you now can create your tabular-inset and save/read it. You'll see that the save-format changed completely :) Angus I didn't add your compile patch in tabular.[Ch] yet as I want to hear Jean-Marc and Lars opinion about your problem and if we can solve this in a better way. I cannot understand why your compiler isn't able to use the constructor! Greets Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug You will always have good luck in your personal affairs. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: tiny tth patch
On Wed, May 03, 2000 at 05:38:34PM +0200, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> I know that people are proposing to redo the Import/Export > Angus> functions. In the meantime, however, the following tiny patch > Angus> allows tth to use LaTeX auxiliary files correctly (and so > Angus> insert references etc) > > Are you sure that it is not possible to play tricks with the basename > command directly? It would be better than adding ad-hoc $$ variables > in the code... Personally I like this approach more then the other you propose. It is more general. I know this since I had the same problem with both linuxdoc and docbook html support, there I also need the file name without extension. For the moment I have postponed that, but I see now that the best solution is to add this variable instead of adding to the code more one special case. I agree that variable should be avoided at all cost but sometimes draconian mesures are worse than (informed) common sense. (Too much philosophy, that is a sign that friday is coming soon ;) Take this with a grain of salt. :) > JMarc -- José
