Re: [PATCH] Re: Bug list - another major update
On Thu, Dec 06, 2001 at 01:02:32AM +, John Levon wrote: it is our old friend, a bv-text misuse. Please apply attached. [...] - Paragraph * par = bv-text-cursor.par(); + Paragraph * par = bv-getLyXText()-cursor.par(); Can't things like that be catched by making bv-text private? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] Re: M-m (
On Mon, Dec 03, 2001 at 04:25:43PM +, John Levon wrote: here's the patch. please apply [...] Index: src/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v retrieving revision 1.429 diff -u -r1.429 ChangeLog --- src/ChangeLog 2001/12/03 13:17:01 1.429 +++ src/ChangeLog 2001/12/03 16:23:23 @@ -1,3 +1,8 @@ +2001-12-03 John Levon [EMAIL PROTECTED] + + * kbsequence.h: + * kbsequence.C: re-instate nmodifier mask + 2001-12-03 Juergen Vigna [EMAIL PROTECTED] Is this one applied? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] Re: Bug list - another major update
On Thu, Dec 06, 2001 at 09:47:19AM +0100, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: - Paragraph * par = bv-text-cursor.par(); + Paragraph * par = bv-getLyXText()-cursor.par(); | Can't things like that be catched by making bv-text private? The problem is that it is sometimes bv-text we want and not bv-getLyXText. So make a second acessor getTheTextAndIReallyMeanIt and use that... Of course not by automatic search-and-replace, but by having a look of all instances... The compiler will make sure that we see all instances... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Quoting in InsetCommands
John == John Levon [EMAIL PROTECTED] writes: John An unanswered question: is it OK to add code to quote '_' etc. John in InsetCommand::asLyXCommand() so the user doesn't have to ? Yes, but we should also make sure the reLyX unquotes it. To know which characters have to be changed. Look at the code in paragraph.C which does the output. Probably the same routine should be used in both places, or insetindex should use an insettext internally. JMarc
Re: layout-Paragraph and stippled lines
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen How about a Paper Clip (TM) which pops up asking: It seems Juergen you want to insert a VSpace! May I help you? A good and Juergen approved method to prevent users from doing something ;-) Or, on a similar line, when the user selects Length, have an 'edit...' button which opens a popup where the user can set length and glue. THis way you (1) make things more complicated and (2) avoid to duplicate everywhere the code to set units and such. How difficult would that be? JMarc
Re: InsetText::the_locking_inset
On 06-Dec-2001 Allan Rae wrote:
The use of the_locking_inset there seems haphazard at best. Some
places seem to clear the_locking_inset after an unlock call while
others don't.
Well sometimes I think you should sleep a bit more before looking at code ;)
You look at functions and don't see the obvious #:O) (a pitty you didn't
write this one on Friday I could think of a really amusing exchange of
emails ;)
Code like:
if (the_locking_inset) {
unlockInsetInInset(bv, the_locking_inset);
the_locking_inset = 0;
}
Ok you're right here the above can safely be change to only
unlockInsetInInset(bv, the_locking_inset);
seems to me to be equivalent to:
unlockInsetInInset(bv, the_locking_inset);
the_locking_inset = 0;
It is indeed!
and could be written as:
if (unlockInsetInInset(bv, the_locking_inset)) {
the_locking_inset = 0;
}
Nope the if is not neccessary, but yes if you like you could write it as
that too ;)
but that isn't really any faster or better but might expose other
bugs.
Why? The code in unlockInsetInInset() is quite clear
if (!the_locking_inset) return false;
Tis will just do nothing and the_locking_inset anyway is already 0,
so we don't have to set it to 0 again, isn't it?
unlockInsetInInset() will do the check for the_locking_inset. The
second line unconditionally resets the_locking_inset while
unlockInsetInset() only resets it if this insets inset is the locking
inset. The return value of unlockInsetInInset() tells whether it
found a locking inset further down in the nested inset structure.
#:O)
Allan if I call unlockInsetInInset with inset==the_locking_inset why should
I check it. Obviously you're right with the setting to 0 the_locking_inset
it is not needed because of:
if (the_locking_inset == inset) {
the_locking_inset-insetUnlock(bv);
the_locking_inset = 0;
...
}
Is there a plan to use the return value at anytime or should the
following lines also reset the_locking_inset unconditionally like all
the other instances in insettabular.C?
We don't need to use the returnvalue as it is irrelevant INSIDE THIS
insettabular, but unlockInsetInInset() is also called from the outside
world and there the returnvalue IS important!
There appear as though there may be a few places where
InsetText::the_locking_inset isn't cleared after an unlock attempt but
??? We don't have a InsetText::the_locking_inset!!!
Maybe I'm misunderstanding something. If an inner inset is locked and
I unlock it should the outer inset also be unlocked?
No, why should it! But if the outer inset is unlocked we have to descent
the tree and unlock ALL inner insets.
Hope this helps you a bit to find some good sleep tonight #:O) otherwise
have some of the really nice beers you produce there in Australia the also
help to have a good sleep ;)
Greets,
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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
I have defined the hundred per cent American as ninety-nine per cent an idiot.
-- George Bernard Shaw
Re: Quoting in InsetCommands
On Thu, Dec 06, 2001 at 10:34:48AM +0100, Jean-Marc Lasgouttes wrote: John == John Levon [EMAIL PROTECTED] writes: John An unanswered question: is it OK to add code to quote '_' etc. John in InsetCommand::asLyXCommand() so the user doesn't have to ? Yes, but we should also make sure the reLyX unquotes it. To know which characters have to be changed. Look at the code in paragraph.C which does the output. Probably the same routine should be used in both places, or insetindex should use an insettext internally. Automatic quoting has a tendency to fire back at some time... Andre' -- André Pönitz .. [EMAIL PROTECTED]
RE: [PATCH][RFC] Table selection
On 06-Dec-2001 John Levon wrote: first, the bugs I noticed in both old and new code : 1) attached file : selection the multicolumn cell, then press up. the topright cell is not selected. I would say this is a feature not a bug, otherwise how would you select exactly the columns which are selected. Well we are inconsistent you'll say because if I do the other way round when entering the multi-cell it is selected till the end. Hmm if someone tells me how to handle this in a good way we should change it obviously, but I'm pretty sure we sill always have problems with this type of stuff. The only good solution would be that while selecting we should be able to add/remove columns also from withing a multi-cell, this should be possible in some way, but I don't see this as a priority, right now! 2) TableExamples.lyx - the minipage is screwed ! Yes I know there is some wrong compatibilty reading, we should have a look at it. Now, my patch. 2) more spreadsheet like feel ??? Where do you feel that :) 5) with this code, I can't see a user-visible reason for the dummy cursor position ... Well I still see one or how would you select otherwise with the cursor? I'm also pretty sure that we need it for the mouseselection also, but well with mouse we could find some workaround, while with the cursor I really don't see one! Juergen ? Others are welcome to try it ... I tried it and find it good! I'll commit it soon! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Living in New York City gives people real incentives to want things that nobody else wants. -- Andy Warhol
RE: Another table selection problem
On 06-Dec-2001 John Levon wrote: If I select from c to d, then even though cell b protudes, I end up at d, with b unselected. It should check all cells all the way to the end of the selection, not just I know, I think I answered this already in my previous mail, didn't I? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If you didn't have to work so hard, you'd have more time to be depressed.
pragma interface/implementation
Can anybody please explain the proper usage of '#pragma interface' and '#pragma implementation'? After reading the info pages I don't really see any benifit in our cases since we are using seperate declaration/definition files anyway, don't we? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: pragma interface/implementation
On Thu, Dec 06, 2001 at 11:20:14AM +0100, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | Can anybody please explain the proper usage of '#pragma interface' and | '#pragma implementation'? info gcc I read that twice. I do not understand it. mark all class definition files with #pragma interface Where? At the very top after the include gueard in the header? and the source files for the class with #pragma implementation this must be set befor the include of the class header file. Before everything or before the class include? If so, would it be sensble to have the class include as the last included item? Does it matter? I am not sure how large the benefit is for gcc-3.x.y (or 2.96 for that matter) but with gcc 2.95 and earlier the benefits were fairly huge. I tried it with 2.95.2 on one of my own files, and the change in .o size was about 200 bytes in a 200_k_ object (with -g). I am curently asking in gnu.g++.help... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Annoying LyX bugs
-BEGIN PGP SIGNED MESSAGE- On Thursday, 6. December 2001 00:58, you wrote: On Thu, Dec 06, 2001 at 10:16:00AM +1100, Ben Stanley wrote: (6) I just installed Lyx1.1.6fix3-1 (the binary rpm) on my RedHat 7.2 box and now the rendering of eps figures in LyX is broken: It still says rendering, but nothing appears. The same file works correctly under older RedHat versions. This annoys me to, but people keep telling me it's an xforms bug and as such can't be fixed until GUII is complete. In the case above, it is a RedHat ghostscript bug. It is the same problem (in SuSE 7.3 with ghostscript 6.51) as Morten reported earlier. We have a dirty, but working solution for it. (maybe, someone is interested?) Kornel - - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQCVAwUBPA9X6LewfbDGmeqhAQG79QQAvTkvR4LfSVo9103Yher78h6LNrsDwQgS MJ4r5lj3jQGPCe7xxrFHhScc+UUaNwCU7rfAwvcQbmw2RNdfUanwvndbqlzDtAwg JoiNQEmBi2quREP1dVvykPhk69gc7fzzgX6+bQVrtH+yDQgh3+GHtz/7HarDr4qt WbDgYbIHxVk= =aoZ8 -END PGP SIGNATURE-
Re: InsetText::the_locking_inset
On 06-Dec-2001 Juergen Vigna wrote: There appear as though there may be a few places where InsetText::the_locking_inset isn't cleared after an unlock attempt but ??? We don't have a InsetText::the_locking_inset!!! Sorry we obviously HAVE one (it was very early and I still had my eyes half closed ;), but IMO this should be changed to use LyXText::the_locking_inset! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 moss on the tree does not fear the talons of the hawk.
Re: [PATCH] mmap CRC checking 1.2cvs
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars I am pretty sure that this is not how we are going to solve this Lars problem. Lars What I need to know is how this is _supposed_ to be done on cxx, Lars and then we can find the correct fix. Well, mmap() returns a void * #include sys/mman.h void *mmap ( void *addr, size_t len, int prot, int flags, int filedes, off_t off ); When there is an error, here is what it does: [Digital] The following definition of the mmap() function does not conform to current standards and is supported only for backward compatibility (see standards(5)): caddr_t mmap ( caddr_t addr, size_t len, int prot, int flags, int filedes, off_t off ); STANDARDS Interfaces documented on this reference page conform to industry standards as follows: mmap(): XPG4-UNIX Refer to the standards(5) reference page for more information about indus- try standards and associated tags. Standards: standards(5) PARAMETERS addr Specifies the starting address of the new region (truncated to a page boundary). len Specifies the length in bytes of the new region (rounded up to a page boundary). prot Specifies access permissions as either PROT_NONE or the result of a logical OR operation on any combination of PROT_READ, PROT_WRITE, and PROT_EXEC. flags Specifies attributes of the mapped region as the results of a bitwise-inclusive OR operation on any combination of MAP_FILE, MAP_ANONYMOUS, MAP_VARIABLE, MAP_FIXED, MAP_SHARED, MAP_PRIVATE, MAP_INHERIT, or MAP_UNALIGNED . filedes Specifies the file to be mapped to the new mapped file region returned by open(). off Specifies the offset into the file that gets mapped at address addr. DESCRIPTION The mmap() function creates a new mapped file region, a new private region, or a new shared memory region. The addr and len parameters specify the requested starting address and length in bytes for the new region. The address is a multiple of the page size returned by sysconf(_SC_PAGE_SIZE). If the len parameter is not a multiple of the page size returned by sysconf(_SC_PAGE_SIZE), then the result of any reference to an address between the end of the region and the end of the page containing the end of the region is undefined. The flags parameter specifies attributes of the mapped region. Values of the flags parameter are constructed by a bitwise-inclusive OR operation on the flags from the following list of symbolic names defined in the sys/mman.h file: MAP_FILE Create a mapped file region. MAP_ANONYMOUS Create an unnamed memory region. MAP_VARIABLE Place region at the computed address. MAP_FIXEDPlace region at fixed address. MAP_SHARED Share changes. MAP_PRIVATE Changes are private. MAP_INHERIT Region not unmapped by exec(2). MAP_UNALIGNED Do not verify that the file offset is page aligned. The MAP_FILE and MAP_ANONYMOUS flags control whether the region to be mapped is a mapped file region or an anonymous shared memory region. One of these flags must be selected. If MAP_FILE is set in the flags parameter: o+ A new mapped file region is created, mapping the file associated with the filedes parameter. o+ The off parameter specifies the file byte offset at which the mapping starts. This offset must be a multiple of the page size returned by sysconf(_SC_PAGE_SIZE). o+ If the end of the mapped file region is beyond the end of the file, the result of any reference to an address in the mapped file region corresponding to an offset beyond the end of the file is unspecified. If MAP_ANONYMOUS is set in the flags parameter: o+ A new memory region is created and initialized to all zeros. This memory region can be shared only with descendents of the current pro- cess. o+ If the filedes parameter is not -1, the mmap() function fails. The new region is placed at the requested address if the requested address is not null and it is possible to place the region at this address. When the requested address is null or the region cannot be placed at the requested address, the MAP_VARIABLE and MAP_FIXED flags control the place- ment of the region. One of these flags must be selected. If MAP_VARIABLE is set in the flags parameter: o+ If the requested address is null or if it is not possible for the sys- tem to place the region at the requested address, the region is placed at an address selected by the system. If MAP_FIXED is set in the flags parameter: o+ If the requested address is not null, the mmap() function succeeds even if
Re: [PATCH] mmap CRC checking 1.2cvs
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc RETURN VALUES Jean-Marc Upon successful completion, the mmap() function returns Jean-Marc the address at which the mapping was placed. Otherwise, Jean-Marc mmap() returns (caddr_t)-1 and sets errno to indicate the Jean-Marc error. Actually in sysmman.h, I find /usr/include/sys/mman.h:#define MAP_FAILED (-1L) /* unsuccessful return from mmap() */ So the reinterpret_cast is probably the right solution here. UNfortunately, I cannot apply the patch just to try it out, because I am over a telnet connection. JMarc PS: sorry for posting the whole man page. This was not the intent.
Re: [PATCH] mmap CRC checking 1.2cvs
On Thu, Dec 06, 2001 at 08:39:47AM +0100, Lars Gullik Bjønnes wrote:
Ben Stanley [EMAIL PROTECTED] writes:
| Please let me know if the attached patch fixes this problem.
| I also tried to fix the Solaris compile problem - Kayvan, could you
| please test it?
I am pretty sure that this is not how we are going to solve this
problem.
I don't like adding the POSIX level hack either.
How about this? (it compiles for me on Solaris).
Index: lyxsum.C
===
RCS file: /cvs/lyx/lyx-devel/src/support/lyxsum.C,v
retrieving revision 1.20
diff -u -r1.20 lyxsum.C
--- lyxsum.C2001/12/03 01:11:05 1.20
+++ lyxsum.C2001/12/06 16:52:22
@@ -40,7 +40,7 @@
void * mm = mmap(0, info.st_size, PROT_READ,
MAP_PRIVATE, fd, 0);
- if (mm == MAP_FAILED) {
+ if (mm == reinterpret_castvoid*(MAP_FAILED)) {
close(fd);
return 0;
}
@@ -52,7 +52,7 @@
crc.process_block(beg, end);
unsigned long result = crc.checksum();
- munmap(mm, info.st_size);
+ munmap((caddr_t) mm, info.st_size);
close(fd);
return result;
Re: [PATCH] mmap CRC checking 1.2cvs
Kayvan == Kayvan A Sylvan [EMAIL PROTECTED] writes: Kayvan On Thu, Dec 06, 2001 at 08:39:47AM +0100, Lars Gullik Bjønnes Kayvan wrote: Ben Stanley [EMAIL PROTECTED] writes: | Please let me know if the attached patch fixes this problem. | I also tried to fix the Solaris compile problem - Kayvan, could you | please test it? I am pretty sure that this is not how we are going to solve this problem. Kayvan I don't like adding the POSIX level hack either. I cannot test it right now, but I suspect that on cxx the caddr_t cast will fail (since the right type seems to be void*). JMarc
Re: [PATCH] Re: Bug list - another major update
On Thu, Dec 06, 2001 at 10:14:48AM +0100, Andre Poenitz wrote: So make a second acessor getTheTextAndIReallyMeanIt and use that... Of course not by automatic search-and-replace, but by having a look of all instances... The compiler will make sure that we see all instances... I have already done that. See my bvtexts list. regards 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: [PATCH][RFC] Table selection
On Thu, Dec 06, 2001 at 11:10:37AM +0100, Juergen Vigna wrote: I would say this is a feature not a bug, otherwise how would you select exactly the columns which are selected. Well we are inconsistent you'll say because if I do the other way round when entering the multi-cell it is selected till the end. Hmm if someone tells me how to handle this in a good way we should change it obviously, but I'm pretty sure we sill always have problems with this type of stuff. The only good solution would be that while selecting we should be able to add/remove columns also from withing a multi-cell, this should be possible in some way, but I don't see this as a priority, right now! agreed. I'm happy with the current behaviour really... 2) TableExamples.lyx - the minipage is screwed ! Yes I know there is some wrong compatibilty reading, we should have a look at it. ok. 2) more spreadsheet like feel ??? Where do you feel that :) in that I can select a cell by clicking on the LHS of it. 5) with this code, I can't see a user-visible reason for the dummy cursor position ... Well I still see one or how would you select otherwise with the cursor? I'm also pretty sure that we need it for the mouseselection also, but well with mouse we could find some workaround, while with the cursor I really don't see one! OK, we still need the cursor position, but we don't ever need to show a cursor being there, and (for example) we don't need to go to the dummy position when unlocking the insettext. Why ? because clicking onto the dummy selects the cell, and from then on both keyboard and mouse selection work as expected... regards 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: Another table selection problem
On Thu, Dec 06, 2001 at 11:11:42AM +0100, Juergen Vigna wrote: If I select from c to d, then even though cell b protudes, I end up at d, with b unselected. It should check all cells all the way to the end of the selection, not just I know, I think I answered this already in my previous mail, didn't I? yep (though it is a slightl different case ;) 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: [PATCH][RFC] FormTabular and width/alignment
On Thu, Dec 06, 2001 at 10:27:48AM +0100, Juergen Vigna wrote: On 06-Dec-2001 John Levon wrote: Any reason why we can't just do like the attached patch does ? Try it out yourself. Just try to edit an entry say you have 1mm and want 100mm try to insert with your patch applied the 00 after the 1. um, it works fine. it changes to 10mm and then 100mm ... what problem should I be seeing ? thanks 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: vspace
On Thu, Dec 06, 2001 at 07:11:57AM +0100, Herbert Voss wrote: looks cool ... I have only one problem: why should I see, that I don't have any space where by default is no additional space ... ;-) the floatingfigure is converted from 1.1.6 to 1.2 by lyx. Can I have the original 1.1.6 lyx file ? It doesn't make any sense too have a length of zero w/o some stretch value as well. Did you add the space of 0cm in the old lyx file, or does the 1.2.0 import introduce it ? thanks 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: vspace
On Thu, Dec 06, 2001 at 10:11:59PM +0100, Herbert Voss wrote: sure, but this was written by lyx into the file: \layout Standard \added_space_top 0cm \added_space_bottom 0cm \align center OK, so for compatibility we should convert these to VSpace::NONE Did you add the space of 0cm in the old lyx file, or does the 1.2.0 import introduce it ? lines, now the two vspace marker. The appear at all tables and floats. I'll have a look for a 1.1.6 file. please thanks 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: vspace
On Thu, Dec 06, 2001 at 10:22:43PM +0100, Herbert Voss wrote: A new situation: I suppose it's no more a problem, because it happens only for 1.1.6 files which I read with 1.2.0 some time (weeks) ago. With latest cvs I can't reproduce. good - I suspect the vspace changes I didn't make are responsible ... btw, Herbert, if you have any 1.1.6 or other files that 1.2.0cvs isn't happy with in whatever way, it would be great if you could email me them with a short note thanks 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: vspace
John Levon wrote: btw, Herbert, if you have any 1.1.6 or other files that 1.2.0cvs isn't happy with in whatever way, it would be great if you could email me them with a short note I'll have a look at weekend. Only one thing which is not a real problem but for the users annoying and also reported. if you have in 1.1.6 a lot of ert-lines without ctrl-enter you'll get for every line an own inset. this is espacially for ert nonsense and makes editing impossible. I think it should be no problem for lyx to save the last action (inset) and don't start a new one if it's the same. Herbert -- http://www.lyx.org/help/
problems with ert
see attached file:
in 1.1.6 you can have a label inside ert.
1.2.0 end's with ert after the label.
should be converted to \label{...}
Herbert
--
http://www.lyx.org/help/
#LyX 1.1 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass article
\language ngerman
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
THis is only ert with a label:
\layout Standard
\latex latex
I like
\begin_inset LatexCommand \label{Label}
\end_inset
ert and labels
\the_end
Re: problems with ert
On Thu, Dec 06, 2001 at 10:57:16PM +0100, Herbert Voss wrote:
see attached file:
in 1.1.6 you can have a label inside ert.
1.2.0 end's with ert after the label.
You description is not accurate.
The 1.1.6 file contains ert-text1[label-inset]ert-text2
In 1.2.0 the result is [ert-inset1][label-inset]ert-text2,
where ert-inset1 contains the text ert-text1,
but ert-text2 appears as text and not inside ert-inset
should be converted to \label{...}
No it shouldn't. The result should be [ert-inset1][label-inset][ert-inset2]
Re: [PATCH] mmap CRC checking 1.2cvs
Lars Gullik Bjønnes wrote: Kayvan A. Sylvan [EMAIL PROTECTED] writes: | On Thu, Dec 06, 2001 at 08:39:47AM +0100, Lars Gullik Bjønnes wrote: Ben Stanley [EMAIL PROTECTED] writes: | Please let me know if the attached patch fixes this problem. | I also tried to fix the Solaris compile problem - Kayvan, could you | please test it? I am pretty sure that this is not how we are going to solve this problem. | I don't like adding the POSIX level hack either. Hmmm... I think that this is the right approach, but what I sent in was a hack. See below. | How about this? (it compiles for me on Solaris). No, won't do. No, I don't like that either. That won't compile elsewhere. Either disable mmap for those platforms of find a better solution. Hmmm... let's try for the better solution. It seems that we have 2 distinct problems: 1) Solaris headers by default provide an old version of munmap with the wrong type in there. 2) compaq provides a definition of MAP_FAILED with a similarly wrong type. The Solaris headers can be told to give us a POSIX compliant definition of munmap by doing #define _POSIX_C_SOURCE 199506L before #include sys/mman.h This seems to be fairly standard - see http://vicente.org/xclib/include/xc/standards.h.html http://www.cs.arizona.edu/computer.help/policy/DIGITAL_unix/AA-QTLMA-TE_html/relnotes5.html Also mentioned at http://mail.gnu.org/pipermail/autoconf/2000-August/006020.html, but this suggests problems with defining this unconditionally on Solaris... This solution would mean that we only have to support POSIX mmap, instead of several non-standard variants. This removes #ifdef and reinterpret_cast clutter from the code, which I consider to be a great advantage. It would be nice to have access to some man pages for the platforms in question. The compaq headers may have a similar feature. The definition that Jean-Marc looked up is also a compatibility defintion. The compq man page suggested looking at standards(5) - Jean-Marc, could you please take a look at this, and perhaps send it to me? Specifically, does it mention _POSIX_C_SOURCE? So, I think that the _POSIX_C_SOURCE define may fix both problems, but I would like to see authorative documentation. I think it is probably safe to define this macro unconditionally for this file because we only need mmap here, and on Linux it has no effect. Ben.
Re: [PATCH] mmap CRC checking 1.2cvs
On Fri, Dec 07, 2001 at 09:29:38AM +1100, Ben Stanley wrote: The Solaris headers can be told to give us a POSIX compliant definition of munmap by doing #define _POSIX_C_SOURCE 199506L before #include sys/mman.h This seems to be fairly standard - see [...] So, I think that the _POSIX_C_SOURCE define may fix both problems, but I would like to see authorative documentation. I think it is probably safe to define this macro unconditionally for this file because we only need mmap here, and on Linux it has no effect. This seems fine to me. I have added just the _POSIX_C_SOURCE definition to the lyxsum.C file and it compiles fine on Solaris. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
DepTable patch for 1.2cvs
Lars Gullik Bjønnes wrote: Ben Stanley [EMAIL PROTECTED] writes: | I still need to get the proper DepTable patch out. The patch that is | currently in 1.2 is b0rken. explain. Hmmm... I have a new implementation which keeps an old and a new mtime, and checks that before checking the old and new crcs (and possibly re-calculating crcs)... but now that I think about it again, I shouldn't need to keep two mtimes. However, the version currently in 1.2 writes the 3 numbers to the deptable, which is incompatible with previous behaviour which writes/reads only 2. This needs to be fixed at the very least - my new patch stores only 2 and 'does the right thing' when presented with an old file, and causes the old implementation to DTRT when presented with a new style file. And the version in 1.2 doesn't behave correctly when it finds a file who's mtime has changed. It doesn't shuffle the crc value from second to first before overwriting it with the new value (in update()). This causes excessive LaTeX runs. I have now written something for 1.2 which keeps only one mtime; I'd better test before posting. Ben
Re: DepTable patch for 1.2cvs
On Fri, Dec 07, 2001 at 01:29:15AM +0100, Lars Gullik Bjønnes wrote: Ben Stanley [EMAIL PROTECTED] writes: | However, the version currently in 1.2 writes the 3 numbers to the | deptable, which is incompatible with previous behaviour which | writes/reads only 2. No, we do not have to do that. Everything in LyX is written to work with USE_TEMPDIR=true, if you don't use that expect strange behaviour. so, why have we got the option again ?? DTRT? do the right thing ... as in the spike lee film ... 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: DepTable patch for 1.2cvs
Lars Gullik Bjønnes wrote: Ben Stanley [EMAIL PROTECTED] writes: | However, the version currently in 1.2 writes the 3 numbers to the | deptable, which is incompatible with previous behaviour which | writes/reads only 2. No, we do not have to do that. Everything in LyX is written to work with USE_TEMPDIR=true, if you don't use that expect strange behaviour. Also I do not think that we have to be deptable compatible with 1.1.6 (and older 1.1.2CVS does not matter). Anyway, my current patch is backwards compatible - reads/writes 2 values, and Does The Right Thing with old/new files, even if it causes CRCs to be calculated when not strictly necessary in the case that you changed LyX version and didn't use a tmp dir. This behaviour came about without writing extra code ie for free :-). Ben.
Re: DepTable patch for 1.2cvs
On Fri, Dec 07, 2001 at 01:42:41AM +0100, Lars Gullik Bjønnes wrote: Everything in LyX is written to work with USE_TEMPDIR=true, if you don't use that expect strange behaviour. | so, why have we got the option again ?? Do I have to say it again? I suppose not ... archives are there for a reason ... DTRT? | do the right thing ... as in the spike lee film ... ok... I usualy use DIR ... now you have to tell us what that stands for and what it means ;) 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
Another crasher
importing ther attached tex file and clicking on a an array cell in lyx crashes - bad GC ... regards 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 badgc.tex Description: TeX document
Source question
in breakParagraph : 1739/* This check is necessary. Otherwise the new empty paragraph will 1740 * be deleted automatically. And it is more friendly for the user! */ 1741if (cursor.pos()) 1742setCursor(bview, cursor.par()-next(), 0); 1743else 1744setCursor(bview, cursor.par(), 0); Why do we have the check for cursor.pos() ? It works fine without, as we check cursor.par()-size() at the start. If we change the above to always do setCursor(bview, cursor.par()-next(), 0); and have : 1664 // can't break on empty paragraphs usually 1665 if ((cursor.par()-size() = 0) !layout.keepempty 1666 layout.labeltype != LABEL_SENSITIVE) 1667 return; (after setting lyx code to KeepEmpty 1, which it should be right ?), then you can type empty lines with lyx-code, i.e. fix a bug Getting backspace to work properly is a bit harder ... 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: problems with ert
Dekel Tsur wrote:
On Thu, Dec 06, 2001 at 10:57:16PM +0100, Herbert Voss wrote:
see attached file:
in 1.1.6 you can have a label inside ert.
1.2.0 end's with ert after the label.
You description is not accurate.
The 1.1.6 file contains ert-text1[label-inset]ert-text2
In 1.2.0 the result is [ert-inset1][label-inset]ert-text2,
where ert-inset1 contains the text ert-text1,
but ert-text2 appears as text and not inside ert-inset
it's a problem of inset inside inset, nothing else.
should be converted to \label{...}
No it shouldn't. The result should be [ert-inset1][label-inset][ert-inset2]
no! If I delete the label, I want to have ONE ert inset!
HErbert
--
http://www.lyx.org/help/
Mee too (Re: [PATCH] Re: M-m ( )
On Thu, Dec 06, 2001 at 09:46:42AM +0100, Lars Gullik Bjønnes wrote: ... Andre Poenitz [EMAIL PROTECTED] writes: ... | Is this one applied? No I do not think so. -- Lgb TGIF! ;-) -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq msg30080/pgp0.pgp Description: PGP signature
Re: [PATCH] Re: Bug list - another major update
On Thu, Dec 06, 2001 at 01:02:32AM +, John Levon wrote: > it is our old friend, a bv->text misuse. Please apply attached. > [...] > - Paragraph * par = bv->text->cursor.par(); > + Paragraph * par = bv->getLyXText()->cursor.par(); Can't things like that be catched by making bv->text private? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] Re: M-m (
On Mon, Dec 03, 2001 at 04:25:43PM +, John Levon wrote: > here's the patch. please apply > [...] > Index: src/ChangeLog > === > RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v > retrieving revision 1.429 > diff -u -r1.429 ChangeLog > --- src/ChangeLog 2001/12/03 13:17:01 1.429 > +++ src/ChangeLog 2001/12/03 16:23:23 > @@ -1,3 +1,8 @@ > +2001-12-03 John Levon <[EMAIL PROTECTED]> > + > + * kbsequence.h: > + * kbsequence.C: re-instate nmodifier mask > + > 2001-12-03 Juergen Vigna <[EMAIL PROTECTED]> Is this one applied? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] Re: Bug list - another major update
On Thu, Dec 06, 2001 at 09:47:19AM +0100, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > >> - Paragraph * par = bv->text->cursor.par(); > >> + Paragraph * par = bv->getLyXText()->cursor.par(); > > > | Can't things like that be catched by making bv->text private? > > The problem is that it is sometimes bv->text we want and not > bv->getLyXText. So make a second acessor "getTheTextAndIReallyMeanIt" and use that... Of course not by automatic search-and-replace, but by having a look of all instances... The compiler will make sure that we see all instances... Andre' -- André Pönitz .. [EMAIL PROTECTED]
RE: [PATCH][RFC] FormTabular and width/alignment
On 06-Dec-2001 John Levon wrote: > > Any reason why we can't just do like the attached patch does ? > Try it out yourself. Just try to edit an entry say you have "1mm" and want 100mm try to insert with your patch applied the 00 after the 1. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Don't believe everything you hear or anything you say.
Re: Quoting in InsetCommands
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> An unanswered question: is it OK to add code to quote '_' etc. John> in InsetCommand::asLyXCommand() so the user doesn't have to ? Yes, but we should also make sure the reLyX unquotes it. To know which characters have to be changed. Look at the code in paragraph.C which does the output. Probably the same routine should be used in both places, or insetindex should use an insettext internally. JMarc
Re: layout->Paragraph and stippled lines
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> How about a Paper Clip (TM) which pops up asking: "It seems Juergen> you want to insert a VSpace! May I help you?" A good and Juergen> approved method to prevent users from doing something ;-) Or, on a similar line, when the user selects Length, have an 'edit...' button which opens a popup where the user can set length and glue. THis way you (1) make things more complicated and (2) avoid to duplicate everywhere the code to set units and such. How difficult would that be? JMarc
Re: InsetText::the_locking_inset
On 06-Dec-2001 Allan Rae wrote:
> The use of the_locking_inset there seems haphazard at best. Some
> places seem to clear the_locking_inset after an unlock call while
> others don't.
Well sometimes I think you should sleep a bit more before looking at code ;)
You look at functions and don't see the obvious #:O) (a pitty you didn't
write this one on Friday I could think of a really amusing exchange of
emails ;)
> Code like:
> if (the_locking_inset) {
> unlockInsetInInset(bv, the_locking_inset);
> the_locking_inset = 0;
> }
Ok you're right here the above can safely be change to only
unlockInsetInInset(bv, the_locking_inset);
> seems to me to be equivalent to:
>
> unlockInsetInInset(bv, the_locking_inset);
> the_locking_inset = 0;
It is indeed!
> and could be written as:
>
> if (unlockInsetInInset(bv, the_locking_inset)) {
> the_locking_inset = 0;
> }
Nope the if is not neccessary, but yes if you like you could write it as
that too ;)
> but that isn't really any faster or better but might expose other
> bugs.
Why? The code in unlockInsetInInset() is quite clear
if (!the_locking_inset) return false;
Tis will just do nothing and the_locking_inset anyway is already 0,
so we don't have to set it to 0 again, isn't it?
> unlockInsetInInset() will do the check for the_locking_inset. The
> second line unconditionally resets the_locking_inset while
> unlockInsetInset() only resets it if this insets inset is the locking
> inset. The return value of unlockInsetInInset() tells whether it
> found a locking inset further down in the nested inset structure.
#:O)
Allan if I call unlockInsetInInset with inset==the_locking_inset why should
I check it. Obviously you're right with the setting to 0 the_locking_inset
it is not needed because of:
if (the_locking_inset == inset) {
the_locking_inset->insetUnlock(bv);
the_locking_inset = 0;
...
}
> Is there a plan to use the return value at anytime or should the
> following lines also reset the_locking_inset unconditionally like all
> the other instances in insettabular.C?
We don't need to use the returnvalue as it is irrelevant INSIDE THIS
insettabular, but unlockInsetInInset() is also called from the outside
world and there the returnvalue IS important!
> There appear as though there may be a few places where
> InsetText::the_locking_inset isn't cleared after an unlock attempt but
??? We don't have a InsetText::the_locking_inset!!!
> Maybe I'm misunderstanding something. If an inner inset is locked and
> I unlock it should the outer inset also be unlocked?
No, why should it! But if the outer inset is unlocked we have to descent
the tree and unlock ALL inner insets.
Hope this helps you a bit to find some good sleep tonight #:O) otherwise
have some of the really nice beers you produce there in Australia the also
help to have a good sleep ;)
Greets,
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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
I have defined the hundred per cent American as ninety-nine per cent an idiot.
-- George Bernard Shaw
Re: Quoting in InsetCommands
On Thu, Dec 06, 2001 at 10:34:48AM +0100, Jean-Marc Lasgouttes wrote: > > "John" == John Levon <[EMAIL PROTECTED]> writes: > > John> An unanswered question: is it OK to add code to quote '_' etc. > John> in InsetCommand::asLyXCommand() so the user doesn't have to ? > > Yes, but we should also make sure the reLyX unquotes it. To know which > characters have to be changed. Look at the code in paragraph.C which > does the output. Probably the same routine should be used in both > places, or insetindex should use an insettext internally. Automatic quoting has a tendency to fire back at some time... Andre' -- André Pönitz .. [EMAIL PROTECTED]
RE: [PATCH][RFC] Table selection
On 06-Dec-2001 John Levon wrote: > > first, the bugs I noticed in both old and new code : > > 1) attached file : selection the multicolumn cell, then press up. the topright > cell is not selected. I would say this is a feature not a bug, otherwise how would you select exactly the columns which are selected. Well we are inconsistent you'll say because if I do the other way round when entering the multi-cell it is selected till the end. Hmm if someone tells me how to handle this in a good way we should change it obviously, but I'm pretty sure we sill always have problems with this type of stuff. The only good solution would be that while selecting we should be able to add/remove columns also from withing a multi-cell, this should be possible in some way, but I don't see this as a priority, right now! > 2) TableExamples.lyx - the minipage is screwed ! Yes I know there is some wrong compatibilty reading, we should have a look at it. > Now, my patch. > 2) more spreadsheet like feel ??? Where do you feel that :) > 5) with this code, I can't see a user-visible reason for the dummy > cursor position ... Well I still see one or how would you select otherwise with the cursor? I'm also pretty sure that we need it for the mouseselection also, but well with mouse we could find some workaround, while with the cursor I really don't see one! > Juergen ? Others are welcome to try it ... I tried it and find it good! I'll commit it soon! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Living in New York City gives people real incentives to want things that nobody else wants. -- Andy Warhol
RE: Another table selection problem
On 06-Dec-2001 John Levon wrote: > If I select from c to d, then even though cell b protudes, I end up at d, > with b unselected. It should check all cells all the way to the end of the selection, > not just I know, I think I answered this already in my previous mail, didn't I? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If you didn't have to work so hard, you'd have more time to be depressed.
pragma interface/implementation
Can anybody please explain the proper usage of '#pragma interface' and '#pragma implementation'? After reading the info pages I don't really see any benifit in our cases since we are using seperate declaration/definition files anyway, don't we? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: pragma interface/implementation
On Thu, Dec 06, 2001 at 11:20:14AM +0100, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | Can anybody please explain the proper usage of '#pragma interface' and > | '#pragma implementation'? > > info gcc I read that twice. I do not understand it. > mark all class definition files with > > #pragma interface Where? At the very top after the include gueard in the header? > and the source files for the class with > > #pragma implementation > > this must be set befor the include of the class header file. Before everything or before the class include? If so, would it be sensble to have the class include as the last included item? Does it matter? > I am not sure how large the benefit is for gcc-3.x.y (or 2.96 for that > matter) but with gcc 2.95 and earlier the benefits were fairly huge. I tried it with 2.95.2 on one of my own files, and the change in .o size was about 200 bytes in a 200_k_ object (with -g). I am curently asking in gnu.g++.help... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: pragma interface/implementation
On Thu, Dec 06, 2001 at 11:32:30AM +0100, Lars Gullik Bjønnes wrote: > #include > // 1 > #ifdef __GNUG__ > #pragma implementation > #endif > // 2 > #include "header.h" > // 3 So where (1, 2 or 3) goes (a) #include (b) #include "paragraph.h" ? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Annoying LyX bugs
-BEGIN PGP SIGNED MESSAGE- On Thursday, 6. December 2001 00:58, you wrote: > On Thu, Dec 06, 2001 at 10:16:00AM +1100, Ben Stanley wrote: > > >(6) I just installed Lyx1.1.6fix3-1 (the binary rpm) on my RedHat 7.2 > > >box and now the rendering of eps figures in LyX is broken: It still says > > >"rendering", but nothing appears. The same file works correctly under > > >older RedHat versions. > > > > This annoys me to, but people keep telling me it's an xforms bug and as > > such can't be fixed until GUII is complete. > > In the case above, it is a RedHat ghostscript bug. It is the same problem (in SuSE 7.3 with ghostscript 6.51) as Morten reported earlier. We have a dirty, but working solution for it. (maybe, someone is interested?) Kornel - - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQCVAwUBPA9X6LewfbDGmeqhAQG79QQAvTkvR4LfSVo9103Yher78h6LNrsDwQgS MJ4r5lj3jQGPCe7xxrFHhScc+UUaNwCU7rfAwvcQbmw2RNdfUanwvndbqlzDtAwg JoiNQEmBi2quREP1dVvykPhk69gc7fzzgX6+bQVrtH+yDQgh3+GHtz/7HarDr4qt WbDgYbIHxVk= =aoZ8 -END PGP SIGNATURE-
Re: InsetText::the_locking_inset
On 06-Dec-2001 Juergen Vigna wrote: >> There appear as though there may be a few places where >> InsetText::the_locking_inset isn't cleared after an unlock attempt but > > ??? We don't have a InsetText::the_locking_inset!!! Sorry we obviously HAVE one (it was very early and I still had my eyes half closed ;), but IMO this should be changed to use LyXText::the_locking_inset! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 moss on the tree does not fear the talons of the hawk.
Re: [PATCH] mmap CRC checking 1.2cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I am pretty sure that this is not how we are going to solve this Lars> problem. Lars> What I need to know is how this is _supposed_ to be done on cxx, Lars> and then we can find the correct fix. Well, mmap() returns a void * #include void *mmap ( void *addr, size_t len, int prot, int flags, int filedes, off_t off ); When there is an error, here is what it does: [Digital] The following definition of the mmap() function does not conform to current standards and is supported only for backward compatibility (see standards(5)): caddr_t mmap ( caddr_t addr, size_t len, int prot, int flags, int filedes, off_t off ); STANDARDS Interfaces documented on this reference page conform to industry standards as follows: mmap(): XPG4-UNIX Refer to the standards(5) reference page for more information about indus- try standards and associated tags. Standards: standards(5) PARAMETERS addr Specifies the starting address of the new region (truncated to a page boundary). len Specifies the length in bytes of the new region (rounded up to a page boundary). prot Specifies access permissions as either PROT_NONE or the result of a logical OR operation on any combination of PROT_READ, PROT_WRITE, and PROT_EXEC. flags Specifies attributes of the mapped region as the results of a bitwise-inclusive OR operation on any combination of MAP_FILE, MAP_ANONYMOUS, MAP_VARIABLE, MAP_FIXED, MAP_SHARED, MAP_PRIVATE, MAP_INHERIT, or MAP_UNALIGNED . filedes Specifies the file to be mapped to the new mapped file region returned by open(). off Specifies the offset into the file that gets mapped at address addr. DESCRIPTION The mmap() function creates a new mapped file region, a new private region, or a new shared memory region. The addr and len parameters specify the requested starting address and length in bytes for the new region. The address is a multiple of the page size returned by sysconf(_SC_PAGE_SIZE). If the len parameter is not a multiple of the page size returned by sysconf(_SC_PAGE_SIZE), then the result of any reference to an address between the end of the region and the end of the page containing the end of the region is undefined. The flags parameter specifies attributes of the mapped region. Values of the flags parameter are constructed by a bitwise-inclusive OR operation on the flags from the following list of symbolic names defined in the sys/mman.h file: MAP_FILE Create a mapped file region. MAP_ANONYMOUS Create an unnamed memory region. MAP_VARIABLE Place region at the computed address. MAP_FIXEDPlace region at fixed address. MAP_SHARED Share changes. MAP_PRIVATE Changes are private. MAP_INHERIT Region not unmapped by exec(2). MAP_UNALIGNED Do not verify that the file offset is page aligned. The MAP_FILE and MAP_ANONYMOUS flags control whether the region to be mapped is a mapped file region or an anonymous shared memory region. One of these flags must be selected. If MAP_FILE is set in the flags parameter: o+ A new mapped file region is created, mapping the file associated with the filedes parameter. o+ The off parameter specifies the file byte offset at which the mapping starts. This offset must be a multiple of the page size returned by sysconf(_SC_PAGE_SIZE). o+ If the end of the mapped file region is beyond the end of the file, the result of any reference to an address in the mapped file region corresponding to an offset beyond the end of the file is unspecified. If MAP_ANONYMOUS is set in the flags parameter: o+ A new memory region is created and initialized to all zeros. This memory region can be shared only with descendents of the current pro- cess. o+ If the filedes parameter is not -1, the mmap() function fails. The new region is placed at the requested address if the requested address is not null and it is possible to place the region at this address. When the requested address is null or the region cannot be placed at the requested address, the MAP_VARIABLE and MAP_FIXED flags control the place- ment of the region. One of these flags must be selected. If MAP_VARIABLE is set in the flags parameter: o+ If the requested address is null or if it is not possible for the sys- tem to place the region at the requested address, the region is placed at an address selected by the system. If MAP_FIXED is set in the flags parameter: o+ If the requested address is not null, the mmap() function succeeds even
Re: [PATCH] mmap CRC checking 1.2cvs
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> RETURN VALUES Jean-Marc> Upon successful completion, the mmap() function returns Jean-Marc> the address at which the mapping was placed. Otherwise, Jean-Marc> mmap() returns (caddr_t)-1 and sets errno to indicate the Jean-Marc> error. Actually in sysmman.h, I find /usr/include/sys/mman.h:#define MAP_FAILED (-1L) /* unsuccessful return from mmap() */ So the reinterpret_cast is probably the right solution here. UNfortunately, I cannot apply the patch just to try it out, because I am over a telnet connection. JMarc PS: sorry for posting the whole man page. This was not the intent.
Re: [PATCH] mmap CRC checking 1.2cvs
On Thu, Dec 06, 2001 at 08:39:47AM +0100, Lars Gullik Bjønnes wrote:
> Ben Stanley <[EMAIL PROTECTED]> writes:
>
> | Please let me know if the attached patch fixes this problem.
> >
> | I also tried to fix the Solaris compile problem - Kayvan, could you
> | please test it?
>
> I am pretty sure that this is not how we are going to solve this
> problem.
I don't like adding the POSIX level hack either.
How about this? (it compiles for me on Solaris).
Index: lyxsum.C
===
RCS file: /cvs/lyx/lyx-devel/src/support/lyxsum.C,v
retrieving revision 1.20
diff -u -r1.20 lyxsum.C
--- lyxsum.C2001/12/03 01:11:05 1.20
+++ lyxsum.C2001/12/06 16:52:22
@@ -40,7 +40,7 @@
void * mm = mmap(0, info.st_size, PROT_READ,
MAP_PRIVATE, fd, 0);
- if (mm == MAP_FAILED) {
+ if (mm == reinterpret_cast(MAP_FAILED)) {
close(fd);
return 0;
}
@@ -52,7 +52,7 @@
crc.process_block(beg, end);
unsigned long result = crc.checksum();
- munmap(mm, info.st_size);
+ munmap((caddr_t) mm, info.st_size);
close(fd);
return result;
Re: [PATCH] mmap CRC checking 1.2cvs
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: Kayvan> On Thu, Dec 06, 2001 at 08:39:47AM +0100, Lars Gullik Bjønnes Kayvan> wrote: >> Ben Stanley <[EMAIL PROTECTED]> writes: >> >> | Please let me know if the attached patch fixes this problem. >> > >> | I also tried to fix the Solaris compile problem - Kayvan, could >> you | please test it? >> >> I am pretty sure that this is not how we are going to solve this >> problem. Kayvan> I don't like adding the POSIX level hack either. I cannot test it right now, but I suspect that on cxx the caddr_t cast will fail (since the right type seems to be void*). JMarc
Re: [PATCH] Re: Bug list - another major update
On Thu, Dec 06, 2001 at 10:14:48AM +0100, Andre Poenitz wrote: > So make a second acessor "getTheTextAndIReallyMeanIt" and use that... > Of course not by automatic search-and-replace, but by having a look of all > instances... The compiler will make sure that we see all instances... I have already done that. See my "bvtexts" list. regards 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: [PATCH][RFC] Table selection
On Thu, Dec 06, 2001 at 11:10:37AM +0100, Juergen Vigna wrote: > I would say this is a feature not a bug, otherwise how would you select > exactly the columns which are selected. Well we are inconsistent you'll > say because if I do the other way round when entering the multi-cell it is > selected till the end. Hmm if someone tells me how to handle this in a > good way we should change it obviously, but I'm pretty sure we sill always > have problems with this type of stuff. The only good solution would be that > while selecting we should be able to add/remove columns also from withing > a multi-cell, this should be possible in some way, but I don't see this as > a priority, right now! agreed. I'm happy with the current behaviour really... > > 2) TableExamples.lyx - the minipage is screwed ! > > Yes I know there is some wrong compatibilty reading, we should have a look > at it. ok. > > 2) more spreadsheet like feel > > ??? Where do you feel that :) in that I can select a cell by clicking on the LHS of it. > > 5) with this code, I can't see a user-visible reason for the dummy > > cursor position ... > > Well I still see one or how would you select otherwise with the cursor? > I'm also pretty sure that we need it for the mouseselection also, but > well with mouse we could find some workaround, while with the cursor I > really don't see one! OK, we still need the cursor position, but we don't ever need to show a cursor being there, and (for example) we don't need to go to the dummy position when unlocking the insettext. Why ? because clicking onto the dummy selects the cell, and from then on both keyboard and mouse selection work as expected... regards 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: Another table selection problem
On Thu, Dec 06, 2001 at 11:11:42AM +0100, Juergen Vigna wrote: > > If I select from c to d, then even though cell b protudes, I end up at d, > > with b unselected. It should check all cells all the way to the end of the >selection, > > not just > > I know, I think I answered this already in my previous mail, didn't I? yep (though it is a slightl different case ;) 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: [PATCH][RFC] FormTabular and width/alignment
On Thu, Dec 06, 2001 at 10:27:48AM +0100, Juergen Vigna wrote: > > On 06-Dec-2001 John Levon wrote: > > > > Any reason why we can't just do like the attached patch does ? > > > > Try it out yourself. Just try to edit an entry say you have > "1mm" and want 100mm try to insert with your patch applied > the 00 after the 1. um, it works fine. it changes to 10mm and then 100mm ... what problem should I be seeing ? thanks 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: vspace
On Thu, Dec 06, 2001 at 07:11:57AM +0100, Herbert Voss wrote: > looks cool ... I have only one problem: > why should I see, that I don't have any space where > by default is no additional space ... ;-) > > the floatingfigure is converted from 1.1.6 to 1.2 > by lyx. Can I have the original 1.1.6 lyx file ? It doesn't make any sense too have a length of zero w/o some stretch value as well. Did you add the space of 0cm in the old lyx file, or does the 1.2.0 import introduce it ? thanks 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: vspace
On Thu, Dec 06, 2001 at 10:11:59PM +0100, Herbert Voss wrote: > sure, but this was written by lyx into the file: > > \layout Standard > \added_space_top 0cm \added_space_bottom 0cm \align center OK, so for compatibility we should convert these to VSpace::NONE > >Did you add the space of 0cm in the old lyx file, or does the 1.2.0 > >import introduce it ? > > lines, now the two vspace marker. > The appear at all tables and floats. > I'll have a look for a 1.1.6 file. please thanks 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: vspace
On Thu, Dec 06, 2001 at 10:22:43PM +0100, Herbert Voss wrote: > A new situation: > > I suppose it's no more a problem, because it happens only > > for 1.1.6 files which I read with 1.2.0 some time (weeks) ago. > With latest cvs I can't reproduce. good - I suspect the vspace changes I didn't make are responsible ... btw, Herbert, if you have any 1.1.6 or other files that 1.2.0cvs isn't happy with in whatever way, it would be great if you could email me them with a short note thanks 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: vspace
John Levon wrote: > > btw, Herbert, if you have any 1.1.6 or other files that 1.2.0cvs isn't > happy with in whatever way, it would be great if you could email > me them with a short note I'll have a look at weekend. Only one thing which is not a real problem but for the users annoying and also reported. if you have in 1.1.6 a lot of ert-lines without ctrl-enter you'll get for every line an own inset. this is espacially for ert nonsense and makes editing impossible. I think it should be no problem for lyx to save the last action (inset) and don't start a new one if it's the same. Herbert -- http://www.lyx.org/help/
problems with ert
see attached file:
in 1.1.6 you can have a label inside ert.
1.2.0 end's with ert after the label.
should be converted to \label{...}
Herbert
--
http://www.lyx.org/help/
#LyX 1.1 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass article
\language ngerman
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
THis is only ert with a label:
\layout Standard
\latex latex
I like
\begin_inset LatexCommand \label{Label}
\end_inset
ert and labels
\the_end
Re: problems with ert
On Thu, Dec 06, 2001 at 10:57:16PM +0100, Herbert Voss wrote:
> see attached file:
> in 1.1.6 you can have a label inside ert.
> 1.2.0 end's with ert after the label.
You description is not accurate.
The 1.1.6 file contains [label-inset]
In 1.2.0 the result is [ert-inset1][label-inset]ert-text2,
where ert-inset1 contains the text ert-text1,
but ert-text2 appears as text and not inside ert-inset
> should be converted to \label{...}
No it shouldn't. The result should be [ert-inset1][label-inset][ert-inset2]
Re: [PATCH] mmap CRC checking 1.2cvs
Lars Gullik Bjønnes wrote: >"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > >| On Thu, Dec 06, 2001 at 08:39:47AM +0100, Lars Gullik Bjønnes wrote: > >>>Ben Stanley <[EMAIL PROTECTED]> writes: >>> >>>| Please let me know if the attached patch fixes this problem. >>> >>>| I also tried to fix the Solaris compile problem - Kayvan, could you >>>| please test it? >>> >>>I am pretty sure that this is not how we are going to solve this >>>problem. >>> >| I don't like adding the POSIX level hack either. > Hmmm... I think that this is the right approach, but what I sent in was a hack. See below. > >| How about this? (it compiles for me on Solaris). > >No, won't do. > No, I don't like that either. That won't compile elsewhere. >Either disable mmap for those platforms of find a better solution. > Hmmm... let's try for the better solution. It seems that we have 2 distinct problems: 1) Solaris headers by default provide an old version of munmap with the wrong type in there. 2) compaq provides a definition of MAP_FAILED with a similarly wrong type. The Solaris headers can be told to give us a POSIX compliant definition of munmap by doing #define _POSIX_C_SOURCE 199506L before #include This seems to be fairly standard - see http://vicente.org/xclib/include/xc/standards.h.html http://www.cs.arizona.edu/computer.help/policy/DIGITAL_unix/AA-QTLMA-TE_html/relnotes5.html Also mentioned at http://mail.gnu.org/pipermail/autoconf/2000-August/006020.html, but this suggests problems with defining this unconditionally on Solaris... This solution would mean that we only have to support POSIX mmap, instead of several non-standard variants. This removes #ifdef and reinterpret_cast clutter from the code, which I consider to be a great advantage. It would be nice to have access to some man pages for the platforms in question. The compaq headers may have a similar feature. The definition that Jean-Marc looked up is also a compatibility defintion. The compq man page suggested looking at standards(5) - Jean-Marc, could you please take a look at this, and perhaps send it to me? Specifically, does it mention _POSIX_C_SOURCE? So, I think that the _POSIX_C_SOURCE define may fix both problems, but I would like to see authorative documentation. I think it is probably safe to define this macro unconditionally for this file because we only need mmap here, and on Linux it has no effect. Ben.
Re: [PATCH] mmap CRC checking 1.2cvs
On Fri, Dec 07, 2001 at 09:29:38AM +1100, Ben Stanley wrote: > The Solaris headers can be told to give us a POSIX compliant definition > of munmap by doing > #define _POSIX_C_SOURCE 199506L > before > #include > > This seems to be fairly standard - see [...] > > So, I think that the _POSIX_C_SOURCE define may fix both problems, but I > would like to see authorative documentation. > > I think it is probably safe to define this macro unconditionally for > this file because we only need mmap here, and on Linux it has no effect. This seems fine to me. I have added just the _POSIX_C_SOURCE definition to the lyxsum.C file and it compiles fine on Solaris. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
DepTable patch for 1.2cvs
Lars Gullik Bjønnes wrote: >Ben Stanley <[EMAIL PROTECTED]> writes: > >| I still need to get the proper DepTable patch out. The patch that is >| currently in 1.2 is b0rken. > >explain. > Hmmm... I have a new implementation which keeps an old and a new mtime, and checks that before checking the old and new crcs (and possibly re-calculating crcs)... but now that I think about it again, I shouldn't need to keep two mtimes. However, the version currently in 1.2 writes the 3 numbers to the deptable, which is incompatible with previous behaviour which writes/reads only 2. This needs to be fixed at the very least - my new patch stores only 2 and 'does the right thing' when presented with an old file, and causes the old implementation to DTRT when presented with a new style file. And the version in 1.2 doesn't behave correctly when it finds a file who's mtime has changed. It doesn't shuffle the crc value from second to first before overwriting it with the new value (in update()). This causes excessive LaTeX runs. I have now written something for 1.2 which keeps only one mtime; I'd better test before posting. Ben
Re: DepTable patch for 1.2cvs
On Fri, Dec 07, 2001 at 01:29:15AM +0100, Lars Gullik Bjønnes wrote: > Ben Stanley <[EMAIL PROTECTED]> writes: > > | However, the version currently in 1.2 writes the 3 numbers to the > | deptable, which is incompatible with previous behaviour which > | writes/reads only 2. > > No, we do not have to do that. > Everything in LyX is written to work with USE_TEMPDIR=true, if you > don't use that expect strange behaviour. so, why have we got the option again ?? > DTRT? do the right thing ... as in the spike lee film ... 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: DepTable patch for 1.2cvs
Lars Gullik Bjønnes wrote: >Ben Stanley <[EMAIL PROTECTED]> writes: > >| However, the version currently in 1.2 writes the 3 numbers to the >| deptable, which is incompatible with previous behaviour which >| writes/reads only 2. > >No, we do not have to do that. >Everything in LyX is written to work with USE_TEMPDIR=true, if you >don't use that expect strange behaviour. > >Also I do not think that we have to be deptable compatible with 1.1.6 > (and older 1.1.2CVS does not matter). > Anyway, my current patch is backwards compatible - reads/writes 2 values, and Does The Right Thing with old/new files, even if it causes CRCs to be calculated when not strictly necessary in the case that you changed LyX version and didn't use a tmp dir. This behaviour came about without writing extra code ie for free :-). Ben.
Re: DepTable patch for 1.2cvs
On Fri, Dec 07, 2001 at 01:42:41AM +0100, Lars Gullik Bjønnes wrote: > >> Everything in LyX is written to work with USE_TEMPDIR=true, if you > >> don't use that expect strange behaviour. > > > | so, why have we got the option again ?? > > Do I have to say it again? I suppose not ... archives are there for a reason ... > >> DTRT? > > > | do the right thing ... as in the spike lee film ... > > ok... I usualy use "DIR" ... now you have to tell us what that stands for and what it means ;) 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"
Another crasher
importing ther attached tex file and clicking on a an array cell in lyx crashes - bad GC ... regards 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" badgc.tex Description: TeX document
Source question
in breakParagraph : 1739/* This check is necessary. Otherwise the new empty paragraph will 1740 * be deleted automatically. And it is more friendly for the user! */ 1741if (cursor.pos()) 1742setCursor(bview, cursor.par()->next(), 0); 1743else 1744setCursor(bview, cursor.par(), 0); Why do we have the check for cursor.pos() ? It works fine without, as we check cursor.par()->size() at the start. If we change the above to always do setCursor(bview, cursor.par()->next(), 0); and have : 1664 // can't break on empty paragraphs usually 1665 if ((cursor.par()->size() <= 0) && !layout.keepempty 1666 && layout.labeltype != LABEL_SENSITIVE) 1667 return; (after setting lyx code to KeepEmpty 1, which it should be right ?), then you can type empty lines with lyx-code, i.e. fix a bug Getting backspace to work properly is a bit harder ... 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: problems with ert
Dekel Tsur wrote:
> On Thu, Dec 06, 2001 at 10:57:16PM +0100, Herbert Voss wrote:
>
>>see attached file:
>>in 1.1.6 you can have a label inside ert.
>>1.2.0 end's with ert after the label.
>>
>
> You description is not accurate.
> The 1.1.6 file contains [label-inset]
> In 1.2.0 the result is [ert-inset1][label-inset]ert-text2,
> where ert-inset1 contains the text ert-text1,
> but ert-text2 appears as text and not inside ert-inset
it's a problem of inset inside inset, nothing else.
>
>>should be converted to \label{...}
>>
>
> No it shouldn't. The result should be [ert-inset1][label-inset][ert-inset2]
no! If I delete the label, I want to have ONE ert inset!
HErbert
--
http://www.lyx.org/help/
Mee too (Re: [PATCH] Re: M-m ( )
On Thu, Dec 06, 2001 at 09:46:42AM +0100, Lars Gullik Bjønnes wrote: ... > Andre Poenitz <[EMAIL PROTECTED]> writes: ... > | Is this one applied? > > No I do not think so. > > -- > Lgb TGIF! ;-) -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq msg30080/pgp0.pgp Description: PGP signature
