[Fwd: Re: wp2latex feature request]
--- Begin Message --- > wp2latex feature request > > Garst R. Reese > Sat, 24 Jun 2006 06:42:28 -0700 > > http://www.penguin.cz/~fojtik/wp2latex/wp2latex.htm > Converts wordperfect.wpd files to .tex > It would be nice to have this in converters if installed. Anyway, wp2latex could parse even other documents like RTF, Accent, HTML, T602, Word (little bit) etc. So the filter could call wp2latex even for these formats. I welcome such support from other programs. If you need some help feel free to ask. Jara > > Thanks, > Garst > --- End Message ---
wp2latex feature request
http://www.penguin.cz/~fojtik/wp2latex/wp2latex.htm Converts wordperfect.wpd files to .tex It would be nice to have this in converters if installed. Thanks, Garst
lyx-1.3.7 & Fedora core 5
It compiles with xforms, but it cannot find colors, so lots of stuff is just black on black. The FC5 release notes say they have moved to X11R7 so a lot of stuff is not where it used to be and applications will have to adjust. How? I have a different problem with qt-3.3. How do I tell Lyx where it is? What should QTDIR say? I got libraries and includes right, but that is not enough. Thanks, Garst (not subscribed)
Re: [Patch] Re: book that prints with 1.3.7 is screwed up with 1.4.1
Martin Vermeer wrote:
On Thu, Apr 20, 2006 at 10:28:51PM -0500, Garst R. Reese wrote:
Martin Vermeer wrote:
I don't agree. You're right in that the only place where a
_correspondence_ is defined between the old numerical parameters and the
new character ones is, precisely, lyx2lyx. And this correspondence
should be _semantically correct_, i.e. 0123 -> ctbs. (Right? You have
1.3.7 installed, so you can verify that truly 0 = center, 1 = top.)
Yes, but why does src/insets/insetminipage.h have
33 enum InnerPosition {
34 inner_center,
35 inner_top,
36 inner_bottom,
37 inner_stretch
instead of
33 enum InnerPosition {
34 inner_top,
35 inner_center,
36 inner_bottom,
37 inner_stretch
?
If this order is changed and lyx_1_4.py is changed to match than 1.3.7
still works.
The only "bug" I see is the inconsistent default conventions: the old
one height = 0, inner_position = 0, and the new one height = "1pt"
(meaning, 1\totalheight) and inner_pos = 't'. The error (the ONLY error
IMHO) is translating the old default to "1pt", 'c', rather than "1pt",
't'. Which my patch corrects in a minimal way. Think what your proposed
remedy would do to a minipage with a manually set height, if the
inner_pos semantics is wrong.
- Martin
Thanks for the pointers. After looking at the relevant files in 1.4.1,
and the insetminipage
files in 1.3.7, I think that both patches to 1.4.1 should be applied. I
tried this and did not have a problem with it. You, of course, know
much better than I and I thank you for sharing.
Garst
Re: [Patch] Re: book that prints with 1.3.7 is screwed up with 1.4.1
Martin Vermeer wrote: On Wed, Apr 19, 2006 at 06:02:33PM -0500, Garst R. Reese wrote: Martin Vermeer wrote: On Wed, Apr 19, 2006 at 08:57:53PM +0300, Martin Vermeer wrote: On Wed, Apr 19, 2006 at 10:20:36AM -0500, Garst R. Reese wrote: ... Try the attached. - Martin Oops, hit reply instead of reply all for the last two msgs. This is to fix things. I played with the Box Settings in 1.4.1 by right clicking on the minipages. It shows Vertical Alignment and Inner Alignment(vert). Horizontal Alignment is greyed out. The working combination is Top Top for the critters and Middle Middle for the title. Lyx2lyx sets them to Top Middle and Middle Middle. For this file, it works to change inner_pos = ["c","t","b","s"] to inner_pos = ["t","c","b","s"]. This changes the title settins to Middle Top, but still gives a correct ps output. So I reverted this change and used the dialog boxes to set Top Top and Middle Top and again got correct output. So what dictates the ordering in inner_pos? Yes it happens to work, but the logic is wrong. The original order of inner_pos is correct and shouldn't be changed: it is the order of the older numerical argument inner_position. I think the old order was a bug and this is a good time to squelch it. in development/FORMAT lines 260-284 you have an Ovalbox and on line 269 you use tcbs for it's inner_pos. But on line 289 you use c/t/b/s for the Frameless box. The only place in the 1.4.1 code that I can find actually using inner_pos is in lyx_1_2.py (line172) and lyx_1_4.py. I think my example doc just exposed this inconsistency as a true bug. Were it not for the strange c/t/b/s mapping all would have been well. Thanks, Garst
Re: [Patch] Re: book that prints with 1.3.7 is screwed up with 1.4.1
Martin Vermeer wrote:
On Wed, Apr 19, 2006 at 08:57:53PM +0300, Martin Vermeer wrote:
On Wed, Apr 19, 2006 at 10:20:36AM -0500, Garst R. Reese wrote:
I have done some experimenting changing the .lyx file. To reproduce the
1.3.7 results, the Box Framless insets for the critters have position
"t" and inner_pos "t" but for the title it needs position "c" and
inner_pos "t". The corresponding Minipage settings in 1.3.7 are position
0, inner_position 0 and position 1, inner_position 0. So, in my case,
inner_position is the same for all of the Minipage insets, but position
changes. I tried all combinations of 0's and 1's
around position and inner_pos in lyx_1_4.py to no avail.
Garst
I think I know what the problem is.
1.3.7 uses the combination of height = 1pt and inner_position = 0 to
indicate the defaults. These should be translated to "1\totalheight" and
"t" to function correctly. Unfortunately lyx2lyx translates it to
"1\totalheight" and "c", because 0 -> "c" and it doesn't recognize the
special case.
Have to sleep on this one, if Jose doesn't beat me to a fix :-)
Try the attached.
- Martin
Oops, hit reply instead of reply all for the last two msgs. This is to
fix things.
I played with the Box Settings in 1.4.1 by right clicking on the
minipages. It shows Vertical Alignment and Inner Alignment(vert).
Horizontal Alignment is greyed out. The working combination is Top Top
for the critters and Middle Middle for the title. Lyx2lyx sets them to
Top Middle and Middle Middle. For this file, it works to change
inner_pos = ["c","t","b","s"]
to inner_pos = ["t","c","b","s"]. This changes the title settins to
Middle Top, but still gives a correct ps output. So I reverted this
change and used the dialog boxes to set Top Top and Middle Top and again
got correct output. So what dictates the ordering in inner_pos?
Your new patch also works and sets the Box Settings the same way -- Top
Top and Middle Top.
Garst
Index: lyx_1_4.py
===
--- lyx_1_4.py (revision 13657)
+++ lyx_1_4.py (working copy)
@@ -987,10 +987,10 @@ def convert_minipage(file):
# convert the inner_position
if file.body[i][:14] == "inner_position":
-file.body[i] = 'inner_pos "%s"' % inner_pos[int(file.body[i][15])]
+ innerpos = inner_pos[int(file.body[i][15])]
+ del file.body[i]
else:
-file.body.insert('inner_pos "%s"' % inner_pos[0])
-i = i + 1
+ innerpos = inner_pos[1]
# We need this since the new file format has a height and width
# in a different order.
@@ -1018,6 +1018,12 @@ def convert_minipage(file):
else:
status = "collapsed"
+ # Handle special default case:
+ if height == ' "1pt"' and innerpos == 'c':
+ innerpos = 't'
+
+file.body.insert(i, 'inner_pos "' + innerpos + '"')
+i = i + 1
file.body.insert(i, 'use_parbox 0')
i = i + 1
file.body.insert(i, 'width' + width)
Re: book that prints with 1.3.7 is screwed up with 1.4.1
I have done some experimenting changing the .lyx file. To reproduce the 1.3.7 results, the Box Framless insets for the critters have position "t" and inner_pos "t" but for the title it needs position "c" and inner_pos "t". The corresponding Minipage settings in 1.3.7 are position 0, inner_position 0 and position 1, inner_position 0. So, in my case, inner_position is the same for all of the Minipage insets, but position changes. I tried all combinations of 0's and 1's around position and inner_pos in lyx_1_4.py to no avail. Garst Martin Vermeer wrote: On Wed, 2006-04-19 at 07:29 -0500, Garst R. Reese wrote: Martin Vermeer wrote: On Wed, 2006-04-19 at 10:57 +0100, Jose' Matos wrote: On Wednesday 19 April 2006 07:52, Martin Vermeer wrote: Sorry for the long analysis. Jose, do you agree? I guess so, after such throughout explanation it is difficult not to agree. :-) Since you understand both codes, I would vote for this code inclusion in both trunk and 1.4. Could you do it, please? But first of all, Garst, does it do the job? No. The patch made no change to the exported .tex file. The c is still a c, not a t. Garst Jose? Where is the right place? - Martin
Re: book that prints with 1.3.7 is screwed up with 1.4.1
Martin Vermeer wrote: On Wed, 2006-04-19 at 10:57 +0100, Jose' Matos wrote: On Wednesday 19 April 2006 07:52, Martin Vermeer wrote: Sorry for the long analysis. Jose, do you agree? I guess so, after such throughout explanation it is difficult not to agree. :-) Since you understand both codes, I would vote for this code inclusion in both trunk and 1.4. Could you do it, please? But first of all, Garst, does it do the job? No. The patch made no change to the exported .tex file. The c is still a c, not a t. Garst - Martin
Re: book that prints with 1.3.7 is screwed up with 1.4.1
Attached .tex files simplified by changing all graphic letters to o found in crittero... Hope this helps. Garst Martin Vermeer wrote: On Tue, Apr 18, 2006 at 10:18:02PM +0200, Michael Gerz wrote: Garst R. Reese wrote: Attached you will find the cover pdf generated with ps2pdf from the print to file output from 1.3.7. I cannot provide the equivalent pdf from 1.4.1 because ps2pdf aborts with errors. View pdf works but instead of 5 lines of letters, there are only 4 and the title is raised a few cm. The difference in the .lyx files is that 1.3.7 says begin_inset Minipage and 1.4.1 begin inset Box Frameless Garst, could you please provide us with a simple test case (minimized LyX file) and add a report to bugzilla? And what is the LaTeX code produced by both? If 1.4.1 and 1.3.7 do not produce the same output, there is a serious regression. The problem could be in lyx2lyx (Minipage -> Box). - Martin Abookcover1.3.7.tex Description: TeX document Abookcover1.4.1.tex Description: TeX document crittero.eps.gz Description: GNU Zip compressed data
Re: book that prints with 1.3.7 is screwed up with 1.4.1
The only difference between the attached files known to the user is the
version of lyx that saved them.
Michael echoes my objections to the new memubar. I spent two weeks
trying to get used to it, but just got increasingly irritated.
Regards,
Garst
Michael Gerz wrote:
Garst R. Reese wrote:
In anycase, I dislike the 1.4.1 menubar so much that I will stay with
1.3.7
Garst, I am afraid agree with you.
IMHO the biggest mistake was to drop the "Format" menu. EVERY text
editing tool but LyX has such a menu and the average user expects it
to contain "Character...", "Paragraph...", and "Document..." entries.
In LyX, you find formatting options in both "Edit" and "Document"
("Edit>Text Style", "Edit>Paragraph Settings", "Document>Settings"
etc.). IMHO this is counter-intuitive and also 'pollutes' the "Edit"
menu. Also: Why is "LaTeX Log" in "Document"? It only makes sense in
the context of "View".
I know that we discussed the menu structure a long time ago.
Nevertheless, I think we should again ask the LyX users what they
think about the new structure and revert some of the changes if they
lead to confusion. It is not a shame to confess that some changes went
into the wrong direction.
Michael
PS: The citation dialog has become very inconvenient. Are there any
plans to revive the good old 1.3.X dialog in 1.4.X?
#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass book
\begin_preamble
\usepackage{oldgerm} % so that the math font matches the textfont
\newcommand{\YIN}{\usefont{U}{yinit}{m}{n}}
\newcommand{\YINA}{\usefont{U}{yinitA}{m}{n}}
\usepackage{euler} % so that the math font matches the textfont
\newcommand{\EUS}{\usefont{U}{eus}{m}{n}}
\end_preamble
\language canadian
\inputencoding latin1
\fontscheme bookman
\graphics default
\paperfontsize default
\spacing single
\papersize Custom
\paperpackage a4
\use_geometry 1
\use_amsmath 1
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\paperwidth 5.5in
\paperheight 4.25in
\leftmargin 7mm
\topmargin 2mm
\rightmargin 8mm
\bottommargin 2mm
\headheight 0in
\headsep 0in
\footskip 0in
\secnumdepth 2
\tocdepth 2
\paragraph_separation skip
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 2
\paperpagestyle empty
\layout Standard
\begin_inset Minipage
position 0
inner_position 0
height "1pt"
width "67col%"
collapsed false
\layout Standard
\begin_inset Graphics
filename eps/crittera.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\SpecialChar ~
\SpecialChar ~
\begin_inset Graphics
filename eps/critterb.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\SpecialChar ~
\SpecialChar ~
\begin_inset Graphics
filename eps/critterc.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\SpecialChar ~
\SpecialChar ~
\begin_inset Graphics
filename eps/critterd.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\newline
\SpecialChar ~
\newline
\begin_inset Graphics
filename eps/crittere.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\SpecialChar ~
\SpecialChar ~
\begin_inset Graphics
filename eps/critterf.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\SpecialChar ~
\SpecialChar ~
\begin_inset Graphics
filename eps/critterg.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\SpecialChar ~
\SpecialChar ~
\begin_inset Graphics
filename eps/critterh.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\end_inset
\begin_inset Minipage
position 1
inner_position 0
height "1pt"
width "33col%"
collapsed false
\layout Standard
\series bold
\size large
The
\newline
AlphaBeast
\newline
Book
\newline
\SpecialChar ~
\newline
by
\newline
Garst R.
Reese
\end_inset
\layout Standard
\pagebreak_bottom \noindent
\begin_inset Graphics
filename eps/critteri.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\SpecialChar ~
\SpecialChar ~
\begin_inset Graphics
filename eps/critterj.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\SpecialChar ~
\SpecialChar ~
\begin_inset Graphics
filename eps/critterk.eps.gz
lyxscale 10
display color
width 1.6cm
height 1.6cm
\end_inset
\SpecialChar ~
\SpecialCh
Re: moc not mentioned in INSTALL or README
Jose' Matos wrote: On Saturday 02 July 2005 04:18, Garst R. Reese wrote: Hi folks, I'm trying to install lyx-1.3.5 in Fedora core 4. configure tells me I don't have moc, and I don't. Nor do I know where to get it or what the containing pkg is called. It's strange because FC2 installed it. $ which moc /usr/bin/moc $ rpm -qf /usr/bin/moc qt-devel-3.3.4-15.1 This should question belongs to the FAQ. :-) If it is not there it should be. Thanks Jose' I would suggest in INSTALL: 0) Linux users beware: if compiling the Qt frontend, you need qt and qt-devel packages of the same version to compile LyX. If "which moc" fails to find moc, qt-devel is not installed. Regards to all, Garst
moc not mentioned in INSTALL or README
Hi folks, I'm trying to install lyx-1.3.5 in Fedora core 4. configure tells me I don't have moc, and I don't. Nor do I know where to get it or what the containing pkg is called. It's strange because FC2 installed it. Please cc me. Thanks Garst
Re: import and insert file
Thanks Jeurgen The bugzilla file said: follow these steps to define a new converter in 1.3.6: 1. Select "from" and "to" formats in the comboxes 2. Press "New". The New converter will be added to the browser, but neither the commands not the flags will be applied 3. Now add commands and flags and press "Modify". This will also save those. I first had to go to file formats and use New to add wordperfect WordPerfect wpd Then the from and to format comboxes worked After pressing Modify, I still had to press Save to get WordPerfect to appear in the Import list. Works now.
Re: import and insert file
Thanks Georg The command line for wp2latex is: wp2latex [input_file [output_file]] [switches] The man page gives details of switches. I can post it to list if requested. pls cc me. Garst
import and insert file
Hi folks, I frequently get short .doc or .wpd files that get converted to tex with wv or wp2latex. The latest versions of both are now working quite well. Import file lists all of the possibilities that I have conversion software installed for, but Insert file does not. It would be more convenient if I had to option of Importing a file to the current document. As things now stand (1.3.5) I have to: 1. run wp2latex if it is a .wpd file to create a .tex file 2. Import the .tex file or the .doc file 3. Insert the file in the master document 4. Clean up the mess. I tried adding a converter for wp2latex but clicking on New under converters does not seem to work. It would be nice if lyx would check for wp2latex and set up the converter. Well, as long as I'm complaining, it would be nice if the README or INSTALL file listed the external packages, like wv, that enhance the utility of LyX. At present, the only way of discovering this is to look at the configure output to see which packages it is checking for. My guess is that a lot of users don't even know that they can import .doc files. Cheers & Thanks Garst
blanket-permission.txt:
Greetings Angus and all, You most certainly have my permission to add my name and meager contributions to the blanket permissions. Thanks for all your help! Garst
epigraph problems
Hi folks, It's been a long time since I bugged you.
With Lyx 1.3.5, I'm trying to put a photo on either a chapter or Part
page with a command like
\epigraphhead[30]{\includegraphics[scale=0.5]{kids.eps}}
If I leave off the \ before the includegraphics, it puts out the text
where it should be.
When I put the \ in, I get a latex error. With Chapter, I put the
command after the Chapter, and get a message that \newpage is an
undefined control sequence.
If I put it before a Part, it says that \part is an undefined control
sequence.
I'm following the instructions in Herbert's epigraph.lyx and the
epigraph.pdf file from CTAN.
Most important, Happy Holidays and a Great New Year!
Garst
Re: Hollywood class
"Kayvan A. Sylvan" wrote: > > In the current CVS, when writing a document with the hollywood class, > I am noticing that the author's address (entered in the "Right Address" > paragraph style) is not rendered in the final output. > > Does anyone know what is happening there? > > Garst, if you are reading this, can you check? It happens with the > examples/script_form.lyx as well. > > Thanks! Hi folks, I don't have current CVS up. With 1.3.2 script_form.lyx works fine. Here's the lyx entry with format 221. FOR A FEW DAYS MORE \layout Author \added_space_bottom vfill by \newline April Rider \layout Right Address \pagebreak_bottom April Rider \newline 555 George St. NNW \newline Kaplan, ND 7 \newline 999-999- I'm in the midst of moving, so pressed for time. What is the status of 1.4CVS now? I'll resubsribed after the holidays. Cheers, Garst
lyx.org
Can't view it with Netscape 4.75 any more, but it looks good under Opera. Bye for awhile, Garst
Re: [Patch] Element inset, XML
Lars Gullik Bjønnes wrote: > We called it LCS a long time. > > -- > Lgb LyxCharStyle ? Garst
Re: [Patch] Element inset, XML
Martin Vermeer wrote: > Don't let the perfect be the enemy of the adequate. Who said "The cost of perfection is bankrupty" ? Garst
Re: [Patch] Element inset, XML
Jose' Matos wrote: > 2) UI where it is assumed that the box inside a box model is too difficult > for the normal user to grasp. > Does LyX have any "normal" users ? Garst
Re: [Patch] Element inset, XML
Lars Gullik Bjønnes wrote: > > Perhaps better, perhaps not... in the .layout file this can be used, > but when inserted by the user (in some dialog) I don't want the user > to be required to know what the latex will look like. Noble goal, I must admit that I resort to the LaTeX Companion far less often than I used to :) But still keep it in view. I'm impressed by how much the "clean-up" has speeded up productive developments. It's a good lesson. I lurk because I learn. Garst
Re: ostream v.s. ostream.h
Lars Gullik Bjønnes wrote: > Also first gcc compiler in the 3 series was released June 18. 2001. > that is now almost two years ago... still there are distributions that > use gcc 2.95 in their "stable" setups. > > -- > Lgb And I still run into apps that will only compile with 2.95, which may explain why some dists use it. There's no excuse for 2.96 tho. Garst
1.3.3cvs spellchecker problem
LyX 1.3.3cvs of Tue, May 6 2003 Built on Sep 9 2003, 23:43:50 Configuration Host type: i586-pc-linux-gnu Special build flags:warnings assertions xforms-image-loader C Compiler: gcc C Compiler flags: -O2 C++ Compiler: g++ (3.2) C++ Compiler flags: -O2 -fno-exceptions -W -Wall Linker flags: Frontend: xforms libXpm version: 4.11 libforms version: 1.0.2 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx When I try to spellcheck I get pop-up saying that lyx could not communicate with the spell-checker. Then the spell-checker pop-up appears saying it has checked 5%. Configured --with-aspell. bash$ aspell --version @(#) International Ispell Version 3.1.20 (but really Aspell 0.50.3) Preferences agrees that I am using aspell. It worked earlier with 1.2 something and this is the first time in some years that I have had a problem. Garst
Re: InseetExternal can now preview stuff too
Looks like a good candidate for examples to show how you did that :) Garst Angus Leeming wrote: > > The preview code is starting to show its age and needs a clean-up but > the inset's interface with it is starting to look Ok. > > Attached is a screen shot for any xfig users out there... > > -- > Angus
Re: Configuring the makefile
John Levon wrote: > > On Tue, Oct 21, 2003 at 07:36:57PM +0200, Kostantino wrote: > > > but after the make command I read: > > > > g++: unrecognised option '-03' > > You typed zero-three "-03" instead of oh-three "-O3". See ? > Oh! Good spotting John. I can't believe how stupid IBM was to put the 0 above the O instead of to the left of the 1 where it belongs. Garst
Re: Configuring the makefile
Kostantino wrote: > > Hi. > In the INSTALL file I read: > > --enable-optimization=VALUE enables you to set optimization >to a higher level as the default (-O), for example > --enable-optimization=-O3. > > So I give the following configure command: > > ./configure --with-frontend=qt --enable-optimization=-O3 > > but after the make command I read: > > g++: unrecognised option '-03' > > This behaviour still remains if I give before the command: > > CXXFLAGS='-03' > > for BASH. > > I use Linux-2.4.22 on Slackware 9.1, LyX-1.3.3, gcc (GCC) 3.2.3, > g++ (GCC) 3.2.3 > Any suggestions for me? Perhaps I wrong something? > > best regards > > Costantino Try --enable-optimisation="-O3" I think that is what WFM. Garst
html hyperlinks & TOC
Is there an html converter that will convert the TOC to hyperlinks, preserving navigation? Garst
Re: [bugzilla-daemon@lyx.org: [Bug 1421] Regression: menu items vanish]
Andre Poenitz wrote: > I find this horribly bad UI. A user never gets to know the 'thing is > there' unless he happens to check the menus at the right time. Agree strongly, Garst
Re: reverting to 1.3.3 from 1.4cvs?
Jose' Matos wrote: > If this helps any of you I am working and will commit soon a process where > lyx2lyx is able to downgrade gracefully to the previous stable version. > That will be nice. Thanks. Garst
Re: reverting to 1.3.3 from 1.4cvs?
You're welcome, I gave up on cvs because it cleared my tables when I tried to insert a row, then crashed. Do you not have this problem? Garst Nirmal Govind wrote: > > Thanks Garst... that script works great! I think I'm still going to > stick with cvs, I feel a little more secure knowing that this script can > (hopefully) get me out of trouble if I do run into major problems with > cvs and need to go back to 1.3... > > nirmal >
Re: reverting to 1.3.3 from 1.4cvs?
See the attached, not sure whether Andre or Angus contributed it, but it what I used to solve your problem. Garst Nirmal Govind wrote: > > Hi.. so I need to port a couple of documents back to 1.3.3 from 1.4cvs.. > and looks like 1.3.3 can't read the 1.4cvs doc, not in any decent > manner... is there any way to restore my document so that I can start > editing it in 1.3.3 again? I converted to .tex and then imported it and > that did almost everything.. didn't do the figure/table floats > properly... please let me know if there's a better way.. btw, the > reason I need to go back to 1.3.3 is cos the table editing is broken now > in cvs - can't center the field, undo magically deletes all the entries > in the table etc.. > > Thanks, > nirmal lyx225to221.sh Description: Bourne shell script
Re: The Compleat Box
Jose' Matos wrote: > > On Tuesday 30 September 2003 15:59, Martin Vermeer wrote: > > > > > > BTW I think this should replace the existing minipage, which means > > > > reLyX should be adapted to convert the old docs. > > > > > > That's lyx2lyx business. > > > > Yes, I am behind the times. > > I am sorry but I disagree here, and as me other people. :-) You disagree with? A. BTW B. That's C. Yes ? Garst
Re: building 1.3.4cvs
Juergen Spitzmueller wrote: => A false friend. In german, we have the participle "gesplittet" (which is, of > course, a loanword and means, basically, the same). So I could argue I just > wanted to teach you some german ;-) Lots of luck. My german prof. thanked me for making him laugh so much, and for that did not fail me ;>) Garst
Re: building 1.3.4cvs
Juergen Spitzmueller wrote: > I have splitted I mention this only because I have seen it many times from many people, and it works its way into docs and comments. There is no word splitted. I split it I have split it I will split it We have split the difference That's my kind of verb :) Garst
Re: 1.3.3 announcements
My kids are all big time mac users, so the sooner the better. Garst Jean-Marc Lasgouttes wrote: > > > "John" == John Levon <[EMAIL PROTECTED]> writes: > > John> Has somebody taken care of announcing to the usual places ? > > John> LWN, LinuxToday, apps.kde.com etc. > > The announcement was Bcc'd to [EMAIL PROTECTED] I did not try the others. > > BTW it already transpires that I forgot to add a few macosx-related > files to EXTRA_DIST (talk about compiling out of the box!) and that > qfont_loader.C does not compile (probably missing header) on qt/mac > 3.1.2 (at least). If there are many qt version where this happens, we > may need to release 1.3.4 soon. > > JMarc
Re: 13x NEWS
Angus Leeming wrote: > The complete list of improvements and fixes can be found at the end of > this message. There have been bug fixes to the xforms frontend also, > but most of these have been made to xforms itself. To benefit you must > recompile LyX against xforms 1.0.2 or greater which is currently INSTALL says xforms 1.0 should be used. Is 1.0.2 actually required? Should INSTALL mention 1.0.2? Any idea when 1.0.2 will be released? Garst
Re: Towards LyX 1.3.3 (status update #4)
Jean-Marc Lasgouttes wrote: > > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> and here are a couple of fixes to this announcement, JMarc. > > Thanks a lot. Something caught my eyes in the diff: > -Prebuild binaries (mainly rpms for linux distributions) should soon be > +Prebuild binaries (mainly rpms for linux distributions) should soon be > > Shouldn't this be 'Prebuilt'? Or something else? > > JMarc Yes, its been that way for awhile, and patchws is spelled patches :) I thought the last sentence was a bit awkward. Here's a patch on top of Angus' patch. Garst--- 1_3_3.txt~ Wed Sep 24 08:06:02 2003 +++ 1_3_3.txt Wed Sep 24 08:15:02 2003 @@ -44,12 +44,12 @@ ftp://ftp.icm.edu.pl/vol/rzm0/lyx/stable/lyx-1.3.3.tar.gz -Prebuild binaries (mainly rpms for linux distributions) should soon be +Prebuilt binaries (mainly rpms for linux distributions) should soon be available at ftp://ftp.lyx.org/pub/lyx/bin/1.3.3/ If you already have LyX 1.3.2 sources, you may want to apply one -of the following patchws instead +of the following patches instead ftp://ftp.lyx.org/pub/lyx/stable/patch-1.3.3.gz ftp://ftp.lyx.org/pub/lyx/stable/patch-1.3.3.bz2 @@ -59,8 +59,8 @@ a bug report at http://bugzilla.lyx.org If you're having trouble using the new version of LyX, or have a question, -first check out http://www.lyx.org/help/, and e-mail the LyX users' list -([EMAIL PROTECTED]) if you can't find an answer there. +first check out http://www.lyx.org/help/. If you can't find the answer there, +e-mail the LyX users' list ([EMAIL PROTECTED]). Enjoy!
Re: new menu layout
John Levon wrote: > Existing users are likely to read the announcement Surely you jest, but it's Friday, so I'll forgive you for not adding a smiley. > or have a Garst to tell them. OK when "them" is a very small number. But at one time, my "them" approached 100. Of course, they were split between "Your UI sucks!" , "Why did you change the UI again?", all of the above. Since there is no way to win, forge on. Garst
Re: new menu layout
Lars Gullik Bjønnes wrote: > > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | The problem is different defaults in 1.3 and 1.4 > > That is not a problem. > > Or are you saying that we can never change defaults once we have > chosen one the first time? > > -- > Lgb My 2 pennies default.ui should be a link to one of the available ui's, inititally pointing to a setup wizard ui, which would be something like preferences. I know that before I install 1.4 on A's box, I will explain that there is a new ui available, walk her through it, and ask which she wants. Fortunately, she is my only user. At the very least, the splash screen should boldly announce the new ui and explain how to select the old one. Garst
Re: 1.3.3CVS lyx2lyx
Jean-Marc Lasgouttes wrote: > Thanks for doing this. This is something I could take into 1.3.3, > provided it is well tested. > > JMarc I tried it on several book length files and it worked fine. Converted 2.15 and 2.20 files to 2.21 with acceptable speed. Thanks Angus! Garst
Re: 1.3.3CVS lyx2lyx
Jean-Marc Lasgouttes wrote: > Angus> I think it as simple as this. Compiles but otherwise untested. > > Thanks for doing this. This is something I could take into 1.3.3, > provided it is well tested. > > JMarc Thanks all. I will start testing. Garst
Re: 1.3.3CVS lyx2lyx
Jean-Marc Lasgouttes wrote: > Thanks. Unfortunately, the patch is a bit large for me. Unless > somebody ports and tests it, I will have to politely decline the > invitation ;) > > JMarc Most of it deals with the asserts that use bformat to make the failure msgs more useful. Porting bformat in src/support/lstrings.Ch might make it easier. Garst
Re: 1.3.3CVS lyx2lyx
Jean-Marc Lasgouttes wrote: > You made up the number, didn't you? > > Seriously, I cannot get it. Do you have an URL? > > JMarc http://www.mail-archive.com/[EMAIL PROTECTED]/msg60797.html
Re: [patch] unneeded full rebreak
John Levon wrote: > > On Tue, Sep 16, 2003 at 11:35:01AM +0200, Andre Poenitz wrote: > > > BTW: I've never ever changed between buffers of UserGuide size, so > > even if Lars' worries were justified, it wouldn't matter in my LyX > > usage. > > I suggest you try doing it for a while, on some older hardware ... > > john, who remembers running lyx somewhat successfully on a 33Mhz 486 > Me too :) 1.4cvs is painful on a 233Mhz 96Mb 586. Except for lyx2lyx, 1.3x is way faster. In principle, I think the code clean-up is a *good thing* , but eventually the speed has to return and the other regressions have to be attended to. In the mean time, I think the 225 to 215 script should be part of the 1.3x release. And yes, I frequently change between large (book sized) buffers. Garst
Re: 1.3.3CVS lyx2lyx
Jean-Marc Lasgouttes wrote: > > >>>>> "Garst" == Garst R Reese <[EMAIL PROTECTED]> writes: > > Garst> I have the same problem I had in 1.4CVS. lyx2lyx takes forever > Garst> converting a 220 to 221 file. Lars fixed it in 1.4 by writing a > Garst> tmp file instead of converting in place. Any chance of porting > Garst> that patch to 1.3.x? Thanks, Garst > > I would definitely be OK with me (if such a port is possible) > > JMarc For reference, Lars posted a patch to 1.4 in msg60797 Garst
1.3.3CVS lyx2lyx
I have the same problem I had in 1.4CVS. lyx2lyx takes forever converting a 220 to 221 file. Lars fixed it in 1.4 by writing a tmp file instead of converting in place. Any chance of porting that patch to 1.3.x? Thanks, Garst
Re: And it was all worth it in the end ;-)
Angus Leeming wrote: > Right. The Qt frontend takes forever to build. Fancy writing an fltk frontend > for LyX? FLTK is designed to be small and modular enough to be statically linked - the "hello" program is only 97k when compiled on an x86 Linux system! I love the use "only" here. 97k to say hello? Everything is relative is guess. Garst > And, of course, FLTK is Fast and Light and runs natively under both *nix and > Windows. I don't know if it supports unicode though. >
CRASH 1.4CVS
Create a table with entries, or use existing table. Try to add a row. This clears the table :( Try to close the file, discarding changes. Boom. Garst
Re: for Angus
Angus Leeming wrote: > There should be a new file src/PrinterParams.C in your tree. Do you have it? > Did it compile? (You need to 'configure --enable-maintainer-mode' for the > Makefile to be re-generated from the modified Makefile.am.) > yes, no, ok, fixed, thanks
for Angus
frontends/controllers/.libs/libcontrollers.a(ControlPrint.o): In function `ControlPrint::apply()': ControlPrint.o(.text+0x66a): undefined reference to `PrinterParams::PrinterParams[in-charge](PrinterParams const&)' collect2: ld returned 1 exit status make[3]: *** [lyx-xforms] Error 1
BUG: Add row clears entire table
New in 1.4CVS since July 1, 2003 Go to any row in any filled table, Edit->Table->Add row to clear the table. Not a nice short cut. Garst
Re: oh come on Lars!
Angus Leeming wrote: > Sorry, you miss my point. ChangeLog's provide a browsable record of what was > done at sometime in the past. If you aren't going to fill them in in a > 'useful' manner, then why bother filling them in at all? Ie, that whole > 'you must add a ChangeLog entry' philosophy is pointless if you just pay > lip service to it. > Go Angus! Good ChangeLogs would be a tremendous help in finding the source of regressions. A simple list of files that changed is not much help. WTF does "adjust" mean? Garst
Re: [BUG] cursor out of sync with position in view
Lars Gullik Bjønnes wrote: > > Note that this patch was not intended to fix find, but to fix drawing > (update) issues when moving the cursor off screen. > The drawing update seems to be fixed. The find problem is no worse. Find is just broken. Sometimes it works if I am near the target, sometimes it seems to do nothing, other times it crashes. I think the crashing has already been filed as a bug. Garst
Re: [BUG] cursor out of sync with position in view
Lars Gullik Bjønnes wrote: > > Note that this patch was not intended to fix find, but to fix drawing > (update) issues when moving the cursor off screen. > OK, but it seemed to make find worse. I'll test some more. Garst
Re: [BUG] cursor out of sync with position in view
"Garst R. Reese" wrote: > > Lars Gullik Bjønnes wrote: > > I have a fix for the cursor movement stuff and missing updates. > > > > Please try it out if you have the time: > > > Compiling. > I'll let know. > Garst Didn't work. I would find the word if I was very close, but otherwise did nothing. Repeating the find eventually sigsegved. Garst
Re: [BUG] cursor out of sync with position in view
Lars Gullik Bjønnes wrote: > I have a fix for the cursor movement stuff and missing updates. > > Please try it out if you have the time: > Compiling. I'll let know. Garst
Re: [BUG] cursor out of sync with position in view
Lars Gullik Bjønnes wrote: > > When scrolling down with PgDown, the cursor moves along, but if you > stop and press then the page switches to a completely > different place (probably one page up or down from what was viewed). > > -- > Lgb There's also a position problem with find. The found word is not always in view. Likewise, it can be a page up or down. Garst
Re: [patch] All ps figures the same
"Garst R. Reese" wrote: > > Angus Leeming wrote: > > > Ok, Garst, I committed a refined version. Hopefully, the code is clearer and > > more robust. Moreover, your temp dir should end up with nicely mangled file > > names. Eg: > > > Neat! I'll test. And it still works :>)
Re: [patch] All ps figures the same
Angus Leeming wrote: > Ok, Garst, I committed a refined version. Hopefully, the code is clearer and > more robust. Moreover, your temp dir should end up with nicely mangled file > names. Eg: > Neat! I'll test. Thanks, Garst
Re: [patch] All ps figures the same
Lars Gullik Bjønnes wrote: > > Angus Leeming <[EMAIL PROTECTED]> writes: > > | The attach patch fixes the bug reported this morning by Garst "All ps > | figures the same" (and by others over the last month). It also fixes the > | bug reported by Konni in Chemnitz that repeated viewings of the dvi file > | trigger repeated, and unnecessary, conversions. > > > | Ok to apply? > > of course. > > -- > Lgb Works great! Thanks, Garst
All ps figures the same
I know this was reported some time ago. The lyx view is fine, but the ps view uses the first figure for all the figures. Bug 1313 says it is fixed. Looks like it's back. Is anybody working on this bug? Thanks, Garst
Re: CRASH: upon loading UserGuide.
Lars Gullik Bjønnes wrote:
>
> This is with xforms.
>
> --
> Lgb
I'm not seeing it with Alfredo's patch:
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.424
diff -u -p -u -r1.424 BufferView_pimpl.C
--- BufferView_pimpl.C 28 Aug 2003 07:41:10 - 1.424
+++ BufferView_pimpl.C 1 Sep 2003 20:12:46 -
@@ -656,7 +656,6 @@ void BufferView::Pimpl::update()
if (bv_->getLyXText()) {
// check needed to survive LyX startup
bv_->getLyXText()->redoCursor();
- fitCursor();
}
screen().redraw(*bv_);
}
and your zlib-2.diff applied.
(also with xforms, preview not enabled).
Garst
Re: Why lyx2lyx? why?
Lars Gullik Bjønnes wrote: > Now come to think of it... not unlikely at all. > > Can you try this patch and see if it makes a difference? > Indeed! That fixes the problem! With Alfredo's last test patch things look pretty good. Thanks, Garst
Re: Why lyx2lyx? why?
Lars Gullik Bjønnes wrote: > > Why is lyx2lyx not creating new files, but returning the whole file as > the result of the command? Not exactly nice use of memory... and quite > surprising to me... (just try my zlib patch and see how...) > > I also think this is wrecking havoc with compressed files. > > IMHO lyx2lyx should take one file and create another, and return the > name of the converted file. > Maybe this is the source of my problem running lyx2lyx from lyx. Garst
Re: graphics loading still jumping to top of doc
Alfredo Braunstein wrote: > > Garst R. Reese wrote: > > > It severly impacts scrolling thru a doc. > > Every time a grapic is loaded the cursor jumps to the the top of the > > document. > > Is it the top of the document or the cursor position? Top of document. > Does this solves it? > Yes. Thanks, Garst
Re: Inset::display() ?
John Levon wrote: > > On Mon, Sep 01, 2003 at 03:05:57PM +0100, Angus Leeming wrote: > > > * why "Box::contained" and not "Box::contains" ? Seems odd to use the > > past tense here ;-) > > It's not past tense: yes it is. > > if (box.contained(x, y)) > > if position x,y is contained in box > Then how would say: if position x,y was contained in box ? The relevant statements are: if box contains position x,y if box contained position x,y Garst
Re: graphics loading still jumping to top of doc
Angus Leeming wrote: > Garst, could you expand further? I've just looked at the ChangeLogs My mistake. It was July 21, and that seems too early. G.
graphics loading still jumping to top of doc
If the ChangeLogs are any indication, this probably started with Angus on Aug 21. It severly impacts scrolling thru a doc. Every time a grapic is loaded the cursor jumps to the the top of the document. Garst
Re: lyxerr paintrows:: rit::
Andre Poenitz wrote: > > On Wed, Aug 27, 2003 at 05:44:10PM -0300, Garst R. Reese wrote: > > Is the serving any purpose? > > Well... > The problem is that I get so many of them that I loose msgs that might tell me something, but if you need it... Garst
lyxerr paintrows:: rit::
Is the serving any purpose? Garst
Re: [patch] LyXRow::fill members
Andre Poenitz wrote: > > On Fri, Aug 22, 2003 at 05:52:20AM -0300, Garst R. Reese wrote: > > I think you guys should buy Juergen V's laptop to test with. > > We are trading memory for better code and better runtime. > > Your argument cuts both ways. > Yes, but we need to know what the minimum hardware is to run LyX. Garst
Re: tex2lyx bug and ERT discussion.
Joao Luis Meloni Assirati wrote: > > Hey guys, > > I am back again to bug you. Welcome back! Bug away Luis. ATM things are pretty chaotic, so bugs come and go rapidly ;>) Garst
Re: Inset::display() ?
John Levon wrote: > We already have fun now - try it. The cursor position is broken and > clicking on the row above can activate the inset. > Whatever happened this afternoon improved things, but now everytime a figure is opened the cursor jumps to the top of the document. Keep on pluggin. Garst
Re: fullRebreak and y positions
Andre Poenitz wrote: > At least for the main text we'll probaby need it. > Apart from that, speed is pretty good now, isn't it? > Once I get the file loaded, speed seems fine. Somebody fixed the scrollbar problem. Yeah! Clicking inside a table does not seem perfect. It usually takes two tries to get the cursor at the right position, but that's not new. I still cannot run lyx2lyx from lyx without long waits :( I think there is a race condition on memory allocation. Things are definitely looking up. Thanks, Garst
dont like ...
This from today's CVS with the remaining lyxerr in rowpainter.C commented out. Garst dont like 1, pos: 1936269362 size: 2 BufferView::update() BufferView::update() BufferView::update() dont like 1, pos: 523 size: 21 BufferView::update() dont like 1, pos: 103 size: 1 BufferView::update() BufferView::update() dont like 1, pos: 1634213996 size: 1 BufferView::update() BufferView::update() BufferView::update() BufferView::update() BufferView::update() BufferView::update() BufferView::update() dont like 3 please report BufferView::update() dont like 3 please report BufferView::update() BufferView::update() BufferView::update() BufferView::update() BufferView::update() BufferView::update() BufferView::update() dont like 1, pos: 494 size: 335 BufferView::update() BufferView::update() BufferView::update() dont like 1, pos: 1869881447 size: 368 BufferView::update() BufferView::update() BufferView::update() BufferView::update() BufferView::update() dont like 1, pos: 206 size: 15 BufferView::update() BufferView::update() BufferView::update() BufferView::update() BufferView::update() BufferView::update() InsetText::lockInsetInInset: 1 a InsetText::lockInsetInInset: 1 b bv: 0x84032d0 inset: 0x860d9d0 InsetText::lockInsetInInset: 1 c
Re: [patch] LyXRow::fill members
Andre Poenitz wrote: > > And that's the patch. > > It's just 16 bytes per row extra, so it should not hurt badly. > I think you guys should buy Juergen V's laptop to test with. Garst
Re: compiling lyx?
Angus Leeming wrote: > > Attached is a little wrapper script that I use. Use it so: > $ ./configure-14x $LYX_DIR xforms qt > Might he also need --with-included-boost ? Garst
Re: [Patch] small Note cleanup
Juergen Spitzmueller wrote: > > Lars Gullik Bjønnes wrote: > > | Sorry, not enough memory to build. :-( > > > > Even if you turn "-g" off? > > I have not tried it, but this is an old toshiba pentium 100 with 16MB RAM and > 100MB disk space. I am happy enough that I can run enlightenment and lyx at > all (which, surprisingly, works rather well). > > Juergen. Amazing! Which version of LyX? Anyway, don't mess with it. Thanks, Garst
Re: [Patch] small Note cleanup
Juergen Spitzmueller wrote: > Would that make sense (i.e. shipping code with two near identical frontends)? > I mean, do you want to include every frontend for which you have volunteers? > As fltk is, as I understand it, more or less an improved xforms, I would not > mind if fltk played the Darwin game with xforms (though xforms works well > enough where I need it , i.e. on slow machines like my old notebook). Have you, or could you, try current cvs on your old notebook loading an old version of UG? It is virtually impossible on mine. Garst
Re: strace on lyx2lyx
Stephan Witt wrote: > Hi Garst, > > brk() in strace context is a system call normally used to get memory for > the dynamic storage allocators like malloc/calloc (C) or new (C++) library > calls. Excessive brk() calls are indicating great memory usage or an memory > leak. Machines with small memory chips are forced to start swapping which is > of course really slow as it accesses the hard disc. Thanks Stephan, I am neither seeing nor hearing and disk activity during the delays. But maybe this will be a clue to others. Garst
Re: strace on lyx2lyx
Andre Poenitz wrote: > No clue. > Today's build made it worse! This points to rowpainter. Please let me know if I can do anything further to help. I think this is going to bite hard when others, like myself, with slow machines start testing. Garst 21:22:29.110661 brk(0x8511000) = 0x8511000 21:22:37.812238 brk(0x851a000) = 0x851a000 21:22:46.140028 --- SIGCHLD (Child exited) --- 21:22:53.905027 brk(0x8526000) = 0x8526000 21:22:53.920342 brk(0x8504000) = 0x8504000
Re: strace on lyx2lyx
Jose' Matos wrote: > > On Friday 15 August 2003 21:42, Garst R. Reese wrote: > > Here is where it seems go get stuck: > > > > mmap2(NULL, 212992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > > 0) = 0x4054 > > Any expert to tell me where to start searching? > > > Zillions of these coming too fast to read. > > > > Garst > > -- > José Abílio > > LyX and docbook, a perfect match. :-) I also get zillions of these: 22:43:51.183458 brk(0x85dd000) = 0x85dd000 22:43:51.200730 brk(0x85df000) = 0x85df000 22:43:51.218437 brk(0x85e1000) = 0x85e1000 22:43:51.227363 brk(0x85e3000) = 0x85e3000 22:43:51.236807 brk(0x85eb000) = 0x85eb000 22:43:51.247569 brk(0x85ed000) = 0x85ed000 22:43:51.258827 brk(0x85ef000) = 0x85ef000 22:43:51.269891 brk(0x85f1000) = 0x85f1000 22:43:51.284264 brk(0x85f3000) = 0x85f3000 22:43:51.303427 brk(0x85f5000) = 0x85f5000 22:43:51.492823 brk(0x85f7000) = 0x85f7000 22:43:51.503154 brk(0x85f9000) = 0x85f9000 22:43:51.514059 brk(0x85fb000) = 0x85fb000 22:43:51.526571 brk(0x85fd000) = 0x85fd000 22:43:51.539239 brk(0x85ff000) = 0x85ff000 22:43:51.556522 brk(0x8601000) = 0x8601000 22:43:51.566912 brk(0x8603000) = 0x8603000 22:43:51.576790 brk(0x8605000) = 0x8605000 22:43:51.586605 brk(0x8607000) = 0x8607000 22:43:51.597654 brk(0x8609000) = 0x8609000 22:43:51.608912 brk(0x860b000) = 0x860b000 22:43:51.621999 brk(0x8613000) = 0x8613000 22:43:51.638342 brk(0x8615000) = 0x8615000 22:43:51.833128 brk(0x8616000) = 0x8616000 22:43:51.843373 brk(0x8617000) = 0x8617000 22:43:51.854500 brk(0x8618000) = 0x8618000 22:43:51.865726 brk(0x8619000) = 0x8619000 22:43:52.088166 munmap(0x4054, 245760) = 0 22:43:52.098032 munmap(0x4057c000, 245760) = 0 22:43:52.108596 munmap(0x400fa000, 4096) = 0 Setting buffer in BufferView (0x84fd900) Buffer addr: 0x84fd900 resizeCurrentBuffer text not available! no text in cache! 22:43:53.340236 brk(0x861a000) = 0x861a000 22:43:53.377424 brk(0x8623000) = 0x8623000 22:43:55.056815 brk(0x862c000) = 0x862c000 22:43:56.588383 brk(0x862d000) = 0x862d000 22:43:56.713239 brk(0x862e000) = 0x862e000 22:43:56.826188 brk(0x862f000) = 0x862f000 BufferView::update() man brk is interesting. brk not defined in C standard, and deliberately excluded from Posix.1 standard. Garst
Re: lyx2lyx & mmap munmap
José Abílio Oliveira Matos wrote: > > On Sat, Aug 16, 2003 at 02:21:51PM -0300, Garst R. Reese wrote: > > Hello José Abílio Oliveira Matos > > this should be some kind of copy & paste, José is my first name so unless > there are too many José's on this list you can treat me as José. :-) I was in the mood for some poetry :) > Now, this is really weird. Could it be the way as lyx2lyx is called from > lyx? I think it because I am running on a slow (233Mhz) box. A smaller file with one table also had the problem until the most recent speed ups. Thanks, Garst
lyx2lyx & mmap munmap
Hello José Abílio Oliveira Matos Do you have any ideas why running lyx2lyx from lyx gives me zillions of mmap2 munmaps to the same address (strace) with lyx1.4cvs ? There appears to be some race condition that only shows up with large files containing lots of tables. I can run lyx2lyx separately with no problems. Thanks, Garst
strace on lyx2lyx
Here is where it seems go get stuck: mmap2(NULL, 212992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4054 munmap(0x40574000, 212992) = 0 mmap2(NULL, 212992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40574000 munmap(0x4054, 212992) = 0 mmap2(NULL, 212992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4054 munmap(0x40574000, 212992) = 0 mmap2(NULL, 212992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40574000 munmap(0x4054, 212992) = 0 mmap2(NULL, 212992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4054 munmap(0x40574000, 212992) = 0 mmap2(NULL, 212992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40574000 munmap(0x4054, 212992) = 0 Zillions of these coming too fast to read. Garst
Re: [patch] row list split
"Garst R. Reese" wrote: > > Andre Poenitz wrote: > > > What's the performance status ? > > > > Performance is really good and I haven't had a crash today... > Relative to July 1, it still sucks(1). Your machine is too fast. > > Garst > > (1) Still Unusable 'Cause Keyboard is Slow. OK, with today's build, after the ' patch, I can insert characters, but the scrollbar does not work for navigation through the doc. Don't know how long that has been true. Page Down works. Garst again
Re: [patch] row list split
Andre Poenitz wrote: > > What's the performance status ? > > Performance is really good and I haven't had a crash today... Relative to July 1, it still sucks(1). Your machine is too fast. Garst (1) Still Unusable 'Cause Keyboard is Slow.
Re: UI tuning
Lars Gullik Bjønnes wrote: > > And what if he is indeed scared off? Why should we have frontend that > no-one is willing to support? > > -- > Lgb Maybe if there was an almost working port there would be more people interested in fixing and maintaining it. As things now stand you (collective) have been pretty effective at stifling all attempts to get a gtk/gnome port working, or even started. It is fairly obvious that the first cut will be both large and imperfect and will probably not be as pretty as the hardcore devs like. Garst -- The cost of perfection is bankruptcy.
Re: lyx-devel src/: BufferView_pimpl.C BufferView_pimpl.h Chan ...
John Levon wrote: > (I have had three hours sleep only due to gas leak in my house ...) Glad to hear it wasn't an infinite sleep. Garst
Re: UG + other slowness
Andre Poenitz wrote: > You could try'CXXFLAGS=-pg configure --disable-debug... ' to include > profile, but no debug information. This links much faster than the > debug-enabled version and should shoul the bottleneck nevertheless. OK, I did that. gprof said lyx took 9.81s, but it took 27 minutes for my large file to display! Thanks, Garst
Re: UG + other slowness
"Garst R. Reese" wrote: > > Could you try to run lyx2lyx manually on UserGuide.lyx to create a > > UserGuide.lyx in the latest format and load this? > > I've already tried that. No help. > Thanks, > Garst Looks like I was wrong. Running lyx2lyx on my large file made it come up quickly. Manual lyx2lyx took about 7s. My guess is that there is a race somewhere. Hopefully it will go away as the cleanup continues. Garst
Re: UG + other slowness
Andre Poenitz wrote: > > On Sun, Aug 10, 2003 at 06:18:07PM -0300, Garst R. Reese wrote: > > "Garst R. Reese" wrote: > > > > > > Andre Poenitz wrote: > Don't know either. > > Could you try to run lyx2lyx manually on UserGuide.lyx to create a > UserGuide.lyx in the latest format and load this? I've already tried that. No help. Thanks, Garst
Re: UG + other slowness
"Garst R. Reese" wrote: > > Andre Poenitz wrote: > > > You could try'CXXFLAGS=-pg configure --disable-debug... ' to include > > profile, but no debug information. This links much faster than the > > debug-enabled version and should shoul the bottleneck nevertheless. > > OK, I did that. gprof said lyx took 9.81s, but it took 27 minutes for my > large file to display! > > Thanks, > Garst More info: top shows lyx running, the lyx & python, then lyx, then lyx & python ... Could a timeout be causing lyx2lyx to run repeatedly ? G.
Re: export discussion
Alfredo Braunstein wrote: > > Jean-Marc Lasgouttes wrote: > > But of course we do not really know what script languages we are going > > to choose... TeXmacs and Siag use Guile/Scheme. Garst
Re: UG + other slowness
Andre Poenitz wrote: > Not much I suppose. :) OK, Thanks
Re: UG + other slowness
Andre Poenitz wrote: > But try recent CVS first. Maybe Sunday noon Greenwich time... > Thanks Andre' I just finished compiling -D "2003-07-27 18:00" I suppose that is 22:00 GMT if the 18:00 is my local time. Loading time is now OK, typing is very slow. Would backing up to noon GMT help that? Garst
Re: UG + other slowness
Lars Gullik Bjønnes wrote: > > No, only the -dbg any switch Comment read: `#LyX 1.4 created this file. For more info see http://www.lyx.org/' Running '/usr/local/share/lyx/lyx2lyx/lyx2lyx -t225 '/home/garst/eagle/NLM-ECG/LYX/NLM-ECG.lyx'' This where it hangs, lyx2lyx -t225 ... > outfile.lyx from a terminal, it works fine, completes in 5s or so. bash$ time /usr/local/share/lyx/lyx2lyx/lyx2lyx -t225 /home/garst/eagle/NLM-ECG/LYX/NLM-ECG.lyx > ~/tmp/NLM-ECG3.lyx This is with a new build after rm -rf'ing and recreating my build directory, autogen.sh, cd build, configure as before, make , make install. Truly strange. Thanks, Garst
Re: UG + other slowness
Jose' Matos wrote: > > And how much time does it takes to load this new file. I know that this > question looks crazy, but I have a reason. I killed it at 35minutes I suppose that answers your question :) > > No problem there. I'll try Asger's Sunday cvs. What is a safe Sunday > > time for cvs -D? > > Thanks, > > Garst >
